INTEGRAÇÃO Marketplace X Protheus Compras (SIGACOM)

Contexto de negócio (Introdução)

A integração entre o ERP TOTVS e o Portal de Compras Paradigma considera a possibilidade de ter uma cotação com uma opção maior de fornecedores e oferta que atenda uma requisição (solicitação de compra) parcialmente ou em sua totalidade, desta forma, ela é realizada após uma requisição emitida pelo ERP TOTVS sendo enviada automaticamente para o Portal de Compras Paradigma que será responsável pelo fluxo da cotação. A cotação retornará para o ERP somente após o seu encerramento, ou seja, quando as cotações estiverem concluídas e a melhor delas for escolhida, assim, é gerado um pedido de compra no ERP TOTVS que refletirá no Portal para que o fornecedor ganhador confirme a capacidade de atendimento.

Esta integração se dará utilizando Mensagem Única/EAI2.

Sistemas Envolvidos

• Portal de Compras Paradigma (WBC – Web Business Center): plataforma de negociações eletrônicas que será responsável pela cotação de itens com diversos fornecedores e que agregam volumes de compras para cotação de preço.
• Módulo de Compras: supre às necessidades de materiais ou serviços de um estabelecimento por meio de um planejamento que mensura a quantidade certa para o momento adequado objetivando um fluxo contínuo de suprimentos que atende as demandas de materiais e serviços da empresa.

Integração

A integração visa melhorias no processo de cotação com o objetivo de comprar materiais e insumos pelos menores preços e contemplar os padrões de quantidade, qualidade e prazos pré-definidos, bem como, redução de custos dos processos de compras para obter ganho de competitividade.

• Premissas
• Parâmetro.
• Adapter.
• Arquivo INI.
• Schedule.
• Carga de Dados / Compatibilizador.

• Arquitetura (Tecnologia)
• EAI – Mensagem Única.

Escopo

Requisitos

• Integrar no Portal Paradigma os seguintes cadastros: moeda, empresa, fornecedor, condição de pagamento, unidade de medida, produto/item, usuário, produto X fornecedor.
• Integrar no Portal Paradigma as seguintes movimentações: solicitação de compra; pedido de compra.
• Integrar no ERP o cadastro de fornecedores vindos do Portal Paradigma.
• Integrar no ERP as cotações do fluxo desta integração vindas do Paradigma.
• Integrar no ERP o cancelamento da solicitação de compra feito no Portal.
• Integrar no ERP do cancelamento do pedido de compra feito no Portal.

Cenário Atual

• Já existe a integração do Protheus com o Portal Paradigma.

Contexto

• O Portal Paradigma dispõe de uma ferramenta chamada ClicBusiness que dispõe de muitos fornecedores cadastrados. Neste local podem ser feitas avaliações dos fornecedores por outros clientes que contempla qualidade do produto e prazo de entrega.
• Serão enviadas para o Portal as solicitações de compra realizadas pelo ERP, depois, as cotações serão devolvidas para o ERP e, posteriormente, enviado o pedido de compra fechado ao Portal.

Solução Proposta

Funcionalidades que serão atendidas: serão apresentados dois fluxos de mensagens trocadas entre o Protheus e o Portal Paradigma que contemplam a gestão de pedidos com cotação (sem contratos) e a gestão de pedidos sem cotação (com contratos). Além disso, existem também os fluxos de mensagens de cadastros, alterações e cancelamentos de requisições e pedidos.

De acordo com o padrão da Paradigma, serão tratadas todas as transações síncronas por meio da Mensagem Única/EAI2 utilizando resposta da própria mensagem única de retorno.

Cenários das operações

• Cadastros

Usuário inclui ou altera um cadastro no ERP

Para equalização das informações entre os dois sistemas (Protheus e Paradigma), será realizada a integração de alguns cadastros que sempre parte do ERP para a Paradigma e ocorre quando há uma inclusão ou alteração de um registro.

Fora do escopo: eliminações não serão tratadas, deverá ser feita exclusão manualmente no Portal.

Como não haverá a integração inversa (da Paradigma para o ERP), os cadastros que forem integrados devem ser bloqueados na Paradigma para que não haja incompatibilidade dos dados. Observações: exceções serão detalhadas na sequência.

Dados do Cadastro incluído ou alterado enviados para o Paradigma: cadastros que serão integrados:

• Moeda: ficou definido que a moeda será integrada através de carga manual no portal de acordo com a sequência de moedas do cliente que irá implantar a ferramenta, que são configuradas nos parâmetros MV_MOEDA1, MV_MOEDA2,...,MV_MOEDA5.
• Empresa (Paradigma trata como Empresa Compradora): ficou definido que a empresa será integrada através de carga manual no portal, ela sempre será como Empresa Compradora, dessa forma, nenhum registro do Protheus gerará uma Empresa Administradora na Paradigma.

Como não serão tratadas regras para outros países nesta primeira fase do projeto, somente estabelecimentos brasileiros serão enviados para a Paradigma.

• Fornecedor (Paradigma trata como Empresa Vendedora): mensagem única Customervendor_2_000.xsd. Como não serão tratadas importações nesta primeira fase do projeto, somente fornecedores nacionais serão enviados para a Paradigma.

Quando for incluído um fornecedor no ERP e integrado com o Portal pela primeira vez, é gerada uma senha para acesso no Portal com o número do CNPJ, assim, quando o fornecedor acessar o portal pela primeira vez, é solicitada a alteração da senha. Observação: como o Protheus não obriga informar e-mail, o Portal realizará essa validação, e caso não esteja preenchido, a mensagem retornará com erro.

Caso a entidade de Fornecedores no Protheus estiver configuradacomo compartilhada, para cada filial será necessário gerar um novo envio da mensagem para que o fornecedor seja vinculado a filial que irá utilizálo.

• Condição de Pagamento: mensagem únicaPaymentCondition_2_000.xsd. Não serão tratadas as condições de pagamento tipo 7, tipo 9, tipo A e tipo B.
• Unidade de Medida: mensagem única UnitofMeasure_2_000.xsd.
• Produto: mensagem única Item_3_000.xsd.
• Compradores (Paradigma trata como Usuário): mensagem única User_3_000.xsd. Serão integrados os usuários de materiais que sejam compradores e/ou requisitantes. Para isso serão considerados somente usuários cadastrados como comprador ou programador que são os utilizados pelo módulo de Compras.

Como no ERP não possui a obrigatoriedade de informar o e-mail no cadastro de usuário, essa validação será realizada pela Paradigma, sendo retornado um erro, caso não seja enviado o e-mail para o usuário.

Quando for incluído um usuário no ERP e integrado com o Portal pela primeira vez, é gerada uma senha para acesso no Portal que é enviada por e-mail para o endereço informado no cadastro de usuário do ERP, assim, quando o usuário acessar o portal pela primeira vez, é solicitada a alteração da senha.

Caso a entidade de Compradores no Protheus estiver configuradacomo compartilhada, para cada filial será necessário fazer o vínculo manualmente no portal, exceto para a filial que enviou a mensagem, pois esta já estará vinculada ao comprador.

• Produto X Fornecedor (Paradigma trata como Produto X Empresa): ao enviar esse relacionamento para a Paradigma, além do envolvimento entre Produto e Empresa, também deverá ser criado este critério entre Categoria e Empresa.

Observação: serão enviados para o Portal somente os relacionamentos de item X fornecedor de fornecedores que possuírem integração com o Portal de Compras.

• Dados de retorno do processamento do cadastro na Paradigma (sucesso ou erro): conforme mencionado, os processos serão tratados como síncrono. Na própria mensagem única é retornado o código de erro que será tratado no ERP para efetivação da inclusão ou alteração do cadastro, somente se houver êxito no Portal.

• Gestão de pedidos com cotações (sem contratos)

