Páginas filhas
  • DI_Integracao_Datasul_x_TOTVS_Colaboracao_2_0_Compras_Vendas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: Migration of unmigrated content due to installation of a new plugin

Integração Datasul x TOTVS Colaboração 2.0 Compras e Vendas

Contexto de negócio (Introdução)

A oferta TOTVS Colaboração, compreende toda integração entre os ERPs TOTVS com a solução NeoGrid. A partir da versão Totvs Colaboração 2.0 a comunicação e transmissão de documentos entre as partes é realizado pelo Client NeoGrid, 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.

 

A oferta TOTVS Colaboração Vendas compreende a integração do recebimento de pedidos de venda no ERP Datasul com a solução NeoGrid, possibilitando o envio de pedidos de compra para o fornecedor, conforme fluxo da figura 3.

               

A oferta TOTVS Colaboração Vendas também compreende a o envio do aviso de embarque do ERP Datasul com a solução NeoGrid, possibilitando o envio de do Aviso de embarque para o cliente, conforme fluxo da figura 4.

 


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), Client NeoGrid, 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), Client NeoGrid, Portal NeoGrid e ERP do cliente.

Para o processo de envio de aviso de embarque para cliente:

ERP Datasul (Módulo de Faturamento), Client NeoGrid, 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 com Totvs Colaboração 2.0: 

  • Versões mínimas de produto:
    • Datasul 11 (12.1.2) - Integração de Pedido;
    • Datasul 11 (12.1.2) - Integração de Programação de entrega;
    • Datasul 11 (12.1.2) - Envio Aviso de embarque;
    • Possuir o Client NeoGrid instalado
    • Possuir acesso ao EDI da NeoGrid (URL, usuários e senhas dos estabelecimentos);
    • Versões inferiores a 12.1.2 porém superiores a 11.5.10 serão enviados pacotes especiais
  • 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.
  • Ferramentas que são necessárias a integração: Client NeoGrid 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 Client NeoGrid.
  • Observação: Não faz parte do escopo deste documento detalhar a instalação do Client NeoGrid, sendo esta responsabilidade da NeoGrid em sua implantação.

Módulos ou programas (ERP Datasul) que geram informações necessárias a integração:

  • Parâmetros Globais (PD0101CD0101) – Ativação da funcionalidade global referente ao TOTVS Colaboração, marcando o flag Totvs Colaboração e Versão igual a 2.0, no folder “Integr II”.
    Observação: Esta funcionalidade somente ficará habilitada quando estiver liberada no License Server a contratação do TOTVS Colaboração.
  • Parâmetros de Integração do Estabelecimento (CD0360) – Parametrização dos documentos que serão transitados pela solução na TOTVS Colaboração por estabelecimento conforme figura 4. A configuração dos diretórios em que o Client Neogrid gravará e buscará os documentos é feita acessando o botão que aparece na parte superior da tela, conforme destacado na figura 4.
    Parâmetros de Integração do Estabelecimento
  • Configurações de diretórios – Nesta tela são informados os diretórios utilizados para leitura e gravação dos documentos transitados na solução Totvs Colaboração, conforme figura 5.
    • Diretório Arquivos: local onde o Client Neogrid fará a gravação e a busca dos documentos. Dentro da pasta selecionada deverão existir dois diretórios, o diretório IN para entrada de documentos e o diretório OUT para o envio de documentos. Nesta pasta serão gravados todos os tipos de documentos.
    • Diretório Documentos Lidos: Nesta pasta serão gravados os arquivos após sua leitura pelo programa CD0590. Tal qual a pasta “Diretório Arquivos” deverá possuir o diretório “RECEIVED” dentro de sua pasta. 
    • Diretório EDI: local onde serão gravados os documentos de entrada relativos a EDI Vendas, como pedido de venda e programação de entrega. Eles serão transferidos do “Diretório Arquivos” para o “Diretório EDI” na execução do programa CD0590.
    • Diretório Recepção Documentos: Local onde serão gravados os documentos de recebimento de NF-e e CT-e.
    • Diretório Manif Destinatário (MD-e): Local onde serão gravados os documentos relativos a MD-e.
      Configurações dos diretórios de gravação
  • 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 mensagens via TOTVS Colaboração, conforme figura 6.
    Manutenção de fornecedores (Folder Comun.)
  • 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 mensagens via TOTVS Colaboração, conforme figura 7.

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 8. Pode também ser enviado utilizando a Emissão de pedido flex, conforme figura 9.

  • 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 10.
    Atualização Notas Fiscais Estoque

 

 

 

 

Datasul

Insira aqui as informações pertinentes a Datasul.

Logix

Insira aqui as informações pertinentes ao Logix.

Protheus

Insira aqui as informações pertinentes ao Protheus.

RM

Insira aqui as informações pertinentes ao RM.

Controle de Versão

O grupo TOTVS, representado por suas marcas, irá administrar as demandas de evolução dos layouts e demais ajustes, acordando junto aos solicitantes o prazo de liberação de release.

Todas as evoluções programadas deverão ser discutidas e aprovadas pelas marcas antes do início do desenvolvimento e somente serão desenvolvidas em caso de concordância das marcas e alinhamento com as diretivas definidas pelo Comitê de Integração TOTVS.

Suporte

O suporte aos recursos da Integração será de responsabilidade de todas as linhas, sendo assim as equipes de suporte dos produtos RM Conector e Backoffice Protheus estarão aptas a fazer a primeira análise e, quando necessário, repassar para a equipe mais adequada em cada caso.

Observação: Este modelo de suporte está sendo revisado pela TOTVS.

Transações/Entidades/Mensagens únicas

Apresente quais as transações/entidades que são trocadas e quem envia a informação para quem. Pode (e recomenda-se) ter um diagrama, uma tabela ou afins que apresente este fluxo.

Relacione quais são as mensagem únicas (TOTVSMessage) utilizadas e qual o seu relacionamento com as entidades já existentes do ERPs envolvidos.

Exemplos:

 

 

 Image Removed

 

Image Removed

 

Método

ID

Descrição

Origem

Destino

XSD (versões podem variar)

Cadastros

01

Cliente/Fornecedor

RM

Protheus

CustomerVendor_1_000.xsd

02

Moeda

RM

Protheus

Currency_1_000.xsd

03

Unidade de Medida

RM

Protheus

UnitOfMeasure_1_000.xsd

04

Produto

RM

Protheus

Item_?_000.xsd

05

Centro de Custo

RM

Protheus

CostCenter_1_000.xsd

06

Ativos

RM

Protheus

NOVA, Ativo fixo

07

Funcionários

RM

Protheus

Employee_1_000.xsd

08

Projeto

RM

Protheus

Project_1_000.xsd

09

Obra

RM

Protheus

SubProject_1_000.xsd

10

Tarefa

RM

Protheus

TaskProject_1_000.xsd

11

Meio de Pagamento

RM

Protheus

?????.xsd

12

Condições de pagamento

RM

Protheus

PaymentCondition_1_000.xsd

13

Coligada*
* implementado, mas o Protheus não vai enviar, estamos avaliando alternativa para preencher o de/para

RM

Protheus

Company_1_000.xsd

14

Filial*
* implementado, mas o Protheus não vai enviar, estamos avaliando alternativa para preencher o de/para

RM

Protheus

Branch_2_000.xsd

Processos

15

Solicitações (compras/armazém)

Protheus

RM

Request_1_000.xsd

16

Cancelar movimento (solicitação, OS, etc)

Protheus

RM

CancelRequest_1_000.xsd

17

Cancelar movimento (solicitação, OS, etc)

RM

Protheus

CancelRequest_1_000.xsd

18

Baixa de estoque

Protheus

RM

Request_1_000.xsd

19

Baixa de estoque

RM

Protheus

Request_1_000.xsd

20

Consulta Saldo

Protheus

RM

 

21

Apropriação de custos

 

 

Request _1_000.xsd

22

Geração de OS

 

 

 

23

Consulta de OS

 

 

 

24

Ampliação patrimonial

 

 

 

 

 

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.

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.
  • A opção “Emissão de Aviso de Embarque” no programa CD0360 deve estar selecionada como “Totvs Colaboração”
  • 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 11.
    Image Added

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 12.
    Image Added 

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 busc. 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 13.
    Image Added  


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:

Image Added

Estrutura da mensagem única de programação de entrega (DeliverySchedule) que será trafegada: 

Image Added

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:

Image Added

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
    Image Added
  •  CDP/CD0024.W – Configurador de Regras
    Image Added

Observação: Para cada tipo de operação, será necessária 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 frequê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 exemplo:

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
    Image Added
  • CDP/CD0024.W – Configurador de Regras
    Image Added

Observação: Para cada tipo de operação, será necessária uma variável com a mesma nomenclatura.

 

Fluxo das Informações

1. Fluxo Completo do Envio de Pedido de Compra

 Cliente (montadora ou indústria) deseja enviar pedido de compra para o fornecedor: 

  •  O ERP grava o XML do pedido de compra no diretório de saída parametrizado.
  • O Client Neogrid envia o XML do pedido de compra para a validação da NeoGrid.
  • A solução NeoGrid realiza a validação do arquivo enviado e disponibiliza o resultado.
  • O ERP do fornecedor busca as informações da solução NeoGrid. 

Image Added

2. Fluxo Completo do Recebimento de Pedido de Venda

Fornecedor busca pedido de compra do cliente (varejo, indústria, montadora):

  • A solução NeoGrid recebe o pedido de compra do cliente, realiza as validações e disponibiliza como pedido de venda.
  • O Client Neogrid busca o XML e disponibiliza para a busca do ERP.
  • O ERP busca o XML do pedido de venda do diretório destino, realiza a implantação, gerando um log informando o resultado.

Image Added

3. Fluxo Completo do Envio de Programação de Entrega

Cliente (montadora ou indústria) deseja enviar programação de entrega para o fornecedor: 

  • O ERP envia inicialmente o XML do pedido de compra para o fornecedor (Fluxo 1).
  • O ERP grava o XML de programação de entrega no diretório de saída.
  • O Client Neogrid envia o XML da programação de entrega para a validação da NeoGrid.
  • A solução NeoGrid realiza a validação do arquivo enviado e disponibiliza o resultado.
  • O ERP do fornecedor busca as programações de entrega da solução NeoGrid e atualiza o pedido de venda.

Image Added

4. Fluxo Completo do Recebimento de Programação de Entrega

Fornecedor busca programação de entrega do cliente (varejo, indústria, montadora):

  • A solução NeoGrid recebe a programação de entrega do cliente, realiza as validações e disponibiliza como programação de entrega.
  • O Client Neogrid busca o XML e disponibiliza para a busca do ERP.
  • O ERP busca o XML de programação de entrega do diretório destino, realiza a implantação, gerando um log informando o resultado.

Image Added

5. Fluxo completo do Envio do Aviso de Embarque

Cliente (montadora ou indústria) deseja enviar Aviso de Embarque para o fornecedor: 

  • O ERP grava o XML do Aviso de Embarque no diretório de saída.
  • O Client Neogrid envia o XML do Aviso de Embarque para a validação da NeoGrid.
  • A solução NeoGrid realiza a validação do arquivo enviado e disponibiliza o resultado.
  • O ERP do fornecedor busca as informações da solução NeoGrid.

Image Added

6. Fluxo do Envio de Pedido de Compra do ERP Datasul para o TSS

Image Added

7. Fluxo do Recebimento do Pedido de Venda pelo ERP Datasul vindo do TSS

Image Added

8. Fluxo do Envio de Programação de Entrega do ERP Datasul para o TSS

Image Added

9. Fluxo do Recebimento da Programação de Entrega pelo ERP Datasul vindo do TSS

Image Added

10. Fluxo do Envio do Aviso de Embarque pelo ERP Datasul vindo do TSS

Image Added

Anexos