Centro de Custo

Trim, maiúsculas, apenas [A-Za-z0-9_-], até 20 caracteres, único por tenant. Nenhuma rota o altera depois da criação.

Não há tipo e não há flag: a distinção é parentId nulo. Nenhuma nomenclatura fixa de "área" e "sub-área" no domínio — a tela nomeia como o cliente chama.

Revista em 08/09/2026. costCenterMaxDepth é opcional, validado na criação e no move, e pode ser levantado sem migração. É gancho declarado, não configuração da v1: o campo é deste documento, o padrão é nulo — profundidade livre — e a entidade de configuração nasce quando o primeiro cliente pedir o teto. Enquanto o valor for nulo não há o que validar, e nenhuma rota o expõe.

O agregado recebe a entidade pai, não o id. Nenhum outro caminho escreve path e depth.

Não há rascunho nem aprovação de cadastro. Criar sob ramo inativo ou fora de vigência é 422, com a cadeia inteira verificada.

PATCH /activate e DELETE. O corpo do PUT não carrega o campo.

Verificada até a raiz por igualdade sobre os caminhos derivados. A recusa não nomeia o ancestral — o breadcrumb já carrega o estado de cada passo.

Só política ativa bloqueia. A recusa é 409 com a contagem, e nada é escrito. Com a FK, a garantia é FOR UPDATE sobre a subárvore.

Um nó já no estado alvo não é tocado nem contado. Ativar uma árvore já ativa responde zero.

Nem o do nó, nem o dos descendentes. Mover para dentro da própria subárvore é 422; mover para o pai atual responde 200 sem escrever nem auditar.

version int é o token de toda escrita rastreada, inclusive um PUT que só troca o nome: o cliente envia o expectedVersion que leu, e a divergência responde 409. path continua conferido em move, como segunda guarda. A resposta é reler e repetir. Até a v2.2 o token era só o path, que só muda em move — renome, vigência e conta concorrentes passavam sem 409.

Nó com empresa não aceita filho de empresa diferente. Nó corporativo aceita filho de qualquer empresa, e o filho define o escopo dali para baixo.

Validado na criação, na edição e no move. Encerrar um pai encerra a subárvore na mesma data, em cascata, com um registro de auditoria no nó disparado.

Nó fora de vigência impede nova intenção. Recebimentos/aceites de obrigação vigente continuam registráveis pela referência e snapshot, com pendência quando houver nova classificação a resolver.

Nasce verdadeiro em folha, falso ao ganhar o primeiro filho. O tenant pode abrir exceção nó a nó.

Owner, Deputy ou Watcher. Vários por nó. Trocar de responsável é encerrar um vínculo e abrir outro.

A tupla é (TenantId, CostCenterId, UserId, Role, período) — exclusão de faixas, com EXCLUDE + btree_gist como exemplo de implementação e verificação na aplicação, sob trava, onde o banco não oferecer equivalente. Checagem em memória sem trava perde a corrida de dois POST simultâneos. Corrigido em 09/09/2026: o mapa de entidades escrevia a tupla sem Role, e como estava proibia a transição de gestão em que a mesma pessoa é Deputy até 31/03 e Owner desde 01/01.

Encerramento aceita apenas data igual ou posterior a hoje. É o que preserva a resposta de "quem tinha autoridade naquela data".

Owners do nó; se vazio, Deputies do nó; se vazio, o pai, até a raiz. A resposta carrega inheritedFrom. Cadeia inteira vazia devolve lista vazia — não é erro aqui.

Dois Owners de R$ 50 mil cobrem até 50 cada. O que acumula é a subida na árvore.

Inativo é estado da conta, não referência errada. Recusar tornaria um nó insalvável por causa do login de alguém. Corrigido em 08/09/2026: esta regra dizia "empresa" porque foi escrita na v1.0, quando empresa queria dizer tenant — e depois que Company virou entidade a mesma palavra passou a ter dois significados na mesma página. O que esta regra checa é pertencer ao tenant. Alcançar a empresa do nó é a RN-CC-30, que é outra checagem, na mesma escrita.

Percentual com seis casas. Linha sem rateio explícito tem uma fatia de 100% — o caso simples e o rateado percorrem o mesmo código.

ROUND_HALF_UP em cada fatia, diferença apurada contra o total da linha e somada à fatia de maior valor; empate pelo menor order. Determinístico, e o total sempre fecha.

Revista em 08/09/2026: esta regra cita, não declara. O limiar é um só por tenant, em percentual e em valor — o que for maior —, e o dono dele é a RN-AP-15, na configuração de tenant do fluxo de aprovação: materialidade muda a cadeia e não o rateio, e pelo motor universal nenhum módulo tem parâmetro próprio de aprovação. O que este documento garante é o efeito sobre o rateio: a fatia imaterial é absorvida pela maior para efeito de alçada — e continua contabilizada integralmente. Ampliada em 09/09/2026: "integralmente" quer dizer que o orçamento sempre vê a decomposição integral e que Block numa fatia absorvida recusa a submissão do mesmo jeito. Materialidade é roteamento, nunca orçamento — as mesmas palavras da RN-O38. Mesma disciplina com que a RN-CC-23 virou a regra única do resíduo: mesma regra em dois lugares é uma regra; duas regras parecidas é uma armadilha.

Com operation, affectedCount e pathPrefix — mais previousPath num move e endedOn numa cascata de vigência. Descendente varrido não ganha registro próprio.

Vale para toda rota, e para os dois escopos: id de outro tenant e id de empresa que o usuário não alcança. 403 confirmaria que o registro existe em algum lugar. Corrigido em 08/09/2026: o título dizia só "outra empresa", com a ambiguidade herdada da v1.0.

Ordenação topológica no servidor, pai referenciado por código, idempotente por código, ciclo recusado nomeando os códigos envolvidos.

includeDeleted=true, search onde nada o consome, sortBy fora do mapa e managerUserId que não é GUID continuam sendo 400.

Toda fatia de novo Commitment ou Obligation exige conta e centro de custo válidos. Fato ocorrido pode ter pendência, conforme Orçamento; corrigir classificação grava pares balanceados e preserva origem.

Criar ou reativar vínculo exige visibilidade e concessão das operações necessárias na empresa do nó. Nó corporativo exige concessão global explícita para o papel correspondente; ausência de linha nunca equivale a global. Alçada financeira é separada. Revogação torna o vínculo inelegível para nova decisão e gera pendência de configuração.

Limite nulo significa ausência de autoridade. hasUnlimitedAuthority=true é ato explícito, com limite/moeda nulos. Cada mudança grava antes/depois, autor, validade e versão; papel ou reserva não concedem alçada automaticamente.

approvalLimitCurrency é obrigatória quando há approvalLimit e nula quando não há. O nó corporativo não tem empresa e por isso não herda moeda funcional de lugar nenhum — ele declara a dele como qualquer outro. A comparação da alçada converte o valor da fatia para esta moeda, com a taxa congelada na submissão, e registra taxa e data no evento de aprovação; par sem cotação vigente é recusa declarada.

Por quê: com Company.functionalCurrency aceitando qualquer ISO 4217 já na v1, um limite sem moeda faz o motor comparar BRL com USD em silêncio — e comparação silenciosa de moedas no ponto da alçada erra por um fator de cinco sem avisar ninguém.

CostAllocation.allocationId é gerado na criação da fatia e preservado em toda edição do documento. order é ordem de exibição e desempate de arredondamento (RN-CC-23), nunca identidade.

Por quê: a chave de idempotência do razão orçamentário usa a fatia (RN-O34). Chaveada por order, a reedição do rateio de 70/30 para 50/50 reusava order = 1, 2 e fazia o movimento corretivo colidir no índice único e ser descartado em silêncio.

CostAllocation.companyId é obrigatório e igual ao documento. Centro de custo é corporativo ou dessa empresa. Compra centralizada separa pedidos por destinatário fiscal; referência ao requisitante externo não move consumo para outra pessoa jurídica.

PATCH …/assignments/{id}/authority altera as três colunas de alçada do vínculo vigente, com expectedVersion e registro do valor anterior na trilha. PATCH …/assignments/{id}/reactivate reabre vínculo encerrado com validFrom igual ou posterior a hoje, refazendo as checagens de sobreposição (RN-CC-17) e de alcance da empresa do nó (RN-CC-30). Papel, pessoa e vigência continuam mudando só por encerrar e abrir (RN-CC-16).

Por quê: a RN-CC-30 fala em "criar ou reativar" um vínculo, e reativar não existia em endpoint nenhum; e approvalLimit não era declarado imutável nem tinha rota que o alterasse — corrigir a alçada de alguém obrigava a encerrar o vínculo e abrir outro, o que reescreve a resposta de "quem tinha autoridade" por um motivo que não é troca de responsável.