ER MANDIS01-410 Story - CIASHOP Receber Pedido de Venda

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

 Realizar a integração entre o ERP Datasul e a Plataforma e-Commerce da Ciashop.  Esta engenharia tem por objetivo específico integrar os Pedidos de Venda, Clientes e Títulos referentes as vendas realizadas nos MarketPlaces. 

Definição da Regra de Negócio

Este projeto visa integrar o ERP Datasul à plataforma de e-commerce Ciashop, possibilitando assim que as indústrias e distribuidores possam realizar suas vendas em marketplaces disponíveis no mercado. 

O conceito de Marketplace (MP), no comércio eletrônico, é a utilização de uma loja virtual de terceiros para vender os seus produtos.

O escopo desta integração é restrito a venda via SalesHub, com venda à consumidor final. Sales Hub é um aplicativo disponível para Lojas Framework da Ciashop que concentra diversos marketplaces, tais como Extra e Walmart. Através deste aplicativo é possível ofertar os produtos da loja nestes marketplaces e gerenciar os pedidos gerados nestes canais em sua própria loja.

As operações B2B  ou venda via loja virtual da Ciashop não serão atendidas neste momento.

A forma de comunicação entre ERP e Ciashop se dará por meio de mensagens enviadas e recebidas de um Web service RESTfull. Os Web services RESTful são serviços construídos com o estilo de arquitetura RESTful. A construção de Web services com a abordagem RESTful está surgindo como uma alternativa popular ao uso de tecnologias baseadas em SOAP para implantação de serviços na Internet, por ser mais leve e ter a capacidade de transmitir dados diretamente via HTTP.

Abaixo, o fluxo de integração:

Esta especificação tem o objetivo de descrever os processos para integração de Clientes, Pedidos de Venda e Títulos,  da Ciashop para o ERP Datasul.

Temos uma tela de parâmetros com as seguintes informações: 

Além das informações técnicas, nesta tela deve-se parametrizar o grupo de cliente que será utilizado para cadastro de novos clientes, ou seja, quando o pedido vier com um cliente que não está cadastrado no ERP, o sistema irá fazer o cadastro e irá buscar as informações "default" deste grupo de clientes.

Deve-se parametrizar as naturezas de operação que serão utilizadas para entrada dos pedidos, considerando venda para consumidor final, operações estaduais e interestaduais.

Deverá também ser informado o depósito que será utilizado para o comércio eletrônico, ou seja, neste depósitos deverão estar disponíveis os itens que possuem saldo para venda no site.  Quando do envio do saldo de estoque para o site, o sistema irá considerar este depósito.

Nesta tela ficará gravado o número do último pedido que foi integrado no ERP Datasul.  Este número corresponde a numeração da Ciashop.  Sempre que for feita a busca de novos pedidos, o sistema irá considerar este código e buscar os pedidos que sejam maiores que este número.

Abaixo temos a tela na qual será feita a busca de Pedidos:

 Neste caso o usuário deverá marcar Pedido de Venda e todos os pedidos com numeração superior ao último pedido integrado, serão buscados.

 O sistema deve permitir que a busca de Pedidos seja agendada via RPW.

Com base nos serviços da Ciashop foram criadas temp tables para facilitar a busca das informações:

Para integração dos pedidos estamos usando os seguintes serviços, para busca de pedidos e itens.

O primeiro passo ao receber um pedido da Ciashop é verificar se o cliente já está cadastrado no ERP.  Caso o cliente não esteja cadastrado, este deve ser inserido através da API , que efetua o cadastro primeiramente no EMS 2 e depois faz a integração automática para o EMS 5.  Para isto o sistema deve verificar no cadastro de parâmetros qual o grupo de cliente está parametrizado para buscar as informações padrões para completar o cadastro do cliente.

Para isto, deve-se ler o cliente:

  FIND FIRST emitente
             WHERE emitente.nome-emit = OrderShippingAddress.recipientName NO-LOCK NO-ERROR.

                
        IF NOT AVAIL emitente THEN DO:

           EMPTY TEMP-TABLE tt_emitente_integr_new.
           EMPTY TEMP-TABLE tt_cont_emit_integr_new. 
           EMPTY TEMP-TABLE tt_retorno_clien_fornec. 
           EMPTY TEMP-TABLE tt_cta_emitente.

           RUN cdp/cd9960.p (OUTPUT i-emitente).
          
           IF AVAIL param-integr-loja THEN
              FIND FIRST gr-cli
                   WHERE gr-cli.cod-gr-cli = param-integr-loja.cod-gr-cli NO-LOCK NO-ERROR.

Para cadastrar o cliente, o sistema deve alimentar a temp table tt_emitente_integr_new e chamar as APIS de integração:

           /* Executa a API para cadastrar o cliente no EMS 2 */
           IF VALID-HANDLE(h-cdapi366b) THEN
              RUN execute_evoluida_7 IN h-cdapi366b (INPUT        TABLE tt_emitente_integr_new,
                                                     INPUT        TABLE tt_cont_emit_integr_new,
                                                     INPUT-OUTPUT TABLE tt_retorno_clien_fornec,
                                                     INPUT              "",
                                                     INPUT-OUTPUT       c-cod-arquivo-log,
                                                     INPUT        TABLE tt_cta_emitente).

Se houver algum problema na integração, os erros serão apresentados no monitor.  Caso contrário, o sistema deverá fazer o cadastro do cliente no EMS 5.

 IF AVAIL emitente AND l-integra-ems5 THEN DO:

              RUN cdp/cd1608.p PERSISTENT SET h-cd1608 (INPUT emitente.cod-emitente,
                                              INPUT emitente.cod-emitente,
                                              INPUT emitente.identific,
                                              INPUT YES,
                                              INPUT 1,
                                              INPUT 0,
                                              INPUT c-cod-arquivo-log /*"utb765zb.tmp"*/,
                                              INPUT "Arquivo":U,
                                              INPUT "").

