Integração OmniCommerce

Informações - O que é OmniCommerce

Foi desenvolvido um novo motor logístico na plataforma LinxCommerce onde conta com serviços de maior performance, por exemplo ElasticSearch, conjunto de APIs.  

Além da nova tecnologia, o novo motor logístico faz com que clientes possam ter uma oferta omni no seu site, ofertando assim estoques não só do CD, mas também lojas físicas, franquias, etc. Sendo assim, é possível o cliente passar para uma oferta denominada de OmniCommerce. 

Além da nova tecnologia empregada e a mudança no modelo de oferta, também dispomos de um serviço de monitoria quanto as performances dos serviços empregados, assim como, monitoria de cliente a cliente que utiliza a oferta OmniCommerce.

1.1 Criação/Atualização de lojas (Locations) - Via Layer

Através do método SaveLocationSeller é possível criar/editar as locations.  

A terminologia por conter seller não remete propriamente a feature de Seller que a plataforma dispõe. O motivo maior desta terminologia tange a possibilidade de clientes utilizarem as locations como lojas e/ou franquias, na qual surge a necessidade que haja um split do pedido, e consequentemente, o split do pagamento para que as lojas/franquias correspondentes ao pedido já possam receber o respectivo valor diretamente na sua conta bancária cadastrada. 

Vale ressaltar que a manipulação é a mesma realizada pelo Admin: ou seja, os ajustes realizados são disseminados entre a API de Inventory e as estruturas de banco de dados do Commerce (sellers e warehouses). 

https://NomeDaLoja.layer.core.dcg.com.br/reference.html?url=/swagger.json#!/MultiSite/SaveLocationSeller 

 Os campos obrigatórios para esta integração são: 

O padrão das informações a serem inseridas segue os mesmos padrões já utilizados nos demais métodos da Layer seja para questão de datas e/ou valores fixos.   

1.2 - Manipulação de Estoques (Criação / Atualização)  - Métodos via API OmniCommerce: 

Em relação à alteração de posições de estoque, os endpoints são do novo serviço de inventory. Todas as chamadas executadas nesses métodos correspondem a recontagem. 

Para execução dos métodos abaixo, a autenticação passa pela geração de um token através do método abaixo: 

http://omnilite.layer.core-tst.dcg.com.br/v1/Security/API.svc/web/GenerateAccessToken 

Obs: para execução do método acima, a autenticação é através do mesmo usuário e senha do admin, contanto que esse usuário possui as permissões de administrador. 

Métodos na API do OmniCommerce para atualização de estoque: 

Swagger: https://api.linxcommerce.io/inventory/v1/swagger/index.html 

Endpoint PRD: https://api.linxcommerce.io 

Endpoint de Staging servirá para ambientes de homologação (HLG): api-stg.linxcommerce.io 

{{Endpoint}}/inventory/v1/stocks 

{{Endpoint}} /inventory/v1/stocks/batch 

2 - Busca de Pedidos na fila(GetOrder) 

Em relação ao consumo dos pedidos, o que muda principalmente é que a estrutura utiliza o sistema de fulfillments (entregas). 

Além do mais, com o OmniCommerce temos a possibilidade de termos um pedido com várias entregas, ou então, cada entrega tornar-se um pedido, o que é denominado como split de pedidos. 

{{EndPointLayer}}/v1/Queue/API.svc/web/SearchQueueItems 

Pedidos com split de pedidos: temos que identificar o tipo do retorno do pedido após execução do método SearchQueueItems, para que aí então possamos buscar as informações dos pedidos através de métodos específicos.  

Quando na propriedade EntityKeyName retornar o valor OrderGroupNumber deveremos utilizar o método {{EndPointLayer}}/v1/Sales/API.svc/web/GetOrderGroupByNumber para buscar as informações do pedido: 

Já quando retornar o valor OrderGroupID na propriedade EntityKeyName, deveremos utilizar o método {{EndPointLayer}}/v1/Sales/API.svc/web/GetOrderGroup: 

Pedidos com mais de uma entrega: Pedidos com N entregas caracterizam-se em pedidos que não há rateio entre as locations engajadas no fechamento do pedido. Sendo assim, todas as entregas são relacionadas ao mesmo pedido, ficando assim: 

Quando necessário consumir um pedido deste cenário, via layer, poderemos identificá-los da seguinte forma quando retornado para consumo no método SearchQueueItems. 

Quando na propriedade EntityKeyName retornar o valor OrderNumber deveremos utilizar o método {{EndPointLayer}}/v1/Sales/API.svc/web/GetOrderByNumber para buscar as informações do pedido. 

Já quando retornar o valor OrderID na propriedade EntityKeyName, deveremos utilizar o método {{EndPointLayer}}/v1/Sales/API.svc/web/GetOrder: 

Coletar o conteúdo da propriedade Orders.Fulfillments.FulfillmentID, e utilizar o método http://omnilite.layer.core-tst.dcg.com.br/v1/Fulfillment/API.svc/web/GetFulfillment para obter os dados específicos da entrega. Neste retorno será listado os itens que correspondem a entrega em questão, assim como, os valores, transportadora responsável, e até mesmo o status da entrega em específica. 

3 - Atualização de Pedidos (UpdateOrder) 

Para atualizar os pedidos, utilizamos o método v1/Sales/API.svc/web/UpdateOrder, onde através dele serão inseridas as informações de Nota Fiscal e Código de rastreio. 

WorkflowTypes permitidos: 

ConfirmPayment, Invoiced, Shipped, Delivered, Canceled, PickupReady, PickupFail. 

4 - Atualização de entrega (UpdateFulfillment) 

Método em processo de criação. Método servirá para atualizar cada uma das entregas. 

5 - Tratamento / Exceção de entregas. (EM BREVE) 

6 - Coleção Postman: 

https://api.postman.com/collections/2169989-3d1709da-6914-4d8d-8c9d-ffe4894fd586?access_key=PMAT-01GVKGP6JVVPMSS7NCDS9VKFS9 

Observação 1: Caso seja necessária alguma informação que ainda não dispomos nos métodos de quem for consumir os métodos listados acima, basta entrar em contato com os times de produto e tecnologia e avaliaremos a implementação dos ajustes que forem necessários. 

Observação 2: Caso haja alguma propriedade em tela que não exista no método, poderão acionar-nos para adicionarmos alguma propriedade faltante.