Considerações do fluxo Gestão de pedidos com cotação (sem contratos):

• O requisitante gera uma solicitação de compra no ERP: todo o processo de criação de requisição/ordem de compra será feito no ERP sem nenhuma integração com o Portal de Compras.

• Aprovador aprova solicitação no ERP: se o controle de alçadas estiver ativo a solicitação de compra só será integrada com o portal Marketplace após aprovação total.

• Comprador seleciona as ordens de compra para tratamento no portal: se o item da solicitação de compra estiver com o campo Envia MKT (B5_ENVMKT) preenchido com a opção Talvez a solicitação só será integrada após o processamento da rotina Portal Marketplace (MATA111).

Para que a ordem de compra possa ser enviada ao Portal ela deve estar como Aberta (não é possível enviar ordens planejadas) e não deve pertencer a um contrato fechado, não ter pedido de compra ainda relacionado e nem fornecedor designado.

As ordens de compra não devem ter datas de entrega menores que a data atual, caso contrário também não podem ser enviadas.

Observação: para ordens de compra que possuem mais de uma entrega, a cada entrega da ordem será criada uma requisição diferenciada na Paradigma.

• Dados da requisição no ERP: o ERP gera um documento de integração (Dados da Requisição no ERP).

Observação: após uma ordem de compra ter sido enviada ao Portal, ela ficará congelada, sendo que neste caso não será permitida a exclusão da ordem de compra. A exclusão ou cancelamento poderá ser feito somente por meio do Portal. A requisição não poderá ser alterada nem no ERP nem no Portal, caso necessário ela deverá ser cancelada e excluída para que uma nova sega criada.

• Retorno do processamento da requisição no Portal: a plataforma do Portal faz o processamento da mensagem de integração (Dados da Requisição no ERP). É retornada na própria mensagem única, se houve algum erro da requisição. No Portal o número da requisição será o mesmo do ERP, neste caso, o usuário tem a rastreabilidade das informações.

Caso tenha ocorrido erro na efetivação de alguma parcela na Paradigma, a ordem deverá ser marcada com erro (retornado de imediato na mensagem, já que é síncrono) para que a situação seja corrigida e a ordem reenviada.

• Comprador cria e envia cotação a partir da requisição: com a requisição integrada no Portal de Compras, o comprador acessa a lista de requisições, podendo criar um processo de Tomada de Preço (Solicitação de Cotação) com os seguintes critérios:

a)    O comprador seleciona as requisições que farão parte da cotação.

b)    São definidos os fornecedores da cotação; conforme relacionamento Produto X Empresa (Fornecedor).

c)     O comprador envia a solicitação de cotação através do Portal de Compras para os fornecedores selecionados.

Observação: como para a Paradigma cada entrega de uma requisição (ordem de compra) é uma requisição independente, o comprador ao inserir uma requisição (entrega) em um processo de cotação, deverá incluir todas as outras requisições (entregas) que são referentes a mesma ordem de compra no ERP no mesmo processo de cotação.

Por conceito do Portal, para que o fornecedor esteja disponível para relacionamento na cotação, é pré-requisito que tenha sido cadastrado o relacionamento do Item X Fornecedor ou ele esteja cadastrado na categoria (Grupo de Produtos).

• Fornecedores respondem a cotação: os fornecedores respondem ao processo de cotação via Portal de Compras.

Diferenças de conceito:

a)    No Protheus a cotação deve ser feita sempre com a unidade de medida do fornecedor, já no Portal não há a opção para que o fornecedor escolha uma unidade de medida ou possa responder na sua unidade de medida, ou seja, o fornecedor sempre terá que responder a cotação na unidade de medida interna do item. Como não existe controle com relação à utilização da unidade de medida do fornecedor, a quantidade a ser apresentada para o fornecedor no portal será sempre a quantidade interna e não a quantidade do fornecedor.

