Web Service: ERP API

OBJETIVO

Integrar os sistemas Seidor e Ti9, referente aos registros de Clientes, Produtos e Pedidos de Vendas.

PRÉ-REQUISITOS

Vide Interface de Programação de Aplicativos (API) para integração ao ERP Ti9: Layout de Integração Ti9 v2.8.pdf

Vide manual da API para toda a especificação técnica: ERP-58899 - Interface de Programação de Aplicativos (API) para integração ao ERP Ti9 - V2.3.pdf

UTILIZAÇÃO

Através dos endpoints disponibilizados, as informações pode ser trocadas com o sistema Ti9 usando os métodos HTTP: POST e GET.

O método POST deve ser usado tanto para a inclusão dos registros quanto para a atualização destes. A API recepcionará o JSON enviado via POST. Todos os dados serão validados e caso estejam coerentes, o registro será salvo.

Para os Produtos:

• Caso um POST seja realizado em um registro já existente, o mesmo será atualizado com todos os dados do JSON.

Para os Clientes:

• Na criação de novo cliente, a resposta do servidor será: 201 - Created, seguida da mensagem que identifica, através de um número, o registro do cliente criado: "Requisição executada com sucesso. Código Pessoa: 007777", onde "007777" é o código do cliente atribuído pelo Ti9.
  
• Caso um POST seja realizado em um registro já existente, o mesmo será atualizado com os dados do JSON (exceto o campo "codigo_servico", pois este campo nunca é atualizado e é considerado apenas na inclusão de novo cliente).
  A API reconhece o cliente através do CNPJ.
  

Para os Pedidos de Vendas:

• Para inserções de pedidos via B2C o campo "ped_cliente" do layout deve ser enviado com o número do pedido Seidor. Este dado é muito importante para a identificação do pedido quando da atualização deste via B2C. Vide abaixo.
• Para atualizações de pedidos via B2B, os campos "filial" e "pedido_fil" do layout devem ser enviados com a filial e número do pedido. Tais campos podem ser encontrados ao abrir-se o pedido na tela "Vendas/Outras Saídas" no ERP-Ti9. Estes dados são muito importantes para a identificação do pedido quando da atualização deste via B2B. Vide abaixo.
• Quando da inserção do pedido de vendas, após validação, todos os dados serão salvos. A resposta do servidor será: 201 - Created, seguida da mensagem que identifica, através de um número, o pedido de vendas criado: “Pedido de vendas adicionado com sucesso! Número (Ti9): 0099999”, onde "0099999" é o número que o Ti9 atribuiu ao pedido criado.
• A partir deste momento, o pedido de vendas fica aguardando a atualização por parte dos sistemas Seidor, das informações de Peso Líquido, Peso Bruto e Volume do Pedido, bem como o Lote dos itens.
  
  
•  Importante: Devido ao fato de todo o cálculo de peso bruto, líquido e volume serem feitos em outros sistemas, o Ti9 espera receber estas informações. Portanto, estas devem ser recebidas no cabeçalho do JSON como total, isto é, a soma dos pesos e volumes de todos os itens.
  
  
• O Ti9 então identifica este pedido com o status "W_UP_FROM_SEIDOR" e bloqueia qualquer tentativa de avanço no fluxo deste pedido de vendas, conforme ilustram as figuras 01 e 02:

Figura 01 - Relação dos pedidos. Aqui notamos quatro pedidos que estão com a situação de aguardo de atualizações.

Figura 02 - Pedido de vendas com fluxo bloqueado por ainda estar aguardando as atualizações de Peso Líquido, Bruto e Volume.

• Para contextos B2C, quando o sistema Seidor desejar enviar estas atualizações para o Ti9 ele deve realizar um novo POST, com o JSON completo do pedido de vendas. A API identificará o pedido de vendas através do campo "ped_cliente", conforme já citado.
• Para contextos B2B, para que a Seidor atualize os dados dados do pedido no Ti9 deve-se realizar um novo POST com o JSON específico para inserções de pedidos B2C. A API identificará o pedido de vendas através dos campos "filial" e "pedido_fil".
• A partir de então, serão considerados os dados de Pesos Bruto, Líquido e Volume do Pedido e o Lote dos Itens recepcionados no JSON. Os dados serão validados e estes serão atualizados no registro do pedido de vendas.
  
  
  
•  Importante: Para o funcionamento desta integração todos os pedidos devem passar pela etapa de expedição. Desta forma, caso a a necessidade da liberação de expedição do pedido for retirada o operador encontrará o seguinte erro ao tentar prosseguir com o pedido no Fluxo de Aprovações:

Figura 03 - Restrição de avanço no Fluxo de Aprovações.

• Caso esta mensagem for exibida o operador deve ligar a necessidade de liberação de expedição para pedidos. Isto pode ser feito acessando-se o submenu "Parâmetros Gerais" da tela "Parâmetros do Faturamento".
  