Se houver algum problema na integração, o sistema deverá gerar um relatório, além de apresentar as informações no monitor.

           
Uma vez que o cliente está ok, o sistema deve ler os pedidos, os itens e seus relacionamentos e alimentar as temp tables necessárias para execução da API de entrada de pedidos, conforme exemplo abaixo. 

Os pedidos vindos da Ciashop serão integrados com código de origem = 22 (Ciashop x Sales Hub x Marketplace).

Deverá ser gravado no ped-venda.char-1, 109,1 o status do Pedido na Ciashop.

             if order.status1 = "Confirmed" then

                 assign overlay(ped-venda.char-1,109,1) = 1  /* Pedido Confirmado */

             if order.status1 = "PaymentApproved" then

                 assign overlay(ped-venda.char-1,109,1) = 2 /* Pagamento Aprovado  */

             if order.status1 = "Cancelled" then

                 assign overlay(ped-venda.char-1,109,1) = 3 /* Pedido Cancelado  */

Deverá ser gravado no ped-venda.nr-pedrep  o código do Pedido na Ciashop.

ped-venda.nr-pedrep   =  order.id. 

run pdp/pdapi500.p (input  pTranAction,
                                 input  table tt-ped-venda,
                                 input  table tt-ped-item,
                                 input  table tt-desc-ped-item,
                                 input  table tt-ped-ent,
                                 input  table tt-unid-neg-ped,
                                 input  table tt-cond-ped,
                                 input  table tt-ped-repre,
                                 input  table tt-ped-antecip,
                                 input  table tt-pd-vendor,
                                 output table RowErrors, 
                                 output table ReturnOrderValues,
                                 output table ReturnItemValues) .

Quando da execução desta API poderão ser gerados erros de integração que serão disponibilizados no Monitor de Integração.

O sistema deve considerar que os pedidos cadastrados no site podem vir com valor de frete e cupons de desconto.  Hoje não temos desconto em valor no Pedido de Venda, então este desconto em valor deverá ser rateado entre os itens.

O valor do Pedido e da Nota Fiscal devem fechar com o preço final apresentado ao cliente no site. 

O valor enviado para o ERP deve ser: valor sem IPI,  sem frete,  somado o desconto do item e o desconto do cupom rateado.  Quando chega no ERP,  o sistema calcula os descontos, soma o frete na base e depois calcula o IPI.

O pagamento será feito diretamente no site através de boleto ou cartão de crédito e será integrado com o módulo de cobranças especiais.

O programa PD1509 - Completa Pedido Batch deverá ser alterado para tratar os pedidos originados da Ciashop.

O PD1509.W deverá ser alterado para tratar a origem 22.

Deverá ser definida a variável:

DEFINE VARIABLE l-pCiashop AS LOGICAL INITIAL yes     

              LABEL "Ciashop"     

              VIEW-AS TOGGLE-BOX     

               SIZE 17 BY 1 NO-UNDO.

E deverá ser tratada a origem 22.

Quando forem integrados pedidos com origem Ciashop e a Central de Vendas estiver habilitada, estes não deverão buscar estabelecimentos diferentes por item assim como estes pedidos não deverão ser quebrados.  Este conceito não se aplica aos pedidos com origem Ciashop, pelo menos nesta fase do projeto, visto que para estes pedidos já temos parametrizado um depósito específico, onde se encontrarão os itens e saldos disponíveis para venda nos Marketplaces.

Para que os pedidos Ciashop não sejam tratados pela funcionalidade Central de Vendas, os seguintes programas deverão ser alterados:

bodi154val.i03 

fchdis0013api.p

fchdis0039api.p, nos seguintes pontos:

Ponto 1

Ponto 2

Ponto 3

Ponto 4

fchdis0047api.p

pd1509.i1

pd4000.m120

pd4000.m33

pd4000.m48

Ponto 1

Ponto 2

pd4000.m66

pd4000.w

Ponto 1

Ponto 2

Ponto 3

Ponto 4

Ponto 5

Ponto 6

Ponto 7

Ponto 8

Ponto 9

pd4050.w

Ponto 1

Ponto 2

pd4050b.w 

Ponto 1

Ponto 2

Ponto 3

Ponto 4

bodi154.i02

bodi154.i04

bodi154sdf.i17

bodi154val.i01

Cadastro Transportador - CD0402

O Cadastro do Transportador deve ser alterado para que, na aba Fretes, ao ser informado o Id Ciashop, seja validade se este ID já não está relacionado a outro transportador e, neste caso, o sistema deve emitir uma mensagem de erro e e não deve permitir o relacionamento.   O mesmo ID Ciashop deverá estar relacionado apenas a um transportador no ERP.

Cancelamento Pedido na Ciashop - PD4000

Quando o Pedido for cancelado na Ciashop, normalmente pela falta de confirmação do pagamento, o mesmo deverá ser cancelado no Datasul.  Para isto, ao buscarmos a atualização do status do pedido no PD0624, se o pedido vier como cancelado, este deverá ser cancelado no PD4000.

Para que seja feito o cancelamento, será necessário informar um motivo.  Para isto, deverá ser verificado se existe algum motivo cadastrado com a descrição igual a "Cancelamento Ciashop". Se existir utiliza esse motivo, senão cria um novo automaticamente,  conforme tela abaixo.

Uma vez que o pedido foi cancelado, será apresentado desta forma no PD1001.

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

Exemplo de Aplicação:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.