Integração com Plataforma

Millenium_Eco

A biblioteca Millenium_Eco foi desenvolvida especialmente para facilitar o uso por integradores com a plataforma Millennium. Esta biblioteca expõe apenas métodos especializados em tarefas comuns de integração como:

• Leitura da árvore de classificações do produto;
• Leitura de produtos com suas características;
• Leitura de estoque;
• Leitura de preço;
• Leitura de cadastros auxiliares;
• Manutenção (inserção e alteração combinada) de clientes e consulta;
• Inserção e consulta de pedidos.

Alguns dos métodos de integração se baseiam no envio de uma data/hora de mudança que o sistema utiliza para retornar apenas os registros que foram modificados a partir dela. Para evitar problemas de sincronização de horários, recomendamos ler a última data de sincronização diretamente dos registros retornados. Isto é possível porque os métodos retornam e são ordenados pelo campo DATA_ATUALIZACAO. Desta forma é apenas necessário armazenar o valor do último registro lido e repassá-lo à consulta na próxima vez.

Além de limitar a lista dos registros antigos, é possível utilizar a opção $top nas chamadas para limitar o número de registros retornados. Esta forma de leitura é importante porque equilibra o processamento em lotes menores entre o servidor e sua aplicação. Os métodos que suportam controle de mudança são:

• Vitrine.Lista_Classificacoes
• Produtos.Lista ou Produtos.ListaVitrine
• Produtos.PrecoDeTabela
• Produtos.SaldoDeEstoque
• Pedido_Venda.ConsultaStatusWF

Abaixo temos um pseudo-código demonstrando este padrão para a listagem de produtos:

O fluxo básico para o qual o millenium_eco foi desenvolvido se baseia na exportação das informações relacionadas aos produtos (incluindo categorias, preços e estoque) e importação dos clientes e pedidos. Os produtos possuem informações sensíveis como preços e estoque que podem ser sincronizadas com maior frequência e informações cadastrais que mudam menos e podem ter maior frequência de atualização. As informações de preços e estoques são obtidas por métodos especializados ao invés de serem listados como mudanças de produtos porque a lista de produtos é muito mais complexa, por outro lado, com métodos especializados é possível retornar milhares de registros mais simples com grande desempenho.

É importante enviar os pedidos ao Millennium imediatamente após serem lançados para que o estoque seja reservado e reflita a baixa. Se isto não for feito, uma chamada que busca o estoque fará a leitura incorreta do saldo, podendo levar a vendas sem estoque disponível. Se a sua plataforma possuir o conceito de reserva, esta chance é bastante minimizada.

O conceito de vitrine foi desenvolvido na plataforma Millennium para permitir diversas apresentações diferentes dos produtos cadastrados no sistema, levando o conceito omnichannel ao extremo. Com este conceito, é possível organizar a árvore de produtos, determinar preços e estabelecer regras para cada canal, mesmo que estes acessem o mesmo servidor Millennium. Cada vitrine pode ser configurada, por exemplo, para atender a um site B2B, outra para B2C, outra para uma loja no facebook e ainda outra para uma loja com parceiro todas compartilhando ou não os mesmos produtos. As possibilidades são ilimitadas.

A integração de produtos se inicia pela integração de categorias. A chamada Vitrine.Lista_Classificacoes recebe um código de vitrine retorna uma lista com uma árvore de classificação no formato id/idpai. As classificações consideradas ativas são aquelas que possuem produtos ativos abaixo dela, o que pode ser verificado pelo campo QTDE_ATIVOS. Quando este campo possui zero, significa que não há produtos ativos em nenhum nível abaixo deste nó e, portanto este pode ser desativado até uma segunda integração. Sempre que existir mudança em um nó da categoria, o sistema irá retornar toda sua hierarquia até o último pai para facilitar a verificação dos nós ativos.

O segundo passo da integração de produtos é a leitura dos cadastros. Para isto é utilizada a chamada Produtos.ListaVitrine. Esta chamada recebe um identificador de vitrine e uma data de atualização. A data de atualização deve ser utilizada conforme o padrão demonstrado no tópico 2.1. Além dos dados básicos de produtos, esta chamada retorna algumas listas importantes:

• SKU: Esta lista possui os dados das variações de um produto como cor e tamanho, além de suas características como dimensões e tempo de entrega. O campo “inativo” também deve ser verificado, já que o usuário pode desativar certos SKUs para que não apareçam para venda. As mudanças de preço e estoque devem ser lidas por meio dos métodos PrecoDeTabela e PRODUTOS.SaldoDeEstoque que também possuem controle de mudança.
• CLASSIFICAÇÕES: Retorna uma lista com os identificadores das classificações da vitrine associadas ao produto. Um produto pode estar associado a mais de uma classificação (isto pode ser controlado por vitrine). Se um produto é adicionado a uma classificação e depois removido, a lista ainda assim retornará tal classificação com o campo “EXCLUÍDO” marcado como true.
• ESPECIFICAÇÕES: A lista de especificações pode ser usada para adicionar classificações que variam produto a produto. Geralmente estes valores são usados para formar a área de filtro dos produtos, ou a aba de especificações técnicas. É possível identificar o uso da especificação por seu código. Cada especificação possui um tipo, um nome e uma descrição que podem ser utilizadas para compor o conteúdo dependendo da necessidade da plataforma. O uso pela plataforma (filtro, aba etc) pode ser controlado pelo tipo da especificação.

Os preços são integrados por meio do método produtos.PrecoDeTabela que recebe um identificador de vitrine, por onde o sistema já identifica as tabelas de preço e as promoções ativas. Este método também recebe e retorna uma data de atualização que deve ser utilizada conforme o padrão demonstrado no tópico 2.1. São retornados os dados do SKU (produto, cor, estampa e tamanho e id SKU) o PRECO1 e PRECO2, sendo que o primeiro é o preço atual do produto. Quando existe uma promoção, o PRECO2 retorna o preço anterior à promoção (ou preço “de”), caso contrário o valor será igual ao do PRECO1.

Os saldos de estoque são integrados por meio do método produtos.SaldoDeEstoque que recebe um identificador de vitrine, por onde o sistema já identifica as tabelas de preço e as promoções ativas. Este método também recebe e retorna uma data de atualização que deve ser utilizada conforme o padrão demonstrado no tópico 2.1. São retornados os dados do SKU (produto, cor, estampa e tamanho e id SKU) e os saldos separados que devem ser utilizados da seguinte forma:

Se sua plataforma possui o conceito de reserva deve ser utilizado como saldo:

((SALDO + RESERVA_VITRINE)-(SALDO_NAOVITRINE – RESERVA_NAOVITRINE))
ESTOQUE_MIN

Se sua plataforma não possui o conceito de reserva, deve ser utilizado como saldo:

(SALDO)-(SALDO_VITRINE – RESERVA_VITRINE)-(SALDO_NAOVITRINE -RESERVA_NAOVITRINE)-ESTOQUE_MIN

Toda a integração de pedidos é orquestrada pelo método pedido_venda/processaStatus. Este método recebe uma lista de registros contendo o código do pedido e o status atual no seu ponto de vista. Esta lista é processada no Millennium e como resposta, é retornada uma lista de códigos de pedido e ações para que você processe, como no diagrama abaixo:

Para facilitar o entendimento, vamos considerar 3 pedidos, WEB-000001 a WEB000003. O código dos pedidos deve ser enviado ao serviço da maneira que serão incluídos no Millennium. É recomendado o uso de um prefixo antes do código do pedido (WEB-* no exemplo), para evitar conflito de numeração. Para cada pedido, deverá será enviado o status conforme tabela abaixo:

A chamada ao Millennium ficará assim:

Quando o Millennium retornar a ação 1, como no pedido WEB-000001 do nosso exemplo, você deve chamar a sequência de inclusão de pedidos, conforme sequencia abaixo:

Quando o Millennium retorna a ação 2 (mudar status), o campo status associado à ele retornará para qual status você deve alterar seu pedido. Conforme o status, alguns campos associados ao registro também retornam conforme tabela abaixo. Note que estes status devem ser considerados sempre quando a ação é 2, em outras ações esta tabela não se aplica:

Vale ressaltar que, enquanto o status não mudar, a ação retornada será 0 (zero), indicando que nada deve ser feito em relação ao pedido. A tabela acima aplica-se apenas quando a ação retornada é 2.