b)    O Portal possui o conceito de que o fornecedor informa o preço bruto da mercadoria, e o sistema calcula internamente o preço líquido. Para que o preço líquido entre os dois sistemas esteja equalizado, devem ser seguidas as regras do documento DefinicaoCalculoPreco_Paradigma.docx (disponível no portal Paradigma) para o cálculo do preço no Portal.

c)     Como a Paradigma controla o preço do fornecedor com 4 decimais e o ERP com 6, podem ocorrer pequenas diferenças entre os preços calculados entre os dois sistemas.

d)    Ao gerar a cotação o Portal possui alguns agrupadores de itens, sendo que várias ordens de compra podem gerar um item na Cotação da Paradigma com a soma das quantidades. Neste caso, o item possui várias entregas que serão as requisições (ordens de compra).

e)    O fornecedor no Portal pode informar uma quantidade inferior da requisição, como o ERP não permite isso, a Paradigma parametrizará para que o fornecedor não altere a quantidade solicitada, ou seja, a resposta será sempre igual a solicitada.

• Comprador Encerra o item de cotação: o comprador analisa as respostas dos fornecedores, seleciona a cotação vencedora e encerra o item de cotação. Neste momento, ocorre o envio de um documento de integração para o ERP (Dados das Respostas da Cotação) com todas as respostas dos fornecedores juntamente com a cotação vencedora.

O Portal não deve permitir que mais de uma proposta seja selecionada como vencedora, ou seja, para cada requisição da cotação, pode haver apenas uma proposta (fornecedor) como vencedora.

A alteração da cotação e cancelamento no Portal é permitida somente antes do encerramento da cotação, depois disso, após ser enviada ao ERP, apenas por intermédio dele poderá reabri-la em função de algumas situações. 

• Dados da resposta da cotação: como o Portal trabalhará de forma ativa, após o encerramento do item de cotação, ele será enviado para ser efetivado pelo ERP.

Uma vez que a cotação tenha sido retornada para o ERP, somente poderá ser disponibilizada novamente pelo Portal se o item estiver reaberto e encerrado novamente pelo comprador. No caso, quando ocorrem esses encerramentos em função de reabertura de itens, apenas os itens de cotação que foram reabertos serão retornados para o ERP.

Sobre a estrutura do processo de cotação no Portal:

­  Uma cotação pode conter diversos itens, ou seja, diversas ordens de compra.

­  Uma cotação pode conter diversas respostas de fornecedores.

­  Uma cotação pode conter diversas respostas do mesmo fornecedor para a mesma ordem de compra.

­  Uma solicitação de cotação (cotação do item do ERP) pode ser enviada ao fornecedor e ele declinar ou não responder. Neste caso, essas cotações não são retornadas ao ERP.

­  Propostas aceitas e desclassificadas pelos compradores são retornadas ao ERP, porém, somente serão gravadas as cotações aceitas.

Em função do Portal não permitir alteração na unidade de medida para que o fornecedor responda a cotação e no Protheus a cotação é realizada na unidade de medida do fornecedor, ao receber uma cotação, a unidade de medida e preço são convertidos conforme a unidade de medida e fator de conversão do relacionamento Item X Fornecedor.

Como as cotações são geradas baseadas nas entregas das propostas do item da cotação, para manter a rastreabilidade também será armazenado um código único (enviado pelo Portal) referente a entrega da proposta.

Como o ERP não possui controle de cotação por parcela da ordem de compra, ao gravar as informações de uma cotação aprovada na Paradigma, não será considerado o prazo de entrega da cotação para recalcular as novas datas de entrega, serão assumidas as datas informadas pelo fornecedor na Paradigma.

Caso ocorram erros na efetivação da cotação vencedora no ERP, será enviada uma mensagem para reabertura de item de cotação no Portal para que possa ser corrigido e a cotação reenviada ao ERP.

