1

RMOURA

INTEGRAÇÃO WMS x ERP (WinThor)

Este documento é confidencial e não pode ser compartilhado.

 2

1. Introdução

A RMoura, é uma empresa especializada em importação e distribuição no atacado

de produtos alimentícios (https://www.rmouracereais.com.br/) e adquiriu em
Setembro/23 o WMS Locus da KMM (https://kmm.com.br), para gestão de carga do
armazém.

Este documento, descreve como será o processo de integração (troca de

informações) entre o WMS Locus e o ERP Totvs (WinThor).

Foi realizada uma reunião inicial de alinhamento entre RMoura, Totvs e KMM para
tratar fluxos desta integração, onde a KMM ficou de retornar com fluxograma e
detalhes técnicos dessa integração.

Esse documento é um complemento da documentação que detalha os Endpoits

de recebimento e cancelamento de Notas bem como seus atributos, presente no
documento “OpenWMS_EDI_v6.1”, disponibilizado anteriormente.

2. Definições
Na reunião citada anteriormente, algumas definições sobre o projeto foram
acordadas:
2.1 – O Locus WMS irá realizar gestão de cargas no armazém localizado em
Brás-SP, portanto somente notas fiscais para armazenagem serão
movimentadas no WMS.
2.2 – Ficou acordado que essa integração inicial irá contemplar os seguintes
fluxos: recebimento, endereçamento, movimentação (apenas de produto
avariado) e separação/expedição, nos quais serão detalhados abaixo.
2.3 – O Fluxo de envio e recebimento de informações entre WMS e ERP
(WinThor ) ficou da seguinte forma:
2.2.1 - Notas de Entrada: A RMoura irá enviar para o WMS o XML (padrão
DANFE) das NFs de Entrada, ou seja, mercadoria própria (fornecedores da
RMoura) que serão recebidas pela equipe do armazém.

Este documento é confidencial e não pode ser compartilhado.

 3

Fig.1: Fluxo de envio das Notas Fiscais de Entrada (xml) para o WMS

Conforme alinhamento com Romulo (WinThor) segue abaixo alguns exemplos de xmls
referente ao método de recebimento bem como os eventos que iremos enviar nesse
fluxo de Entrada.

Como detalhado no documento “OpenWMS_EDI_v6.1” Rmoura irá nos enviar via

EDI as NFs para armazenagem através do método receiveDocument.
Exemplo de requisição Entrada ‘EN’:

Abaixo segue exemplos de xmls dos eventos que iremos enviar após finalização
de algumas etapas. E importante ressaltar que nessa etapa precisamos que a
RMoura/ERP nos informe seus Endpoits, bem como os métodos e eventos para
envio dos retornos presentes nesse documento.

Recebimento: após recebimento dos itens pelo operador, via coletor de dados, o
WMS irá disparar para ERP (WinThor) uma confirmação desse recebimento
concluído, enviando os itens (Skus), quantidades e data/hora.

Este documento é confidencial e não pode ser compartilhado.

4

As tags acima correspondem respectivamente:

<item>: tag onde irá conter a relação dos skus, bem como as tags de data
<DATA_RECEBIMENTO> e hora <HORA_RECEBIMENTO> daquele documento
recebido.
specific: tag livre que poderá conter qualquer informação que a RMoura julgar
importante, cujo a mesma tenha sido enviada no documento de entrada. Basta
especificar qual informação presente nessa tag que deveremos mapear para
conter nos eventos de retorno.

Fig.2 trecho de especificação desse atributo presente na documentação ‘OpenWMS_EDI_v6.1’

Endereçamento: esse evento se assemelha ao anterior, a diferença será o nome

do evento, que no exemplo abaixo é ‘T_ESTOCAGEM’

Movimentação: nessa etapa, conforme acordado em reunião, enviaremos

somente se houver alguma movimentação de produto para um deposito de
avaria, cujo configura-se um produto avariado e não poderá ser disponibilizado
para venda.

Este documento é confidencial e não pode ser compartilhado.

5

2.2.2 - Gestão de Estoque: Ficou alinhado que o WMS não irá enviar para o ERP
informações de movimentações de saldo de produtos (Dados operacionais de
Recebimento e/ou Expedição), exceto movimentação de produto avariado.
Portanto, o estoque físico será controlado exclusivamente pelo WMS.

2.2.3 - Notas de Saída: As NFs de saída, serão geradas pelo ERP da RMoura.
O WMS ficará apenas com a etapa de gerar o Romaneio automaticamente,
mediante envio do documento de solicitação de saída (Pedido) utilizando o
método receiveDocument, o mesmo utilizado para envio de notas de entrada, o
que irá diferenciar o envio de entrada e saída é o atributo <type> que para saída
seu valor é igual a ‘EX.’
Finalizada a separação e conferência pelo operador, o WMS irá enviar
confirmação de conclusão para o ERP, que por sua vez irá gerar a NF de Saída
valida pela SEFAZ.

Fig.3: Fluxo de envio das Notas Fiscais de Saída (xlm) para criação de Romaneio

Exemplo de Requisição de Saida ‘EX’:

Resposta: retorna success contendo código do romaneio gerado e data/hora ou

error (mensagem de erro).

Mediante integração enviada, o Romaneio é criado automaticamente no WMS,

conforme citado acima. A NF/ Pedido é anexada na aba "Documentos" do
Romaneio e a partir desse ponto o fluxo da operação de separação e conferência

Este documento é confidencial e não pode ser compartilhado.

6

segue normalmente pela aplicação WMS.

Obs.: A NF /Pedido, enviada via integração, fica com status Finalizada, pois a
mesma será usada apenas como gatilho de geração automática de Romaneio!

Finalizado a conferência o WMS irá enviar para o ERP a confirmação de

romaneio finalizado “Conferência Finalizada”, contendo os dados:
salesOrder code (número do romaneio), date (data e hora), status (Conferencia
Finalizada), total (valor Total $ do romaneio), weight (Peso), amountVolum
(volumes inseridos no romaneio), document (número do pedido).

2.2.4 - Cancelamento: Quando houver a necessidade de cancelamento de

um Pedido/Romaneio, O ERP irá enviar para o WMS o XML de cancelamento.

Fig.4: Fluxo de envio de cancelamento de uma nota fiscal/romaneio

Exemplo requisição de cancelamento.

Este documento é confidencial e não pode ser compartilhado.

 7

3. Detalhes técnicos

Por parte do WMS Locus, a integração poderá ser realizada através de API, web services
Soap (https://pt.wikipedia.org/wiki/SOAP).

3.1 - WMS enviar eventos e informações para ERP:

Entendendo que precisamos de agilidade para cumprir com o cronograma do projeto

RMoura, a KMM solicita que os Endpoints/apis do lado ERP (WinThor) sejam também no
padrão SOAP com autenticação Basic auth ou Token Bearer.

Este documento é confidencial e não pode ser compartilhado.