Integração TOTVS APS x Protheus

Contexto de negócio

O TOTVS APS é uma ferramenta avançada de planejamento da produção, que é executada independente do ERP. Têm como principais características: a rapidez e desempenho no processamento; a precisão nas programações geradas; a elevada capacidade de refletir a realidade operacional dos diferentes sistemas de produção e a alta tecnologia com que são desenvolvidos.

Veja abaixo o que o TOTVS APS pode responder:

• O que, quanto e quando produzir;
• O que, quanto e quando comprar;
• Em que máquina produzir;
• A que horas começar;
• Quando liberar o material para a fábrica;
• Qual a melhor sequência de produção/setups;
• Como reagir a eventos inesperados;
• A necessidade de turnos adicionais ou horas extras;
• Quando será possível entregar cada pedido;
• O que está restringindo a produção;
• Onde investir para melhorar a entrega.

Sendo que os Resultados gerados são:

• Mais precisão nos Prazos de Entrega;
• Redução das Despesas Operacionais;
• Diminuição do lead-time de produção;
• Flexibilização da Produção;
• Agilidade nas Reprogramações;
• Aumento no Ganho pela Otimização das Restrições;
• Redução dos Estoques de matéria-prima, processo e produto acabado.

O TOTVS APS necessita de várias informações oriundas do ERP para realizar o planejamento de produção, tais como a lista de materiais, processos de fabricação dos produtos, ordens de compra, produção em andamento, pedidos e previsões de venda, posição de estoque entre outros.

Esta integração viabiliza aos clientes TOTVS que utilizam o ERP Protheus como seu sistema de gestão empresarial usufruir dos benefícios do sistema APS. 

Configuração da Integração APS x Protheus

Existem três pontos de integração do APS com o Protheus:

1. Atualização de Dados - Planejamento: responsável por buscar no ERP as informações que o APS necessita para realizar o Planejamento da Produção. Devido ao alto volume de dados, neste ponto o APS irá buscar as informações via acesso direto ao banco de dados do Protheus;

2. Atualização de Dados - Pontos de Controle: o APS também irá acessar via banco de dados às informações do Protheus necessárias para o controle de produção realizado pelo gerenciamento de pulmões (módulo Buffer Management);

3. Confirmação da Programação: o APS irá enviar ao Protheus as informações necessárias para confirmação de ordens de produção e compras, via Web Services Protheus.

A Confirmação de Programação realiza os seguintes passos:

1. A Confirmação gera a mensagem com as informações a serem enviadas ao Protheus (Ordens de Compra, Produção e Operações).
2. O WS Protheus tenta gravar as informações no Protheus.
3. O WS retorna o número dos documentos criados (OPs, operações e OCs) e / ou os erros encontrados ao tentar criá-los no Protheus.

1. Protheus

1. Verificar se o Protheus está atualizado na última versão disponível;

Eis a lista das rotinas utilizadas para integração APS e Protheus. No ambiente do cliente, todas essas rotinas devem estar com data igual ou superior as indicadas abaixo.

A versão do programa pode ser verificada no Inspetor de objetos do Protheus:

2. O banco de dados do ERP Protheus deverá ser Oracle ou MS-SQL. Para isso, configurar o arquivo appserver.ini do servidor do Protheus, informando na propriedade “TopDatabase” a string referente ao banco do Protheus (“MSSQL” para SQL Server e “ORACLE” para Oracle)

3. Criar uma fonte de dados (ODBC) da base de dados do Protheus para que o APS possa acessá-lo;
4. Parâmetros: para acessar a tela de parâmetros, execute o Protheus e informe na tela de Parâmetros Iniciais, o Programa Inicial SIGACFG. Configure os seguintes parâmetros:

• Preencher parâmetro MV_APS com TOTVS;
• Caso deseje utilizar quantidades negativas no Protheus, deverá habilitar o parâmetro MV_NEGESTRUT;
• As ordens que forem geradas pelo TOTVS APS não sofrerão efeito dos parâmetros MV_GERAOPI e MV_GERASC (utilizados no Microsiga Protheus para gerar Solicitações de Compras e Ordens de Produção dos semielaborados). Isso ocorre porque o TOTVS APS envia ao Microsiga Protheus tudo que deve ser criado de SCs e OPs. As ordens de produção criadas no Protheus continuam respeitando os parâmetros acima citados;

5. Obter licenças para Web services do Protheus: para a utilização de web services no Protheus são necessárias liberações de licenças do tipo TOTVS I;
6. Executar o programa update para criação da tabela de operações da ordem SHY: na entrada do Protheus digitar o programa U_UPDPCP16. O programa tem interface de Wizard. Basta avançar os passos selecionando as opções conforme vão aparecendo e concluir.

7. Configurar Web Services Protheus:

• Parametrizar um WebServices do Protheus para cada filial envolvida na integração. Exemplo: Filial 1 – http://servidor:8010/ws1; Filial 2 – http://servidor:8010/ws2;
• Cada WebService deve possuir pelo menos um agente ativo e disponível para integração com APS, pois são geradas chamadas simultâneas para ordem de compra, ordem de produção e operação. Para garantir um bom desempenho na integração é sugerido, no mínimo, a utilização de cinco JOBS (cinco licenças) para cada filial que executará o planejamento APS x Protheus;
• Configuração do .ini do Protheus com web services, esse ponto é vital para o funcionamento da integração, os web services deverão estar parametrizados conforme o exemplo abaixo:

[HTTP]
ENABLE=1
PATH=C:\p10\Protheus_Data\web\ws
PORT=8010
ENVIRONMENT=ENVIRONMENT
UPLOADPATH=\Protheus_Data\web\ws

[JOB_WS_0101]
TYPE=WEBEX
ENVIRONMENT=ENVIRONMENT
INSTANCES=5,5
SIGAWEB=WS
INSTANCENAME=WS
ONSTART=__WSSTART
ONCONNECT=__WSCONNECT
PREPAREIN=01,01
[localhost:8010/ws]
ENABLE=1
PATH=C:\p10\Protheus_Data\web\ws
ENVIRONMENT=ENVIRONMENT
INSTANCENAME=WS
RESPONSEJOB=JOB_WS_0101
DEFAULTPAGE=wsindex.apw
[ONSTART]
JOBS= JOB_WS_0101
Os parâmetros que serão modificados são:
a. ENVIRONMENT: Colocar o ambiente. Exemplo: PRODUCAO, TESTE, DESENVOLVIMENTO;
b. PORT: Endereço da porta que rodará o serviço (pode ser qualquer uma disponível);
c. [JOB_WS_0101]: Nome do JOB Responsável pelo serviço (É sugerido utilizar algo pra identificar que o JOB é referente a uma determinada Empresa e Filial) Exemplo: JOB_WS0101, JOB_WS0102;
d. INSTANCES: O Primeiro valor antes da vírgula se refere à quantidade de JOBS que iram iniciar junto do serviço. O segundo valor é referente ao Número de JOBS para executar o serviço (sugerimos ao menos cinco para bom desempenho). Exemplo: INSTANCES=3,5. Reservo cinco Jobs para o meu serviço, porem inicio apenas três. Se for necessário usar os outros dois Jobs, ele irá verificar se eles estão disponíveis, e daí utilizar o serviço. Sugerimos que a quantidade de Jobs reservada e iniciada sejam as mesmas, pois já é reservado o numero necessário para a integração, tendo um bom desempenho.
e. PREPAREIN: O primeiro valor antes da vírgula se refere ao código da empresa cadastrada no ambiente Protheus. O segundo valor é referente ao código da filial. Exemplo: PREPAREIN=01,01;
f. [localhost:8010/ws]: Deve-se colocar no formato <Servidor>:Port/<Nome do WS dessa filial> Exemplo: Server:8010/ws_01;
g. RESPONSEJOB: Deve ser o nome do JOB parametrizado conforme o tópico ‘c’;
h. JOBS: Deve ser parametrizado com os Jobs de todas as filiais separados por vírgula ex: JOB_WS0101, JOB_WS0102;
i. Caso se tenha mais filiais, deve-se repetir dos passos C ao G para cada filial, e também colocar nos JOBS (tópico h), o nome do JOB responsável por cada filial adicionada.

