Com a integração entre o ERP 2 e o Portal de Compras Paradigma (WBC – Web Business Center), que será responsável pela cotação de itens com diversos fornecedores, é possível agregar volumes de compras para cotação de preço, dentre outras vantagens. A integração proporciona uma automação da área de compras, pois todo o processo de respostas de cotações é realizado pelos próprios fornecedores no portal de compras da Paradigma. A geração de ordens de compra será realizada no ERP 2, e serão enviadas para o portal de acordo com a necessidade, para o tratamento pelo portal de compras. O processo de cotação e escolha dos vencedores é realizada no portal, sendo o pedido de compra gerado pelo ERP 2 e posteriormente enviado para o portal de compras da Paradigma.
Existe ainda um segundo fluxo nesta integração, onde o comprador pode realizar todo o processo até a geração do pedido de compra dentro do ERP e enviar então o pedido para o portal.
Além da integração de transações de negócio (ordens de compra, cotação e pedido) são integrados uma série de cadastrados para equalizar os dados utilizados entre os dois sistemas.
Contrato realizado com a Paradigma para utilização do portal de compras (WBC – Web Business Center).
Datasul EAI e TOTVS ESB instalados, configurados e ativos para a integração com o portal da Paradigma.
Nota:
TOTVS | ESB Server 12.2.3 ou superior;
TOTVS | Developer Studio 11.1;
TOTVS | ESB Plugin 12.2.3 ou superior.
Configurar os diagramas no ESB conforme orientações disponíveis em configurações do ESB.
Para realizar a carga de dados cadastrais na Paradigma, deve ser utilizado o programa de Carga de Dados via EAI (CD0323), selecionando a opção Marketplace (Paradigma). No programa serão listados todos os programas para realizar a carga de dados de cada entidade.
Nota:
É importante que seja executado o programa de conferência de dados antes de iniciar as cargas de dados, para identificar possíveis inconsistências.
Cálculo do preço líquido
É necessário realizar as configurações para o cálculo do preço líquido na Paradigma. Variáveis envolvidas no cálculo:
Manutenção de Parâmetros de Compra (CC0104)) como deve ser o cálculo;
Pré-requisitos das taxas a serem informadas no Paradigma:
Nota:
Para mais detalhes, veja o cálculo do preço líquido.
Abaixo são apresentados os dois fluxos de mensagens que são trocadas entre o EMS e o portal Paradigma: gestão de pedidos com cotação e gestão de pedidos sem cotação. Além disso, são apresentados os fluxos de mensagens de cadastros, alterações e cancelamentos de requisições (ordens de compra) e pedidos.
A Paradigma trata todas as suas transações como síncrona, porém para não prejudicar a performance do sistema, através do TOTVS ESB, as transações são tratadas de forma assíncrona. Ou seja, o retorno das mensagens será tratado como uma nova mensagem no EAI, onde se houverem erros, o usuário deverá corrigir e integrar novamente o registro em questão.
1. Usuário inclui ou altera um cadastro no ERP
Para equalização dos dados cadastrais entre os dois sistemas (Datasul EMS 2 e Paradigma) será realizada a integração de alg uns cadastros. A integração desses cadastros parte do ERP para a Paradigma, e ocorre quando há uma inclusão ou alteração de um registro. Eliminações não são tratadas.
A integração do sentido contrário da Paradigma para o ERP será realizada apenas para o cadastro de fornecedor. Apenas para o cadastro de fornecedor, quando for buscado um fornecedor do Clic Business para a base na empresa. Os demais cadastros que forem integrados devem ser bloqueados na Paradigma para que não haja incompatibilidade dos dados.
Nota:
Exceções serão detalhadas na sequência.
2. Dados do Cadastro incluído ou alterado são enviados para a Paradigma
Os cadastros que serão integrados são os seguintes:
Quando incluído um fornecedor no ERP e integrado com o portal pela primeira vez, é gerada uma senha para acesso no portal com o usuário sendo o número do CNPJ do fornecedor. Quando o fornecedor acessar o portal pela primeira vez, é solicitada a alteraçã o da senha.
Nota:
1. Como o EMS não obriga informar e-mail no cadastro, o portal irá realizar essa validação, e caso não esteja preenchido a mensagem será retornada com erro.
2. O EMS possui opção de deixar o fornecedor inativo por um determinado período, no final deste período o fornecedor é considerado automaticamente ativo. O Portal não possui esse tipo de controle, portanto para ativar o fornecedor no portal ao final do período, o cadastro deverá ser alterado para envio da mensagem de alteração.
3. Somente serão integrados com o portal os fornecedores que forem parametrizados para esse fim, esse controle estará disponível para o usuário no Cadastro de Fornecedores do ERP (CD0401).
4. O código do fornecedor na Paradigma terá a seguinte estrutura: for + <código do fornecedor no ERP>
Como não serão tratadas regras para outros países, somente estabelecimentos brasileiros serão enviados para a Paradigma;
Nota:
O código do estabelecimento na Paradigma terá a seguinte estrutura: est + <código do estabelecimento no ERP>
Nota:
O código do transportador na Paradigma terá a seguinte estrutura: tra + <código do transportador no ERP>
Nota:
Somente serão enviados para o portal os relacionamentos de item x fornecedor de fornecedores que possuírem integração com o portal de compras, configurado na função Cadastro de Fornecedores do ERP (CD0401).
Como é necessário vincular o usuário a uma única empresa ao enviar a integração, esse cadastro deverá ser habilitado para alt eração na Paradigma. Isso se faz necessário para que seja possível relacionar um usuário a mais de uma empresa.
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 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 (por isso é importante que essa informação esteja correta). Quando o usuário acessar o portal pela primeira vez, é solicitada a alteração da senha.
3. Dados de retorno do processamento do cadastro na Paradigma (sucesso ou erro)
A Paradigma trata todas as suas transações como síncrona, porém para não prejudicar a performance do sistema, através do TOTVS ESB, o processo foi tornado assíncrono. Ou seja, o retorno das mensagens será tratado como uma nova mensagem no EAI (Transaçã o “ReturnIntegrationErrors” no EAI), onde se houverem erros, o usuário deverá corrigir e integrar o cadastro novamente.
4. Busca o fornecedor do Clic business para a sua base de fornecedores
Quando o usuário atualiza o fornecedor no portal que estava disponível no Clic Business, esse fica pendente para integrar com o ERP.
5. Dados do fornecedor na Paradigma
6. Atualiza código fornecedor
Não ocorrendo nenhum erro na integração do fornecedor no ERP, o código do ERP desse fornecedor é atualizado no portal para manter a integridade entre eles.
No fluxo de gestão de pedidos com cotações, o processo de cotações das ordens de compra e escolha do fornecedor vencedor é realizado no portal de compras da Paradigma.
Detalhamento do fluxo:
1. O requisitante gera uma solicitação de compra no ERP.
Todo o processo de criação de requisição ou geração de ordens de compra serão feitos no ERP, sem nenhuma integração com o portal de compras.
2. Aprovador aprova solicitação no ERP.
A solicitação passa pela estratégia atual de aprovação interna no ERP (caso exista) e, uma vez aprovado, é enviada para o comprador fazer o tratamento necessário.
3. Comprador Gera Ordem de Compra.
O comprador analisa as solicitações em aberto, agrupa por item se necessário e gera a ordem de compra.
4. Comprador seleciona as ordens de compra para tratamento no portal.
O comprador seleciona as ordens de compra que deseja trabalhar através do portal de Compras e as envia, através da rotina “Envio de Ordens para o portal” (CC0324), que permite ao comprador selecionar as ordens que deseja enviar para o portal de compras.
Nota:
Podem ser enviadas ordens de compra que tenham sido originadas de requisições ou que foram criadas por outras rotinas no ERP.
Para que a ordem de compra possa ser enviada ao portal ela deve estar como “Não Confirmada”, não deve pertencer a um pacote de compra e não deve pertencer a um contrato. A ordem não precisa ter um comprador definido para ser enviado, ele poderá ser definido no portal. As parcelas da ordem de compra não devem ter datas de entrega menores que a data atual, caso contrário também não podem ser enviadas.
Nota:
Para ordens de compra que possuam mais de uma entrega (parcela), a cada entrega da ordem será criada uma requisição diferenciada na Paradigma (sendo que essas requisições sempre deverão ser tratadas em conjunto na Paradigma).
5. Dados da requisição no ERP.
O ERP gera um documento de integração (Dados da Requisição no ERP) – Transação “PurchaseOrderLine” no EAI.
Nota:
Após uma ordem de compra ter sido enviada ao portal, ela ficará congelada, sendo que neste caso não será permitida a eliminaç ão da ordem de compra. A eliminação, ou no caso cancelamento, somente poderá ser feito através da Paradigma. Os dados alterados da ordem de compra após ela ter sido enviada para a Paradigma são reenviados para que seja mantida a consistência entre os do is sistemas.
6. 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). (Transação “RequisitionOrderConfirm” e “ReturnIntegrationErrors” no EAI).
O retorno é efetivado no ERP, que atualiza se a requisição foi integrada com sucesso ou se ocorreram erros na integração. Os erros são listados através do EAI para o usuário possa consultá-los, corrigir e reenviar a ordem de compra.
Nota:
1. Consultar a situação na ordem de compra na consulta de ordens de compra (CC0505).
2. Não é necessário armazenar nenhum número de referência da Paradigma, pois o número da requisição no Portal será o mesmo do ERP. Neste caso o usuário tem a rastreabilidade das informações.
3. Caso tenha ocorrido erro na efetivação de alguma parcela na Paradigma, a ordem deverá ser marcada com erro, para que a situação seja corrigida e a ordem reenviada.
7. Comprador cria e envia cotação a partir da requisição.
Com a requisição salva 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). Neste processo temos:
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.
Nota:
1 - 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á inserir todas as outras requisições (entregas) que são referentes a mesma ordem de compra no ERP no mesmo processo de cotação.
2 - 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.
8. Fornecedores respondem a cotação.
Os fornecedores respondem ao processo de cotação via Portal de Compras. Diferenças de conceito:
a. No EMS a cotação deve ser feita sempre com na 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;
b. 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;
c. 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 para configuração de preço líquido já apresentadas anteriormente);
d. Como a Paradigma controla o preço do fornecedor com 4 decimais e o ERP com 5, poderão haver pequenas diferenças entre os preços calculados entre os dois sistemas;
e. Ao gerar a cotação a Paradigma 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);
f. Não será permitido ao fornecedor informar uma condição específica de pagamento que não esteja cadastrada no sistema.
9. 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 será enviado um documento de integração para o ERP (Dados das Respostas da Cotação – Transação “ProcessQuotations”) com todas as respostas dos fornecedores juntamente com a cotação vencedora.
A Paradigma não deve permitir que mais uma proposta seja selecionada como vencedora, ou seja, para cada requisição d a cotação, pode haver apenas uma proposta (fornecedor) como vencedor.
A alteração da cotação e cancelamento na Paradigma somente é permitida antes do encerramento da cotação. Após a cotação ter sido encerrada e enviada ao ERP, somente o ERP poderá reabri-la em função de algumas situações detalhadas posteriormente.
10. Dados da resposta da cotação.
Após o encerramento do item de cotação na Paradigma, ele fica disponível para ser buscado e efetivado pelo ERP. Uma vez que a cotação tenha sido retornada para o ERP, somente poderá ser disponibilizada novamente pela Paradigma caso o item tenha sido reaberto e encerrado novamente pelo comprador. No caso, quando ocorrem esses encerramentos em função de reabertura de itens, somente os itens de cotação que foram reabertos serão retornados para o ERP na nova busca.
Sobre a estrutura do processo de cotação na Paradigma:
Em função dessa estrutura, e de que o Pedido de compra na Paradigma somente pode ser referente a uma co tação, ao chegar uma cotação da Paradigma, será gerado um Processo de Compras, que agrupará as ordens de compra conforme o que foi feito na Paradigma. Após a criação do processo, são efetivadas as cotações, sendo que uma cotação da Paradigma, quando efetiv ada no ERP pode gerar diversas cotações (respostas de fornecedores).
Para que o usuário possa manter a rastreabilidade entre o processo de cotação da Paradigma e o processo de compra do ERP, a descrição do processo de compras criado no ERP será sempre o Código do processo da Paradigma (sendo que este não poderá se repetir para diferentes processos na Paradigma). O processo de compra também fica como integrado com a Paradigma, consultar na função Consulta Processo (OC0401).
Em função do portal não permitir alteração na unidade de medida para que o fornecedor responda a cotação e o EMS exige que a cotação seja realizada na unidade de medida do fornecedor, ao receber uma cotação, a unidade de medida e preço são convertido s conforme a unidade de medida e fator de conversão do relacionamento Item X Fornecedor.
Para manter a rastreabilidade entre os sistemas será armazenado no ERP além dos códigos internos de controle da Paradigma o “Código do processo”, através do qual o usuário consegue identificar a cotação na Paradigma.
Nota:
Consultar na função Consulta Cotações (CC0506).
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.
O Portal permite que o fornecedor informe preço proposto igual a R$ 0,00, caso isso ocorra o ERP irá bloquear a cotação para ajuste. Caso ocorram erros na efetivação da cotação vencedora no ERP, será enviada uma mensagem para reabertura de item de cotação na Paradigma, para que possa ser corrigido o problema e a cotação reenviada ao ERP.
11. Aprovador aprova ou recusa processo de compra.
O processo de compra passa pela estratégia atual de aprovação interna no ERP (caso exista) e, uma vez aprovado, o comprador pode fazer a geração do pedido.
12. 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, pode-se realizar 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, caso o comprador deseje gerar o pedido dos itens que foram efetivados com sucesso, isso será possível. E neste caso ele poderá realizar a correção do item da cotação que deu problema posteriormente e gerar um pedido separadamente.
13. Comprador gera pedido de compra no ERP.
Com base nas respostas vencedoras o comprador gera o pedido de compra no ERP. Neste caso o comprador terá que criar o pedido sempre se baseando no processo de compras que foi gerado para a cotação.
Nota:
Essa regra do processo de compra foi criada para atender a estrutura da Paradigma, que não permite que um pedido de compra tenha ordens de compra (requisições) referente a processos de Cotação distintos.
14. 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.
15. Comprador seleciona pedidos para tratamento no portal.
Comprador seleciona os pedidos e envia para o portal de compras, por intermédio da interface para envio de pedidos (CC0329). Para que o pedido possa ser enviado ao portal ele deve estar “Aprovado”, “Impresso" e não deve possuir uma condição de pagamento específica. Diferenças de conceito:
a. O portal não possui suporte a informação de condições específicas de pagamento, portando sempre será necessário informar uma condição de pagamento que não seja a “0 – Condição especial de pagamento”.
b. Os pedidos neste caso serão enviados sempre como Normais.
16. Dados do pedido no ERP.
É enviada uma mensagem de integração (Dados do Pedido no ERP) para criação do pedido no portal (Transação “PurchaseOrder” no EAI). O número do pedido do portal deverá ser o mesmo que o ERP para permitir a rastreabilidade entre os sistemas.
Neste momento do envio do pedido, é recalculado o valor líquido do pedido, pois podem ter ocorrido mudanças, e enviado o novo valor para a Paradigma, que assumirá o novo valor do pedido.
17. Retorno do processamento dos pedidos no Portal.
A plataforma do portal faz o processamento da mensagem de integração (Dados do Pedido no ERP ). Se ocorrer um erro no processamento, é devolvida uma mensagem contendo o código do erro e sua descrição, neste caso o pedido é marcado “Com Erro”. Se for integrado com sucesso o pedido é marcado como “Integrado”. (Transação “RequisitionOrderConfirm” e “ReturnIntegrationErrors” no EAI).
Nota:
Consultar situação do pedido na Função Consulta de Pedidos (CC0509).
18. Fornecedor realiza Aceita/Recusa do pedido.
O fornecedor realiza o aceite/recusa do pedido no portal.
19. Dados do aceite do pedido no Portal.
O ERP busca essa informação de aceite/recusa e atualiza esse dado no ERP.
Nota:
1. Caso o pedido esteja recusado pelo fornecedor, o recebimento não será permitido.
2. Consultar situação do pedido (aceite/recusa) no Função Consulta de Pedidos (CC0509).
1. Criação do Pedido no ERP.
O comprador gera um pedido de compra no ERP sem integração com o portal de compras.
2. Aprovação do Pedido no ERP.
O pedido passa pela estratégia atual de aprovação interna no ERP (caso exista) e, caso aprovado, é enviado para o comprador f azer o tratamento necessário. Esse passo também é realizado sem integração com o portal de compras.
3. Comprador seleciona pedidos para tratamento no portal.
Comprador seleciona os pedidos e envia para o portal de compras. Essa ação poderá ser realizada pela rotina de envio de pedidos para o portal (CC0329) ou no momento da impressão do pedido de compra (CC0305).
Para que o pedido possa ser enviado ao portal ele deve estar “Aprovado”, “Impresso” e não deve possuir uma condição de pagamento específica.
Diferenças de conceito:
a. O portal não possui suporte a informação de condições específicas de pagamento, portando sempre será necessário informar uma condição de pagamento que não seja a “0 – Condição especial de pagamento”.
b. Os pedidos são divididos em três categorias para serem enviados ao portal: Normal, emergencial e com contrato.
4. Dados do pedido no ERP.
É enviada uma mensagem de integração (Dados do Pedido no ERP – Transação “PurchaseOrder” no EAI) para criação do pedido no portal. O número do pedido do portal deverá ser o mesmo que o ERP para permitir a rastreabilidade entre os sistemas.
Neste momento do envio do pedido, é calculado o valor líquido do pedido e enviado o novo valor para a Paradigma.
5. Retorno do processamento do pedidos no Portal.
A plataforma do portal faz o processamento da mensagem de integração (Dados do Pedido no ERP). Se ocorrer um erro no processamento, é devolvida uma mensagem contendo o código do erro e sua descrição, neste caso o pedido é marcado “Com Erro”. Se for integrado com sucesso o pedido é marcado como “Integrado”. (Transação “RequisitionOrderConfirm” e “ReturnIntegrationErrors” no EAI).
Nota:
Consultar situação do pedido na Função Consulta de Pedidos (CC0509).
6. Fornecedor realiza Aceita/Recusa do pedido.
O fornecedor realiza o aceite/recusa do pedido no portal.
7. Dados do aceite do pedido no Portal.
O ERP busca essa informação de aceite/recusa e atualiza esse dado no ERP.
Nota:
Caso o pedido esteja recusado pelo fornecedor, o recebimento não será permitido.
Consultar situação do pedido (aceite/recusa) na Função Consulta de Pedidos (CC0509).
Na integração existem ainda os fluxos alternativos, que contemplam as alterações de ordens e pedidos, e também os cancelamentos.
1. Comprador altera o pedido de compra.
Após o pedido de compra ter sido enviado para a Paradigma a alteração do mesmo somente pode ser feita no ERP. Toda vez que el e for alterado, será enviada uma mensagem de atualização do pedido para a Paradigma assim que não houverem mais pendências de aprovação.
Caso o ERP envie uma mensagem de alteração de pedido de compra e na Paradigma ocorra algum problema na efetivação, será retornado um erro. Neste caso o usuário terá que desfazer a alteração do pedido manualmente no ERP para deixar as informações equalizadas entre os sistemas.
2. Aprovador aprova o pedido no ERP.
Caso esteja parametrizado para gerar pendências de aprovação, o pedido passa pelo fluxo de aprovação antes da atualiz ação ser enviada para Paradigma.
3. Dados do Pedido no ERP.
Quando não houverem mais pendências de aprovação, o pedido é enviado para a Paradigma. (Transação “PurchaseOrder” no EAI).
4. Retorno do processamento do pedido no portal.
A plataforma do portal faz o processamento da mensagem de integração (Dados do Pedido no ERP). Se ocorrer um erro no processamento, é devolvida uma mensagem contendo o código do erro e sua descrição, neste caso o pedido é marcado “Com Erro”, porém mantido como “Integrado” para saber se já foi integrado anteriormente e já está na Paradigma. (Transação “RequisitionOrderConfirm” e “ReturnIntegrationErrors” no EAI).
Nota:
Consultar situação do pedido na Função Consulta de Pedidos (CC0509).
5. Fornecedor aceita/recusa o pedido.
Cada vez que é enviada uma atualização de pedido para a Paradigma, o pedido passa pelo aceite do fornecedor novamente.
Nota:
Consultar situação do pedido (aceite/recusa) na Função Consulta de Pedidos (CC0509).
1. Comprador altera a ordem de compra.
Após a ordem de compra ter sido enviada para a Paradigma a alteração da mesma somente pode ser feita no ERP. Toda vez que ela for alterada, será enviada uma mensagem de atualização de requisição para a Paradigma.
2. Dados da ordem de compra no ERP.
Os dados da ordem de compra são enviados para a Paradigma. (Transação “PurchaseOrderLine” no EAI).
3. Retorno do processamento da ordem de compra no portal.
A plataforma do portal faz o processamento da mensagem de integração (Dados da requisição no ERP). Se ocorrer um erro no processamento, neste caso a ordem de compra é marcada “Com Erro”, porém mantida como “Integrada” para saber se já foi integrada anteriormente e já está na Paradigma. (Transação “RequisitionOrderConfirm” e “ReturnIntegrationErrors” no EAI).
Nota:
Consultar no CC0505.
Caso o ERP envie uma mensagem de alteração de ordem de compra e na Paradigma e ocorra algum problema na efetivação, será retornado um erro. Neste caso o usuário terá que desfazer a alteração da ordem manualmente no ERP para deixar as informações equalizadas entre os sistemas.
1. Comprador cancela/elimina o pedido de compra no ERP.
Caso seja necessário realizar o cancelamento do pedido, esse deverá ser realizado no ERP, nesta ação será enviado um document o de integração (Dados do Cancelamento do Pedido) para o portal também realize o cancelamento.
2. Dados para o cancelamento do pedido.
Os dados do cancelamento do pedido enviados para a Paradigma.
3. Retorno do cancelamento do pedido no portal.
O cancelamento do pedido é a única transação executada totalmente de forma síncrona com a Paradigma, pois não se pode deixar o pedido ser eliminado no ERP sem saber se pode ser eliminado na Paradigma.
1. Comprador cancela/elimina a requisição no Portal
Caso seja necessário realizar o cancelamento da requisição, esse deverá ser realizado no portal de compras, nesta ação será e nviado um documento de integração (Dados do Cancelamento da Requisição no ERP – Transação “PurchaseOrderLine” no EAI) para que o cancelamento também seja realizado no ERP.
No processo de cotação, caso o usuário elimine uma Requisição (ordem de compra) da cotação e informe que ela não deve ser liberada para poder ser utilizada em uma nova cotação, esta deverá ser retornada como uma requisição cancelada para o ERP.
Nota:
A busca dos cancelamentos de requisição deve ocorrer da mesma forma que as cotações, ou seja, uma vez buscadas pelo ERP não devem mais ser retornadas.
2. Dados para eliminação da ordem de compra no ERP.
A requisição é eliminada no ERP com base nos dados enviados pela Paradigma.
Como na Paradigma podem existir diversas requisições para a mesma ordem de compra, o cancelamento de uma requisição na Paradigma pode representar a eliminação de uma parcela no ERP, portanto o Paradigma obrigará o cancelamento de todas as parcelas da requisição no Portal para que seja cancelada a ordem de compra no ERP.
Com a integração entre o ERP 2 e o Portal de Compras Paradigma (WBC – Web Business Center), que será responsável pela cotação de itens com diversos fornecedores, é possível agregar volumes de compras para cotação de preço, dentre outras vantagens. A integração proporciona uma automação da área de compras, pois todo o processo de respostas de cotações é realizado pelos próprios fornecedores no portal de compras da Paradigma. A geração de ordens de compra será realizada no ERP 2, e serão envia das para o portal de acordo com a necessidade, para o tratamento pelo portal de compras. O processo de cotação e escolha dos vencedores é realizada no portal, sendo o pedido de compra gerado pelo ERP 2 e posteriormente enviado para o portal de compra s da Paradigma.
Existe ainda um segundo fluxo nesta integração, onde o comprador pode realizar todo o processo até a geração do pedido de compra dentro do ERP e enviar então o pedido para o portal.
Além da integração de transações de negócio (ordens de compra, cotação e pedido) são integrados uma série de cadastrados para equalizar os dados utilizados entre os dois sistemas.
Os mapas de integração das transações abaixo encontram-se liberadas no Datasul EAI:
Transação | Adapter | Envio/ Recebimento | Aplicativo | Web Service e operação executada na Paradigma |
CancelationOrder | adapters/xml/utp/axsut004.p (Web Service) URL: http://<servidor>:<porta>/ws/esb/ESBWebServ ice,<servidor>, <porta>,sendMessageSync,message,queue,stri ng,WSCancelOrder | Envio | sender | WS: Pedido Operação: ProcessarPedidoCancelamento |
Carrier | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: Empresa Operação: ProcessarEmpresa |
Currency | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: Moeda Operação: ProcessarMoeda |
CustomerVendor | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | sender | WS: Empresa Operação: ProcessarEmpresa |
InventoryGroup | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: Categoria Operação: ProcessarCategoriaProduto |
Item | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: Produto Operação: ProcessarProduto |
MaterialUser | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: Usuario Operação: ProcessarUsuario |
PaymentPlan | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: CondicaoPagamento Operação: ProcessarCondicaoPagamento |
ProcessQuotations | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: Cotacao Operação: ReabrirCotacaoItem |
PurchaseOrder | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: Pedido Operação: ProcessarPedido |
PurchaseOrderLine | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: Requisicao Operação: ProcessarRequisicao |
Site | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: Empresa Operação: ProcessarEmpresa |
UnitOfMeasure | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: UnidadeMedida Operação: ProcessarUnidadeMedida |
VendorItem | adapters/xml/utp/axsut001.p (Fila EAI) | Envio | Sender | WS: EmpresaProduto Operação: ProcessarEmpresaProduto |
ProcessQuotations | adapters/xml/su2/axrsu003.p (Padrão de negócio – Recebimento) | Recebimento | receiver | WS: Cotacao Operação: RetornarCotacaoItem |
PurchaseOrder | adapters/xml/su2/axrsu004.p (Padrão de negócio – Recebimento) | Recebimento | receiver | WS: Pedido Operação: RetornarPedidoAceite |
PurchaseOrderLine | adapters/xml/su2/axrsu002.p (Padrão de negócio – Recebimento) | Recebimento | receiver | WS: Requisicao Operação: RetornarRequisicaoEntregaCancelame nto |
RequisitionOrderConfir m | adapters/xml/su2/axrsu011.p | Recebimento | receiver | Retorno do processamento de ordem de compra e pedido de compra |
ReturnIntegrationError s | adapters/xml/su2/axrsu014.p | Recebimento | receiver | Retorno do processamento de cadastros |
CustomerVendorParadi gma | adapters/xml/su2/axrsu012.p | Recebimento | receiver | WS: Empresa Operação: RetornaEmpresaSemDePara |
Permite a manutenção da fila de mensagens XML utilizadas na integração assíncrona do EAI. As mensagens assíncronas são mensagens utilizadas para transportar informações entre produtos integrados. Levam esse nome pois não são simultâneas e não possuem ritmo regular e definido.
As mensagens visualizadas no Monitor são filtradas de acordo com seu destino, estado de processamento, tipo, transação às quais estão associadas e a data em que foram geradas.
São necessários os seguintes procedimentos para visualizar as mensagens do Monitor de Integração:
Nota:
Para mais detalhes relacionados aos procedimentos do aplicativo Datasul EAI, acessar o Manual de Referência do EAI, em especi al a função Monitor de Integração.
Neste documento é abordado a configuração de mapas e diagramas no ESB para as transformações de mensagens trocadas entre o ERP 2 e a Paradigma.
Nota:
Para realizar as configurações listadas na sequência é necessário ter o ESB (versão 12.1 ou superior) instalado, assim como o by You Studio. Atentar para se já existir uma versão inferior no ESB sendo utilizada, será necessário migrar os diagramas/mapas para utilização através da nova versão do ESB.
Por intermédio do by You Studio criar um novo Projeto do tipo “ESB Project”:
Neste projeto, será necessário criar um diretório chamado “Paradigma” (indicado pelo número 1 na figura) e importar os diagra mas para o projeto (indicado pelo número 2 na figura). Os 8 diagramas estão disponíveis estão disponíveis no diretório “Integrator/Paradigma” no produto EAI.
Dentro do diretório “Paradigma” devem ser colocados todos os arquivos com extensão “.xsl” (eles estão disponíveis no diretóri o “Integrator/Paradigma” no produto EAI). Esses arquivos são necessários para realizar a conversão de mensagens no formato Datasul para o formato Paradigma, e vice-versa, assim como realizar algumas configurações da integração.
Exemplo dos arquivos já dentro do projeto do ESB:
Tendo os diagramas e arquivos dentro do projeto do ESB, pode-se iniciar a configurações dos componentes para realizar o acesso aos Web Services da Paradigma e ao banco de dados do EAI.
Nota:
Para configuração dos componentes Web Services é necessário ter o conhecimento da URL a ser utilizada para acesso a Paradigma.
Nos diagramas, é necessário configurar os componentes “WS Receiver” e “WS Sender” para realizar a conexão correta aos Web Services da Paradigma.
Na sequência, é apresentado um exemplo do diagrama “ParadigmaAceiteRecusaPedReceiver”, in dicado em vermelho pelo número 1 está o componente “WS Receiver” que precisa ser configurado. Indicado pelo número 2, onde deve ser configurado a URL (WSDL URL) e Operação (Operation).
A tabela abaixo contém a configuração para os componentes “WS Receiver” nos demais diagramas:
Diagrama | Componente do Diagrama | WSDL URL | Operation |
ParadigmaAceitaRecusaPedR eceiver | WSReceiverAceiteRecusa | <URL Paradigma>/Pedido.svc?ws dl | RetornarPedidoAceite |
ParadigmaCancRequsicaoRec eiver | WSReceiverRequisicaoCancela mento | <URL Paradigma>/Requisicao.svc ?wsdl | RetornarRequisicaoEntregaCancel amento |
ParadigmaCotacaoItemReceiv er | WSReceiverCotacaoItem | <URL Paradigma>/Cotacao.svc? wsdl | RetornarCotacaoItem |
paradigmacustomervendor | WSReceiverCustomerVendor | <URL Paradigma>/ Empresa.svc?wsdl | RetornaEmpresaSemDePara |
Na sequência é apresentado um exemplo do diagrama “ParadigmaErroCotacaoReceiver”, indicado em vermelho pelo número 1 onde está o componente “WS Sender” que precisa ser configurado. Indicado pelo número 2, onde deve ser configurado a URL (WSDL URL) , Operação (Operation) e Parâmetros.
A tabela abaixo contém a configuração para os componentes “WS Sender” nos demais diagramas:
Diagrama | Componente do Diagrama | WSDL URL | Operation |
ParadigmaErroCotacaoReceiver | WSCotacaoItem | <URL Paradigma>/Cotacao.svc?wsdl | ReabrirCotacaoItem |
ParadigmaCadastrosReceiver | WSUnidadeMedida | <URL Paradigma>/UnidadeMedida.svc?wsdl | ProcessarUnidadeMedida |
ParadigmaCadastrosReceiver | WSCondicaoPagamento | <URL Paradigma>/CondicaoPagamento.svc?wsdl | ProcessarCondicaoPagamento |
ParadigmaCadastrosReceiver | WSCategoria | <URL Paradigma>/Categoria.svc?wsdl | ProcessarCategoriaProduto |
ParadigmaCadastrosReceiver | WSItem | <URL Paradigma>/Produto.svc?wsdl | ProcessarProduto |
ParadigmaCadastrosReceiver | WSVendorItem | <URL Paradigma>/EmpresaProduto.svc?wsdl | ProcessarEmpresaProduto |
ParadigmaCadastrosReceiver | WSEmpresa | <URL Paradigma>/Empresa.svc?wsdl | ProcessarEmpresa |
ParadigmaCadastrosReceiver | WSCurency | <URL Paradigma>/Moeda.svc?wsdl | ProcessarMoeda |
ParadigmaCadastrosReceiver | WSMaterialUser | <URL Paradigma>/Usuario.svc?wsdl | ProcessarUsuario |
ParadigmaTransNegocioReceiver | WSPedido | <URL Paradigma>/Pedido.svc?wsdl | ProcessarPedido |
ParadigmaTransNegocioReceiver | WSPurchaseRequisition | <URL Paradigma>/Requisicao.svc?wsdl | ProcessarRequisicao |
ParadigmaTransNegocioReceiver | WSReabrirCotacaoItem | <URL Paradigma>/Cotacao.svc?wsdl | ReabrirCotacaoItem |
ParadigmaTransNegocioReceiver | WSReabrirCotacao | <URL Paradigma>/Cotacao.svc?wsdl | ReabrirCotacao |
ParadigmaWSCancelOrder | WSCancelationOrder | <URL Paradigma>/Pedido.svc?wsdl | ProcessarPedidoCancelamento |
Os parâmetros para todos os componentes “WS Sender” devem ser:
Name | Data Type | Value |
# | XMLDocument | # |
Nos diagramas é necessário configurar os componentes “TOTVS Sender” e “TOTVS Receiver” para realizar a conexão com o banco de dados do EAI.
Na sequência é apresentado um exemplo do diagrama “ParadigmaCancRequisicaoReceiver”, indicado em vermelho pelo número 1 está o componente “TOTVSSender” que precisa ser configurado. Indicado pelo número 2, onde deve ser configurado o acesso ao banco de dados do EAI. A conexão pode ser testada através do botão “Test Connection”.
Nota:
As informações deverão ser configuradas conforme a instalação do banco EAI no ambiente do cliente.
A tabela abaixo possui a lista dos componentes que precisam ser configurados para conectar corretamente o banco de dados do E AI:
Diagrama | Componente no Diagrama |
ParadigmaCadastrosReceiver | CadastrosReceiver |
ParadigmaCadastrosReceiver | ErroCadastrosEAI |
ParadigmaCancRequisicaoReceiver | SenderCancReqEAI |
ParadigmaCotacaoItemReceiver | SendCotacaoEAI |
ParadigmaErroCotacaoReceiver | ErroCotacaoReceiver |
ParadigmaTransNegocioReceiver | TransNegocioReceiver |
ParadigmaTransNegocioReceiver | RetornoNegocioEAI |
ParadigmaAceitaRecusaPedReceiver | TOTVSSender1437 |
paradigmacustomervendor | TOTVSSenderCustomer |
ShipToAddress: Endereço de entrega padrão a ser definido. Essa informação será utilizada no envio de ordens de compra para o portal da Paradigma, somente se o cliente desejar utilizar um endereço de entrega padrão, ao invés de ser o próprio estabelecimento da ordem de compra. Obs.: Não será necessário configurar caso o endereço de entrega deva ser o estabelecimento da ordem de compra.
Nota:
Trocar o valor “401”pelo código do endereço de entrega (Estabelecimento) padrão informado pelo cliente.
BillToAddress: Endereço de cobrança padrão a ser definido. Essa informação será utilizada no envio de ordens de compra para o portal da Paradigma, somente se o cliente desejar utilizar um endereço de cobrança padrão, ao invés de ser o próprio estabelecimento da ordem de compra. Obs.: Não será necessário configurar caso o endereço de cobrança deva ser o estabelecimento da ordem de compra.
Nota:
Trocar o valor “401” pelo código do endereço de cobrança (Estabelecimento) padrão informado pelo cliente.
Caso o usuário deseje alterar essas informações de Endereços no envio da ordem de compra, deverá alterar o arquivo "purchaseorderline_to_paradigma.xsl" para utilizar os templates que desejar, exemplo:
Como o arquivo é expedido:
Alterados para utilizar os endereços padrões:
Country: Sigla do país. Essa informação será utilizada para tradução da descrição do país (Brasil) cadastrada no EMS, para a sigla do país enviada para a Paradigma.
Nota:
Somente é necessário alterar essa informação caso no cadastro possua uma descrição diferente de “Brasil”.
A base para os cálculos é o Preço Fornecedor (cotacao-item.preco-fornec).
IPI pelo preço líquido
Encargos financeiros inclusos no preço do fornecedor:
IPI pelo preço bruto
Encargos financeiros inclusos no preço do fornecedor:
Encargos financeiros não inclusos no preço do fornecedor:
Prazo | Percentual de pagamento duplicata |
30 | 33,33 |
60 | 33,33 |
90 | 33,34 |
Obs.: Exemplo considerando que o IPI está sendo calculado pelo preço líquido.
Passo 1:
Retirar o valor do desconto do preço (preço = preço - Valor do desconto)
12,4 – 0,1240 = 12,276
Passo 2:
Retirar a taxa financeira do preço
1. Para cada parcela calcular: Prazo de pagamento X Percentual Pagamento da Duplicata
30 x 33,33 = 999,99
60 x 33,33 = 1999,8
90 x 33,34 = 3000,6
2. Somar todos os resultados obtidos e dividir o valor por 100
(Considerar o valor obtido como "Prazo")
999,99 + 1999,8 + 3000,6 = 6000,39 “Prazo” = 6000,39 / 100 = 60,0039
3. Calcular: (Valor da Taxa / 100) + 1
(Considerar o valor obtido como "Cálculo 1") "Cálculo 1" = (0,9 / 100) + 1 = 1,009
4. Calcular: (1 / Número de dias da taxa financeira)
(Considerar o valor obtido como "Cálculo 2") "Cálculo 2" = (1 / 5) = 0,2
5. Calcular: Elevar o valor de "Cálculo 1" a potência encontrada em "Cálculo 2"
(Considerar o valor obtido como "Cálculo 3") "Cálculo 3" = (1,009)0,2 = 1,0017935547
6. Calcular: Elevar o valor de "Cálculo 3" a potência encontrada em "Prazo" (Considerar o valor obtido como "Cálculo 4")
"Cálculo 4" = (1,0017935547)60,0039 = 1,1135174520
7. Resultado final: Preço = Preço / "Cálculo 4". (Preço sem o desconto)
12,276 / 1,1135174520 = 11,0245241132
Passo 3:
Retirar o IPI do preço (preço = preço / (1 + (Alíquota IPI / 100)))
11,0245241132 / (1 + (10 / 100)) = 10,0223
Preço Líquido: R$ 10,0223
