Mapa de domínio

A pessoa jurídica, chaveada pela raiz de 8 do CNPJ. Quem assina, quem tem regime tributário, orçamento e alçada. Nasce obrigatória e sempre existe — tenant com uma empresa é o modo isolado, tenant com N é o consolidado, e o domínio é escrito uma vez para os dois. O CNPJ solto do tenant morre — e TenantSettings, que as specs citavam como se fosse da plataforma, não existe no Gryd.IO; a configuração por tenant do Nexio é pendência abaixo.

O CNPJ de 14, matriz ou filial, com inscrição estadual, endereço fiscal por código IBGE, Suframa e situação cadastral próprios. A empresa é quem assina; o estabelecimento é quem recebe a nota. Espelha SupplierEstablishment: um CNPJ tem um modelo mental só no produto, de dentro e de fora.

Onde o caminhão para. Pendura obrigatoriamente num Establishment — quem recebe fiscalmente — e tem endereço próprio só quando precisa: doca e setor herdam, CD alugado e canteiro de obra não. A decisão que a torna brasileira: UF de entrega diferente da do estabelecimento exige motivo declarado de uma lista fechada, porque entregar em outro estado mantendo o destinatário original não produz tratamento interestadual — produz autuação. Endereço eventual existe, vive só no snapshot do documento e nunca vira linha de catálogo.

A terceira árvore do produto, com a mesma mecânica de caminho materializado das outras duas. Plano único do tenant, com GLAccountCompany carregando habilitação e código externo por empresa. A conta da fatia de rateio é sugerida pelo item, depois pela categoria — encerra a pendência do eixo contábil registrada no Cadastro de Item.

Numeração com escopo declarado — tenant, empresa ou estabelecimento, com empresa como padrão — e incremento atômico no banco. Nasce junto com a empresa porque é dela que o escopo depende.

Verba por empresa × centro de custo × conta × período, com as duas últimas dimensões anuláveis e rollup nas duas árvores. Não é um número, é um livro-razão: BudgetEntry append-only em três estágios — comprometido na aprovação da requisição, empenhado na emissão do pedido, realizado no recebimento — em que cada estágio liquida o anterior na proporção do que avançou. Controle é opt-in por nó de centro de custo; carry-forward é modo de leitura, não movimento de transporte; competência é a data de necessidade. Documento em moeda estrangeira converte uma vez, no movimento, e a taxa é congelada — o cadastro e a resolução dela vivem em Moeda e Câmbio.

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 guarda de move — mecânica preservada da primeira versão; o token de concorrência é version int, único no produto desde 03/09/2026. Novo: escopo por empresa (nó corporativo ou de uma Company), 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 nó com allowsPosting — folha, por padrão. Mesma mecânica de árvore do centro de custo e da conta contábil desde 08/09/2026. 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.

ItemSupplier guarda a relação de qualificação e preferência. ItemSupplierOffer versiona embalagem, código, MOQ, múltiplo e prazo; ItemSupplierPrice referencia a oferta e suas condições por empresa/destino. Componentes de custo total são explícitos e Incoterm é condicional à operação. Cada documento congela oferta, preço e fatores.

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; agrupamento de requisições de vários solicitantes numa única cotação; e o modelo de requisição — conjunto de linhas pré-preenchidas que faz o papel do kit de compra, porque o Cadastro de Item decidiu que item não é composto de item.

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 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 QuotationResponse e QuotationResponseItem como respostas, em rodadas. O nome foi decidido em 08/09/2026: até então este parágrafo dizia SupplierQuote e QuoteItem, enquanto o Anexo e o Modelo já usavam QuotationResponse dentro do enum fechado AttachmentOwnerType — e mexer num enum fechado, que o caminho do portal e os códigos de erro do anexo já citam, é caro; mexer em prosa não é. A linha do documento segue a convenção do produto: <Documento>Item.

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.

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.

Especificada em 2 de setembro de 2026, fora de ordem e antes da Requisição — que é exatamente o que "barato agora, caríssimo depois" queria dizer. A linha de documento nasce com as sete colunas de snapshot de entrega em vez de ganhá-las por migração.