Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Objetivo

A integração entre o BackOffice Datasul e a Plataforme Plataforma de Força de Vendas MasterSales tem como objetivo realizar a comunicação entre a implantação de pedidos efetuados no MasterSales com o Datasul.

Sistemas Envolvidos

Linha MasterSales:

  • Especializado em gestão comercial e gestão de clientes, integrando equipes internas e externas, oferecendo uma visão 360º do cliente, desde a geração de demanda até o pós venda.

Linha Datasul:

  • Sistema de BackOffice para gestão de empresas com ênfase no segmento de Manufatura. Disponibiliza módulos de gestão e controle da distribuição com foco nos requisitos comerciais, fiscais e tributários, entre eles: Pedidos de Venda, Faturamento e Embarques.

Integração

A integração entre Datasul x MasterSales disponibiliza para os clientes mais uma forma de inserção de Pedido de Vendas no BackOffice através dos representantes em campo, trazendo uma opção a mais para que o cliente possa escolher o que melhor se adequá adequar a sua rotina.

Para que seja possível atender essa demanda e possibilitar uma nova oferta de mercado TOTVS, através por meio desta integração será possível a utilização da solução MasterSales integrado com o módulo de Pedido de Vendas do BackOffice da linha Datasul.

  • Premissas:
    • Possibilitar a integração de cadastros principais como: Estabelecimento, Empresa, Cidade, Família Comercial, Endereço de Entrega, Itens, Condição de Pagamento, Tabela de Preço, Canal de Venda, Unidade de Medida e , Estoque do Item, Cliente/Fornecedor, Representantes, Títulos do Contas a Receber e Notas Fiscais.
    • Integrar a solução MasterSales com o módulo de Pedido de Vendas do BackOffice Datasul.
  • Arquitetura (Tecnologia):

Escopo

Possibilitar a integração de cadastros principais do Datasul para o MasterSales.

Possibilitar para que todo o pedido que será criado no MasterSales e enviado que os pedidos criados no MasterSales, sejam enviados para o BackOffice Datasul seja e devidamente cadastradocadastrados, calculado calculados e devolvido devolvidos ao MasterSales com os todos os resultados dos cálculos e/ou validações padrões que foram feitas.

Descreva, dado o contexto, qual o escopo de atuação da integração. Cite as áreas/perfis de usuários e funções impactadas. Se existe uma parte do contexto de negócio que a integração não tenta resolver, deixe explícito.

Defina exatamente o que a integração FAZ, o que ela NÃO FAZ e a sua finalidade.

[O conteúdo poderá estar disponível na ferramenta PMS – Painel de Gestão de Projetos, opção Plano do Projeto]

Como são os processos os que serão integrados, mas com uma visão geral e não só o ponto de integração caso contrário a homologação [ou outro que pegar o documento] não saberá do que se trata no sistema vertical, de forma sucinta, como funciona e o(s) ponto(s) de integração.

Citar a responsabilidade de cada produto.

Descrever com mais detalhes sobre o que será integrado (mas não ser especialista nas entidades/processos, pois suas particularidades serão descritas posteriormente) incluindo diagramas, prints, imagens, etc o que for interessante para auxiliar o entendimento.

Interessante aqui a inclusão de diagramas, imagens, lógicas, fluxo(s) do(s) processo(s) o que considerar interessante e agregador ao documento e ao escopo.


Pré-requisitos instalação/implantação/utilização

Relacione quais são os pré-requisitos (técnicos ou de negócio) para a integração. Este tópico não deve incluir informações da implantação normal do módulo, mas apenas informações específicas da integração. É como se este tópico já partisse do princípio que o módulo que será integrado já está normalmente instalado.

Entre os tópicos deste tópico podemos citar:

  • Versões mínimas de produtos.
  • Módulos ou programas que geram informações necessárias a integração. Muitas vezes a integração partirá de informações que somente são trabalhadas em um determinado programa ou processo, que deverá estar em uso no cliente.
  • Ferramentas que são necessárias a integração, como: EAI, ESB, servidor de WebService etc.
  • Aspectos legais nos quais as partes envolvidas na integração devem estar inseridas, caso as informações envolvidas sejam utilizadas para o cumprimento de alguma lei específica.
  • Requisitos de hardware ou Software, como servidores, link de internet, capacidade de armazenamento e memória, sistema operacional.

Datasul

Os requisitos para a utilização da integração entre Datasul e MasterSales são:

  • Versão/Release: 12.1.24;
  • Deve ser usado e configurado a Sugestão Automática da Natureza de Operação;
  • Ter o EAI previamente configurado com as rotas ativas de cada mensagem que será transitada e ativo no CD0101;nos Parâmetros Gerais do Datasul (CD0101);
  • Recomendado a instalação do Progress 11.7, ou então substituir as bibliotecas do Progress 11.6 pelas do 11.7. São duas: DLC\gui\OpenEdge.Core.pl e DLC\gui\netlib\OpenEdge.Net.pl.

Instalação/Atualização

Quando houver a atualização de alguns dos sistemas deve estar atento as versões das Mensagens Únicas. As mensagens e versões homologadas entre as partes está descrita no tópico: Transações/Entidades/Mensagens Únicas.

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 Datasul e MasterSales 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

Datasul para MasterSales

Método

ID

Descrição

Origem

Destino

XSD

Cadastros

01

Estabelecimento

Datasul

MasterSales

Branch_2_001.xsd

02

Cidade

Datasul

MasterSales

City_2_000.xsd

03

Família Comercial

Datasul

MasterSales

CommercialFamily_1_000.xsd

04

Empresa

Datasul

MasterSales

Company_2_002.xsd

05

Endereço de Entrega

Datasul

MasterSales

CustomerShippingAddress_1_002.xsd

06

Notas Fiscais

Datasul

MasterSales

Invoice_3_013.xsd

07

Condição de Pagamento

Datasul

MasterSales

PaymentCondition_2_001.xsd

08

Tabela de Preço

Datasul

MasterSales

PriceListHeaderItem_2_002.xsd

09

Canal de Venda

Datasul

MasterSales

SalesChannel_2_000.xsd

10

Estoque do Item

Datasul

MasterSales

StockTurnover_1_005.xsd

11

Unidade de Medida

Datasul

MasterSales

UnitOfMeasure_2_000.xsd

12

Cliente/Fornecedor

Datasul

MasterSales

CustomerVendor_2_006.xsd

13

Representante

Datasul

MasterSales

Seller_3_000.xsd

14

Títulos do Contas a Receber

Datasul

MasterSales

AccountReceivableDocument_2_008.xsd

Processos

15

Pedido de Vendas

Datasul

MasterSales

Order_4_007.xsd


MasterSales para Datasul 

Método

ID

Descrição

Origem

Destino

XSD

(versões podem variar)

Cadastros

01

Cliente/Fornecedor

MasterSales

Datasul

CustomerVendor_2_006.xsd

02

Representante

MasterSales

Datasul

Seller_3_000.xsd

Processos

15

Pedido de Vendas

MasterSales

Datasul

Order_4_007.xsd

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).

 

Cadastros

Cada cadastro destacado no  tópico Transações/Entidades/Mensagens Únicas, quando inserido um novo registro no Datasul, será disparada a mensagem correspondente (no EAI) para que o mesmo registro seja devidamente cadastrado no lado do MasterSales.

Existe um programa responsável por executar uma carga de todos os cadastros que serão usados na integração. Para saber mais como usar esse programa clique aqui.

Os únicos cadastros que serão recebidos pelo Datasul serão: Cliente/Fornecedor e Representante. Os demais cadastros serão inseridos somente no Datasul e enviados para o MasterSales.

As mensagens de cadastros que serão transitadas via EAI serão todas no modo assíncrono.

A imagem a seguir demonstra como será a comunicação e o envio dos cadastros para o MasterSales:

Image Added


Notas:

Os códigos "chaves" de cada entidade, não serão os mesmos nos dois sistemas, para isso o EAI usará o de/para das chaves pra identificar cada registro.

Processos

Transação/Processo

Tipo de Fluxo: MasterSales -> Datasul

Mensagem: Order_4_007

Versão: 4.007

O processo principal da integração é a inserção de Pedidos de Vendas do MasterSales para o Datasul. Essa ferramenta será usada principalmente pelos representantes, que irão visitar seus clientes e cadastrar os pedidos na hora da visita e assim enviá-los ao Datasul que será o responsável por todo o cálculo de imposto e controle de estoque.

O fluxo do processo acontecerá da seguinte maneira:

Image Added

O OrderAdapter é o responsável por ler todo o XML que é enviado na mensagem e criar as tabela temporárias que terão os dados para a criação do Pedido.

A PDAPI517 é a responsável por fazer as validações iniciais, como campos com informações incorretas, e posteriormente chamar a PDAPI500 que é responsável por criar o pedido e chamar todas as BO's de validação e cálculos do pedido.

Quando o processo é executado sem nenhum erro, o Datasul responde a mensagem de Order recebida pelo MasterSales, com o número do pedido criado, e depois ele envia uma nova mensagem de Order com os mesmos dados do pedido só que com todos os cálculos aplicados, para que os valores do pedido no MasterSales fiquem corretos.

Se no processo ocorrer alguma validação de negócio, o Datasul responderá a mensagem de Order com o código e a descrição do erro ocorrido, e não enviará a nova mensagem de Order com o pedido calculado, pois o mesmo não foi criado.

Notas:

Para essa integração é obrigatório a utilização da Sugestão Automática da Natureza de Operação. O tipo de operação é o que determina qual a natureza será usada (de acordo com o que foi parametrizado), e esse cadastro não possui integração entre os produtos, então ele deve ser cadastrado tando no Datasul (CD0640) quanto no MasterSales, com o mesmo código.

Limitações / Restrições Gerais

Tabela de preço:

  • Serão enviadas para o MasterSales somente as tabelas de preço com a data de validade vigente.
  • Para os itens da tabela se aplica o mesmo.

Itens:

  • Serão enviados somente itens faturáveis. 

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.
Anexos