Histórico da Página

Atualização na API do TOTVS FOOD - Novas Regras de Busca de Vendas

Com a mais recente atualização na API do TOTVS FOOD, foram implementadas novas regras na busca de vendas para aprimorar a eficiência e a confiabilidade do sistema.
Por favor, atente-se às seguintes diretrizes para o processo de venda no campo de Configuração :

1. Intervalo de Tempo para Busca de Vendas:

   • As buscas de vendas devem ser realizadas em intervalos regulares de 30 minutos default, configurado na Tag: tempBuscaVenda.
   • Reprocessamentos de vendas com erro podem ocorrer entre 00:00 e 06:00, com a possibilidade de intervalos menores, configurados nas Tags: horaReproceInicio e horaReproceFinal.

2. Busca de Vendas por Loja:

   • Cada busca de venda por loja deve respeitar um intervalo de 15 segundos antes de iniciar uma nova busca para outra loja.

Para obter informações detalhadas sobre essas atualizações e garantir a integração eficaz com a API, consulte a documentação fornecida pela equipe do TOTVS FOOD: API - Capa Venda

IMPORTANTE: Para que não ocorra bloqueios por consumo indevido, as chamadas na API devem ter intervalos mínimos de 30 minutos entre cada chamada e o período de d - 7 máximo. Caso seja recorrente o consumo da base histórica, poderá acarretar em consumo indevido e bloqueio do uso da API. Isto ocorrendo é necessário realizar a abertura de uma chamado para o time TOTVS FOOD.

