O que precisamos entender?

Precisamos compreender melhor os aspectos relacionados ao split de pedidos para implantação o melhoria no LinxERP e discutir também o funcionamento do CCF para obtermos uma compreensão mais profunda, especialmente no que diz respeito ao CCF, como ponto de partida para identificar as necessidades de desenvolvimento do LinxERP.

Além disso, é importante considerar que haverá várias alterações em conjunto, exigindo uma abordagem integrada. Devemos analisar quais funcionalidades são essenciais e como serão implementadas dentro do Linx RP e em outros sistemas correlatos.


LinxERP

Qual é o momento ideal para o LinxERP receber esses pedidos? Considerando que o Millennium já recebe essas informações diretamente do Linx IO, surge a dúvida se a integração entre o LinxERP e o Millennium conseguiria captar esses dados. São nuances do fluxo que precisamos compreender.

O cliente Inbrands é um caso à parte, exigindo um entendimento específico. O mesmo se aplica a LePostich e Via Vêneto.

Será necessário contar com alguém familiarizado com o Millennium para compreender o funcionamento atual do conector.

Entedemos que a principio na primeira conversa não teremos nenhum GAP nesta conversa, e precisamos puxar um segundo papo com Edson Reis.

Futuras alterações no ERP, irão refletir na Loja, porque a estrutura é a mesma se não muito parecida.


Split de Pedidos

A divisão de pedidos para a mesma loja ocorre quando há múltiplas entregas, cada uma por uma transportadora diferente. Esta divisão é necessária devido às diferentes limitações de peso das transportadoras envolvidas. Por exemplo, uma transportadora pode aceitar cargas a partir de 2kg, enquanto outra apenas a partir de 1kg. Portanto, cada entrega é tratada separadamente para garantir que cada transportadora possa atender às suas restrições específicas.

Hoje, quando um pedido é recebido do sistema OMS (Order Management System), um único ID de pedido é gerado. No entanto, se houver múltiplas entregas para o mesmo endereço, cada uma com suas próprias restrições de transporte, é necessário realizar a divisão do pedido. Isso resulta em dois IDs de pedido distintos, cada um representando uma entrega diferente, mas ambos saindo da mesma origem e indo para o mesmo destino.

No contexto do sistema Millennium, o processo de recebimento de pedidos do OMS é facilitado pelo conector do Millennium. Este conector realiza a leitura das informações fornecidas pelo OMS e as transforma no formato adequado para o sistema Millennium, geralmente em formato JSON. Após essa transformação, o pedido é postado no sistema Millennium, que o disponibiliza para processamento.

Entretanto, o problema surge quando o conector do Millennium recebe o pedido completo do sistema Millennium. Como mencionado anteriormente, se houver múltiplas entregas para o mesmo ID de pedido, o sistema Millennium não é capaz de registrar essas entregas separadamente. Isso cria uma limitação no processo atual, impedindo o registro correto de pedidos com múltiplas entregas.

Portanto, ao inserirmos um OrderID, não é possível adicionar outros grupos de entrega porque acabamos de registrar um para aquela loja. O sistema entende que se trata do mesmo pedido, e a construção do conector foi planejada dessa forma para lidar com um único pedido ou entrega para aquele centro de distribuição (CD).


Fallback como funciona

Entramos então no cenário de fallback do CD, que ocorre quando um pedido é recebido pelo conector. Ele captura o pedido completo e o considera destinado ao CD. No entanto, ele grava apenas o que é pertinente àquela loja, descartando o restante, pois está destinado a um ponto de venda (PDV) para outro processo de faturamento. Isso ocorre quando a loja não possui os produtos necessários e não notificou o CD sobre a falta de estoque ou sobre o pedido. Nesse caso, o conector deveria ler a fila de realocação do sistema Linx IO. Um detalhe importante é que essa funcionalidade ainda não foi implementada no conector Millennium, que não realiza a leitura dessa fila de realocação. Mesmo que fosse feita a leitura, seria necessário conseguir gravar esse segundo pedido completo. Assim, surge o problema do split, onde o cenário 1 envolve a divisão do pedido para o CD em duas entregas partindo do CD, ambas com destino ao mesmo endereço, mudando apenas o transportador.

O fallback descarta o pedido porque não está relacionado àquela loja específica, já que o pedido é recebido assim que é gerado.