8. Atualizar clientes dos WebServices que serão utilizados pela integração, que são: MTPurchasesRequest, MTProductionOrder e MTIntegrationAPS;

1.1. Atualizando Client WebServices

1) Através de um navegador de internet, acessar a lista de serviços do WS Protheus (através da URL utilizada no totvsappserver.ini). Clicar no serviço a ter o client atualizado. Exemplo: http://servidor:8010/ws1

2) Na tela seguinte serão apresentados os detalhes do serviço acessado. Clicar no link a direita do texto “Descrição do Serviço (WSDL)”.

3) Após clicar no link será aberta uma nova janela no navegador. Nesta janela deverá ser copiada a URL contida na barra de endereços.

4) Acessar o Totvs Developer Studio (Protheus) e acessar o menu Arquivo/Novo, em seguida acessar o menu Ferramentas/Gerar Client WebService.

5) Na janela exibida, informar a URL copiada e confirmar. No novo arquivo será gerado o código do client ws.

6) Salvar o arquivo com um nome qualquer, adicioná-lo ao projeto e compilar. Se não ocorrerem erros o processo esta finalizado.

7) Caso seja gerado um erro acusando “classe duplicada” o arquivo deverá ser salvo com nome idêntico ao apresentado na mensagem de erro (logo após as palavras “Encontrada em”).

8) Remova o arquivo antigo do projeto, adicione o novo e compile-o. Se não ocorrerem erros, o processo está finalizado.

9) Para integração APS x Protheus: gerar o client dos serviços:

a. MTINTEGRATIONAPS
b. MTPRODUCTIONORDER
c. MTPURCHASESREQUEST

10) No log do Protheus podem ser encontradas as mensagens de erro ocorridas durante seu uso. Seguem abaixo as mais comuns e como proceder para sua correção.

2. TOTVS APS

A partir da release Datasul 11.5.3, a parametrização ocorre na rotina DB1000 – Parâmetros Planejamento Avançado e as informações requeridas são:

• Diretório Retorno: informar o diretório das informações de retorno do ERP para o APS, após a confirmação da programação. Neste diretório serão gravadas informações referentes a ordens de produção (e suas operações) e ordens compras criadas no ERP, que serão utilizados pela rotina Monitor de Integração APS (DB0299). Deve ser preferencialmente um diretório de rede, pois será utilizado pela sessão do Agente EAI Receiver para gerar os arquivos necessários para o Monitor de Integração APS (DB0299);
• Empresa: A empresa informada se refere à empresa do Protheus e é extremamente importante a parametrização, pois sem isso será impossível executar o procedimento de atualização de dados. Ex.: Se a tabela do banco de dados for SB1010 significa que sua empresa no Protheus é a 01;
• Servidor: nome do servidor em que a base de dados do Microsiga Protheus está hospedada. Este campo não é obrigatório quando o banco é Oracle, pois a conexão é feita somente pelo Datasource, utilizando o servidor que está gravado no arquivo TNSNAMES.ORA dentro da instalação do Oracle. Já para banco SQL Server é este campo é obrigatório (se a base estiver na mesma máquina do APS, pode ser informado o valor “localhost”);
• Datasource: informar a string com o DSN (Data Source Name ou Nome de Fonte de Dados);
• Usuário: informar o usuário do banco do Protheus (seja ele SQL ou Oracle). Caso não haja um usuário, é necessária a criação do mesmo com, no mínimo, permissões de leitura;
• Senha: Senha da base de dados do usuário informado.

A partir da release Datasul 11.5.8 foram implementadas as seguintes opções:

• ERP Origem: ERP que será integrado com o TOTVS APS;
• Banco de Dados: Banco de dados do ERP integrado com o TOTVS APS;
• Testar Conexão: efetua um teste de conexão com o Banco de Dados, conforme os valores inseridos.

Eis abaixo um exemplo de conexão com os bancos Oracle e SQL Server:

Parametrização DB1000 com Banco Oracle – Release Datasul 11.5.8:

Parametrização DB1000 com Banco SQL Server – Release Datasul 11.5.8:

IMPORTANTE:

• Caso ocorra erro de conexão, tentar realizar a conexão do banco de dados utilizando um software específico para a fornecedora de banco de dados. No caso do Oracle, utilizar SQL Plus ou SQL Tools e no caso do SQL Server usar o SQL Managenement Studio;
• Na release Datasul 11.5.7 e anteriores é necessário habilitar a integração com Protheus por intermédio da rotina CD7070 - Liberação de Função Especial, ativando a função “integra-aps-protheus”. Se a banco de dados do Protheus for Oracle, habilitar também a função “protheus-oracle”;
• O botão de teste de conexão e as opções de seleção de ERP e Banco de Dados estão disponíveis apenas para as releases Datasul 11.5.8 e superiores.

3. Confirmação com WebService Protheus

A partir do release 12.1.4 é necessário informar os WebService para cada Estabelecimento do Protheus, isso deve ser realizado no programa DB0136 Cadastro de estabelecimentos do APS.

4. Características da Integração

4.1. Acesso as tabelas no Protheus: Exclusivo x Compartilhado

A integração contempla as situações de tabelas compartilhadas e exclusivas existentes no Protheus, sendo que existem algumas restrições que devem ser respeitadas:

• Estrutura: Não podem existir estruturas diferenciadas para um mesmo item, independente se as tabelas de estrutura e item estejam configuradas como compartilhadas ou exclusivas.
  - Caso exista estrutura para mais de uma filial, somente a da primeira filial será considerada;
  - Um mesmo código de item não poderá existir em mais de um estabelecimento, pois o controle de Item do APS não é por estabelecimento. Ex: Item 00A41 vinculado ao Estab 1 e 2, sendo que no Estab 1, ele possui a descrição “Madeira” e no Estab 2 possui a descrição “Chapa de Aço”
• Para alguns cadastros do Protheus, há uma limitação quando usados de forma exclusiva. Para estas entidades, quando houver registros de filiais distintas, porém de mesmo código, sempre será considerado o primeiro registro encontrado, desconsiderando-se os demais. São estas entidades:
  - Recursos;
  - Tipo de Produtos;
  - Ferramentas;
  - Centro de Trabalho;
  - Grupo de Produtos;
  - Unidade de Medida.
• Empresa: a integração APS x Protheus é monoempresa, ou seja, o APS só lê dados de uma só empresa do Protheus.
  Assim, para cada empresa existente no Protheus, seria necessário uma base do APS (bancos mgdbr e movdbr)

4.2. Entidades / Transações em comum

Na Atualização de Dados do Planejamento, o APS acessa o banco de dados Protheus para busca de dados das seguintes entidades:

(*) Para essas tabelas é necessário que o modo de acesso seja compartilhado. Caso o modo de acesso seja exclusivo e haja duplicidade de código do registro, será trazido para o APS somente o primeiro registro encontrado.
Na Atualização de Dados do Pontos de Controle, o APS acessa o banco de dados Protheus para busca de dados das seguintes entidades.

Na Confirmação da Programação, o APS utilizam as seguintes transações para integração:

4.3. Entidades que não são importadas do Protheus

As tabelas listadas abaixo foram entidades identificadas no APS que não possuem correspondência nas tabelas do Protheus, ou não podem ser importadas porque no Protheus não estão gravadas em base de dados. Para cada caso foi adotada uma solução conforme segue.
Note que algumas entidades são de cadastro obrigatório para o funcionamento do APS.
Tabelas em que serão utilizadas informações cadastradas no APS:

Tabelas em que serão criadas com somente um registro (valor fixo):

Tabelas que não serão consideradas:

As entidades abaixo não serão utilizadas na integração. O APS não trata o conceito de grade existente no Protheus. E para o APS não virão itens com referência.

4.4. Campos do APS e seus correspondentes no Protheus

São os campos que são atualizados no APS através dos dados do Protheus. Os campos que não existem no Protheus podem ser atualizados diretamente no APS. Ao executar novamente o passo da atualização, essas alterações não serão sobrescritas. Porém se o campo existir no Protheus, ou tiver algum correspondente, ele será sobrescrito com o valor vindo do Protheus toda vez que for rodado a atualização e solicitado para atualizar tal tabela.

Nas tabelas abaixo estão os campos das principais entidades que serão atualizados do Protheus. Os demais campos são informados diretamente no APS.

4.4.1. Família Materiais

4.4.2. Item Manufatura

Campos sem correspondente no Protheus: Fator Refugo, Horizonte Fixo, Período Fixo, Quantidade Perda, Ressupr Compras, Ressupr CQ Compras, Prioridade, Planejador, Antecipação, Lote Mínimo, Lote Máximo, Arredonda Sobra, Divide Ordem.

4.4.3. Ferramenta Produção

4.4.4. Turno Exceção

4.4.5. Grupo de Máquinas (Centro de Trabalho)

4.4.6. Centro de Trabalho (Recurso)

4.4.7. Centro de Trabalho Válido

Eficiência Centro de Trabalho e Performance CT Válido.

Os campos serão alterados somente na primeira atualização do registro, a partir das seguintes, será mantido o valor informado no APS. Ou seja, sempre que um CT ou CT Válido não existir no APS, o mesmo será atualizado com o valor informado no Protheus, senão será mantido o valor do APS.

Performance do CT Válido.

Existem 3 formas de atualizar os CT Válidos:

1) Recurso alternativo do cadastro de recurso. O campo Performance corresponde ao “M.O.(efic)” (H1_MAOOBRA) do cadastro do recurso alternativo multiplicado por 100.

Image Added

Image Added

2) Recurso informado na operação: O campo Performance correspondente ao “M.O.(efic)” (H1_MAOOBRA) do cadastro do recurso informado multiplicado por 100.

Image Added

Image Added

3) Recurso alternativo da operação: O campo Performance corresponde ao “Efic” (H3_EFICIEN) informada na tela do alternativo.

Image Added

Observações:

• O campo eficiência do Centro de Trabalho e performance do CT Válido no APS possui o limite de 999.9 e 999.99, respectivamente, enquanto no Protheus esse limite pode ser ultrapassado. Quando exceder o limite, a atualização de dados considerará o valor padrão do campo, ou seja, 100%, além de informar o usuário sobre essa ação e o motivo.

4.4.8. Operações da Ordem de Produção

IMPORTANTE: Não existe tela para consulta dessas informações no APS(op-ord-dbr) e Protheus (SHY).

4.4.9. Roteiro Fabricação – Operações

Campos sem Correspondente no Protheus: Tempo Significativo, Lote Padrão, Lote Múltiplo, Lote Mínimo.

4.4.10. Roteiro Fabricação – Relação Item x Roteiro

Importante: Caso o valor do roteiro de fabricação no Protheus seja diferente de 01 ou exista mais de um roteiro, este roteiro deve ser informado no campo Rt. Op. Padrão (campo B1_OPERPAD da tabela SB1) no Cadastro do Produto (MATA010), caso contrário o APS importará o roteiro 01.

Image Added

Integração

O que levou a criação da integração / o porquê da integração (Finalidade/Objetivo), de forma macro, o que será integrado do, por exemplo, Vertical com o ERP (BackOffice)

Explique o contexto de negócio ou do problema na qual esta integração estará inserida. Isto inclui o funcionamento da(s) ponta(s) envolvida(s).

Apresentar a integração como uma melhoria para o cenário ou como uma solução para o problema.

• Premissas
  Gerais, do Vertical, do BackOffice e dos demais artefatos/sistemas envolvidos
  Premissas Gerais
  Premissas A
  Premissas B

• Arquitetura (Tecnologia)

Escopo

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

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.

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:

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>

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.

Anexos