Histórico da Página
Integração Datasul x TOTVS Colaboração Compras e Vendas
Contexto de negócio
A oferta TOTVS Colaboração, compreende toda integração entre os ERP’s TOTVS com a solução NeoGrid. A responsabilidade do TSS (TOTVS Service SPED) no TOTVS Colaboração é de integrar os ERP’s com a NeoGrid, provendo serviços que possibilitem a comunicação e transmissão de documentos entre as partes, conforme pode ser visto na figura 1.
A oferta TOTVS Colaboração Compras compreende a integração da emissão de pedidos de compra e programação de entrega do ERP Datasul com a solução NeoGrid, possibilitando o envio de pedidos de compra e programação de entrega para o fornecedor, conforme fluxo da figura 2.
Seu negócio, sua gestão, complexidade, o que está envolvido (em demais áreas), processos, etc. Tais explanações não precisam citar ferramentas (softwares) e sim as expectativas e resultados do uso de um sistema informatizado.
Interessante citar as tendências e necessidades de mercado, o quê, em geral, os software proporcionam (destinam/propósito), principais recursos, etc, e motivos que levaram a criar a integração (em outros termos, o porquê de integrar).
Sistemas Envolvidos
Para os processos de envio de pedido de compra e programação de entrega de clientes:
ERP Datasul (Módulo de compras/contratos), TOTVS Service Sped (TSS), Portal Neogrid e ERP do fornecedor.
Para o processo de recebimento de pedidos de venda para fornecedores:
ERP Datasul (Módulo de Pedidos/Pedido de Venda), TOTVS Service Sped (TSS), Portal Neogrid e ERP do cliente.
Para o processo de envio de aviso de embarque para cliente:
ERP Datasul (Módulo de Faturamento), TOTVS Service Sped (TSS), Portal Neogrid e ERP do cliente.
Integração
A integração tem o objetivo de permitir que o cliente com ERP Datasul realize o envio de pedidos de compra e programação de entrega para fornecedores via oferta do TOTVS Colaboração, ou caso o cliente usuário do ERP Datasul ter a função de fornecedor, realize o recebimento e implantação de pedidos de venda enviados via TOTVS Colaboração, e posteriormente envie o aviso de embarque das notas fiscais.
Escopo
O escopo desta integração é o envio da entidade pedido de compra e programação de entrega do cliente para o fornecedor, ou o recebimento de pedido de venda enviado por meio da oferta TOTVS Colaboração ao ERP Datasul do fornecedor. Não faz parte do escopo o envio de mensagens com as entidades relacionadas ao pedido de compra/programação de entrega, como por exemplo: Informações específicas do Item (Produto) e cadastro do Cliente. A estrutura da mensagem foi montada para que o receptor possa realizar a implantação de um pedido de venda tendo as informações principais.
Pré-requisitos instalação/implantação/utilização
Pré-requisitos (técnicos ou de negócio) para o funcionamento da integração:
- Versões mínimas de produto:
- Datasul EMS 2.06B (pacote 2.06.B.99) ou Datasul 11 (11.5.3) - Integração de Pedido;
- Datasul EMS 2.06B (pacote 2.06.C.01) ou Datasul 11 (11.5.4) - Integração de Programação de entrega;
- Datasul EMS 2.06B (pacote 2.06.C.01) ou Datasul 11 (11.5.4) - Envio Aviso de embarque;
- TSS atualizado até a versão 2.14 ou superior;
- Possuir acesso ao EDI da NeoGrid (URL, usuários e senhas dos estabelecimentos);
- Pré-requisitos de negócio:
- Contratação da oferta do TOTVS Colaboração (TOTVS e Neogrid).
- Acordo comercial cadastrado no portal da Neogrid referente aos CNPJ trafegados.
- TSS configurado para utilização das transações a serem utilizadas no TOTVS Colaboração.
- Ferramentas que são necessárias a integração: TSS (TOTVS Service Sped) e EDI Neogrid.
Instalação/Atualização
Este tópico tem por objetivo orientar a instalação da integração, visando o seu funcionamento completo.
1. Parametrizações Comuns
- Instalação do aplicativo servidor do TSS (TOTVS Service Sped) versão 2.14 ou superior.
Observação: Não faz parte do escopo deste documento detalhar a instalação do TSS no ambiente, favor utilizar manual específico para tal instalação.
Módulos ou programas (ERP Datasul) que geram informações necessárias a integração:
- Ativar a seguinte função no produto Datasul (via programa CD7070):
- TOTVS-COLABORACAO
- Parâmetros Globais – Ativação da funcionalidade global referente ao TOTVS Colaboração, folder “Colab II”.
Observação: Esta funcionalidade somente ficará habilitada quando estiver liberada no License Server a contratação do TOTVS Colaboração. - Manutenção de Estabelecimento – Parametrização do TSS por estabelecimento para trabalhar com TOTVS Colaboração. A configuração do TSS é feita acessando o botão que aparece na parte superior da tela, conforme figura 4.
- Configurações do TSS – Tela utilizada para informar as configurações de acesso ao TSS: URL de conexão, tipos de ambiente (Homologação/Produção) e o usuário e senha para autenticação no portal Neogrid, figuras 5 e 6.
Configurações importantes para a integração (folder “Colaboração” exibida na figura 5):
- URL de conexão com o TSS.
- Usuário e senha de autenticação com o portal da Neogrid.
Configurações importantes para a integração (folder “Colab II” exibida na figura 6): - Habilitar a funcionalidade de Pedidos de Compra/Venda.
- Configurar o tipo do ambiente (Homologação/Produção).
- Nesta mesma tela está disponível também a parametrização para envio de programação de entrega, com o mesmo formato.
- Também é possível realizar a parametrização para envio do aviso de embarque (complemento da nota fiscal), com o mesmo formato.
- Manutenção de Fornecedores (exclusivo para envio de pedido de compra/programação de entrega) – Marcar a opção “Colaboração Compras” no folder “Comun.”, informando ao sistema que o Fornecedor recebe mensagem via TOTVS Colaboração, conforme figura 7.
- Manutenção de Clientes (exclusivo para envio de aviso de embarque) – Marcar a opção “Colaboração Vendas” no folder “Fiscal.”, informando ao sistema que o cliente envia mensagem via TOTVS Colaboração, conforme figura 8.
2. Envio de Pedido de Compra
- Emissão de Pedido de Compra – Realiza o envio de pedido de compra para o fornecedor via TOTVS Colaboração, conforme figura 9. Pode também ser enviado utilizando a Emissão de pedido flex, conforme figura 10.
- Observações: Não faz parte do escopo deste documento detalhar a implantação de um pedido de compra, etapa anterior a “Emissão de pedido de compra”.
3. Envio do Aviso de Embarque
- Atualização Notas Fiscais Estoque – Realiza o envio do aviso de embarque para o fornecedor via TOTVS Colaboração, conforme figura 11.
4. Premissas para o Envio do Aviso de Embarque
- A nota fiscal eletrônica deve estar com a “Situação NFe” igual à “Uso Autorizado”, não pode estar cancelada e deve estar confirmada.
- O parâmetro “Totvs Colaboração” na aba “Integr II” no programa CD0101 – Atualização Parâmetro Global deve estar marcado.
- O parâmetro “Habilitado” no programa CD0403B – Configuração do TSS na aba “Colab II“ referente à Nota Fiscal deve estar marcado.
- O parâmetro “Colaboração Vendas” no programa CD0704 – Manutenção de Clientes deve estar marcado.
5. Recebimento de Pedido de Venda
- Recebimento de pedido de venda (exclusivo para o papel de fornecedor) – Realiza a busca do pedido de compra enviado ao fornecedor usuário do ERP Datasul, via TOTVS Colaboração. Ao passar pelo Neogrid este pedido se transforma em pedido de venda e é disponibilizado para busca pelo TSS. O programa que faz a busca e implantação dos pedidos de venda, por estabelecimento e data de emissão do pedido, conforme figura 12.
6. Envio de Programação de Entrega
- Emissão de Programa de entrega – Realiza o envio de programação de entrega para o fornecedor via TOTVS Colaboração. Deve ser marcada a opção “Enviar programação” para que seja enviada a mensagem XML para o TSS, conforme figura 13.
7. Recebimento de Programação de Entrega
- Recebimento de programação de entrega (exclusivo para o papel de fornecedor) – Realiza a busca da programação de entrega enviada ao fornecedor usuário do ERP Datasul, via TOTVS Colaboração. Ao passar pelo Neogrid esta programação se transforma em programação de entrega e é disponibilizado para busca pelo TSS. O programa que faz a busca e implantação das programações de entrega, por estabelecimento e data de emissão da programação de entrega, conforme figura 14.
Transações/Entidades/Mensagens únicas
Estão detalhadas aqui as entidades e transações que serão enviadas no documento XML de pedido de compra, não serão replicados cadastros de uma ponta a outra de forma integrada, para que a integração seja concretizada de forma correta os cadastros base deverão existir nas duas pontas. Segue considerações:
Vínculos feitos a partir do CNPJ (ERP que recebe o documento XML deve encontrar as informações baseado no CNPJ):
- Cadastro de Estabelecimento – Folder “Endereço”.
- Cadastro de Fornecedores – Folder “Fiscal”.
- Cadastro de Transportadores – Folder “Fiscal”.
Entidade Item (identificação do Produto):
Para o envio da tag <itemcode>, o sistema irá realizar a seguinte validação: Caso exista código EAN cadastrado na manutenção de itens materiais (CC0103), ele será enviado ao fornecedor, caso contrário, será enviado o código de item interno do EMS.
No caso da tag <prodcodsuplli>, será enviado sempre o código de item do fornecedor, cadastrado na manutenção item fornecedor (CC0105).
Outras entidades/cadastros:
Moeda – Caso a moeda seja Real, será enviado o código 1 na tag <CurrencyId>, caso contrário, será enviado 6 e a descrição da moeda na tag <Currencydesc>.
Unidade de Medida – Será enviada a unidade de medida interna do ERP na tag <internalmensuunit> e a unidade de medida do fornecedor (CC0105) na tag <supllimensuunit>.
Programação de Entrega – Envio
Na tag referente à quantidade da entrega (quantrequest) sempre será enviado o saldo da parcela da ordem de compra. Conforme consta no manual do produto: “As quantidades e datas da programação de entrega serão parcelas não recebidas dos pedidos de compra selecionados”.
Estrutura da mensagem única de pedido de compra (Order) que será trafegada:
Estrutura da mensagem única de programação de entrega (DeliverySchedule) que será trafegada:
Importante: A equipe de suporte do TSS mantém o documento detalhado com as informações dos Layouts padrões TOTVS Colaboração que são utilizados por todos os produtos TOTVS. Acima consta apenas a estrutura da mensagem, não estão contempladas todas as tags da cada mensagem.
Estrutura da mensagem única do aviso do envio de embarque (tss_tc_tipos_aviso) que será trafegada:
Pedido de Venda
Para o recebimento de pedido de venda será necessário o cadastramento de Engine de Regras para que as informações padrão do XML sejam recebidas e transformadas em valores equivalentes na base do cliente. Informações como moeda, condição de pagamento, tipo de frete e tipo de preço:
Deve-se utilizar o Engine de Regras para adequar aos dados da base do fornecedor as seguintes informações padronizadas pela EANCOM para integrações entre sistemas. Para que as informações a seguir listadas sejam alteradas foram criados tipos de operação para transformação, (citados ao lado de cada campo) que deverão ser cadastradas no Engine de Regras:
- Moeda (tipo de operação so-moeda):
Código | Descrição |
1 | Real |
2 | Dólar |
3 | UFIR |
4 | EURO |
5 | IENE |
6 | Outras |
- Condição de Pagamento (tipo de operação so-cond):
Código | Descrição |
1 | Básico |
3 | Data Fixa (Pagamento realizado na data ou período estipulado no pedido) |
20 | Multa |
21 | Pagamento Parcelado |
22 | Desconto por antecipação de Pagamento |
B01 | Pagamento com Data de Concentração |
JRM | Juros de Mora |
- Tipo de Frete (tipo de operação so-frete):
Código | Descrição |
1 | CIF – Custo, Seguro, Frete por conta do vendedor até o destino designado. |
2 | FOB – Posto a bordo. Porto de embarque designado |
3 | SFT - Sem Frete |
- Tipo de Preço (tipo de operação so-preço):
Código | Descrição |
1 | Preço Informado |
2 | Preço Data de Implantação |
3 | Preço Data de Faturamento |
Para o cadastramento das regras no Engine de Regras é necessário utilizar os programas a seguir apresentados:
- CDP/CD0025.W – Cadastro de Tipo de Operação
- CDP/CD0024.W – Configurador de Regras
Observação: Para cada tipo de operação, será necessário uma variável com a mesma nomenclatura.
Programação de Entrega
Para o recebimento da programação de entrega será necessário o cadastramento de Engine de Regras para que as informações padrão do XML sejam recebidas e transformadas em valores equivalentes na base do cliente. Informações como freqüência do fornecimento:
Deve-se utilizar o Engine de Regras para adequar aos dados da base do fornecedor as seguintes informações padronizadas pela EANCOM para integrações entre sistemas. Para que as informações a seguir listadas sejam alteradas foram criados tipos de operação para transformação, (citados ao lado de cada campo) que deverão ser cadastradas no Engine de Regras:
- Frequência de fornecimento:
Código | Descrição |
A | Anual (ano calendário). Código definindo uma previsão anual. |
F | Intervalo flexível (da data X até a data Y). Código definindo uma previsão de utilização planejada entre duas datas especificadas. |
M | Mensal (meses calendário). Código definindo uma previsão mensal. |
Q | Trimestral (trimestres calendário). Código definindo uma previsão trimestral. Por ex. Jan-Mar, Abr- Jun, Jul-Set, Out-Dez. |
S | Semestral (ano calendário). Código definindo uma previsão para os 1ºs ou últimos seis meses do ano. |
W | Semanal. Código definindo uma previsão para intervalos semanais. |
Y | Diário. Código definindo uma previsão para intervalos diários. |
T | Quinzenal |
D | Descêndial |
Para o cadastramento das regras no Engine de Regras, é necessário utilizar os programas a seguir apresentados:
- CDP/CD0025.W – Cadastro de Tipo de Operação
- CDP/CD0024.W – Configurador de Regras
Observação: Para cada tipo de operação, será necessário uma variável com a mesma nomenclatura.
Pedido: 1 ocorrência |
<VendorGovInfo>
<CustomerGovInfo>
<BillingLocationGovInfo>
<DeliveryCustomerGovInfo>
<CarrierGovInfo>
<OTHER>
<ADDFIELDS>
<ADDFIELD>
Parcelas das condições de pagamento: de 0 a N ocorrências |
<TERM>
Ordens de Compra/Itens: de 1 a N ocorrências |
<Item>
Entregas: de 0 a N ocorrências |
<CROSSDOCKING>
<CROSSDOCKING_ITEM>
Resumo: 1 ocorrência |
<SUMMARY>
Fluxo das Informações
Para cada fluxo de informação descreva, se necessário, alterações de comportamento que o respectivo produto irá sofrer. Por exemplo: quando o Logix recebe o PEDIDO de OUTRO ERP, este pedido não poderá ser alterado no Logix.
Liste quais as entidades integradas e como é o mapeamento entre as diferentes estruturas. Por exemplo: Classe no sistema A vira categoria no sistema B, o campo X é refletido no campo Y etc.
Liste quais transações/operações a integração fará com as entidades relacionadas. Exemplo: Insert de PEDIDO, Insert, update de ITEM, buscar saldo em estoque do ITEM no dia X ou buscar dados do FUNCIONÁRIO.
Cadastros
Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.
Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos
Em seguida faça uma descrição para cada um dos fluxos para cada entidade
<Transação/Entidade>
Identificador da Mensagem: <mensagem>
Versão: <versão>
Módulo <marca 1>: <BackOffice – Gestão xxxxxxx>
Módulo <marca 2>: <SIGAXXX>
Tipo de Envio: <Assíncrona/Síncrona>
Mensagem Padrão | PROTHEUS | RM | ||
Tabela | Campo | Tabela | Campo | |
Code | CTO990 | CTO_SIMB | GMOEDA | SIMBOLO * |
Description | CTO990 | CTO_DESC | GMOEDA | DESCRICAO |
Symbol | CTO990 | CTO_SIMB | GMOEDA | SIMBOLO |
Notas:
Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela
A seguir descrever as variações, particularidades da mensagem e processos (integração) de acordo com cada marca
Limitações/Restrições
Descreva limitações e restrições para a integração que está sendo descrita.
Processos
Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.
Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos
Em seguida faça uma descrição para cada um dos fluxos para cada entidade
<Transação/Processo>
Tipo de Fluxo: Protheus -> RM
Mensagem: Request_1_000
Versão: 1.000
Descrição de todo o comportamento e funcionamento do processo. Breve contexto, origem, regras, integração (geração da mensagem, envio, recebimento no destino), o quê supostamente irá ocorrer no destino, retorno, impacto, consequências, o que foi afetado, como conferir, validar, etc o retorno.
Acrescentar um diagrama do processo.
A seguir descrever as variações, particularidades da mensagem e processos (desta integração) de acordo com cada marca
Notas:
Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela
Limitações/Restrições
Descreva limitações e restrições para a integração que está sendo descrita.
Limitações / Restrições Gerais
Descreva limitações e restrições para cada fluxo descrito no tópico anterior. Exemplo:
- ERP1 envia ITEM cadastrado para o ERP2
ERP1 somente enviará o ITEM se este estiver em uma das famílias cadastradas no parâmetro FAMILIA_INTEGRACAO.
Se o tipo de valorização do estoque for FIFO.
- ERP2 envia PEDIDO cadastrado para o ERP1
O pedido recebido no ERP1 vindo do ERP2 estará bloqueado para alteração.
Como fazer (opcional)
Descreva os passos que viabilizem a integração.
Exemplo:
Os passos para viabilizar a integração são:
- No Logix ou no Protheus efetue o cadastro das seguintes informações: Clientes, fornecedores, transportadores, cidades, cotação de moeda e unidades de medida.
- No Logix cadastrar um novo depositante e efetuar toda a parametrização necessária para a operação de WMS.
- No Logix cadastrar um novo produto que seja controlado pelo WMS, para o depositante cadastrado anteriormente.
- No Logix efetuar um processo de recebimento para o produto cadastrado anteriormente, utilizando uma nota fiscal provisória (tipo “A”).
- No Protheus consultar a nota fiscal de recebimento que foi registrada no Logix, validando as informações recebidas.
- No Logix efetuar um processamento de regularização fiscal, efetuando a cobertura dos produtos recebidos anteriormente.
- No Protheus verificar se foi efetuado corretamente o relacionamento entre os dois documentos.
- No Logix efetuar um processo de expedição para o novo produto cadastrado, até o momento do envio da mensagem de integração de pedido de venda.
- No Protheus efetuar o faturamento do pedido de venda recebido.
- No Protheus verificar se a nota fiscal gerada contém todas as informações necessárias para o segmento de operador logístico (armazém geral).
- No Protheus efetuar a escrituração fiscal das notas fiscais, verificando se as regras da legislação deste segmento foram respeitadas.
- No Logix é possível consultar o número do pedido de venda gerado para as notas fiscais de retorno simbólico e conta/ordem no programa WMS6333 (Consulta de Documentos). Para os processos de faturamento de serviço o número do pedido está disponível no programa WMS6411 (Movimentos a Faturar).
Situações comuns (opcional)
Descreva situações problemáticas comuns que podem ocorrer durante o funcionamento da integração e como solucioná-los. Neste ponto também é importante dar instruções de como reconhecer e investigar problemas que podem vir a ocorrer durante a integração. Se houver, apresente tabelas de códigos e descrições de erros que a integração poderá apresentar.
Este tópico possivelmente será alimentado com as experiências durante o desenvolvimento da integração e poderá ser realimentado durante o uso da integração no cliente.
Exemplo 1:
Tratamento de erros de integração (Produto A)
Erro | Mensagem | Solução |
Código do erro | Mensagem exibida | Ação a ser tomada para resolução do erro. |
Tratamento de erros de integração (Produto B)
Erro | Mensagem | Solução |
Código do erro | Mensagem exibida | Ação a ser tomada para resolução do erro. |
Exemplo 2:
Quando uma mensagem é enviada do Logix para o Protheus, podem ocorrer situações em que o WebService não estará totalmente funcional. Nestes casos uma mensagem de erro genérica irá aparecer na tela:
Exemplo:
Erro ao enviar a mensagem de Cidade via Integração
Se o arquivo de log for analisado, poderemos ver a falha na comunicação com o sistema destino:
-------------------------------------------------------------------------------
WSCERR044 / Não foi possível POST : URL http://172.16.31.57:8011/ws/FWWSEAI.apw
ADVPL WSDL Client 1.080707 / tst on 20120315 08:49:51
-------------------------------------------------------------------------------
Para resolver este problema, verifique as configurações do sistema de destino, analisando o funcionamento do servidor utilizado para esta comunicação e a habilitação do endereço do WebService.
Checklist de suporte da aplicação
Crie um check-list de verificação de alguns pontos importantes para o funcionamento e atendimento da integração.
Instalação/Configuração
Relacione itens de verificação para garantir que a integração está corretamente instalada e configurada. Isto não pode ser uma cópia do procedimento de instalação/configuração, mas verificações pontuais que podem remeter aos itens da instalação.
Checklist de Verificações:
Relacione itens de verificações para que o atendente possa:
- Identificar o funcionamento da integração;
- Identificar a ocorrências de problemas;
- Coletar evidências do mau funcionamento relatado pelo cliente;
- Realizar possíveis ajustes na integração quanto à configuração ou negócio.