Marketplaces consolidados

Para cada marketplace, declare qual fonte define a venda (o próprio marketplace via API, o hub ou o ERP) e a partir de quando. As outras fontes servem para conciliar, nunca para somar. Guarde essa escolha numa tabela de canais com data de início e fim, para a regra ser lida pelo dashboard e pelo agente.

No hub, cada marketplace e cada conta é uma loja com id próprio. Classifique o canal pelo id da loja numa tabela de mapeamento (loja → marketplace → conta), e não por texto livre. No ERP, quando não há loja, o canal sai de uma combinação documentada: origem do pedido, vendedor de integração, projeto ou observação que cita o marketplace. Escreva os critérios no context document.

No Mercado Livre, o carrinho com vários itens gera vários pedidos agrupados por pack_id, e um envio pode cobrir o pack inteiro. O hub pode guardar no número da loja o id do pedido ou o pack_id. Conte pedidos pelo id do pedido do canal, use o pack para casar com o hub e com o envio. A tabela de pedidos do canal vem com versões repetidas: fique com a última versão de cada id.

Case o pedido do hub com o do marketplace em ordem de força: número da loja igual ao id do pedido (alta), número da loja igual ao pack_id (alta), mesmo valor e data próxima na mesma conta (média), sem par (pendente). Grave a regra que casou e a evidência em colunas. Relatórios dizem quanto está conciliado; a IA nunca afirma que um par é confirmado quando a confiança é média.

Há canais que, a partir de uma data, passam a ser faturados direto em NF-e (em geral numa série própria) sem pedido de venda no ERP. A base do canal é a união dos pedidos identificados com as notas de saída dessa série emitidas sem pedido. Nota que já tem pedido não entra de novo. Uma flag de CFOP de venda separa venda de remessa, transferência ou envio para armazém do marketplace: filtre só venda.

Quando o canal migra de uma conta do hub para outra, ou do hub para a API do marketplace, cada fonte contribui só com o seu período. Declare a data de corte (último dia na fonte antiga, primeiro na nova) e garanta que nenhum dia aparece nas duas nem fica sem nenhuma.

A data de referência do faturamento é a data de confirmação do pedido. O recebimento segue a regra de liberação de saldo de cada marketplace, que pode cair semanas depois. Mantenha as duas linhas do tempo em colunas separadas e nunca compare faturamento de um mês com repasse do mesmo mês como se fossem o mesmo dinheiro.

Relatórios de alguns canais contam uma linha por item como um pedido (o relatório de pedidos da Amazon replica o "Quantity Ordered" de ferramentas de BI de e-commerce). Defina por canal se "pedidos" é pedido distinto ou linha de item e escreva na descrição da coluna. Receita na Amazon é itemPrice sem imposto; imposto vem separado. SKU sem mapeamento para produto vai para "Sem categoria" com flag, nunca some.

Conte pedidos válidos e cancelados em colunas separadas, por data do pedido. Cancelado não entra no faturamento, mas entra na taxa de cancelamento. Carregue de forma incremental pela data de atualização do pedido (no hub, o campo de alteração), não pela data de criação: pedidos antigos mudam de status e só assim a mudança chega.

Para cada fonte e conta, registre período coberto, dias com dado, dias sem registro e a última carga. Um dia sem linhas numa conta que vende todo dia é falha de carga até prova em contrário. O dashboard mostra o canal como "sem dado" e não como zero, e a IA avisa quando a fonte está atrasada.