• Geração automática do pedido agrupando todas as ordens de uma cotação por fornecedor vencedor: junto à cotação já virá o fornecedor vencedor da cotação, assim, em função dessa estrutura e de que o Pedido de Compra no Portal pode ser referente somente a uma cotação, ao chegar uma cotação do Portal será gerado um pedido que agrupará as ordens de compra conforme o que foi feito no Portal, ou seja, por cotação e fornecedor vencedor.

Para que o usuário possa manter a rastreabilidade entre o processo de cotação do Portal e o pedido no ERP, será armazenado o número da cotação nos pedidos criados e terá opção de consulta na tela de pedidos por número da cotação trazendo todos os respectivos pedidos.

• Reabertura de item de cotação na Paradigma: caso ocorram erros na efetivação da cotação vencedora vinda do Portal ou o processo seja reprovado no fluxo de aprovação do ERP, é enviada uma mensagem para a Paradigma contendo os dados para a reabertura do item da cotação. Nestes casos, será feita a reabertura do item da cotação na Paradigma para que seja realizada a correção do que gerou o problema, encerrar a cotação novamente e ela ser efetivada no ERP.

Como o controle será por item de cotações, se o comprador deseja gerar o pedido dos itens que foram efetivados com sucesso, isso será possível e ele poderá realizar a correção do item da cotação que deu problema posteriormente e gerar um pedido separadamente.

• Pedido passa pela aprovação interna do ERP: o pedido passa pela estratégia atual de aprovação interna no ERP (caso exista) e, uma vez aprovado, fica disponível para o comprador fazer o envio para o portal.
• Retorno do processamento dos pedidos no Portal: a plataforma do Portal faz o processamento da mensagem de integração (Dados do Pedido no ERP). Como a integração ocorre de forma síncrona e na própria mensagem única retorna um erro se não for processado com sucesso, caso contrário, o pedido não é sinalizado como enviado ao Portal para que possa ser enviado posteriormente.
• Fornecedor realiza Aceita/Recusa do pedido: o fornecedor realiza o aceite/recusa do pedido no portal.
• Dados do aceite do pedido no Portal: como o Portal trabalhará de forma ativa, ela enviará uma mensagem de aceite/recusa do pedido e o ERP vai ler esta informação.

Observação: se o pedido estiver recusado pelo fornecedor, o recebimento não será permitido, ou seja, ele será cancelado.

• Alterações e cancelamentos

Na integração existem ainda os fluxos alternativos que contemplam as alterações de ordens e pedidos, bem como, os cancelamentos.

Cancelamento de Pedido de Compra

• Comprador cancela/elimina o pedido de compra no ERP: se for necessário realizar o cancelamento do pedido, o procedimento deve ser feito no ERP, assim, nesta ação será enviado um documento de integração (Dados do Cancelamento do Pedido) para que o Portal também faça o cancelamento.
• Dados para o cancelamento do pedido: os dados do cancelamento do pedido são enviados para o Portal.
• Retorno do cancelamento do pedido no portal: o cancelamento do pedido também é executado de forma síncrona com o Portal, pois, não é possível deixar o pedido ser eliminado no ERP sem saber se pode ser extinto no Portal.

Cancelamento de Ordem de Compra

• Comprador cancela/elimina a requisição no Portal: se for necessário realizar o cancelamento da requisição, o procedimento deve ser feito no Portal de compras. Nesta ação será enviado um documento de integração (Dados do Cancelamento da Requisição no ERP) para que o cancelamento também seja feito no ERP.

No processo de cotação, se o usuário eliminar uma Requisição (ordem de compra) da cotação e informar que ela não deve ser liberada para ser utilizada em uma nova cotação, ela deve retornar como uma requisição cancelada para o ERP.

Observação: uma vez enviadas ao ERP, não serão mais ser enviadas.

• Dados para eliminação da ordem de compra no ERP: a requisição é cancelada no ERP com base nos dados enviados pelo Portal.

Como no Portal podem existir diversas requisições para a mesma ordem de compra, o cancelamento de uma requisição pode representar a eliminação de uma parcela no ERP, portanto o Portal obrigará o cancelamento de todas as parcelas da requisição no Portal para que seja cancelada a ordem de compra no ERP.

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

Parâmetros

MV_EAIMETH: receiveMessage

MV_EAIURL2: coloque o endereço do ambiente do Marketplace. É necessário verificar no caso de implantação.

MV_EAIWS:  WSEAISERVICE

MV_EAIXSD: \xsd\totvsmessage

MV_MKPLACE: quando houver integração com o Marketplace deixe o parâmetro como .T.

WebService

O WebService é fundamental para integração das funcionalidades do TOTVS – Protheus com o Portal MarketPlace Paradigma.

O WebService deve estar com o Serviço EAISERVICE - HABILITADO, como segue figura abaixo:

Configuração do appserver.ini a ser realizada no ambiente do cliente.

;===========   WEBSERVICE MARKETPLACE  ============

 [HTTP]

Enable=1

Port=8096

Path=C:\TOTVS\P11\Protheus_Data\WEB\WS

[JOB_WS_TMP_PRD]

TYPE=WEBEX

ENVIRONMENT=Protheus_TMp

INSTANCES=5,10

SIGAWEB=WS

INSTANCENAME=WS

ONSTART=__WSSTART

ONCONNECT=__WSCONNECT

TRACE=1

XMLSAVEALL=1

 [192.168.2.253:8096]

ENABLE=1

PATH=C:\TOTVS\P11\Protheus_Data\WEB\WS

ENVIRONMENT= Protheus _TMp

RESPONSEJOB=JOB_WS_TMP_PRD

INSTANCENAME=WS

DEFAULTPAGE=wsindex.apw

[186.255.47.249:8096]

ENABLE=1

PATH=C:\TOTVS\P11\Protheus_Data\WEB\WS

ENVIRONMENT= Protheus _TMp

RESPONSEJOB=JOB_WS_TMP_PRD

INSTANCENAME=WS

DEFAULTPAGE=wsindex.apw

[ONSTART]

JOBS=JOB_WS_TMP_PRD

REFRASHRATE=180

RefreshRate=120

Acessando o Configurador, Menu Ambiente – Schedule – Schedule                                                  

Schedules já configurados:

Image Added

Configuração do Agent:

Image Added

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.

Monitor do Agent:

Image Added

Agendamentos:

Image Added

Após cadastro do Agendamento, deve-se configurar a Recorrência, clicando no botão Image Added e configurando conforme tela abaixo:

Image Added

RM

Insira aqui as informações pertinentes ao RM.

Instalação/Atualização

Este tópico tem por objetivo orientar a instalação da integração, visando o seu funcionamento completo. Instalação de produtos ou ferramentas necessárias podem referenciar outros documentos existentes, desde que estejam disponíveis no repositório de documentação da TOTVS ou sejam enviados junto com o documento da integração em si. As informações mínimas necessárias para teste tópico são:

• Procedimentos que devem ser observados quando um dos produtos for atualizado.
• Configuração necessária que deve ser realizada em arquivos de configuração ou programas de parâmetros etc.
• Arquivos diversos que devem ser mantidos em determinados locais para o funcionamento da integração, exemplo: xml, xsd.
• Atualizações necessárias em banco de dados ou instruções para que elas sejam feitas.
• Processos, módulos ou programas que precisam ser instalados ou atualizados. Deve ser definida a versão mínima necessária dos programas envolvidos.
• Ferramentas, servidores ou serviços que precisam ser disponibilizados e configurados, o que pode gerar necessidade de novo hardware ou aumento de capacidade. Exemplo: serviço de WebService.
• Instruções para habilitar a comunicação da ferramenta EAI entre as partes, quais rotas devem ser definidas ou como as transações devem ser habilitadas.

Observação: evite o uso de Prints de telas, facilitando, assim, o trabalho de tradução e versionamento deste documento.

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 Added

Image Added

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

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

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>

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)

Tratamento de erros de integração (Produto B)

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.

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.