{
    "url":"http://{url_do_servidor}/api/CapaVenda/ListPorDataMovimento",
    "SL2":"self:oRegistro['Itens']

{
    "CodigoLoja":"&self:aArrayFil[self:nFil][1]",
    "DataMovimentoInicial":"&Str( Year(dDatabase), 4) +'-'+  StrZero( Month(dDatabase), 2) +'-'+ StrZero( Day(dDatabase), 2)",
    "DataMovimentoFinalSL4":"&Str( Year(dDatabase), 4) +'-'+  StrZero( Month(dDatabase), 2) +'-'+ StrZero( Day(dDatabase), 2)"
}

• As tags L1_FILIAL, L2_FILIAL e L4_FILIAL são preenchidas pelo Protheus, então devem ficar com o conteúdo vazio.

Foi disponibilizada a rotina com a nova regra para consumo da API capaVenda, agora só será permitida a integração com intervalos de no mínimo 30 minutos.

Caso a integração seja executada antes deste período será apresentada a mensagem:

• • 20/12/23 15:46:48  - [VENDA] Busca não será executada, intervalo de tempo mínimo(00:30:00) não foi atingido. Intervalo atual: 00:01:25

Para o caso de reprocessamento, caso seja executada antes do periodo será apresentada a mensagem:

• • 20/12/23 15:46:49 RMIREPROCESSA - Reprocessamento da integracao com o FOOD nao executado, pois esta fora do horario permitido: 00:00 as 06:00

Para Reprocessar vendas com erro é necessário incluir tags de controle no layout de envio:

• DataReprocessamento: Data de controle para inicialização do mecanismo de reprocessamento. Essa dava deve ser preenchida com um dia antes da data atual da maquina onde o serviço RMIBUSCA esta configurado.
• UltimodiaReprocessado: Data de controle para saber qual foi o ultimo dia reprocessado automaticamente pelo sistema.
• DiasRetroceder: dias definido pelo usuário para controle da DataReprocessamento. 

Exemplo:

    "DataReprocessamento": "20230515",

    "UltimodiaReprocessado": "20230515",   

    "DiasRetroceder": 10

Como será inicializado o reprocessamento?

O serviço RMIBUSCA verifica se a data da maquina onde se encontra o mesmo é maior que a data contida na tag DataReprocessamento. Caso seja será inicializado o reprocessamento seguindo as considerações abaixo:

A data inicial do reprocessamento será realizada através do calculo:

UltimodiaReprocessado - DiasRetroceder = 05/05/2023

Com isso o reprocessamento se busca as vendas do dia 05/10/2023 até o dia 14/05/2023.

As tags DataReprocessamento e UltimodiaReprocessado são atualizadas após cada execução com isso não será mais necessário realizar essa alteração manualmente.

Neste cenário começará a partir de 05/05/23 e terminará na data atual;

Com isso o Layout de Envio deve estar com essa estrutura.

{
    "CodigoLoja": "&self:aArrayFil[self:nFil][1]",
    "notasinutilizadas": 1,
    "DataMovimentoInicial": "&Str( Year(dDatabase), 4) +'-'+  StrZero( Month(dDatabase), 2) +'-'+ StrZero( Day(dDatabase), 2)",
    "DataMovimentoFinal": "&Str( Year(dDatabase), 4) +'-'+  StrZero( Month(dDatabase), 2) +'-'+ StrZero( Day(dDatabase), 2)",

    "DataReprocessamento": "20230515",

    "UltimodiaReprocessado": "20230515",   

    "DiasRetroceder": 10
}

Para mais informações referente à campos na API do FOOD acesse: API - FOOD CAPA VENDA.

TipoFormaPagamento = 3 é para identificar as formas de pagamento do tipo cartão.

Após ter realizado as configurações acima a integração da VENDA seguirá o seguinte fluxo:

Serviço RMIBUSCA: Neste serviço o Protheus irá realizar a busca das vendas no sistema Totvs Chef, e grava-las na tabela MHQ - Mensagens Publicadas.  

Serviço RMIDISTRIB: Após as mensagens serem publicadas na tabela MHQ, o serviço RMIDISTRIB se encarregará de distribuir as vendas para seus assinantes, neste caso as mensagens serão distribuídas para o assinante Protheus, neste processo será gravado as distribuições na tabela MHR - Mensagens Distribuição  

Serviço RMIENVIA: Com as mensagens distribuídas para o assinante Protheus o serviço RMIENVIA é responsável por gerar a venda de cada mensagem distribuída. Neste momento é gravado as tabelas SL1, SL2 e SL4(Tabelas responsáveis pela venda) e caso a venda seja gerada com sucesso será gravado o numero da mesma no campo MHR_RETORN. Caso o seja encontrado algum erro no momento da geração da venda no Protheus, no campo MHR_ENVIO é gravado os dados que foram passados para gerar a venda e no campo MHR_RETORN é gravado o motivo da inconsistência na geração da venda.

Serviço RMICONTROL: Com as vendas geradas nas tabelas SL1, SL2 e SL4,  o campo L1_SITUA deve estar com o conteúdo IP (Integração Pendente), para que o serviço RMICONTROL realize as validações da venda. Caso seja encontrado alguma inconsistência na venda o campo L1_SITUA sera atualizado para IR (Integração com erro) e será gravado um log do motivo desta inconsistência na tabela MHL - Logs de Integração. Caso a venda seja validada com sucesso o campo L1_SITUA é atualizado para RX (Recebido pelo Server).

Serviço do GravaBacth:  Para as vendas que estejam campo L1_SITUA = RX, este serviço tem como objetivo: Gerar financeiro, Baixa de estoque, Livros fiscais etc. Caso seja encontrado alguma inconsistência no processamento deste serviço o campo L1_SITUA é atualizado para ER. Caso o processamento da venda seja finalizado com sucesso o campo L1_SITUA é atualizado para OK.

O Cancelamento de Venda seguirá o seguinte fluxo:

Serviço RMIBUSCA: Neste serviço é realizado a busca das vendas no Totvs Chef, o serviço identifica se a tag StatusVenda (Api Capa venda) é igual a 2, Caso seja significa que se trata de um cancelamento, com isso é gravado um registro na tabela MHQ - Mensagens Publicadas com o campo MHQ_EVENTO = 2 (Exclusão).

Serviço RMIDISTRIB: Após a Publicação do cancelamento o serviço RMIDISTRIB se encarregará de distribuir o cancelamento da venda  para o assinante Protheus, gerando um registro na tabela MHR - Mensagens Distribuição.

Serviço RMIENVIA: Realizado a distribuição, o serviço RMIENVIA inclui as informações do cancelamento da venda na tabela SLX - Log Cancelamento x Devolução.

Serviço RMICONTROL: Com as informações do cancelamento inseridos na tabela SLX - Log Cancelamento x Devolução este serviço realiza a leitura das informações e em seguida é executado a rotina padrão de cancelamento LOJA140, com isso realizando o cancelamento da venda no Protheus.

A Devolução não esta implementada nesta integração, caso tenha alguma devolução no sistema Totvs Chef, a devolução devera ser realizada manualmente no Protheus. Não existe integração de venda com NCC.

Os valores de desconto nos totalizadores da venda devem vir rateados nos itens.

"TotalizadorVenda": {
  "ValorTotalDescontoFiscal": 0.01,
  "ValorTotalDescontoSistema": 0.01,

"Produto": {
                "Codigo": 5,
                "Nome": "PRODUTO TESTE",
            },
            "Quantidade": 1,
            "ValorUnitario": 1,
            "ValorDesconto": 0.01,

O Cancelamento de Venda seguirá o seguinte fluxo:

Serviço RMIBUSCA: Neste serviço é realizado a busca das vendas no Totvs Chef, o serviço identifica se a tag StatusVenda (Api Capa venda) é igual a 3, Caso seja significa que se trata de um cancelamento, com isso é gravado um registro na tabela MHQ - Mensagens Publicadas com o campo MHQ_EVENTO = 3 (Exclusão).

Serviço RMIDISTRIB: Após a Publicação do cancelamento o serviço RMIDISTRIB se encarregará de distribuir o cancelamento da venda  para o assinante Protheus, gerando um registro na tabela MHR - Mensagens Distribuição.

Serviço RMIENVIA: Realizado a distribuição, o serviço RMIENVIA inclui as informações do cancelamento da venda na tabela SLX - Log Cancelamento x Devolução.

Serviço RMICONTROL: Com as informações do cancelamento inseridos na tabela SLX - Log Cancelamento x Devolução este serviço realiza a leitura das informações e em seguida é executado a rotina padrão de cancelamento LOJA140, com isso realizando o cancelamento da venda no Protheus.

A Devolução não esta implementada nesta integração, caso tenha alguma devolução no sistema Totvs Chef, a devolução devera ser realizada manualmente no Protheus.