Figura 04 - Parametrização da exigência de liberação de expedição

• A partir daí, o pedido está liberado para seguir o fluxo.

GET do status do Pedido de Vendas:

• A API também disponibiliza três GETs para que o sistema Seidor receba a situação deste pedido de vendas; isto é, em qual etapa do fluxo Ti9 ele se encontra. O primeiro destes GETs trata do contexto B2C, retornando um pedido a partir do campo "ped_cliente". O segundo e o terceiro tratam do contexto B2B, sendo que o segundo retornará um pedido a partir dos campos "filial" e "pedido_fil" e o terceiro retornará uma lista de pedidos com Status "NOVO" e "PENDENTE", ou seja, pedidos que não foram expedidos e estejam válidos (i.e., não encerrados nem bloqueados).
  Cada uma destas requisições GET retornará a mesma estrutura de dados, exemplificada abaixo.
  
  
•  Importante: Os status descritos abaixo seguem um padrão usado pelo cliente. Sua equivalência no fluxo de aprovação do ERP-Ti9 pode ser vista abaixo:

Figura 05 - Relação Status Ti9 x Cliente

•  Importante: Para o GET da lista de Pedidos B2B, deve-se primeiramente parametrizar quais códigos de operação serão usados como filtro dos pedidos a serem retornados. Para tal, deve-se editar o campo "Código Operação API", encontrado no submenu "Parâmetros Gerais" da tela "Parâmetros do Faturamento".
  
  
  

  Figura 06 - Parametrização dos Códigos de Operação da API.

  
  
  
  
  
  PENDENTE: o pedido de vendas se encontra na etapa "Pedido" do fluxo do Ti9. Pode ou não já ter recebido as atualizações por parte da Seidor. O pedido pode ser atualizado por parte da Seidor quantas vezes for necessário se ainda estiver nesta etapa.
  
  

Figura 07 - Get do status Etapa Pendente.


Figura 08 - Post da atualização Etapa Pendente.


APROVADO: o pedido de vendas já foi atualizado com as informações por parte da Seidor e o usuário já o avançou no fluxo do Ti9. As atualizações neste pedido por parte da Seidor não são mais aceitas, onde qualquer tentativa retornará mensagem de crítica por parte da API.


Figura 09 - Get do status Aprovado.


Figura 10 -Post de tentativa de atualização.


FATURADO: o pedido já foi faturado no Ti9. Pode ou não já ter sua nota transmitida (NFe) para a SEFAZ. Caso já tenha sido transmitida com sucesso, o retorno também contemplará o número e série da NF, bem como o DANFE em formato Base64.


Figura 11 - Get do status. Pedido já faturado e NFe devidamente transmitida para a SEFAZ. Veja que o DANFE está contido no JSON, em formato Base64.

TAG de Serviço do Transportador

• Importante: Inserção de Etiquetas para parametrização de TAG de Serviço do Transportador
  Para que o código de serviço do correios seja disponibilizado no endpoint Get Pedido de Vendas, deve-se cadastrá-lo na tela "Campo do EDI e Etiquetas" de acordo com as instruções abaixo:
  
  
  1.Cadastro do Grupo “CORREIOS”
  
  2.Cadastro da variável "CÓDIGO SERVIÇO"
  
  3.Grupo "CORREIOS" inserido no cadastro do cliente 
  
  
  4.Variável do Serviço inserido no Cadastro do Cliente
  
  
  5.  Sobre a qual parte do Fluxo de Aprovações do Pedido de Vendas acionaria a disponibilização de tal campo para a OT, foi concordado que seria a etapa Expedição.
  
  
  Cabe aqui ressaltar que o Faturista poderá mudar o valor do campo "CÓDIGO SERVIÇO" na tela acima a qualquer momento antes da etapa Expedição. Caso a etapa de Expedição já tenha sido alcançada, deve-se voltar o pedido para uma etapa anterior de modo a realizar esta alteração. 
  
  

GET do Produto

• A API disponibiliza um GET para que o sistema Seidor receba dados de produtos. 

  Para tal, deve-se primeiro parametrizar os grupos de estoque que serão usados para filtrar o retorno de tais produtos.
  A parametrização deve ser feita no ERP Ti9 através do módulo "Estoque", tela "Parâmetros de Estoque", menu "Integração".

  

   

  Após concluída a parametrização, o GET retornará todos os produtos ativos a partir da data informada no endpoint

  

GET da view v_wel_ipi_produto

Para a consulta da relação de dados da view "v_wel_ipi_produto" a API fornece dois endpoints: um para a consulta de todos as linhas da view e outro para consulta de algum produto específico (onde deve ser fornecido o código do produto no endpoint).

Quando o GET é feito sem especificar o produto, todos da view serão retornados:

Quando o código do produto for informado ao final da URL, serão retornadas as informações do produto em questão: