Histórico da Página
EGRAÇÃO
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 contempla 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 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 Supre as 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 fornecedorFornecedor, 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 compraSolicitaçã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 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 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 Exceções serão detalhadas na sequência.
Dados do Cadastro incluído ou alterado enviados para o Paradigma: cadastros Cadastros que serão integrados:
- Moeda:ficou definido que a moeda 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 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
- , somente estabelecimentos brasileiros serão enviados para a Paradigma.
- Fornecedor (Paradigma trata como Empresa Vendedora): mensagem 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,
- será gerada uma senha para acesso no Portal com o número do CNPJ, assim, quando o fornecedor acessar o portal pela primeira vez,
- será 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 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 Mensagem única UnitofMeasure_2_000.xsd.
- Produto: mensagem Mensagem única Item_3_000.xsd.
- Compradores (Paradigma trata como Usuário): mensagem 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,
- será gerada uma senha para acesso no Portal
- que será 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,
- será 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 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.
Caso as entidades estejam configuradas como compartilhadas, 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.
A entidade Compradores configurada como compartilhada não necessita de vínculo manual. - Dados de retorno do processamento do Dados de retorno do processamento do cadastro na Paradigma (sucesso ou erro):conforme mencionado, os processos Os processos de envio e recebimento de mensagem única 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 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 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 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
- conter datas de entrega menores que a data atual, caso contrário também não
- poderão ser enviadas.
Observação:
- Para as ordens de compra que
- possuam mais de uma entrega, a cada entrega da ordem será criada uma requisição diferenciada na Paradigma.
- Dados da requisição no ERP:o 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
- seja criada.
- Retorno do processamento da requisição no Portal:a 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 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 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 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 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 écotação ser 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
corrigidocorrigida 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 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 possa 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á a 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 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, é será 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 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 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 O fornecedor realiza o aceite/recusa do pedido no portal.
- Dados do aceite do pedido no Portal: como 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 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 Os dados do cancelamento do pedido são enviados para o Portal.
- Retorno do cancelamento do pedido no portal:o 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 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
- enviadas.
- Dados para eliminação da ordem de compra no ERP:a 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.
MV_ACCISV: Informar o código de um usuário Comprador devidamente integrado ao portal Marketplace.
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:
Configuração do Agent:
Monitor do Agent:
Agendamentos:
Após o cadastro do Agendamento, deve-se configurar a Recorrência, clicando no botão 
e configurando conforme tela abaixo:
Tabelas envolvidasEnvolvidas
- Cadastro de Produto – SB1.
O cadastro de Produto deve ter todos os campos obrigatórios do sistema preenchidos.
- Cadastro de Complemento de Produto – SB5.
Pasta Cadastrais:
- SB5->B5_COD: campo Código do Produto.
- SB5->B5_CEME: campo Nome Científico do Produto.
Pasta Outros:
SB5->B5_ENVMKT: campo Envia MKT. Apresenta as opções:
0 – Não: não realiza a integração.
1 – Sim: sempre envia Solicitações com este produto.
2 – Talvez: prepara Solicitação para envio; só é enviada com intervenção do operador.
Detalhes para criação do campo SB5->B5_ENVMKT:
Controle de Integração
Caso haja a necessidade de se integrar alguma entidade apenas em condições específicas, será necessário a criação do campo _INTMKT na entidade em questão, e adicionar o campo criado na condição do cadastro do adapter referente a entidade conforme o exemplo:
Integrar apenas Produtos produtos com o campo _INTMKT = 1-Sim:
- Crie o campo B1_INTMKT como combo com opções 1-Sim; 2-Não.
- Coloque no campo Condição do Cadastro de Adapters a seguinte expressão: B1_INTMK == ‘1’.
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.
Cadastro de Adapters
Centro de Custo
Item
Fornecedor
Coloque no campo Condição a seguinte expressão: !Empty(SA2->A2_CGC) .And. !Empty(SA2->A2_EMAIL) .And. !Empty(SA2->A2_CONTATO) .And. SA2->A2_TIPO <> "X"
Produto X Fornecedor
Coloque no campo condição a seguinte expressão: SA2->( DbSeek(xFilial("SA2")+SA5->A5_FORNECE + SA5->A5_LOJA ) ) .And. !SA2->A2_TIPO == "X"
Comprador
Coloque no campo Condição a expressão: !Empty(SY1->Y1_EMAIL)
Solicitação de Compra
Cancelamento de Solicitação de Compra
Pedido de Compra
Cotação
Condição de Pagamento
Unidade de Medida
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.
Transações / Entidades / Mensagens únicas
Método | ID | Descrição | Origem | Destino | XSD (versões podem variar) |
Cadastros | 01 | Centro de Custo | Protheus | Marketplace | CostCenter_2_000.xsd |
02 | Produto | Protheus | Marketplace | Item_2_000.xsd | |
03 | Comprador | Protheus | Marketplace | User_4_001.xsd | |
04 | Condições de pagamento | Protheus | Marketplace | PaymentCondition_2_000.xsd | |
| 05 | Unidade de medida | Protheus | Marketplace | UnitOfMeasure_2_000.xsd | |
| 06 | Fornecedor | Protheus | Marketplace | CustomerVerndor_2_000.xsd | |
| 07 | Produto X Fornecedor | Protheus | Marketplace | ProductSupplierRealationship_2_000.xsd | |
Processos | 08 | Solicitação de Compras | Protheus | Marketplace | Request_1_005.xsd |
| 09 | Cancelamento da Solicitação de Compras | Protheus | Marketplace | CancelRequest_1_000.xsd | |
10 | Pedido de compra | Protheus | Marketplace | Order_3_002.xsd | |
11 | Cotação | Protheus | Marketplace | Quotation_1_000.xsd |
Transações/Entidades/Mensagens únicas
Método | ID | Descrição | Origem | Destino | XSD (versões podem variar) |
Cadastros | 01 | Fornecedor | Protheus | Marketplace | CustomerVendor_1_000.xsd |
02 | Unidade de Medida | Protheus | Protheus | UnitOfMeasure_1_000.xsd | |
04 | Produto | Protheus | Protheus | Item_?_000.xsd | |
05 | Centro de Custo | Protheus | Protheus | CostCenter_1_000.xsd | |
12 | Condições de pagamento | Protheus | Protheus | PaymentCondition_1_000.xsd | |
Processos | 15 | Solicitação de Compras | 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) | Protheus | Protheus | CancelRequest_1_000.xsd | |
18 | Baixa de estoque | Protheus | RM | Request_1_000.xsd | |
19 | Baixa de estoque | Protheus | Protheus | Request_1_000.xsd | |
20 | Consulta Saldo | Protheus | RM |
|
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.Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas