Mapa de domínio

A árvore que responde quem paga. Caminho materializado com profundidade livre, código imutável, duas portas de status com cascata assimétrica e path como token de concorrência — mecânica preservada da v1.0. Novo: escopo por empresa (nó corporativo ou de uma LegalEntity), vigência própria para obra e projeto, e allowsPosting — só folha recebe lançamento.

O responsável pelo nó, com papel (Owner, Deputy, Watcher), vigência e alçada própria. Substitui o campo managerUserId. Resolve: substituto, co-gestão e — o que importa de verdade — a pergunta "quem tinha autoridade nesta data", que um campo único não sabe responder. Ausente no nó, resolve subindo a árvore.

Agregado único que descreve matéria-prima, produto acabado, MRO, serviço, assinatura e ativo. Descrição gerada de basicName + atributos, com attributeSignature como chave de antiduplicidade. Resolve: o que exatamente está sendo comprado, com precisão suficiente para cotar, comparar, aprovar e conferir — e sem o campo-texto livre que transforma catálogo em lixeira.

Entidade de configuração por tenant, não enum. Dirige field selection, classes de unidade permitidas e destinação padrão. Resolve: um único cadastro atender indústria e serviço sem virar formulário com quarenta campos opcionais.

Nó de taxonomia auto-relacionado, com maxDepth configurável (default 2) e classificação só em folha. Resolve: a categoria de sourcing — o eixo do mercado fornecedor, distinto do NCM (natureza física) e da conta contábil (reporte). É também onde a regra de aprovação se amarra, guardando o nó e valendo por rollup.

Catálogo global + camada do tenant, sigla local de até 6 caracteres como chave, conversão em numerador/denominador inteiros e hierarquia ItemSupplier > Item > global > erro. Resolve: que o comparativo de cotações signifique alguma coisa. É o módulo mais curto e o de maior consequência: sem ele, 84 unidades viram 84 caixas.

Raiz de 8 dígitos do CNPJ, com certidão federal, CRF, CNDT, regime tributário e quadro societário. Resolve: grupo econômico derivado, homologação escopada por categoria, estado Prospect que cota sem receber pedido, e a separação entre documento enviado e verificação em fonte oficial.

CNPJ de 14 — filial, com situação cadastral, IE, IM, alvará e licença ambiental próprios. Resolve: a filial baixada com a matriz ativa, que nenhum cadastro de nível único enxerga. É também o nível que emite a nota e recebe o pedido.

A junção entre catálogo e fornecimento: preço, prazo, MOQ, múltiplo, código no fornecedor e unidade de compra. Resolve: tirar do item tudo que é negociado. Precedência na linha: contrato > ItemSupplier > Item — e é justamente o topo dessa precedência que ainda não existe como entidade.

O que é: a demanda interna — quem pediu, para qual centro de custo, qual item, quantidade, data necessária, justificativa. Cabeçalho com N linhas.

O que resolve: dá origem a tudo. É o objeto que entra no fluxo de aprovação, que se agrupa em cotação e que se converte em pedido, mantendo rastreabilidade da linha até a nota.

Decisões que nascem aqui: rateio de centro de custo por linha (padrão no Brasil desde o Protheus v10 — e a alçada deve avaliar a fatia rateada, não o total); linha de catálogo versus free-text para o que não está cadastrado; e agrupamento de requisições de vários solicitantes numa única cotação.

Saiu da lista de pendências. O motor está especificado em nove entidades e independe de qual documento o aciona — a Requisição só precisa submeter um assunto com valor, empresa, requisitante e linhas.

O que a Requisição ainda precisa entregar a ele: o rateio por linha (que o Centro de Custo v2.0 já define como CostAllocation) e o evento de alteração que dispara a reavaliação.

O que é: o evento de sourcing — convite a N fornecedores, com SupplierQuote e QuoteLine como respostas, em rodadas.

O que resolve: o mapa comparativo com frete, impostos e prazo equalizados; a negociação em mais de uma rodada; e a justificativa obrigatória quando o escolhido não é o menor preço, que é o controle que auditoria efetivamente cobra.

Decisões que nascem aqui: o fornecedor responde por portal ou por planilha importada; o comparativo honra o "não comparável" da classe Serviço já decidido em UoM; e o Prospect pode ser convidado, mas o vencedor precisa estar homologado na categoria antes de virar pedido.

O que é: o compromisso legal com o fornecedor. Cabeçalho, linhas e cronograma de entrega (a mesma linha entregue em parcelas com datas distintas).

O que resolve: preço, quantidade, condição de pagamento, local de entrega, moeda e status aberto / parcial / fechado. É onde o priceQty e o snapshot do fator de conversão viram dinheiro de verdade.

Decisões que nascem aqui: alteração de pedido já enviado é versão nova, não update — e alteração acima de tolerância volta para aprovação; envio e aceite pelo fornecedor; e conversão parcial de requisição (uma requisição vira dois pedidos para fornecedores diferentes).

O que é: o recebimento — quantidade recebida, divergência, aceite ou rejeição, devolução, recebimento parcial, quem recebeu e quando.

O que resolve: é o "R" do three-way match e a fonte do desempenho do fornecedor — OTIF, atraso e divergência calculados do fato, não de formulário de avaliação. A spec de Fornecedor já promete esse indicador; ele só existe se o recebimento existir.

Decisões que nascem aqui: serviço precisa de um irmão — medição e aceite de serviço, no espírito do service entry sheet do SAP. Recebimento físico não modela hora trabalhada nem entrega parcial de projeto.

O que é: a nota do fornecedor entrando no sistema — XML da NF-e, chave de acesso, itens, impostos.

O que resolve: a conferência automática pedido × recebimento × nota, com tolerância configurável por tipo de divergência e bloqueio explícito quando estoura. É o que transforma o Nexio de ferramenta de compra em controle de gasto.

Decisões que nascem aqui: a fronteira com o financeiro. A recomendação é conciliar e liberar, não pagar — contas a pagar fica no ERP. Entra também a manifestação do destinatário e o que fazer com nota sem pedido.

Empresa e filial dentro do tenant. Hoje TenantSettings tem um único CNPJ, o que força grupo econômico a virar N tenants — duplicando catálogo, centro de custo, alçada e usuário. Resolve: no Brasil, empresa e filial são dimensão de regra de aprovação, de numeração de documento e de nota fiscal. É a decisão mais cara de adiar: entra na chave de quase todo agregado transacional.

O eixo contábil ausente. Conta contábil mais o mapping set categoria → conta, amarrável em qualquer nível da árvore, no padrão Oracle. Resolve: cliente vindo do Protheus amarra alçada em entidade contábil — centro de custo, conta, classe de valor. Sem esse eixo, o Nexio não conversa com o razão e a integração com o ERP vira digitação.

Já é o topo da precedência de preço e não existe como entidade. Preço negociado com vigência, volume comprometido, saldo consumido (contrato guarda-chuva com liberação parcial), reajuste por índice, renovação e SLA. Resolve: compra recorrente sem RFQ toda vez — é o que separa um sistema de cotação de um sistema de compras.

Armazém, filial, obra. Resolve: para onde entrega e qual CNPJ recebe — que é dimensão fiscal (ICMS interestadual muda com a UF de destino). Depende de LegalEntity; modelado antes dela, nasce errado.

Verba por centro de custo × conta × período, com empenho na aprovação da requisição ou na emissão do pedido, e política de estouro configurável (avisar ou bloquear). Resolve: a pergunta de primeira reunião comercial no Brasil. Coupa, Oracle e Precoro vendem controle orçamentário como diferencial; sem ele o comprador aprova no escuro.