Ponto de partida
Como ler o mapa
O domínio de um sistema de compras se organiza em três camadas, e a confusão entre elas é a origem de quase todo retrabalho de modelagem. A camada mestre descreve o mundo — existe antes de qualquer transação e sobrevive a todas elas. A espinha transacional é o ciclo do gasto: cada documento nasce do anterior, carrega um instante congelado dos mestres e nunca mais muda de significado. As camadas transversais não são módulos, são capacidades que todo agregado consome.
Para ver os campos e as cardinalidades de tudo o que já está especificado numa página só, abra o Modelo de classes — este mapa mostra a forma do domínio; aquele mostra a forma dos dados.
Mestre muda; documento não. Preço, fator de conversão, cadeia de aprovação e dados do fornecedor são copiados para a linha no momento em que ela é criada. Sem isso, editar um cadastro reescreve o passado.
Cada documento tem um antecessor rastreável. Requisição → cotação → pedido → recebimento → nota. A linha guarda de onde veio, e é essa corrente que sustenta saldo, três vias e indicador de fornecedor.
O que é transversal não vira campo. Anexo, auditoria, notificação, numeração e motivo aparecem em oito agregados. Modelados um a um, viram oito implementações divergentes.
Visão do todo
Mapa do domínio
Contract, o ItemSupplier e a árvore de categorias precisam ser consultados de novo, e só na criação da linha seguinte. A faixa de baixo desenha a fronteira com a plataforma, que nunca esteve neste mapa — e foi por isso que empresa quase foi modelada duas vezes. As cinco caixas tracejadas à esquerda são do gryd e não se alteram; a caixa azul à direita, isolada de propósito, é a única coisa nova e é do Nexio: o gryd não conhece Company, então o recorte por empresa vive em UserCompanyScope, no nosso esquema.Já fechado
Camada mestre
Especificada entre 27 de agosto e 2 de setembro de 2026 — incluindo as cinco do controle orçamentário e as cinco de moeda e câmbio, ambas fechadas em 1º de setembro. A contagem não se repete aqui: raízes de agregado vivem no cabeçalho desta página e o inventário de classes no Modelo. Foi repetindo número em prosa que esta nota passou semanas dizendo "vinte e cinco raízes, 34 entidades" enquanto o cabeçalho dizia outra coisa. As caixas com +N no mapa são raízes que respondem por entidades que não têm caixa própria. Nada implementado no domínio de compras — o levantamento de negócio ainda está em curso.
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.
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.
Especificado · 30/08/2026
Motor de aprovação
Não é uma entidade — são doze, em duas camadas: oito de configuração e quatro de execução. Um motor só, genérico por processo, para toda aprovação humana do Nexio: requisição, cotação, pedido, contrato, cadastro e homologação de fornecedor, alteração bancária, curadoria de item, exercício e remanejamento de verba — dez processos-semente desde 04/09/2026 (Fluxo, princípio 7). Nenhum módulo tem rota própria de aprovar; o que parece exceção é ato unilateral com motivo (bloqueio, promoção manual, revogação, substituição, expurgo), e está listado no Fluxo.
- ApprovalProcess — o que é aprovável, e o que "valor" significa naquele documento
- ApprovalPolicy — a regra, versionada.
Baseconcorre por prioridade;Supplementalempilha - ApprovalCriteria — quinze critérios; nós de centro de custo, de categoria e de conta contábil valem por rollup
- ApprovalLevel — tipo de aprovador, modo dentro do nível (uma rejeição encerra, em todos), SLA, valor de ativação, escopo e o alvo do escalonamento
- ApprovalGroup — comitês
- ApprovalDelegation — ausência temporária: uma vigente por processo, com delegado, teto e fim obrigatório
- ApprovalProcessSettings — os parâmetros que variam por processo: dedupe, tolerância de reavaliação, SLA padrão e o comportamento de escalonamento, que tem aqui o seu dono único. Chamava-se
ApprovalSettingsaté 08/09/2026 - ApprovalSettings — novo em 08/09/2026, uma linha por tenant: o limiar de materialidade do rateio, o teto de duração da delegação e o expediente com a lista de dias não úteis. É a configuração que vale para todos os processos de uma vez
- ApprovalRequest — a instância, com a cadeia congelada e as versões das políticas que a formaram
- ApprovalStep — o nível resolvido, com escopo: documento, linha ou fatia de rateio — e a marca de alçada estourada, avisada à controladoria antes da decisão
- ApprovalAssignment — a tarefa de uma pessoa. É a entidade que faltava, e sem ela não existe fila endereçável, aprovação por papel, delegação registrada nem paralelo dentro do nível
- ApprovalEvent — append-only. O estado é projeção; a trilha é a fonte
Abrir a especificação completa do Fluxo de Aprovação →
A decisão que reorganiza tudo: a cadeia é congelada na submissão e as pessoas são resolvidas na ativação de cada passo. O que a política decidiu não muda quando alguém edita a configuração; quem aprova é sempre quem responde pelo nó hoje. As cinco decisões que estavam em aberto desde junho caem como consequência disso e do escopo do passo.
A construir · prioridade máxima
Espinha transacional
Sem estes seis, o Nexio é um cadastro. Com eles, é um sistema de compras.
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.
A construir · decidir cedo
Estruturais
Baratos agora, caríssimos depois — todos mudam a chave primária ou a dimensionalidade de agregados que já vão existir. Um dos dois já saiu; resta o Contract.
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.
Capacidades · cinco feitas, uma é da plataforma, uma a construir
Transversais
Currency · TenantCurrency · CurrencyPair · ExchangeRate · CurrencySettings — cinco entidades sob uma caixa só no mapa. Catálogo ISO 4217 com minorUnits, ativação por tenant, pares monitorados, cotação datada por tipo e o serviço de conversão. Nasceu dentro do orçamento e saiu em 1º de setembro de 2026, porque Catálogo, Fornecedor, Cotação, Pedido e Nota consomem os mesmos. Captura automática do boletim de fechamento do Banco Central, com provedor plugável.
Attachment · AttachmentType sobre o GrydFiles. Duas camadas: o arquivo é da plataforma, o vínculo é do Nexio. Dono polimórfico com registro de descritores, visibilidade Internal | Supplier desde a v1, propagação explícita entre documentos e revogação com duas regras — em rascunho libera o arquivo, fora de rascunho não. Saiu em 2 de setembro de 2026 porque a Requisition a consome no dia 1.
Sai do backlog. O GrydAudit já entrega interceptor com diff automático, RecordAsync para evento de negócio manual, consulta por entidade, por usuário e controller — e é o precedente interno do polimorfismo, amarrando em EntityType + EntityId sem chave estrangeira. A convenção de nomes de ação fechou em 08/09/2026: <entidade>.<verbo-no-passado>, a mesma cauda do slug, gravada em AdditionalData["action"] pelo RecordAsync — porque o AuditLog não tem coluna de ação. Fica registrada aqui a pendência de plataforma: GrydAudit — coluna Action no AuditLog, no molde do GrydFiles, com consulta e índice próprios. Nenhuma spec do Nexio espera por ela.
Encolheu e saiu. O GrydNotifications já entrega canal, template com override por tenant, fila, agendador, retry, in-app, push e e-mail — nada disso foi remodelado. A spec de 3 de setembro escreveu o que a plataforma não pode saber: catálogo de vinte e quatro slugs extraído das nove specs publicadas, preferência por usuário que guarda exceção e não estado, cinco resolvedores de audiência, e a regra de que notificação é ponteiro, não relatório — nenhum valor sob permissão sai no corpo. E a fila do aprovador continua não sendo notificação: é ApprovalAssignment.
Numeração por tenant, empresa e tipo de documento. Parece detalhe e sempre vira migração dolorosa, porque o número já foi impresso e enviado ao fornecedor.
Referência externa em fornecedor, item, centro de custo e pedido, mais fila de saída para o ERP. O Nexio quase sempre vai conviver com Protheus, SAP ou Omie — não substituí-los.
A frase virou spec. Catálogo único de motivos com appliesTo sobre um enum fechado de doze usos — rejeitar, devolver, cancelar, bloquear, desbloquear, revogar, substituir, forçar duplicata, promover fornecedor, escolher quem não é o mais barato. Trinta códigos semeados, tenantId nulo = do produto. O ato grava a chave e o rótulo congelado, e motivo é dado, nunca regra: nenhum código muda fluxo, estado ou permissão. Saiu junto com as correções das cinco specs que tinham texto livre.
Decisões de tamanho
Fronteiras do produto
1. Portal do fornecedor — proposta na mesa
Sem portal, todo documento de homologação, toda proposta de RFQ e toda confirmação de pedido entram por e-mail e alguém digita — e metade do valor das specs de Fornecedor e Cotação evapora. Com portal, você ganha um segundo tipo de usuário, autenticação externa, superfície de segurança e um roadmap paralelo. Ariba Network, Coupa Supplier Portal, Mercado Eletrônico e Nimbi vivem disso. Metade da decisão já estava escrita: o Anexo recusou o usuário de tenant com permissões podadas e o Fornecedor declarou o portal projeto próprio. A outra metade está na proposta do Portal do Fornecedor, de 08/09/2026 — conta sem credencial, link por convite, e a cotação como único ato da v1. Em validação; enquanto não for validada, esta continua sendo a maior decisão de escopo em aberto.
2. Onde o Nexio para no financeiro
Recomendação: parar no match e na liberação para pagamento. Contas a pagar, fluxo de caixa e conciliação bancária são território de ERP, e entrar neles multiplica a superfície fiscal e contábil sem aumentar o diferencial competitivo.
3. Estoque continua fora
Já declarado fora de escopo, com ItemType.controlsStock sempre false como gancho. Vale reconfirmar agora, porque Requisição e Recebimento vão puxar por ele — "requisição contra saldo" e "recebimento que dá entrada" são pedidos que aparecem na primeira demo.
Recomendação
Sequenciamento
| # | Módulo | Depende de | Desbloqueia | Custo de adiar |
|---|---|---|---|---|
| 1 | Company + Establishment + GLAccount especificado | Centro de Custo especificado | numeração, alçada, integração, todo agregado transacional | — |
| 2 | GrydFiles + ClamAV a implementar · plataforma | GrydFiles especificado · Anexo especificado | anexo em todo documento; storedFileId em Item, Fornecedor e Notificação. A Requisição não começa antes | alto |
| 3 | Requisition | Item, CC, UoM, Company, Anexo especificado · GrydFiles a implementar | o produto começa a existir | — |
| 4 | Motor de aprovação | Requisition especificado | a promessa central do Nexio | — |
| 5 | PurchaseOrder | Requisition, ItemSupplier | Receipt, Invoice, indicador de fornecedor | — |
| 6 | Receipt | PurchaseOrder | OTIF, three-way match | — |
| 7 | QuotationRequest | Requisition, Fornecedor | sourcing e negociação | médio |
| 8 | Contract | ItemSupplier, Quotation | compra recorrente sem RFQ | médio |
| 9 | Invoice + match | PO, Receipt | controle de gasto | — |
| 10 | Budget especificado · fora de ordem | GLAccount, CC especificado | bloqueio por verba, critério orçamentário no motor | — |
| 11 | Moeda e Câmbio especificado · fora de ordem | Company especificado | compra em moeda estrangeira, comparativo de cotação multimoeda, câmbio no pedido e na nota | — |
| 12 | Local de Entrega especificado · fora de ordem | Establishment especificado | destino fiscal congelado na linha, preço por UF no ItemSupplier, critério de UF na aprovação | — |
| 13 | Anexo especificado · fora de ordem | GrydFiles especificado · a implementar | anexo em requisição, cotação, pedido, recebimento e nota; resposta do fornecedor pelo portal | — |
| 14 | Notificação especificado · fora de ordem | GrydNotifications na plataforma | catálogo de slugs, preferência por usuário, e a submissão diferida que destrava o documento com anexo em verificação | — |
| 15 | Motivo especificado · fora de ordem | — nenhuma | motivo contável em rejeição, devolução, bloqueio, revogação e substituição; fecha o gate transversal da Requisition | — |
Na coluna de dependências, especificado é spec publicada neste site; na plataforma existe no Gryd.IO em código; a implementar só existe como spec — e é o que bloqueia a linha seguinte.
Por que cotação vem depois do pedido. Parece contraintuitivo — no fluxo real a cotação vem antes. Mas o caminho mais curto até um produto utilizável é requisição → aprovação → pedido: já existe cliente que compra de fornecedor fixo e só precisa de controle de alçada. Cotação é o módulo mais caro (rodadas, equalização, resposta do fornecedor) e o mais dependente da decisão sobre portal. Especificar depois do pedido significa especificá-lo já sabendo como a linha de documento se comporta.
Por que o GrydFiles tem linha própria. Cinco specs já apontam para storedFileId e FileReference, e a própria spec do GrydFiles escreve o gate: a Requisição não começa antes de a v1 do módulo existir no framework. Até 03/09/2026 esta tabela dizia "feito" tanto para o que está especificado quanto para o que existe na plataforma — e o GrydFiles é o único caso em que as duas coisas diferem, porque é spec de plataforma escrita pelo Nexio. A linha 2 é a dependência com dono: módulo no Gryd.IO mais clamd e freshclam operacionais, com versão mínima do pacote fixada quando o release existir. O plano B — anexo direto por IObjectStorageService — fica recusado: criaria exatamente a divergência que a spec de Anexo existe para impedir.
Aferição
Referência de mercado
Nenhuma entidade proposta aqui é invenção — todas existem, com nomes diferentes, nos produtos que o Nexio vai encontrar em concorrência.
| Nexio | SAP Ariba | Coupa | Oracle Procurement | Protheus |
|---|---|---|---|---|
| Requisition | Requisition | Requisition | Requisition | Solicitação de Compra |
| ApprovalPolicy · Request | Approval Flow | Approval Chain | Approval Task (BPM) | Alçadas de aprovação |
| QuotationRequest | Sourcing Event / RFx | Sourcing Event | Negotiation | Cotação |
| PurchaseOrder | Purchase Order | Purchase Order | Purchase Order | Pedido de Compra |
| Receipt | Goods Receipt | Receipt | Receiving | Documento de Entrada |
| Invoice + match | Invoice Reconciliation | Invoice / AP | Invoice Matching | Pré-nota e classificação |
| Contract | Ariba Contracts | Contracts / CLM | Blanket & Contract Purchase Agreement | Contratos de Parceria |
| Budget | Spend control | Budgets | Budgetary Control | Controle Orçamentário |
| Company + Establishment | Business Unit | Business Group | Business Unit / Legal Entity | Empresa e Filial |
| Portal do fornecedor | Ariba Network | Coupa Supplier Portal | Supplier Portal | Portal de Compras |
Carregado das specs anteriores
Pendências herdadas
- Esquema de atributos semente por setor versus cada tenant desenhar o seu
- Extração assistida por LLM na importação — MVP ou depois
- Mapeamento categoria → conta contábil — resolvido em
GLAccount: sugestão em cascata por item, depois por categoria, sempre editável - Multi-empresa / múltiplos CNPJs — resolvido em
Company+Establishment, dentro do tenant. OcompanyIddo nó de centro de custo passa a se chamarcompanyId
- Fonte de consulta ao CNPJ: base própria dos dados abertos versus serviço comercial com SLA
- O Nexio guarda dado bancário ou só referencia o ERP
- Base compartilhada de fornecedores entre tenants — decisão jurídica antes de produto
- Embalagem que muda: nova versão do
ItemSupplierou novo código de unidade (CX10)
- Configuração por tenant do Nexio — a especificar.
TenantSettingsnão existe na plataforma, e cinco specs a citavam como se existisse. O CNPJ não precisa dela — vive emCompanyeEstablishment. Precisam de um lar os parâmetros que são do tenant e não da empresa:costCenterMaxDepth(Centro de Custo),catalogMaxCategoryDepth(Item),allocationMaterialityPercenteallocationMaterialityAmount(dono decidido em 08/09/2026: o motor, um valor por tenant — o Centro de Custo passou a citar em vez de redeclarar) e o expediente com a listanonWorkingDates(Fluxo). Padrão a seguir: entidade nomeada por assunto, comoCurrencySettingseApprovalSettings— nunca um JSON genérico. ObusinessCalendarIdsaiu da lista em 08/09/2026: com prazo de cotação e prazo de entrega contando em dias corridos, o SLA ficou o único consumidor de dia útil no produto, e uma lista de datas semeada com os feriados nacionais faz o serviço sem entidade — a pendência perdeu um item, e nenhum dos que restam pede raiz de agregado. E em 08/09/2026 a pendência fechou. A casa saiu:ApprovalSettings, uma linha por tenant no fluxo de aprovação, com materialidade,maxDelegationDayse os três campos de calendário — e a antigaApprovalSettingsvirouApprovalProcessSettings, para que cada nome declare a própria chave. Os dois tetos de árvore não ganharam entidade: viraram gancho declarado nas suas próprias specs — profundidade é livre na v1, o campo tem nome e dono, e a configuração nasce quando o primeiro cliente pedir o teto. Não sobrou nenhum parâmetro sem lar - Banco de dados — a decidir na arquitetura. Nenhuma spec assume um banco como premissa; onde um recurso é nomeado, Postgres é o exemplo de implementação (restrição de exclusão por período,
NULLS NOT DISTINCT,GIN/pg_trgm,jsonb,FOR UPDATE) — oltreedoCategoryNode, único tipo de coluna que dependia do banco, saiu em 08/09/2026. A lista está na tabela de convenções do Modelo de classes; cada ponto tem equivalente ou verificação na aplicação, e nenhuma regra de negócio depende do banco - Leva de consistência do motor (M3) — aplicada em 08/09/2026. Fluxo:
ApprovalGroupMembercom vigência;DrafteExpiredsaíram do enum da instância por não terem produtor;NotifyManagersaiu do escalonamento porque depende da hierarquia de pessoas, que é fase 2;escalationBehaviorpassou a ter dono único (o processo); a resposta ao pedido de informação e a recusa do delegado ganharam rota. As duas decisões que sobravam foram fechadas no mesmo dia (Fluxo):Escalatepassou a ter alvo declarado no nível quando o nível não caminha árvore, e processo de controle não escala (allowEscalationfalso na semente doBANK_ACCOUNT_CHANGE) — RN-AP-35; e a delegação virou uma vigente por delegante e por processo, comvalidToobrigatório limitado amaxDelegationDays, teto que só reduz e processos marcadosdelegable = false— RN-AP-36 e RN-AP-37 - Gate 9 da contra-análise — fechado em 06/09/2026. Rejeição encerra a instância em todo modo;
allowSelfApprovaldeixou de existir; alçada estourada ganhou marca no passo, evento, aviso à controladoria antes da decisão e checagem no/validate; o Fluxo ganhou uma seção de exemplos por processo. Ficam para a fase 2, com o padrão já decidido:Vote(n)— votação com dissidência tolerada, só emBUDGET,BUDGET_CHANGEeCONTRACT— eauthorityExceededBehaviorpor processo, padrão aprovar no topo
O bloqueio saiu. Company, Establishment e GLAccount apareceram em quatro specs seguidas como "decidir depois" e estão especificados desde 01/09/2026. A dívida que restava foi paga no mesmo dia: legalEntityId virou companyId no Centro de Custo, o critério Empresa do Fluxo de Aprovação passou a ler o companyId do documento e ganhou um critério irmão por estabelecimento, e o Cadastro de Item ganhou defaultGlAccountId em Item e CategoryNode. Nada disso teve dado para migrar. E a plataforma não foi tocada: o escopo por empresa vive em UserCompanyScope, tabela do Nexio — o gryd não conhece Company e não deve conhecer.