A diferença entre a integração com o sistema Linx IO e o LinxPOS, por exemplo, é que o POS só reconhece a existência do pedido quando ele já foi separado e verificado, estando disponível no OMS ou no sistema de gerenciamento de estoque (Skype de Billy). Nesse momento, ele está pronto para ser faturado. Portanto, ele não está ciente de realocações ou rupturas de estoque. O Millennium, por outro lado, faz a leitura do pedido completo assim que é gerado, e se houver alguma alteração, recebe atualizações em filas distintas, como filas de status ou de realocação. O POS só lê o pedido quando está pronto para ser faturado. Assim, temos a estrutura de fallback e split em ação.


O que é o CCF?

O CCF (Central de Comissões e Fretes) é essencialmente um módulo e um serviço integrado ao OMS (Order Management System), responsável por monitorar os pedidos e realizar repasses. Esse recurso é especialmente útil para questões relacionadas a franquias. Imagine o cenário em que um franqueado realiza uma venda em uma loja física ou no site da marca. Geralmente, a marca cobra uma comissão, que pode ser, por exemplo, de 20% sobre o valor da venda ou do pedido. O CCF calcula essa comissão com base nesses parâmetros.

Além da comissão, podem haver outros custos envolvidos, dependendo das preferências do cliente. No entanto, em sua essência, trata-se principalmente da comissão retida pela marca sobre o valor da mercadoria. Após esse cálculo, o valor precisa ser repassado ao franqueado, assim como o custo do frete, se aplicável.

No caso de um pedido que o próprio lojista irá despachar, há um custo de frete envolvido. Nesse aspecto, cada marca pode adotar uma abordagem diferente: algumas absorvem esse custo, enquanto outras o repassam ao franqueado. Em suma, o CCF desempenha um papel crucial na gestão transparente e eficiente das comissões e dos custos de frete dentro do contexto de operações de franquia.

O CCF, ou Centro de Comissões e Frações, é um componente integrado ao Cockpit do sistema OMS (Order Management System). Ele gerencia os valores relacionados às comissões, mercadorias, fretes e questões de pagamento de cada pedido. Por exemplo, em transações parceladas, as comissões podem ser divididas de acordo com o cronograma de recebíveis do cliente, ou o cliente pode optar por pagar todas as comissões em um mês subsequente. Tudo isso é configurado no CCF.

Atualmente, o CCF realiza esses cálculos dentro do OMS, fornecendo uma interface no Cockpit, relatórios e a capacidade de ajustar os parâmetros conforme as necessidades do cliente. Os clientes podem personalizar sua visualização, gerar extratos e relatórios em CSV para ajustes manuais ou criar dashboards conforme sua preferência.

Entretanto, ainda falta a funcionalidade principal de lançar automaticamente esses dados para os clientes. Alguns clientes desenvolveram internamente soluções para isso, como o caso da Alpargatas, que utiliza o SAP em conjunto com o CCF. Após o cálculo, o sistema gera um JSON com os repasses, que é transmitido através de um barramento. Precisamos evoluir nesse aspecto, buscando automatizar esse processo de integração.

Além disso, é importante notar que é possível ter mais de um rateio em um único pedido. Por exemplo, em um pedido com dois produtos distintos, cada um pode ser faturado para uma loja de franqueado diferente. Essa flexibilidade é importante para atender às necessidades específicas de cada cliente.

Quanto ao tratamento de devoluções de pedidos pelo CCF, o sistema atualmente só registra o movimento oposto: quando a loja recebe produtos da marca. Isso pode gerar problemas quando franqueados de diferentes estados precisam lidar com devoluções. É crucial que os times comecem a discutir esses fluxos para encontrar soluções adequadas.

É importante ressaltar que o CCF não lida com compensação fiscal, mas sim com repasses financeiros. Seu propósito é promover os franqueados, incentivando-os a explorar diferentes canais de vendas, como marketplaces e comércio eletrônico. Esses estímulos são baseados em diversos critérios, os quais podem ser ajustados pelo varejista para atender às necessidades de cada franquia e negócio individualmente.

No processo CCF, referente ao pedido, há algum campo que especifica a destinação do pedido para uma franquia, loja ou centro de distribuição (CD), e como essa destinação é identificada? Atualmente, essa identificação é feita através do LocationID. O CCF examina cada entrega individualmente dentro de um pedido no OMS, considerando várias entregas e vários pontos de faturamento (fullfilments). Cada fullfilment é analisado separadamente, e toda entrega que atinge determinado status é integrada ao CCF. Essa configuração pode ser ajustada de acordo com as necessidades do cliente. Atualmente, o ID da loja e o ID do ponto de venda (LocationID e PointID) são os campos utilizados para determinar a origem e o destino dos repasses.