SAGRES Captura 2.0 Manual institucional consolidado Documentação Funcional do Módulo Contabilidade — Catálogo completo das 48 fichas Versão 1.6.0Lotes 1 a 6Julho de 2026 Navegação Apresentação Índice das entidades Planejamento e orçamento CTB-001 · Ação CTB-002 · Programa CTB-003 · Unidade Orçamentária CTB-004 · Atualização Orçamentária CTB-008 · Decreto Ofício CTB-009 · Despesa Extra CTB-010 · Dotação 2025-2026 CTB-011 · Dotação 2027 CTB-012 · Emenda Impositiva CTB-013 · Empenho 2025-2026 CTB-014 · Empenho 2027 CTB-025 · Liquidação CTB-028 · Norma Orçamentária Cadastros CTB-007 · Credor CTB-029 · Ordenador Receitas CTB-033 · Receita Extra CTB-034 · Receita Orçamentária CTB-035 · Receita Prevista Execução financeira e bancos CTB-005 · Conta Bancária CTB-006 · Conta Bancária Credor CTB-027 · Movimentação entre Contas Bancárias CTB-030 · Pagamento CTB-044 · Saldo Inicial Conciliado CTB-045 · Saldo Mensal Extrato CTB-046 · Transferência Concedida CTB-047 · Transferência Recebida Restos a pagar CTB-026 · Liquidação Resto CTB-031 · Pagamento Resto CTB-041 · Resto Inscrito Retenções e estornos CTB-015 · Estorno Despesa Extra CTB-016 · Estorno Empenho CTB-017 · Estorno Liquidação CTB-018 · Estorno Liquidação Resto CTB-019 · Estorno Pagamento CTB-020 · Estorno Pagamento Resto CTB-021 · Estorno Receita Extra CTB-022 · Estorno Resto CTB-023 · Estorno Retenção CTB-024 · Estorno Retenção Resto CTB-042 · Retenção CTB-043 · Retenção Resto Integrações CTB-036 · Relacionamento Empenho Licitação CTB-037 · Relacionamento Empenho Natureza Contratação CTB-038 · Relacionamento Empenho Obra CTB-039 · Relacionamento Liquidação Agrupamento Folha CTB-040 · Responsável SIAFIC Referências documentais CTB-032 · Programa (referência duplicada) CTB-048 · Unidade Orçamentária (referência duplicada) Apresentação Este documento consolida em um único arquivo HTML a documentação funcional do módulo Contabilidade do SAGRES Captura 2.0. As fichas foram reconstruídas a partir da matriz funcional consolidada v1.6.0, preservando atributos, regras, dependências, observações e referências oficiais. 48Fichas documentadas 476Atributos catalogados 213Regras catalogadas 44Observações documentais Acompanhamento da implementação Dashboard das tarefas Não concluídas 48 100% Em andamento 0 0% Concluídas 0 0% Progresso geral 0% Em andamento vale 50% Progresso ponderado 0% Ailton 0 atribuídas 0 em andamento 0 concluídas Odair 0 atribuídas 0 em andamento 0 concluídas Diego 0 atribuídas 0 em andamento 0 concluídas Sem responsável 48 entidades Desenvolvedor Atribuídas Não concluídas Em andamento Concluídas Conclusão Não concluído Em andamento Concluído Filtrar por status: Objetivos Disponibilizar uma referência única para análise, desenvolvimento, implantação e homologação. Consolidar chaves, atributos, regras, dependências e inconsistências por entidade. Facilitar a navegação e a consulta técnica das equipes de ERP. Preservar a rastreabilidade com as páginas oficiais do TCE-PB. Fluxo funcional resumido Planejamento → Programa → Ação → Unidade Orçamentária → Dotação → Empenho → Liquidação → Pagamento → Retenção → Restos → Estornos → Saldos e Transferências. Índice geral das entidades Planejamento e orçamento CTB-001AçãoCadastro orçamentárioCTB-002ProgramaCadastro orçamentárioCTB-003Unidade OrçamentáriaCadastro orçamentárioCTB-004Atualização OrçamentáriaMovimentação orçamentáriaCTB-008Decreto OfícioInstrumento orçamentárioCTB-009Despesa ExtraMovimento extraorçamentárioCTB-010Dotação 2025-2026Cadastro orçamentárioCTB-011Dotação 2027Cadastro orçamentárioCTB-012Emenda ImpositivaCadastro orçamentárioCTB-013Empenho 2025-2026Execução orçamentáriaCTB-014Empenho 2027Execução orçamentáriaCTB-025LiquidaçãoExecução orçamentáriaCTB-028Norma OrçamentáriaCadastro orçamentário Cadastros CTB-007CredorCadastro de pessoaCTB-029OrdenadorCadastro de pessoa Receitas CTB-033Receita ExtraReceita extraorçamentáriaCTB-034Receita OrçamentáriaReceita orçamentáriaCTB-035Receita PrevistaPlanejamento da receita Execução financeira e bancos CTB-005Conta BancáriaCadastro financeiroCTB-006Conta Bancária CredorCadastro financeiroCTB-027Movimentação entre Contas BancáriasMovimentação financeiraCTB-030PagamentoExecução financeiraCTB-044Saldo Inicial ConciliadoConciliação bancáriaCTB-045Saldo Mensal ExtratoConciliação bancáriaCTB-046Transferência ConcedidaTransferências financeirasCTB-047Transferência RecebidaTransferências financeiras Restos a pagar CTB-026Liquidação RestoRestos a pagarCTB-031Pagamento RestoRestos a pagarCTB-041Resto InscritoRestos a pagar Retenções e estornos CTB-015Estorno Despesa ExtraEstorno extraorçamentárioCTB-016Estorno EmpenhoEstorno orçamentárioCTB-017Estorno LiquidaçãoEstorno orçamentárioCTB-018Estorno Liquidação RestoRestos a pagarCTB-019Estorno PagamentoEstorno financeiroCTB-020Estorno Pagamento RestoRestos a pagarCTB-021Estorno Receita ExtraEstorno extraorçamentárioCTB-022Estorno RestoRestos a pagarCTB-023Estorno RetençãoEstorno financeiroCTB-024Estorno Retenção RestoRestos a pagarCTB-042RetençãoRetençõesCTB-043Retenção RestoRetenções de restos Integrações CTB-036Relacionamento Empenho LicitaçãoIntegração LicitaçõesCTB-037Relacionamento Empenho Natureza ContrataçãoIntegração contratualCTB-038Relacionamento Empenho ObraIntegração ObrasCTB-039Relacionamento Liquidação Agrupamento FolhaIntegração FolhaCTB-040Responsável SIAFICGovernança SIAFIC Referências documentais CTB-032Programa (referência duplicada)Cadastro orçamentárioCTB-048Unidade Orçamentária (referência duplicada)Cadastro orçamentário CTB-001 Ação Cadastrar as ações orçamentárias da unidade gestora, com descrição, tipo, meta e unidade de medida. Desenvolvedor Versão2025 ~ EnvioOrçamento/Diário Atributos7 Regras5 ComplexidadeNão classificada CriticidadeNão classificada 1. Identificação funcional Categoria Cadastro orçamentário Chave de unicidade Exercício + Código Unidade Gestora + Código Ação Objeto raiz timestamp + elementos Dependências Dependências não registradas de forma consolidada. Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/acao-2025 2. Objetivo e finalidade Cadastrar as ações orçamentárias da unidade gestora, com descrição, tipo, meta e unidade de medida. Identificar os instrumentos de execução dos programas orçamentários utilizados no orçamento e em movimentações posteriores. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6 ^[0-9]+$   Chave Código da unidade gestora. codigoAcao string Sim 4 / 4 ^[0-9]+$   Chave Código da ação. descricaoAcao string Sim 10 / 70       Descrição da ação. tipoAcao string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Ação   Tipo da ação válido para o exercício. descricaoMeta string Sim 10 / 150       Descrição da meta. unidadeMedida string Sim 1 / 50       Unidade de medida da meta. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave de unicidade. A unidade gestora deve estar homologada pelo TCE antes do cadastro. O tipo da ação deve ser válido para o exercício, conforme a tabela oficial. Somente prefeituras e consórcios podem enviar ações. A prefeitura informa UGs do mesmo município; o consórcio informa apenas a si próprio. Catálogo completo de regras (5) Identificador Descrição Classificação ACAO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave de unicidade. Validação UNIDADE_GESTORA_HOMOLOGADA A unidade gestora deve estar homologada pelo TCE antes do cadastro. Validação ACAO_TIPO_VALIDO O tipo da ação deve ser válido para o exercício, conforme a tabela oficial. Validação RESPONSABILIDADE_PROTOCOLO Somente prefeituras e consórcios podem enviar ações. Validação ACAO_ESCOPO_CADASTRO A prefeitura informa UGs do mesmo município; o consórcio informa apenas a si próprio. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-002 Programa Cadastrar os programas orçamentários e sua associação ao objetivo do milênio. Desenvolvedor Versão2025 ~ EnvioOrçamento/Diário Atributos6 Regras5 ComplexidadeNão classificada CriticidadeNão classificada 1. Identificação funcional Categoria Cadastro orçamentário Chave de unicidade Exercício + Código Unidade Gestora + Código Programa Objeto raiz timestamp + elementos Dependências Dependências não registradas de forma consolidada. Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/programa-2025 2. Objetivo e finalidade Cadastrar os programas orçamentários e sua associação ao objetivo do milênio. Organizar ações e objetivos governamentais em programas utilizados na estrutura do orçamento. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6 ^[0-9]+$   Chave Código da unidade gestora. codigoPrograma string Sim 4 / 4 ^[0-9]+$   Chave Código do programa. descricaoPrograma string Sim 10 / 70       Descrição do programa. descricaoObjetivoMilenio string Sim 10 / 150       Descrição do objetivo do milênio. tipoObjetivoMilenio string Sim 2 / 2 ^[0-9]+$ Tabela Tipo Objetivo Milênio   Tipo do objetivo do milênio. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave de unicidade. A unidade gestora deve estar homologada pelo TCE antes do cadastro. O tipo de objetivo do milênio deve constar na tabela oficial. Somente prefeituras e consórcios podem enviar programas. A prefeitura cadastra programas das UGs vinculadas; o consórcio, apenas os próprios. Catálogo completo de regras (5) Identificador Descrição Classificação PROGRAMA_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave de unicidade. Validação UNIDADE_GESTORA_HOMOLOGADA A unidade gestora deve estar homologada pelo TCE antes do cadastro. Validação PROGRAMA_TIPO_OBJETIVO_MILENIO_VALIDO O tipo de objetivo do milênio deve constar na tabela oficial. Validação RESPONSABILIDADE_PROTOCOLO Somente prefeituras e consórcios podem enviar programas. Validação PROGRAMA_ESCOPO_CADASTRO A prefeitura cadastra programas das UGs vinculadas; o consórcio, apenas os próprios. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação documental O payload publicado utiliza a coleção 'programas', enquanto o schema define a coleção raiz como 'elementos'. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-003 Unidade Orçamentária Cadastrar as unidades orçamentárias vinculadas às unidades gestoras. Desenvolvedor Versão2025 ~ EnvioOrçamento/Diário Atributos4 Regras4 ComplexidadeNão classificada CriticidadeNão classificada 1. Identificação funcional Categoria Cadastro orçamentário Chave de unicidade Exercício + Código Unidade Gestora + Código Unidade Orçamentária Objeto raiz timestamp + elementos Dependências Dependências não registradas de forma consolidada. Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/unidade-orcamentaria-2025 2. Objetivo e finalidade Cadastrar as unidades orçamentárias vinculadas às unidades gestoras. Identificar a estrutura administrativa responsável por dotações e execução orçamentária. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6 ^[0-9]+$   Chave Código da unidade gestora. codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Código da unidade orçamentária. descricaoUnidadeOrcamentaria string Sim 10 / 50       Descrição da unidade orçamentária. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave de unicidade. A unidade gestora deve estar homologada pelo TCE antes do cadastro. Somente prefeituras e consórcios podem enviar unidades orçamentárias. A prefeitura cadastra UOs das UGs vinculadas; o consórcio, apenas as próprias. Catálogo completo de regras (4) Identificador Descrição Classificação UNIDADE_ORCAMENTARIA_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave de unicidade. Validação UNIDADE_GESTORA_HOMOLOGADA A unidade gestora deve estar homologada pelo TCE antes do cadastro. Validação RESPONSABILIDADE_PROTOCOLO Somente prefeituras e consórcios podem enviar unidades orçamentárias. Validação UNIDADE_ORCAMENTARIA_ESCOPO_CADASTRO A prefeitura cadastra UOs das UGs vinculadas; o consórcio, apenas as próprias. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação documental O payload publicado utiliza a coleção 'unidadesOrcamentarias', enquanto o schema define 'elementos'. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-004 Atualização Orçamentária Registrar alterações orçamentárias realizadas por decreto ou ofício sobre dotações e fontes de recursos. Desenvolvedor Versão2025 ~ EnvioDiário Atributos17 Regras28 ComplexidadeNão classificada CriticidadeNão classificada 1. Identificação funcional Categoria Movimentação orçamentária Chave de unicidade Exercício + UG + UO + Função + Subfunção + Programa + Ação + Categoria Econômica + Natureza + Modalidade + Elemento + Fonte + Exercício Fonte + Número Decreto/Ofício + Tipo Decreto/Ofício + Tipo Alteração Objeto raiz timestamp + elementos Dependências Dependências não registradas de forma consolidada. Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/atualizacao-orcamentaria-2025 2. Objetivo e finalidade Registrar alterações orçamentárias realizadas por decreto ou ofício sobre dotações e fontes de recursos. Controlar suplementações, anulações, transposições e demais tipos de alteração previstos na tabela oficial. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6 ^[0-9]+$   Chave Código da unidade gestora. codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária cadastrada. codigoFuncao string Sim 2 / 2 ^[0-9]+$ MSC/STN Chave Código de função. codigoSubfuncao string Sim 3 / 3 ^[0-9]+$ MSC/STN Chave Código de subfunção. codigoPrograma string Sim 4 / 4 ^[0-9]+$   Chave Programa cadastrado. codigoAcao string Sim 4 / 4 ^[0-9]+$   Chave Ação cadastrada. codigoCategoriaEconomica string Sim 1 / 1 ^[0-9]+$ MSC/STN Chave Categoria econômica. codigoNaturezaDespesa string Sim 1 / 1 ^[0-9]+$ MSC/STN Chave Natureza da despesa. codigoModalidadeDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN Chave Modalidade de aplicação. codigoElementoDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN Chave Elemento de despesa. codigoFonteRecurso string Sim 3 / 3 ^[0-9]+$ MSC/STN Chave Fonte de recurso. exercicioFonteRecurso string Sim     ATUAL; ANTERIOR Chave Exercício da fonte. numeroDecretoOficio string Sim 9 / 9 ^[0-9]+$   Chave Número do instrumento. tipoDecretoOficio string/integer Sim     DECRETO; OFICIO Chave Tipo do instrumento. tipoAlteracao string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Alteração Chave Tipo da alteração. valorAtualizacao number Sim   > 0     Valor da atualização. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave. Somente UGs do mesmo município; consórcio apenas a si próprio. Prefeituras e consórcios enviam decreto/ofício; câmaras apenas ofício. A unidade orçamentária deve existir no exercício. O programa deve existir no exercício. Catálogo completo de regras (28) Identificador Descrição Classificação ATUALIZACAO_ORCAMENTARIA_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave. Validação ATUALIZACAO_ORCAMENTARIA_UNIDADE_GESTORA_MUNICIPIO Somente UGs do mesmo município; consórcio apenas a si próprio. Validação ATUALIZACAO_ORCAMENTARIA_RESPONSABILIDADE_PROTOCOLO Prefeituras e consórcios enviam decreto/ofício; câmaras apenas ofício. Validação ATUALIZACAO_ORCAMENTARIA_UNIDADE_ORCAMENTARIA_CADASTRADA A unidade orçamentária deve existir no exercício. Validação ATUALIZACAO_ORCAMENTARIA_PROGRAMA_CADASTRADO O programa deve existir no exercício. Validação ATUALIZACAO_ORCAMENTARIA_ACAO_CADASTRADA A ação deve existir no exercício. Validação ATUALIZACAO_ORCAMENTARIA_FUNCAO_STN Função deve seguir a MSC/STN. Validação ATUALIZACAO_ORCAMENTARIA_SUBFUNCAO_STN Subfunção deve seguir a MSC/STN. Validação ATUALIZACAO_ORCAMENTARIA_CATEGORIA_ECONOMICA_STN Categoria econômica deve seguir a MSC/STN. Validação ATUALIZACAO_ORCAMENTARIA_NATUREZA_DESPESA_STN Natureza de despesa deve seguir a MSC/STN. Validação ATUALIZACAO_ORCAMENTARIA_ELEMENTO_DESPESA_STN Elemento de despesa deve seguir a MSC/STN. Validação ATUALIZACAO_ORCAMENTARIA_FONTE_RECURSO_STN Fonte de recurso deve seguir a MSC/STN. Validação ATUALIZACAO_ORCAMENTARIA_SUPLEMENTACAO_ANULACAO Tipos 4 e 8 devem equilibrar com tipo 11 por decreto. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_14_15 Tipo 14 exige tipo 15 com o mesmo valor. Validação ATUALIZACAO_ORCAMENTARIA_DECRETO_OFICIO_OBRIGATORIO Toda atualização deve estar vinculada a decreto/ofício. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_6_7_8_9_16_DOTACAO_INEXISTENTE Tipos 6, 7, 8, 9 e 16 só podem ser inseridos se a dotação não existir; ela será criada. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_2 Tipo 2 usa fonte ANTERIOR; a dotação ATUAL deve existir e a ANTERIOR pode ser criada. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_10 Se a dotação não existir, será criada; se existir, registra-se somente a atualização. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_7_16_EXERCICIO_FONTE Tipos 7 e 16 exigem fonte ANTERIOR e criam equivalente ATUAL com valor zero. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_6_8_9_EXERCICIO_FONTE Tipos 6, 8 e 9 exigem fonte ATUAL. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_REQUER_DOTACAO_EXISTIR Tipos 1, 3, 4, 11, 12 e 14 exigem dotação existente. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_15_DOTACAO Tipo 15 deve corresponder ao tipo 14, alterando apenas o elemento; soma por ofício deve ser igual. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_13_DOTACAO Tipo 13 deve igualar a soma dos tipos 12 por fonte e exercício; pode criar dotação. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_11_SOMA_SUPLEMENTACAO Soma do tipo 11 por decreto deve igualar tipos 4 ou 8. Validação ATUALIZACAO_ORCAMENTARIA_DECRETO_TIPO_4_8_NAO_PERMITIDO Um decreto não pode conter tipos 4 e 8 simultaneamente. Validação ATUALIZACAO_ORCAMENTARIA_DECRETO_TIPOS_INCOMPATIVEIS Não combinar tipos 1–4 com tipos 6, 7, 8, 9, 10 e 15 no mesmo decreto. Validação ATUALIZACAO_ORCAMENTARIA_OFICIO_TIPO_OBRIGATORIO Ofício só admite tipo 14 ou 15. Validação ATUALIZACAO_ORCAMENTARIA_TIPO_ALTERACAO_VALIDO O tipo de alteração deve constar na tabela oficial. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação documental O schema lista 'dataAtualizacao' como obrigatório, mas esse atributo não aparece na relação de propriedades nem no payload publicado. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação documental O tipo do campo tipoDecretoOficio está declarado como integer, embora o enum e o payload usem textos DECRETO/OFICIO. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação documental Há uma vírgula aparentemente ausente entre codigoPrograma e codigoAcao no schema publicado. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-005 Conta Bancária Cadastrar contas bancárias utilizadas pela unidade gestora. Desenvolvedor Versão2025 ~ EnvioDiário Atributos7 Regras3 ComplexidadeNão classificada CriticidadeNão classificada 1. Identificação funcional Categoria Cadastro financeiro Chave de unicidade Código Unidade Gestora + Número Conta + Banco + Agência + Tipo Conta + CNPJ Gerência + Descrição Objeto raiz timestamp + elementos Dependências Dependências não registradas de forma consolidada. Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/conta-bancaria-2025 2. Objetivo e finalidade Cadastrar contas bancárias utilizadas pela unidade gestora. Identificar contas para pagamentos, movimentações e conciliações bancárias. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição numeroContaBancaria string Sim 1 / 13 ^[A-Z0-9]+$   Chave Número da conta. codigoBancoContaBancaria string Sim 3 / 3 ^[0-9]+$ FEBRABAN Chave Código do banco. numeroAgenciaContaBancaria string Sim 1 / 6 ^[A-Z0-9]+$   Chave Número da agência. descricaoContaBancaria string Sim 10 / 100     Chave Descrição da conta. tipoContaBancaria string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Conta Bancária Chave Tipo da conta. cnpjGerenciaContaBancaria string Sim 14 / 14 ^[A-Z0-9]+$   Chave CNPJ da gerência. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave. Tipo de conta deve constar na tabela oficial. Código do banco deve ser válido na FEBRABAN. Catálogo completo de regras (3) Identificador Descrição Classificação CONTA_BANCARIA_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave. Validação CONTA_BANCARIA_TIPO_VALIDO Tipo de conta deve constar na tabela oficial. Validação CONTA_BANCARIA_CODIGO_BANCO_VALIDO Código do banco deve ser válido na FEBRABAN. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação documental A chave publicada inclui Código Unidade Gestora, mas o atributo não aparece no item/schema da página. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-006 Conta Bancária Credor Cadastrar as contas bancárias dos credores. Desenvolvedor Versão2025 ~ EnvioDiário Atributos5 Regras3 ComplexidadeNão classificada CriticidadeNão classificada 1. Identificação funcional Categoria Cadastro financeiro Chave de unicidade Código Unidade Gestora + Número Conta + Banco + Agência + CPF/CNPJ Credor Objeto raiz timestamp + elementos Dependências Dependências não registradas de forma consolidada. Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/conta-bancaria-credor-2025 2. Objetivo e finalidade Cadastrar as contas bancárias dos credores. Disponibilizar dados bancários vinculados ao credor para operações financeiras. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição cpfCnpjCredor string Sim 11 / 14 ^[A-Z0-9]+$   Chave CPF/CNPJ do credor. numeroContaBancariaCredor string Sim 1 / 13 ^[A-Z0-9]+$   Chave Número da conta do credor. codigoBancoContaBancariaCredor string Sim 3 / 3 ^[0-9]+$ FEBRABAN Chave Código do banco. numeroAgenciaContaBancariaCredor string Sim 1 / 6 ^[A-Z0-9]+$   Chave Número da agência. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave. Código do banco deve ser válido na FEBRABAN. O credor deve estar previamente cadastrado para a unidade gestora. Catálogo completo de regras (3) Identificador Descrição Classificação CONTA_BANCARIA_CREDOR_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave. Validação CONTA_BANCARIA_CREDOR_CODIGO_BANCO_VALIDO Código do banco deve ser válido na FEBRABAN. Validação CONTA_BANCARIA_CREDOR_CREDOR_CADASTRADO O credor deve estar previamente cadastrado para a unidade gestora. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação documental A chave publicada inclui Código Unidade Gestora, mas o atributo não aparece no item/schema da página. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-007 Credor Cadastrar pessoas físicas ou jurídicas que atuam como credores da unidade gestora. Desenvolvedor Versão2025 ~ EnvioDiário Atributos4 Regras3 ComplexidadeNão classificada CriticidadeNão classificada 1. Identificação funcional Categoria Cadastro de pessoa Chave de unicidade Código Unidade Gestora + CPF/CNPJ + Nome Objeto raiz timestamp + elementos Dependências Dependências não registradas de forma consolidada. Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/credor-2025 2. Objetivo e finalidade Cadastrar pessoas físicas ou jurídicas que atuam como credores da unidade gestora. Permitir a vinculação do credor a empenhos, liquidações, pagamentos e contas bancárias. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição cpfCnpj string Sim 11 / 14 ^[A-Z0-9]+$   Chave CPF/CNPJ. nome string Sim 1 / 150     Chave Nome do credor. tipo string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Credor   Tipo do credor. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave. Tipo de credor deve constar na tabela oficial. O nome deve corresponder ao cadastro na Receita Federal. Catálogo completo de regras (3) Identificador Descrição Classificação CREDOR_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave. Validação CREDOR_TIPO_VALIDO Tipo de credor deve constar na tabela oficial. Validação CREDOR_NOME_INVALIDO O nome deve corresponder ao cadastro na Receita Federal. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação documental O payload usa cpfCnpjCredor, nomeCredor e tipoCredor, enquanto o schema define cpfCnpj, nome e tipo. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação documental A chave publicada inclui Código Unidade Gestora, mas o atributo não aparece no item/schema da página. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-008 Decreto Ofício Registrar decretos e ofícios que fundamentam atualizações orçamentárias. Desenvolvedor Versão2025 ~ EnvioDiário Atributos6 Regras6 ComplexidadeNão classificada CriticidadeNão classificada 1. Identificação funcional Categoria Instrumento orçamentário Chave de unicidade Exercício + Código Unidade Gestora + Número Decreto/Ofício + Tipo Documento Objeto raiz timestamp + elementos Dependências Dependências não registradas de forma consolidada. Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/decreto-oficio-2025 2. Objetivo e finalidade Registrar decretos e ofícios que fundamentam atualizações orçamentárias. Vincular o instrumento legal, seu protocolo e anexo às alterações do orçamento. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição numeroDecretoOficio string Sim 9 / 9 ^[0-9]+$   Chave Número do decreto ou ofício. tipoDocumento string/integer Sim     DECRETO; OFICIO Chave Tipo do documento. protolocoLei string Sim 9 / 9 ^\d{6}/\d{2}$     Protocolo da lei no banco do TCE. dataDecretoOficio string/date Sim   format: date     Data do documento. referenciaAnexo string Sim 33 / 33 ^[0-9]{6}\.[A-Z2-7]{26}$     Hash do anexo PDF. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave. O protocolo da lei deve existir no banco de legislação do TCE. O número deve existir em atualização orçamentária no mesmo envio. Não enviar decreto/ofício sem atualização orçamentária no mesmo envio. Prefeituras e consórcios enviam decretos/ofícios; câmaras enviam ofícios. Catálogo completo de regras (6) Identificador Descrição Classificação DECRETO_OFICIO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave. Validação DECRETO_OFICIO_PROTOCOLO_LEI_EXISTENTE O protocolo da lei deve existir no banco de legislação do TCE. Validação DECRETO_OFICIO_NUMERO_ATUALIZACAO_COMPETENCIA O número deve existir em atualização orçamentária no mesmo envio. Validação DECRETO_OFICIO_ATUALIZACAO_OBRIGATORIA Não enviar decreto/ofício sem atualização orçamentária no mesmo envio. Validação DECRETO_OFICIO_RESPONSABILIDADE_PROTOCOLO Prefeituras e consórcios enviam decretos/ofícios; câmaras enviam ofícios. Validação DECRETO_OFICIO_ANEXO_OBRIGATORIO O arquivo PDF do instrumento deve ser enviado. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação documental A propriedade está grafada como 'protolocoLei' na documentação. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação documental O tipoDocumento é declarado como integer, mas o enum e o payload usam DECRETO/OFICIO. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação documental O schema exige codigoUnidadeGestora, mas essa propriedade não aparece na lista de propriedades. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação documental Há uma vírgula aparentemente ausente antes da propriedade action no schema publicado. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-009 Despesa Extra Registrar despesas extraorçamentárias, seus credores, contas contábeis, fontes de recursos e eventual vínculo com receita extra. Desenvolvedor Versão2025 ~ EnvioDiário Atributos19 Regras5 ComplexidadeAlta CriticidadeAlta 1. Identificação funcional Categoria Movimento extraorçamentário Chave de unicidade Exercício + Código Unidade Gestora + Número Despesa Extra Objeto raiz timestamp + elementos Dependências Credor; Conta Bancária; Receita Extra (condicional); tabelas STN/MSC Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/despesa-extra-2025 2. Objetivo e finalidade Registrar despesas extraorçamentárias, seus credores, contas contábeis, fontes de recursos e eventual vínculo com receita extra. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Despesa Extra. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição numeroDespesaExtra string Sim 7 / 7 ^[0-9]+$   Chave Número da despesa extra. codigoContaContabil string Sim 9 / 9 ^[0-9]+$ IPC 00/STN e ajustes TCE-PB   Conta contábil. cpfCnpjCredor string Sim 14 / 14 ^[0-9]+$     CPF/CNPJ do credor. exercicioFonteRecurso string Sim     ATUAL; ANTERIOR   Exercício da fonte. codigoFonteRecurso string Sim 3 / 3 ^[0-9]+$ MSC/STN   Fonte de recurso. codigoBancoContaBancaria string Sim 3 / 3 ^[0-9]+$ FEBRABAN   Banco. numeroContaBancaria string Sim 1 / 13 ^[0-9]+$     Conta bancária. numeroAgenciaContaBancaria string Sim 1 / 6 ^[0-9]+$     Agência. tipoContaBancaria string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Conta Bancária   Tipo da conta. cnpjGerenciaContaBancaria string Sim 14 / 14 ^[0-9]+$     CNPJ da gerência. valorDespesaExtra number Sim > 0       Valor da despesa extra. historico string Sim 10 / 500       Histórico. codigoDespesaExtra string Sim 8 / 8 ^[0-9]+$ Tabela Código Despesa Extra   Código da despesa extra. codigoFonteRecursoPagamento string Sim 3 / 3 ^[0-9]+$ MSC/STN   Fonte do pagamento. co string Sim 4 / 4 ^[0-9]+$ MSC/STN   Código de acompanhamento. codigoUnidadeGestoraReceitaExtra string Condicional 6 / 6 ^[0-9]+$     UG da receita extra vinculada. exercicioReceitaExtra string Condicional 4 / 4 ^[0-9]+$     Exercício da receita extra. numeroReceitaExtra string Condicional 7 / 7 ^[0-9]+$     Número da receita extra. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave. A receita extra vinculada deve existir quando a conta contábil assim exigir. A conta contábil deve seguir os códigos definidos pelo STN. O credor deve estar previamente cadastrado. A UG da receita extra deve estar homologada e pertencer ao mesmo município. Catálogo completo de regras (5) Identificador Descrição Classificação DESPESA_EXTRA_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave. Validação DESPESA_EXTRA_RECEITA_EXTRA_EXISTENTE A receita extra vinculada deve existir quando a conta contábil assim exigir. Validação DESPESA_EXTRA_CONTA_CONTABIL A conta contábil deve seguir os códigos definidos pelo STN. Validação DESPESA_EXTRA_CREDOR_CADASTRADO O credor deve estar previamente cadastrado. Validação UNIDADE_GESTORA_HOMOLOGADA A UG da receita extra deve estar homologada e pertencer ao mesmo município. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial O schema exige cpfCnpjFornecedor, mas a propriedade e o payload utilizam cpfCnpjCredor. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação oficial A tabela usa codigoCO, enquanto schema e payload usam co. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação oficial O payload possui exercicio e dataDespesaExtra, mas essas propriedades não constam no schema. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-010 Dotação 2025-2026 Cadastrar dotações orçamentárias para os exercícios de 2025 e 2026. Desenvolvedor Versão2025-2026 EnvioOrçamento Atributos14 Regras11 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Cadastro orçamentário Chave de unicidade Exercício + UG + UO + Função + Subfunção + Programa + Ação + Categoria Econômica + Natureza + Modalidade + Elemento + Fonte + Exercício Fonte Objeto raiz timestamp + elementos Dependências Unidade Gestora; Unidade Orçamentária; Programa; Ação; MSC/STN Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/dotacao-2025-2026 2. Objetivo e finalidade Cadastrar dotações orçamentárias para os exercícios de 2025 e 2026. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Dotação 2025-2026. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6 ^[0-9]+$   Chave Código da unidade gestora. codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária cadastrada. codigoFuncao string Sim 2 / 2 ^[0-9]+$ MSC/STN Chave Função. codigoSubfuncao string Sim 3 / 3 ^[0-9]+$ MSC/STN Chave Subfunção. codigoPrograma string Sim 4 / 4 ^[0-9]+$   Chave Programa cadastrado. codigoAcao string Sim 4 / 4 ^[0-9]+$   Chave Ação cadastrada. codigoCategoriaEconomica string Sim 1 / 1 ^[0-9]+$ MSC/STN Chave Categoria econômica. codigoNaturezaDespesa string Sim 1 / 1 ^[0-9]+$ MSC/STN Chave Natureza da despesa. codigoModalidadeDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN Chave Modalidade de aplicação. codigoElementoDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN Chave Elemento de despesa. exercicioFonteRecurso string Sim     ATUAL; ANTERIOR Chave Exercício da fonte de recurso. codigoFonteRecurso string Sim 3 / 3 ^[0-9]+$ MSC/STN Chave Fonte de recurso. valorDotacao number Sim > 0       Valor da dotação. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave de unicidade. A unidade gestora deve estar homologada pelo TCE. Função deve seguir a MSC/STN. Subfunção deve seguir a MSC/STN. Categoria econômica deve seguir a MSC/STN. Catálogo completo de regras (11) Identificador Descrição Classificação DOTACAO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave de unicidade. Validação UNIDADE_GESTORA_HOMOLOGADA A unidade gestora deve estar homologada pelo TCE. Validação DOTACAO_CODIGO_FUNCAO_VALIDO Função deve seguir a MSC/STN. Validação DOTACAO_CODIGO_SUBFUNCAO_VALIDO Subfunção deve seguir a MSC/STN. Validação DOTACAO_CODIGO_CATEGORIA_ECONOMICA_VALIDO Categoria econômica deve seguir a MSC/STN. Validação DOTACAO_CODIGO_NATUREZA_DESPESA_VALIDO Natureza da despesa deve seguir a MSC/STN. Validação DOTACAO_CODIGO_MODALIDADE_DESPESA_VALIDO Modalidade de aplicação deve seguir a MSC/STN. Validação DOTACAO_CODIGO_ELEMENTO_DESPESA_VALIDO Elemento de despesa deve seguir a MSC/STN. Validação DOTACAO_PROGRAMA_CADASTRADO Programa deve estar cadastrado para o exercício. Validação DOTACAO_ACAO_CADASTRADA Ação deve estar cadastrada para o exercício. Validação DOTACAO_UNIDADE_ORCAMENTARIA_CADASTRADA Unidade orçamentária deve estar cadastrada para o exercício. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-011 Dotação 2027 Cadastrar dotações orçamentárias a partir de 2027, com referências opcionais a emendas. Desenvolvedor Versão2027 ~ EnvioOrçamento Atributos16 Regras11 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Cadastro orçamentário Chave de unicidade Mesma chave funcional da Dotação 2025-2026 Objeto raiz timestamp + elementos Dependências Dependências da dotação; Emenda Impositiva (quando informada); Tabela Emenda Parlamentar Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/dotacao-2027 2. Objetivo e finalidade Cadastrar dotações orçamentárias a partir de 2027, com referências opcionais a emendas. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Dotação 2027. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6 ^[0-9]+$   Chave Código da unidade gestora. codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária cadastrada. codigoFuncao string Sim 2 / 2 ^[0-9]+$ MSC/STN Chave Função. codigoSubfuncao string Sim 3 / 3 ^[0-9]+$ MSC/STN Chave Subfunção. codigoPrograma string Sim 4 / 4 ^[0-9]+$   Chave Programa cadastrado. codigoAcao string Sim 4 / 4 ^[0-9]+$   Chave Ação cadastrada. codigoCategoriaEconomica string Sim 1 / 1 ^[0-9]+$ MSC/STN Chave Categoria econômica. codigoNaturezaDespesa string Sim 1 / 1 ^[0-9]+$ MSC/STN Chave Natureza da despesa. codigoModalidadeDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN Chave Modalidade de aplicação. codigoElementoDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN Chave Elemento de despesa. exercicioFonteRecurso string Sim     ATUAL; ANTERIOR Chave Exercício da fonte de recurso. codigoFonteRecurso string Sim 3 / 3 ^[0-9]+$ MSC/STN Chave Fonte de recurso. codigoEmendaParlamentar string Não 4 / 4 ^[0-9]+$ Tabela Emenda Parlamentar   Código da emenda parlamentar. numeroEmendaImpositiva string Não 1 / 4 ^[0-9]+$     Número da emenda impositiva. valorDotacao number Sim > 0       Valor da dotação. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave de unicidade. A unidade gestora deve estar homologada pelo TCE. Função deve seguir a MSC/STN. Subfunção deve seguir a MSC/STN. Categoria econômica deve seguir a MSC/STN. Catálogo completo de regras (11) Identificador Descrição Classificação DOTACAO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave de unicidade. Validação UNIDADE_GESTORA_HOMOLOGADA A unidade gestora deve estar homologada pelo TCE. Validação DOTACAO_CODIGO_FUNCAO_VALIDO Função deve seguir a MSC/STN. Validação DOTACAO_CODIGO_SUBFUNCAO_VALIDO Subfunção deve seguir a MSC/STN. Validação DOTACAO_CODIGO_CATEGORIA_ECONOMICA_VALIDO Categoria econômica deve seguir a MSC/STN. Validação DOTACAO_CODIGO_NATUREZA_DESPESA_VALIDO Natureza da despesa deve seguir a MSC/STN. Validação DOTACAO_CODIGO_MODALIDADE_DESPESA_VALIDO Modalidade de aplicação deve seguir a MSC/STN. Validação DOTACAO_CODIGO_ELEMENTO_DESPESA_VALIDO Elemento de despesa deve seguir a MSC/STN. Validação DOTACAO_PROGRAMA_CADASTRADO Programa deve estar cadastrado para o exercício. Validação DOTACAO_ACAO_CADASTRADA Ação deve estar cadastrada para o exercício. Validação DOTACAO_UNIDADE_ORCAMENTARIA_CADASTRADA Unidade orçamentária deve estar cadastrada para o exercício. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial O payload publicado repete codigoEmendaParlamentar no mesmo objeto. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação oficial Os novos campos de emenda são propriedades opcionais e não compõem a chave publicada. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-012 Emenda Impositiva Cadastrar emendas impositivas, seus autores, beneficiários, finalidade e valor. Desenvolvedor Versão2027 ~ EnvioOrçamento/Diário Atributos9 Regras3 ComplexidadeMédia CriticidadeAlta 1. Identificação funcional Categoria Cadastro orçamentário Chave de unicidade Exercício + Código Unidade Gestora + Número Emenda Impositiva Objeto raiz timestamp + elementos Dependências Unidade Gestora Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/emenda-impositiva-2027 2. Objetivo e finalidade Cadastrar emendas impositivas, seus autores, beneficiários, finalidade e valor. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Emenda Impositiva. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6 ^[0-9]+$   Chave Unidade gestora. numeroEmendaImpositiva string Sim 1 / 4 ^[0-9]+$   Chave Número da emenda. cpfAutor string Sim 11 / 11 ^[0-9]+$     CPF do autor. nomeAutor string Sim 1 / 150       Nome do autor. cnpjBeneficiario string Sim 14 / 14 ^[A-Z0-9]+$     CNPJ do beneficiário. nomeBeneficiario string Sim 1 / 150       Nome do beneficiário. finalidade string Sim 10 / 500       Finalidade da emenda. valorEmendaImpositiva number Sim > 0       Valor da emenda. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio A unidade gestora deve estar homologada pelo TCE. Apenas prefeituras e consórcios enviam emendas impositivas. Prefeitura cadastra UGs vinculadas; consórcio apenas suas próprias informações. Catálogo completo de regras (3) Identificador Descrição Classificação UNIDADE_GESTORA_HOMOLOGADA A unidade gestora deve estar homologada pelo TCE. Validação RESPONSABILIDADE_PROTOCOLO Apenas prefeituras e consórcios enviam emendas impositivas. Validação EMENDA_IMPOSITIVA_ESCOPO_CADASTRO Prefeitura cadastra UGs vinculadas; consórcio apenas suas próprias informações. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial A lista required exige valorEmenda, mas a propriedade e o payload usam valorEmendaImpositiva. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-013 Empenho 2025-2026 Registrar empenhos emitidos nos exercícios de 2025 e 2026. Desenvolvedor Versão2025-2026 EnvioDiário Atributos24 Regras6 ComplexidadeMuito Alta CriticidadeCrítica 1. Identificação funcional Categoria Execução orçamentária Chave de unicidade Exercício + Código Unidade Gestora + Código Unidade Orçamentária + Número Empenho Objeto raiz timestamp + elementos Dependências Dotação; Credor; Ordenador; Programa; Ação; domínios de contratação e licitação Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/empenho-2025-2026 2. Objetivo e finalidade Registrar empenhos emitidos nos exercícios de 2025 e 2026. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Empenho 2025-2026. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Número do empenho. tipoEmpenho string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Empenho   Tipo do empenho. valorEmpenho number Sim > 0       Valor do empenho. codigoFuncao string Sim 2 / 2 ^[0-9]+$ MSC/STN   Função. codigoSubfuncao string Sim 3 / 3 ^[0-9]+$ MSC/STN   Subfunção. codigoPrograma string Sim 4 / 4 ^[0-9]+$     Programa. codigoAcao string Sim 4 / 4 ^[0-9]+$     Ação. codigoCategoriaEconomica string Sim 1 / 1 ^[0-9]+$ MSC/STN   Categoria econômica. codigoNaturezaDespesa string Sim 1 / 1 ^[0-9]+$ MSC/STN   Natureza da despesa. codigoModalidadeDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN   Modalidade de aplicação. codigoElementoDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN   Elemento da despesa. codigoSubelementoDespesa string Sim 3 / 3 ^[0-9]+$ MSC/STN   Subelemento da despesa. codigoCO string Não 4 / 4 ^[0-9]+$ MSC/STN   Código de acompanhamento orçamentário. exercicioFonteRecurso string Sim     ATUAL; ANTERIOR   Exercício da fonte. codigoFonteRecurso string Sim 3 / 3 ^[0-9]+$ MSC/STN   Fonte de recurso. codigoNaturezaContratacao string Sim     Tabela Natureza Contratação   Natureza da contratação. codigoModalidadeLicitacao string Não     Tabela Modalidade Licitação   Modalidade da licitação. numeroObra string Não         Número da obra. numeroLicitacao string Não         Número da licitação. historico string Sim 10 / 500       Histórico do empenho. cpfCnpjCredor string Sim 11 / 14 ^[A-Z0-9]+$     CPF/CNPJ do credor. cpfOrdenador string Sim 11 / 11 ^[0-9]+$     CPF do ordenador. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave de unicidade. A dotação referenciada deve existir no exercício do envio. O ordenador deve estar cadastrado para a unidade gestora. O credor deve estar cadastrado para a unidade gestora. O tipo de empenho deve constar na tabela oficial. Catálogo completo de regras (6) Identificador Descrição Classificação EMPENHO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave de unicidade. Validação EMPENHO_DOTACAO_CADASTRADA A dotação referenciada deve existir no exercício do envio. Validação EMPENHO_ORDENADOR_CADASTRADO O ordenador deve estar cadastrado para a unidade gestora. Validação EMPENHO_CREDOR_CADASTRADO O credor deve estar cadastrado para a unidade gestora. Validação EMPENHO_TIPO_VALIDO O tipo de empenho deve constar na tabela oficial. Validação EMPENHO_NATUREZA_CONTRATACAO_VALIDA A natureza da contratação deve constar na tabela oficial. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-014 Empenho 2027 Registrar empenhos a partir de 2027, incluindo referência opcional à emenda parlamentar. Desenvolvedor Versão2027 ~ EnvioDiário Atributos25 Regras6 ComplexidadeMuito Alta CriticidadeCrítica 1. Identificação funcional Categoria Execução orçamentária Chave de unicidade Exercício + Código Unidade Gestora + Código Unidade Orçamentária + Número Empenho Objeto raiz timestamp + elementos Dependências Dependências do empenho; Tabela Emenda Parlamentar Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/empenho-2027 2. Objetivo e finalidade Registrar empenhos a partir de 2027, incluindo referência opcional à emenda parlamentar. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Empenho 2027. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Número do empenho. tipoEmpenho string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Empenho   Tipo do empenho. valorEmpenho number Sim > 0       Valor do empenho. codigoFuncao string Sim 2 / 2 ^[0-9]+$ MSC/STN   Função. codigoSubfuncao string Sim 3 / 3 ^[0-9]+$ MSC/STN   Subfunção. codigoPrograma string Sim 4 / 4 ^[0-9]+$     Programa. codigoAcao string Sim 4 / 4 ^[0-9]+$     Ação. codigoCategoriaEconomica string Sim 1 / 1 ^[0-9]+$ MSC/STN   Categoria econômica. codigoNaturezaDespesa string Sim 1 / 1 ^[0-9]+$ MSC/STN   Natureza da despesa. codigoModalidadeDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN   Modalidade de aplicação. codigoElementoDespesa string Sim 2 / 2 ^[0-9]+$ MSC/STN   Elemento da despesa. codigoSubelementoDespesa string Sim 3 / 3 ^[0-9]+$ MSC/STN   Subelemento da despesa. codigoCO string Não 4 / 4 ^[0-9]+$ MSC/STN   Código de acompanhamento orçamentário. exercicioFonteRecurso string Sim     ATUAL; ANTERIOR   Exercício da fonte. codigoFonteRecurso string Sim 3 / 3 ^[0-9]+$ MSC/STN   Fonte de recurso. codigoNaturezaContratacao string Sim     Tabela Natureza Contratação   Natureza da contratação. codigoEmendaParlamentar string Não 4 / 4 ^[0-9]+$ Tabela Emenda Parlamentar   Código da emenda parlamentar. codigoModalidadeLicitacao string Não     Tabela Modalidade Licitação   Modalidade da licitação. numeroObra string Não         Número da obra. numeroLicitacao string Não         Número da licitação. historico string Sim 10 / 500       Histórico do empenho. cpfCnpjCredor string Sim 11 / 14 ^[A-Z0-9]+$     CPF/CNPJ do credor. cpfOrdenador string Sim 11 / 11 ^[0-9]+$     CPF do ordenador. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave de unicidade. A dotação referenciada deve existir no exercício do envio. O ordenador deve estar cadastrado para a unidade gestora. O credor deve estar cadastrado para a unidade gestora. O tipo de empenho deve constar na tabela oficial. Catálogo completo de regras (6) Identificador Descrição Classificação EMPENHO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave de unicidade. Validação EMPENHO_DOTACAO_CADASTRADA A dotação referenciada deve existir no exercício do envio. Validação EMPENHO_ORDENADOR_CADASTRADO O ordenador deve estar cadastrado para a unidade gestora. Validação EMPENHO_CREDOR_CADASTRADO O credor deve estar cadastrado para a unidade gestora. Validação EMPENHO_TIPO_VALIDO O tipo de empenho deve constar na tabela oficial. Validação EMPENHO_NATUREZA_CONTRATACAO_VALIDA A natureza da contratação deve constar na tabela oficial. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial O schema required usa cpfCnpjFornecedor, enquanto a tabela e o payload usam cpfCnpjCredor. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação oficial A principal alteração identificada em 2027 é a inclusão de codigoEmendaParlamentar. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-015 Estorno Despesa Extra Registrar estornos de despesas extraorçamentárias. Desenvolvedor Versão2025 ~ EnvioDiário Atributos6 Regras3 ComplexidadeMédia CriticidadeAlta 1. Identificação funcional Categoria Estorno extraorçamentário Chave de unicidade Exercício + Código Unidade Gestora + Número Despesa Extra + Número Estorno Objeto raiz timestamp + elementos Dependências Despesa Extra Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-despesa-extra-2025 2. Objetivo e finalidade Registrar estornos de despesas extraorçamentárias. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Despesa Extra. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição numeroDespesaExtra string Sim 7 / 7 ^[0-9]+$   Chave Despesa extra referenciada. numeroEstornoDespesaExtra string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno. dataEstornoDespesaExtra date Sim   format: date     Data do estorno. valorEstornoDespesaExtra number Sim > 0       Valor estornado. motivo string Sim 1 / 255       Motivo do estorno. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir duplicidade. A despesa extra referenciada deve existir no exercício. A soma dos estornos não pode superar a despesa extra. Catálogo completo de regras (3) Identificador Descrição Classificação ESTORNO_DESPESA_EXTRA_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação ESTORNO_DESPESA_EXTRA_DESPESA_EXTRA_CADASTRADA A despesa extra referenciada deve existir no exercício. Validação ESTORNO_DESPESA_EXTRA_VALOR_ESTORNADO_EXCEDE_VALOR A soma dos estornos não pode superar a despesa extra. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial A chave textual publicada menciona Número Receita Extra, embora os atributos se refiram a Despesa Extra. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-016 Estorno Empenho Registrar estornos de valores empenhados. Desenvolvedor Versão2025 ~ EnvioDiário Atributos6 Regras3 ComplexidadeMédia CriticidadeAlta 1. Identificação funcional Categoria Estorno orçamentário Chave de unicidade Exercício + UG + UO + Número Empenho + Número Estorno Empenho Objeto raiz timestamp + elementos Dependências Empenho Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-empenho-2025 2. Objetivo e finalidade Registrar estornos de valores empenhados. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Empenho. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave UO. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Empenho. numeroEstornoEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno. valorEstornoEmpenho number Sim > 0       Valor estornado. motivo string Sim 500       Motivo. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. O empenho referenciado deve existir. O valor estornado não pode superar o saldo disponível do empenho. Catálogo completo de regras (3) Identificador Descrição Classificação ESTORNO_EMPENHO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação ESTORNO_EMPENHO_EMPENHO_CADASTRADO O empenho referenciado deve existir. Validação ESTORNO_EMPENHO_VALOR_EXCEDE_SALDO O valor estornado não pode superar o saldo disponível do empenho. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-017 Estorno Liquidação Registrar estornos de liquidações do exercício. Desenvolvedor Versão2025 ~ EnvioDiário Atributos7 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Estorno orçamentário Chave de unicidade Exercício + UG + UO + Número Empenho + Número Liquidação + Número Estorno Objeto raiz timestamp + elementos Dependências Liquidação; Empenho Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-liquidacao-2025 2. Objetivo e finalidade Registrar estornos de liquidações do exercício. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Liquidação. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave UO. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Empenho. numeroLiquidacao string Sim 7 / 7 ^[0-9]+$   Chave Liquidação. numeroEstornoLiquidacao string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno. motivoEstornoLiquidacao string Sim 500       Motivo. valorEstornoLiquidacao number Sim > 0       Valor estornado. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. A liquidação referenciada deve existir. O estorno não pode superar o saldo da liquidação. Catálogo completo de regras (3) Identificador Descrição Classificação ESTORNO_LIQUIDACAO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação ESTORNO_LIQUIDACAO_LIQUIDACAO_CADASTRADA A liquidação referenciada deve existir. Validação ESTORNO_LIQUIDACAO_VALOR_EXCEDE_SALDO O estorno não pode superar o saldo da liquidação. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-018 Estorno Liquidação Resto Registrar estornos de liquidações de restos a pagar. Desenvolvedor Versão2025 ~ EnvioDiário Atributos8 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Restos a pagar Chave de unicidade Exercício + UG + Ano Empenho + UO + Empenho + Liquidação + Número Estorno Objeto raiz timestamp + elementos Dependências Liquidação Resto; Empenho/Resto Inscrito Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-liquidacao-resto-2025 2. Objetivo e finalidade Registrar estornos de liquidações de restos a pagar. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Liquidação Resto. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição anoEmissaoEmpenho string Sim 4 / 4 ^[0-9]+$   Chave Ano do empenho. codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave UO. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Empenho. numeroLiquidacao string Sim 7 / 7 ^[0-9]+$   Chave Liquidação do resto. numeroEstornoLiquidacaoResto string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno. motivo string Sim 1 / 120       Motivo. valorEstornoLiquidacaoResto number Sim > 0       Valor estornado. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. A liquidação de resto referenciada deve existir. O valor estornado não pode superar o saldo da liquidação de resto. Catálogo completo de regras (3) Identificador Descrição Classificação ESTORNO_LIQUIDACAO_RESTO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação ESTORNO_LIQUIDACAO_RESTO_LIQUIDACAO_CADASTRADA A liquidação de resto referenciada deve existir. Validação ESTORNO_LIQUIDACAO_RESTO_VALOR_EXCEDE_SALDO O valor estornado não pode superar o saldo da liquidação de resto. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-019 Estorno Pagamento Registrar estornos de pagamentos vinculados a empenho e liquidação. Desenvolvedor Versão2025 ~ EnvioDiário Atributos8 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Estorno financeiro Chave de unicidade Exercício + Código Unidade Gestora + Número Empenho + Número Pagamento + Número Estorno Liquidação + Número Estorno Pagamento Objeto raiz timestamp + elementos Dependências Pagamento; Liquidação; Empenho Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-pagamento-2025 2. Objetivo e finalidade Registrar estornos de pagamentos vinculados a empenho e liquidação. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Pagamento. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Número do empenho. numeroLiquidacao string Sim 7 / 7 ^[0-9]+$   Chave Número da liquidação. numeroPagamento string Sim 7 / 7 ^[0-9]+$   Chave Número do pagamento. numeroEstornoPagamento string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno de pagamento. motivoEstornoPagamento string Sim 500       Motivo do estorno. valorEstornoPagamento number Sim > 0       Valor estornado. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados pela chave. O pagamento referenciado deve estar cadastrado no exercício. A soma dos estornos não pode superar o valor pago. Catálogo completo de regras (3) Identificador Descrição Classificação ESTORNO_PAGAMENTO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave. Validação ESTORNO_PAGAMENTO_PAGAMENTO_CADASTRADO O pagamento referenciado deve estar cadastrado no exercício. Validação ESTORNO_PAGAMENTO_VALOR_ESTORNADO_EXCEDE_VALOR_PAGO A soma dos estornos não pode superar o valor pago. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial A chave textual menciona Número Estorno Liquidação, mas o item/schema não possui esse campo. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação oficial O payload usa a coleção estornosPagamento, enquanto o schema define elementos. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-020 Estorno Pagamento Resto Registrar estornos de pagamentos de restos a pagar. Desenvolvedor Versão2025 ~ EnvioDiário Atributos12 Regras4 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Restos a pagar Chave de unicidade Exercício + UG + Ano Empenho + UO + Empenho + Liquidação + Pagamento + Número Estorno Pagamento Resto Objeto raiz timestamp + elementos Dependências Pagamento Resto; Liquidação Resto; Resto Inscrito Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-pagamento-resto-2025 2. Objetivo e finalidade Registrar estornos de pagamentos de restos a pagar. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Pagamento Resto. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição anoEmissaoEmpenho string Sim 4 / 4 ^[0-9]+$   Chave Ano do empenho. codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Número do empenho. numeroLiquidacao string Condicional/Chave 7 / 7 ^[0-9]+$   Chave Número da liquidação. numeroPagamento string Sim 7 / 7 ^[0-9]+$   Chave Número do pagamento. numeroEstornoPagamentoResto string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno. dataEstornoPagamentoResto date Sim   format: date     Data do estorno. codigoUnidadeGestoraOrigem string Sim 6 / 6 ^[0-9]+$     UG de origem. motivo string Sim 1 / 120       Motivo. despesaLiquidada string Sim     SIM; NAO   Indica se a despesa está liquidada. valorEstornoPagamentoResto number Sim > 0       Valor estornado. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. O pagamento de resto deve estar cadastrado. A soma estornada não pode exceder o valor pago. Somente UGs do mesmo município; consórcio apenas a si próprio. Catálogo completo de regras (4) Identificador Descrição Classificação ESTORNO_PAGAMENTO_RESTO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação ESTORNO_PAGAMENTO_RESTO_PAGAMENTO_CADASTRADO O pagamento de resto deve estar cadastrado. Validação ESTORNO_PAGAMENTO_RESTO_VALOR_ESTORNADO_EXCEDE_LIQUIDADO A soma estornada não pode exceder o valor pago. Validação ESTORNO_PAGAMENTO_RESTO_ESCOPO_CADASTRO Somente UGs do mesmo município; consórcio apenas a si próprio. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial A chave e a tabela do item incluem numeroLiquidacao, mas o required do schema não exige esse campo. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação oficial O schema exige dataEstornoPagamentoResto, embora a tabela resumida do item não o liste. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-021 Estorno Receita Extra Registrar estornos de receitas extraorçamentárias. Desenvolvedor Versão2025 ~ EnvioDiário Atributos6 Regras3 ComplexidadeMédia CriticidadeAlta 1. Identificação funcional Categoria Estorno extraorçamentário Chave de unicidade Exercício + Código Unidade Gestora + Número Estorno + Número Receita Extra Objeto raiz timestamp + elementos Dependências Receita Extra Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-receita-extra-2025 2. Objetivo e finalidade Registrar estornos de receitas extraorçamentárias. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Receita Extra. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição numeroReceitaExtra string Sim 7 / 7 ^[0-9]+$   Chave Número da receita extra. numeroEstornoReceitaExtra string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno. dataEstornoReceitaExtra date Schema apenas   format: date     Data do estorno. valorEstornoReceitaExtra number Sim > 0       Valor estornado. motivo string Sim 10 / 255       Motivo. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. A receita extra deve estar cadastrada no exercício. A soma estornada não pode superar o valor da receita extra. Catálogo completo de regras (3) Identificador Descrição Classificação ESTORNO_RECEITA_EXTRA_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação ESTORNO_RECEITA_EXTRA_RECEITA_EXTRA_CADASTRADA A receita extra deve estar cadastrada no exercício. Validação ESTORNO_RECEITA_EXTRA_VALOR_ESTORNADO_EXCEDE_VALOR A soma estornada não pode superar o valor da receita extra. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial O required do schema inclui dataEstornoReceitaExtra, mas a propriedade não está declarada e o payload não a informa. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-022 Estorno Resto Registrar estornos de valores inscritos em restos a pagar. Desenvolvedor Versão2025 ~ EnvioDiário Atributos10 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Restos a pagar Chave de unicidade Exercício + UG + Ano Empenho + UO + Empenho + Número Estorno Resto Objeto raiz timestamp + elementos Dependências Resto Inscrito; Empenho Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-resto-2025 2. Objetivo e finalidade Registrar estornos de valores inscritos em restos a pagar. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Resto. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição anoEmissaoEmpenho string Sim 4 / 4 ^[0-9]+$   Chave Ano do empenho. codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Número do empenho. numeroEstornoResto string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno. dataEstornoResto date Schema apenas   format: date     Data do estorno. valorEstornoResto number Sim > 0       Valor estornado. motivo string Sim 1 / 120       Motivo. despesaLiquidada string Sim     SIM; NAO   Indica se a despesa está liquidada. codigoUnidadeGestoraOrigem string Sim 6 / 6 ^[0-9]+$     UG de origem. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. O resto inscrito deve estar cadastrado. A soma estornada não pode superar o valor inscrito. Catálogo completo de regras (3) Identificador Descrição Classificação ESTORNO_RESTO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação ESTORNO_RESTO_RESTO_CADASTRADO O resto inscrito deve estar cadastrado. Validação ESTORNO_RESTO_VALOR_ESTORNADO_EXCEDE_INSCRITO A soma estornada não pode superar o valor inscrito. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial O schema exige dataEstornoResto, mas essa propriedade não aparece no bloco properties. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-023 Estorno Retenção Registrar estornos de retenções incidentes sobre pagamentos do exercício. Desenvolvedor Versão2025 ~ EnvioDiário Atributos9 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Estorno financeiro Chave de unicidade Exercício + UG + UO + Empenho + Liquidação + Pagamento + Tipo Retenção + Número Retenção + Número Estorno Retenção Objeto raiz timestamp + elementos Dependências Retenção; Pagamento; Liquidação; Empenho Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-retencao-2025 2. Objetivo e finalidade Registrar estornos de retenções incidentes sobre pagamentos do exercício. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Retenção. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Empenho. numeroLiquidacao string Sim 7 / 7 ^[0-9]+$   Chave Liquidação. numeroPagamento string Sim 7 / 7 ^[0-9]+$   Chave Pagamento. tipoRetencao string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Retenção Chave Tipo da retenção. numeroRetencao string Item/Payload 7 / 7 ^[0-9]+$   Chave Número da retenção. numeroEstornoRetencao string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno. valorEstornoRetencao number Sim > 0       Valor estornado. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. A retenção deve estar cadastrada no exercício. A soma estornada não pode superar o valor retido. Catálogo completo de regras (3) Identificador Descrição Classificação ESTORNO_RETENCAO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação ESTORNO_RETENCAO_RETENCAO_CADASTRADA A retenção deve estar cadastrada no exercício. Validação ESTORNO_RETENCAO_VALOR_ESTORNADO_EXCEDE_VALOR_RETIDO A soma estornada não pode superar o valor retido. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial A chave, a tabela do item e o payload usam numeroRetencao, mas o schema não declara nem exige essa propriedade. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-024 Estorno Retenção Resto Registrar estornos de retenções vinculadas a pagamentos de restos a pagar. Desenvolvedor Versão2025 ~ EnvioDiário Atributos12 Regras4 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Restos a pagar Chave de unicidade Exercício + UG + Ano Empenho + UO + Empenho + Liquidação + Pagamento + Tipo Retenção + Número Estorno Retenção Resto Objeto raiz timestamp + elementos Dependências Retenção Resto; Pagamento Resto; Liquidação Resto Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/estorno-retencao-resto-2025 2. Objetivo e finalidade Registrar estornos de retenções vinculadas a pagamentos de restos a pagar. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Estorno Retenção Resto. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição anoEmissaoEmpenho string Sim 4 / 4 ^[0-9]+$   Chave Ano do empenho. codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Empenho. numeroLiquidacao string Chave/Item 7 / 7 ^[0-9]+$   Chave Liquidação. numeroPagamento string Sim 7 / 7 ^[0-9]+$   Chave Pagamento. tipoRetencao string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Retenção Chave Tipo da retenção. numeroEstornoRetencaoResto string Sim 7 / 7 ^[0-9]+$   Chave Número do estorno. dataEstornoRetencaoResto date Sim   format: date     Data do estorno. codigoUnidadeGestoraOrigem string Sim 6 / 6 ^[0-9]+$     UG de origem. motivo string Sim 1 / 120       Motivo. valorEstornoRetencaoResto number Sim > 0       Valor estornado. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. A liquidação de resto deve estar cadastrada. A soma estornada não pode superar o valor retido. Somente UGs do mesmo município; consórcio apenas a si próprio. Catálogo completo de regras (4) Identificador Descrição Classificação ESTORNO_RETENCAO_RESTO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação ESTORNO_RETENCAO_RESTO_LIQUIDACAO_CADASTRADA A liquidação de resto deve estar cadastrada. Validação ESTORNO_RETENCAO_RESTO_VALOR_ESTORNADO_EXCEDE_RETIDO A soma estornada não pode superar o valor retido. Validação ESTORNO_RETENCAO_RESTO_ESCOPO_CADASTRO Somente UGs do mesmo município; consórcio apenas a si próprio. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial A chave e a tabela do item incluem numeroLiquidacao, mas o required do schema não exige esse campo. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-025 Liquidação Registrar liquidações de empenhos, com dados opcionais ou obrigatórios de nota fiscal conforme o elemento e subelemento. Desenvolvedor Versão2025 ~ EnvioDiário Atributos11 Regras8 ComplexidadeMuito Alta CriticidadeCrítica 1. Identificação funcional Categoria Execução orçamentária Chave de unicidade Exercício + Código Unidade Gestora + Código Unidade Orçamentária + Número Empenho + Número Liquidação Objeto raiz timestamp + elementos Dependências Empenho; Credor; Tabela Tipo Nota Fiscal; regras de elemento/subelemento Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/liquidacao-2025 2. Objetivo e finalidade Registrar liquidações de empenhos, com dados opcionais ou obrigatórios de nota fiscal conforme o elemento e subelemento. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Liquidação. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Empenho. numeroLiquidacao string Sim 7 / 7 ^[0-9]+$   Chave Liquidação. tipoNotaFiscal string Condicional 2 / 2 ^[0-9]+$ Tabela Tipo Nota Fiscal   Tipo da nota fiscal. numeroChaveNotaFiscal string Condicional 44 / 44 ^[0-9]+$     Chave da nota fiscal. numeroNotaFiscal string Condicional 15       Número da nota fiscal. serieNotaFiscal string Condicional 12       Série da nota fiscal. dataNotaFiscal date Condicional   format: date     Data da nota fiscal. valorNotaFiscal number Condicional > 0       Valor da nota fiscal. valorLiquidacao number Sim > 0       Valor liquidado. action string Payload/Propriedade     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. O empenho deve estar cadastrado no exercício. O CPF/CNPJ da NFE deve coincidir com o credor do empenho. Elementos 30 e 52 usam tipos 01 ou 02, com exceções para subelementos específicos. Para tipo de nota 01, o fornecedor deve ser pessoa física. Catálogo completo de regras (8) Identificador Descrição Classificação LIQUIDACAO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação LIQUIDACAO_EMPENHO_CADASTRADO O empenho deve estar cadastrado no exercício. Validação LIQUIDACAO_NOTA_FISCAL_EMPENHO_CREDOR O CPF/CNPJ da NFE deve coincidir com o credor do empenho. Validação LIQUIDACAO_TIPO_NOTA_ELEMENTO_SUBELEMENTO_INVALIDO Elementos 30 e 52 usam tipos 01 ou 02, com exceções para subelementos específicos. Validação LIQUIDACAO_TIPO_NOTA_01_PESSOA_FISICA Para tipo de nota 01, o fornecedor deve ser pessoa física. Validação LIQUIDACAO_NOTA_FISCAL_OBRIGATORIA Nota fiscal é obrigatória para combinações específicas de elemento e subelemento. Validação LIQUIDACAO_TIPO_NOTA_FISCAL_VALIDO O tipo da nota deve constar na tabela oficial. Validação LIQUIDACAO_VALOR_LIQUIDADO_EXCEDE_VALOR_EMPENHADO A soma das liquidações não pode superar o valor empenhado. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial O schema declara action como propriedade, mas não o inclui na lista required. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação oficial A página mantém uma versão tachada da regra LIQUIDACAO_NOTA_FISCAL_OBRIGATORIA e também uma regra ativa com o mesmo ID. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-026 Liquidação Resto Registrar liquidações de restos a pagar não processados. Desenvolvedor Versão2025 ~ EnvioDiário Atributos14 Regras4 ComplexidadeMuito Alta CriticidadeCrítica 1. Identificação funcional Categoria Restos a pagar Chave de unicidade Exercício + UG + Ano Empenho + UO + Empenho + Número Liquidação Resto Objeto raiz timestamp + elementos Dependências Resto Inscrito; Empenho; Tabela Tipo Nota Fiscal Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/liquidacao-resto-2025 2. Objetivo e finalidade Registrar liquidações de restos a pagar não processados. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Liquidação Resto. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição anoEmissaoEmpenho string Sim 4 / 4 ^[0-9]+$   Chave Ano do empenho. codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave Unidade orçamentária. numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave Empenho. numeroLiquidacaoResto string Sim 7 / 7 ^[0-9]+$   Chave Liquidação de resto. dataLiquidacaoResto date Sim   format: date     Data da liquidação. tipoNotaFiscal string Sim 2 / 2 ^[0-9]+$ Tabela Tipo Nota Fiscal   Tipo da nota. numeroChaveNotaFiscal string Sim 44 / 44 ^[0-9]+$     Chave da nota fiscal. numeroNotaFiscal string Sim 1 / 15       Número da nota fiscal. serieNotaFiscal string Sim 1 / 12       Série. dataNotaFiscal date Sim   format: date     Data da nota. valorNotaFiscal number Sim > 0       Valor da nota. valorLiquidacaoResto number Sim > 0       Valor liquidado. codigoUnidadeGestoraOrigem string Sim 6 / 6 ^[0-9]+$     UG de origem. action string Sim     CREATE; UPDATE; DELETE   Operação solicitada. 5. Principais regras de negócio Não permitir registros duplicados. A liquidação referenciada deve estar cadastrada. A soma liquidada não pode exceder o valor inscrito não processado. Somente UGs do mesmo município; consórcio apenas a si próprio. Catálogo completo de regras (4) Identificador Descrição Classificação LIQUIDACAO_RESTO_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação LIQUIDACAO_RESTO_LIQUIDACAO_CADASTRADA A liquidação referenciada deve estar cadastrada. Validação LIQUIDACAO_RESTO_VALOR_LIQUIDADO_EXCEDE_INSCRITO A soma liquidada não pode exceder o valor inscrito não processado. Validação LIQUIDACAO_RESTO_ESCOPO_CADASTRO Somente UGs do mesmo município; consórcio apenas a si próprio. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação oficial A regra LIQUIDACAO_RESTO_LIQUIDACAO_CADASTRADA parece referir-se à própria liquidação de resto; exige revisão semântica antes da implementação. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-027 Movimentação entre Contas Bancárias Registrar transferências entre contas bancárias da unidade gestora. Desenvolvedor Versão2025 ~ EnvioDiário Atributos12 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Movimentação financeira Chave de unicidade Exercício + UG + conta origem + conta destino + código movimentação Objeto raiz timestamp + elementos Dependências Conta Bancária origem; Conta Bancária destino Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/movimentacao-entre-contas-bancarias-2025 2. Objetivo e finalidade Registrar transferências entre contas bancárias da unidade gestora. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Movimentação entre Contas Bancárias. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoBancoContaBancariaOrigem string Sim 3 / 3 ^[0-9]+$ FEBRABAN Chave   numeroAgenciaContaBancariaOrigem string Sim 6 / 6 ^[0-9]+$   Chave   numeroContaBancariaOrigem string Sim 13 / 13 ^[0-9]+$   Chave   tipoContaBancariaOrigem string Sim 1 / 1 ^[0-9]+$ Tipo Conta Chave   codigoBancoContaBancariaDestino string Sim 3 / 3 ^[0-9]+$ FEBRABAN Chave   numeroAgenciaContaBancariaDestino string Sim 6 / 6 ^[0-9]+$   Chave   numeroContaBancariaDestino string Sim 13 / 13 ^[0-9]+$   Chave   tipoContaBancariaDestino string Sim 1 / 1 ^[0-9]+$ Tipo Conta Chave   valorTransferencia number Sim > 0         dataMovimentacao date Sim   format: date       codigoMovimentacao string Sim 7 / 7 ^[0-9]+$   Chave   action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Conta de origem deve estar cadastrada. Conta de destino deve estar cadastrada. Catálogo completo de regras (3) Identificador Descrição Classificação MOV_ENTRE_CONTAS_BANCARIAS_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação MOV_ENTRE_CONTAS_BANCARIAS_CONTA_BANCARIA_CADASTRADA Conta de origem deve estar cadastrada. Validação MOV_ENTRE_CONTAS_BANCARIAS_CONTA_BANCARIA_DESTINO_CADASTRADA Conta de destino deve estar cadastrada. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação dataMovimentacao consta em required e no payload, mas não aparece em properties. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-028 Norma Orçamentária Registrar leis e normas que autorizam o orçamento e alterações orçamentárias. Desenvolvedor Versão2025 ~ EnvioDiário Atributos8 Regras3 ComplexidadeAlta CriticidadeAlta 1. Identificação funcional Categoria Cadastro orçamentário Chave de unicidade Exercício + UG + número lei + data publicação Objeto raiz timestamp + elementos Dependências Banco de legislação TCE; Tipo Lei Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/norma-orcamentaria-2025 2. Objetivo e finalidade Registrar leis e normas que autorizam o orçamento e alterações orçamentárias. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Norma Orçamentária. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição exercicioLei string Sim 4 / 4 ^[0-9]+$   Chave   numeroLei string Sim 9 / 9 ^[0-9]+$   Chave   dataPublicacao date Sim   format: date   Chave   tipoLei string Sim 1 / 1 ^[0-9]+$ Tipo Lei     protocoloTCE string Sim 9 / 9 ^[0-9]{6}/[0-9]{2}$       tipoAutorizacao string Sim     SIM; NAO     valor number Sim > 0         action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Tipo de lei deve ser válido. Protocolo deve existir no banco do TCE. Catálogo completo de regras (3) Identificador Descrição Classificação NORMA_ORCAMENTARIA_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação NORMA_ORCAMENTARIA_TIPO_LEI_VALIDO Tipo de lei deve ser válido. Validação NORMA_ORCAMENTARIA_PROTOCOLO_VALIDO Protocolo deve existir no banco do TCE. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação A tabela do item usa autorizacaoPercentual, mas schema/payload usam tipoAutorizacao. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação A chave publicada repete a expressão Código Unidade Gestora. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-029 Ordenador Cadastrar ordenadores de despesa da unidade gestora. Desenvolvedor Versão2025 ~ EnvioDiário Atributos3 Regras2 ComplexidadeAlta CriticidadeAlta 1. Identificação funcional Categoria Cadastro de pessoa Chave de unicidade Exercício + UG + CPF + Nome Objeto raiz timestamp + elementos Dependências Receita Federal; Unidade Gestora Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/ordenador-2025 2. Objetivo e finalidade Cadastrar ordenadores de despesa da unidade gestora. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Ordenador. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição cpfOrdenador string Sim 11 / 11 ^[0-9]+$   Chave   nomeOrdenador string Sim 1 / 150     Chave   action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Nome deve corresponder à Receita Federal. Catálogo completo de regras (2) Identificador Descrição Classificação ORDENADOR_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação ORDENADOR_NOME_INVALIDO Nome deve corresponder à Receita Federal. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-030 Pagamento Registrar pagamentos de liquidações do exercício. Desenvolvedor Versão2025 ~ EnvioDiário Atributos15 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Execução financeira Chave de unicidade Exercício + UG + UO + Empenho + Liquidação + Pagamento Objeto raiz timestamp + elementos Dependências Liquidação; Empenho; Conta Bancária; Conta Bancária Credor Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/pagamento-2025 2. Objetivo e finalidade Registrar pagamentos de liquidações do exercício. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Pagamento. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave   numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave   numeroLiquidacao string Sim 7 / 7 ^[0-9]+$   Chave   numeroPagamento string Sim 7 / 7 ^[0-9]+$   Chave   valorPagamento number Sim > 0         codigoBancoContaBancaria string Sim 3         numeroContaBancaria string Sim 13         tipoContaBancaria string Sim 1 / 1 ^[0-9]+$       numeroAgenciaContaBancaria string Sim 6         cnpjGerenciaContaBancaria string Sim 14 / 14         numeroDocumentoDebito string Sim 11         codigoBancoContaBancariaCredor string Sim 3         numeroAgenciaContaBancariaCredor string Sim 6         numeroContaBancariaCredor string Sim 13         action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Liquidação deve existir. Soma dos pagamentos não pode exceder o valor liquidado. Catálogo completo de regras (3) Identificador Descrição Classificação PAGAMENTO_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação PAGAMENTO_LIQUIDACAO_CADASTRADA Liquidação deve existir. Validação PAGAMENTO_VALOR_PAGO_EXCEDE_LIQUIDADO Soma dos pagamentos não pode exceder o valor liquidado. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-031 Pagamento Resto Registrar pagamentos de restos a pagar. Desenvolvedor Versão2025 ~ EnvioDiário Atributos22 Regras4 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Restos a pagar Chave de unicidade Exercício + UG + ano empenho + UO + empenho + liquidação + pagamento resto Objeto raiz timestamp + elementos Dependências Liquidação Resto; Resto Inscrito; Contas Bancárias Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/pagamento-resto-2025 2. Objetivo e finalidade Registrar pagamentos de restos a pagar. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Pagamento Resto. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição anoEmissaoEmpenho string Sim 4 / 4 ^[0-9]+$   Chave   codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave   numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave   numeroLiquidacao string Sim 7 / 7 ^[0-9]+$   Chave   numeroPagamentoResto string Sim 7 / 7 ^[0-9]+$   Chave   dataPagamentoResto date Sim   format: date       valorPagamentoResto number Sim > 0         codigoBancoContaBancariaDebito string Sim 3 / 3 ^[0-9]+$       numeroContaBancariaDebito string Sim 13 / 13         numeroAgenciaContaBancariaDebito string Sim 6 / 6         tipoContaBancariaDebito string Sim 1 / 1         cnpjGerenciaContaBancariaDebito string Sim 14 / 14         numeroCheque string Sim 6 / 6         numeroDocDebito string Sim 11 / 11         codigoBancoContaBancariaCredito string Sim 3 / 3         numeroAgenciaContaBancariaCredito string Sim 6 / 6         numeroContaBancariaCredito string Sim 13 / 13         exercicioFonteRecurso string Sim     ATUAL; ANTERIOR     codigoFonteRecurso string Sim 3 / 3         codigoCO string Sim 4 / 4         codigoUnidadeGestoraOrigem string Sim 6 / 6         action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Liquidação de resto deve existir. Valor pago não pode exceder o liquidado. Somente UGs do mesmo município. Catálogo completo de regras (4) Identificador Descrição Classificação PAGAMENTO_RESTO_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação PAGAMENTO_RESTO_LIQUIDACAO_CADASTRADA Liquidação de resto deve existir. Validação PAGAMENTO_RESTO_VALOR_PAGO_EXCEDE_LIQUIDADO Valor pago não pode exceder o liquidado. Validação PAGAMENTO_RESTO_ESCOPO_CADASTRO Somente UGs do mesmo município. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação numeroLiquidacao aparece na chave e properties, mas não no required nem no payload. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-032 Programa (referência duplicada) Revalidar a entidade Programa já documentada no Lote 1. Desenvolvedor Versão2025 ~ EnvioOrçamento/Diário Atributos6 Regras3 ComplexidadeBaixa CriticidadeMédia 1. Identificação funcional Categoria Cadastro orçamentário Chave de unicidade Exercício + UG + Código Programa Objeto raiz timestamp + elementos Dependências Unidade Gestora; Tipo Objetivo Milênio Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/programa-2025 2. Objetivo e finalidade Revalidar a entidade Programa já documentada no Lote 1. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Programa (referência duplicada). 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6 ^[0-9]+$   Chave   codigoPrograma string Sim 4 / 4 ^[0-9]+$   Chave   descricaoPrograma string Sim 10 / 70         descricaoObjetivoMilenio string Sim 10 / 150         tipoObjetivoMilenio string Sim 2 / 2   Tipo Objetivo Milênio     action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. UG deve estar homologada. Tipo deve ser válido. Catálogo completo de regras (3) Identificador Descrição Classificação PROGRAMA_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação UNIDADE_GESTORA_HOMOLOGADA UG deve estar homologada. Validação PROGRAMA_TIPO_OBJETIVO_MILENIO_VALIDO Tipo deve ser válido. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação Esta página já corresponde à CTB-002; foi mantida no Lote 4 por constar na lista fornecida, sem duplicar o catálogo mestre. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-033 Receita Extra Registrar receitas extraorçamentárias e seus vínculos com retenções. Desenvolvedor Versão2025 ~ EnvioDiário Atributos20 Regras4 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Receita extraorçamentária Chave de unicidade Exercício + UG + Número Receita Extra Objeto raiz timestamp + elementos Dependências Credor; Conta Bancária; Retenção; MSC/STN Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/receita-extra-2025 2. Objetivo e finalidade Registrar receitas extraorçamentárias e seus vínculos com retenções. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Receita Extra. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição numeroReceitaExtra string Sim 7 / 7 ^[0-9]+$   Chave   codigoContaContabil string Sim 9 / 9 ^[0-9]+$ IPC/STN     cpfCnpjCredor string Sim 14 / 14         exercicioFonteRecurso string Sim     ATUAL; ANTERIOR     codigoFonteRecurso string Sim 3 / 3         codigoBancoContaBancaria string Sim 3 / 3         numeroContaBancaria string Sim 1 / 13         numeroAgenciaContaBancaria string Sim 1 / 6         tipoContaBancaria string Sim 1 / 1         cnpjGerenciaContaBancaria string Sim 14 / 14         valorReceitaExtra number Sim > 0         historico string Sim 10 / 500         codigoReceitaExtra string Sim 8 / 8   Código Receita Extra     codigoUnidadeGestoraRetencao string Condicional 6 / 6         codigoUnidadeOrcamentariaRetencao string Condicional 5 / 5         numeroEmpenho string Condicional 7 / 7         numeroPagamento string Condicional 7 / 7         numeroRetencao string Condicional 7 / 7         tipoRetencao string Condicional     Tipo Retenção     action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Conta contábil deve seguir STN. Credor deve estar cadastrado. Vínculo de retenção deve existir quando informado. Catálogo completo de regras (4) Identificador Descrição Classificação RECEITA_EXTRA_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação RECEITA_EXTRA_CONTA_CONTABIL Conta contábil deve seguir STN. Validação RECEITA_EXTRA_CREDOR_CADASTRADO Credor deve estar cadastrado. Validação RECEITA_EXTRA_RETENCAO_EXISTENTE Vínculo de retenção deve existir quando informado. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-034 Receita Orçamentária Registrar arrecadações de receitas orçamentárias. Desenvolvedor Versão2025 ~ EnvioDiário Atributos14 Regras4 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Receita orçamentária Chave de unicidade Exercício + UG + data + número + código receita + tipos + fonte + CO + conta bancária Objeto raiz timestamp + elementos Dependências Receita Prevista; Conta Bancária; MSC/STN Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/receita-orcamentaria-2025 2. Objetivo e finalidade Registrar arrecadações de receitas orçamentárias. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Receita Orçamentária. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição numeroReceita string Sim 7 / 7 ^[A-Z0-9]+$   Chave   codigoReceitaOrcamentaria string Sim 8 / 8 ^[0-9]+$ MSC/STN Chave   tipoLancamentoReceita string Sim 1 / 1   Tipo Lançamento Chave   tipoReceitaLancada string Sim 1 / 1   Tipo Receita Chave   exercicioFonteRecurso string Sim     ATUAL     codigoFonteRecurso string Sim 3 / 3   MSC/STN Chave   valorReceitaOrcamentaria number Sim > 0         codigoCO string Sim 4 / 4   MSC/STN Chave   numeroContaBancaria string Sim 1 / 13     Chave   codigoBancoContaBancaria string Sim 3 / 3     Chave   numeroAgenciaContaBancaria string Sim 1 / 6     Chave   tipoContaBancaria string Sim 1 / 1     Chave   cnpjGerenciaContaBancaria string Sim 14 / 14     Chave   action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Código deve existir na receita prevista. Valor deve ser positivo. Conta bancária deve estar cadastrada. Quando o CO for 0000 a propriedade codigoCO não será enviado na estrutura do json Catálogo completo de regras (4) Identificador Descrição Classificação RECEITA_ORCAMENTARIA_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação RECEITA_ORCAMENTARIA_RECEITA_PREVISTA Código deve existir na receita prevista. Validação RECEITA_ORCAMENTARIA_VALOR_VALIDO Valor deve ser positivo. Validação RECEITA_ORCAMENTARIA_CONTA_BANCARIA_CADASTRADA Conta bancária deve estar cadastrada. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-035 Receita Prevista Registrar previsão de receitas no orçamento. Desenvolvedor Versão2025 ~ EnvioOrçamento Atributos7 Regras8 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Planejamento da receita Chave de unicidade Exercício + UG + Código Receita + Fonte + Tipo Receita Objeto raiz timestamp + elementos Dependências Unidade Gestora; MSC/STN Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/receita-prevista-2025 2. Objetivo e finalidade Registrar previsão de receitas no orçamento. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Receita Prevista. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6     Chave   codigoReceitaOrcamentaria string Sim 8 / 8   MSC/STN Chave   exercicioFonteRecurso string Sim     ATUAL; ANTERIOR     codigoFonteRecurso string Sim 3 / 3   MSC/STN Chave   tipoReceitaLancada string Sim 1 / 1   Tipo Receita Lançada Chave   valorReceita number Sim > 0         action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. UG deve estar homologada. Tipo deve ser válido. Fonte deve seguir MSC. Receita deve seguir MSC. Catálogo completo de regras (8) Identificador Descrição Classificação RECEITA_PREVISTA_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação UNIDADE_GESTORA_HOMOLOGADA UG deve estar homologada. Validação RECEITA_PREVISTA_TIPO_VALIDO Tipo deve ser válido. Validação RECEITA_PREVISTA_CODIGO_FONTE_RECURSO_VALIDO Fonte deve seguir MSC. Validação RECEITA_PREVISTA_CODIGO_RECEITA_ORCAMENTARIA_VALIDO Receita deve seguir MSC. Validação RECEITA_PREVISTA_EXERCICIO_FONTE_RECURSO_VALIDO Fonte anterior apenas para RPPS. Validação RESPONSABILIDADE_PROTOCOLO Prefeituras e consórcios enviam. Validação RECEITA_PREVISTA_ESCOPO_CADASTRO Respeitar escopo da UG. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-036 Relacionamento Empenho Licitação Relacionar empenhos a processos licitatórios. Desenvolvedor Versão2025 ~ EnvioDiário Atributos6 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Integração Licitações Chave de unicidade Exercício + UG + UO + Empenho + UG Licitação + Licitação + Modalidade Objeto raiz timestamp + elementos Dependências Empenho; Módulo Licitação Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/relacionamento-empenho-licitacao-2025 2. Objetivo e finalidade Relacionar empenhos a processos licitatórios. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Relacionamento Empenho Licitação. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5     Chave   numeroEmpenho string Sim 7 / 7     Chave   codigoUnidadeGestoraLicitacao string Sim 6 / 6     Chave   numeroLicitacao string Sim       Chave   codigoModalidadeLicitacao string Sim       Chave   action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Empenho deve existir. Licitação deve existir. Catálogo completo de regras (3) Identificador Descrição Classificação RELACIONAMENTO_EMPENHO_LICITACAO_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação RELACIONAMENTO_EMPENHO_LICITACAO_EMPENHO_CADASTRADO Empenho deve existir. Validação RELACIONAMENTO_EMPENHO_LICITACAO_LICITACAO_CADASTRADA Licitação deve existir. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-037 Relacionamento Empenho Natureza Contratação Relacionar empenho à natureza de contratação. Desenvolvedor Versão2025 ~ EnvioDiário Atributos4 Regras3 ComplexidadeAlta CriticidadeAlta 1. Identificação funcional Categoria Integração contratual Chave de unicidade Exercício + UG + UO + Empenho + Natureza Contratação Objeto raiz timestamp + elementos Dependências Empenho; Tabela Natureza Contratação Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/relacionamento-empenho-natureza-contratacao-2025 2. Objetivo e finalidade Relacionar empenho à natureza de contratação. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Relacionamento Empenho Natureza Contratação. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5     Chave   numeroEmpenho string Sim 7 / 7     Chave   codigoNaturezaContratacao string Sim     Natureza Contratação Chave   action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Empenho deve existir. Natureza deve ser válida. Catálogo completo de regras (3) Identificador Descrição Classificação RELACIONAMENTO_EMPENHO_NATUREZA_CONTRATACAO_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação RELACIONAMENTO_EMPENHO_NATUREZA_CONTRATACAO_EMPENHO_CADASTRADO Empenho deve existir. Validação RELACIONAMENTO_EMPENHO_NATUREZA_CONTRATACAO_VALIDA Natureza deve ser válida. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-038 Relacionamento Empenho Obra Relacionar empenhos a obras cadastradas. Desenvolvedor Versão2025 ~ EnvioDiário Atributos4 Regras3 ComplexidadeAlta CriticidadeAlta 1. Identificação funcional Categoria Integração Obras Chave de unicidade Exercício + UG + UO + Empenho + Número Obra Objeto raiz timestamp + elementos Dependências Empenho; Módulo Obras Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/relacionamento-empenho-obra-2025 2. Objetivo e finalidade Relacionar empenhos a obras cadastradas. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Relacionamento Empenho Obra. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5     Chave   numeroEmpenho string Sim 7 / 7     Chave   numeroObra string Sim       Chave   action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Empenho deve existir. Obra deve existir. Catálogo completo de regras (3) Identificador Descrição Classificação RELACIONAMENTO_EMPENHO_OBRA_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação RELACIONAMENTO_EMPENHO_OBRA_EMPENHO_CADASTRADO Empenho deve existir. Validação RELACIONAMENTO_EMPENHO_OBRA_OBRA_CADASTRADA Obra deve existir. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-039 Relacionamento Liquidação Agrupamento Folha Relacionar liquidações aos agrupamentos da folha de pagamento. Desenvolvedor Versão2025 ~ EnvioBalancete - Contabilidade Atributos5 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Integração Folha Chave de unicidade Exercício + mês + UG + UO + Empenho + Liquidação + Código Agrupamento Objeto raiz timestamp + elementos Dependências Liquidação; Folha de Pagamento Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/relacionamento-liquidacao-codigo-agrupamento-folha-pagamento-2025 2. Objetivo e finalidade Relacionar liquidações aos agrupamentos da folha de pagamento. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Relacionamento Liquidação Agrupamento Folha. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5     Chave   numeroEmpenho string Sim 7 / 7     Chave   numeroLiquidacao string Sim 7 / 7     Chave   codigoAgrupamentoFolha string Sim 10 / 10     Chave   action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. Somente uma liquidação por agrupamento. Todos os empenhos de folha devem ser informados. Catálogo completo de regras (3) Identificador Descrição Classificação RELACIONAMENTO_LIQUIDACAO_CODIGO_AGRUPAMENTO_FOLHA_PAGAMENTO_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação RELACIONAMENTO_LIQUIDACAO_CODIGO_AGRUPAMENTO_FOLHA_PAGAMENTO_UMA_LIQUIDACAO Somente uma liquidação por agrupamento. Validação RELACIONAMENTO_LIQUIDACAO_CODIGO_AGRUPAMENTO_FOLHA_PAGAMENTO_EXISTE_EMPENHOS_FOLHA_NAO_INFORMADO Todos os empenhos de folha devem ser informados. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-040 Responsável SIAFIC Registrar empresa fornecedora do SIAFIC e responsável técnico. Desenvolvedor Versão2025 ~ EnvioBalancete - Contabilidade Atributos14 Regras2 ComplexidadeAlta CriticidadeAlta 1. Identificação funcional Categoria Governança SIAFIC Chave de unicidade Exercício + UG + dados da empresa e responsável técnico Objeto raiz timestamp + elementos Dependências Cadastro SIAFIC; Receita Federal Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/responsavel-siafic-2025 2. Objetivo e finalidade Registrar empresa fornecedora do SIAFIC e responsável técnico. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Responsável SIAFIC. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição cnpjEmpresa string Sim 14 / 14     Chave   nomeEmpresa string Sim 1 / 150         tipoLogradouro string Sim           numeroLogradouro string Sim           complementoLogradouro string Sim           cepLogradouro string Sim 8 / 8         telefoneEmpresa string Sim           emailEmpresa string Sim           denominacaoSiafic string Sim           cpfResponsavelTecnico string Sim 11 / 11         nomeResponsavelTecnico string Sim 1 / 150         emailResponsavelTecnico string Sim           telefoneResponsavelTecnico string Sim           action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. CNPJ deve ser válido. Catálogo completo de regras (2) Identificador Descrição Classificação RESPONSAVEL_SIAFIC_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação RESPONSAVEL_SIAFIC_CNPJ_VALIDO CNPJ deve ser válido. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-041 Resto Inscrito Registrar saldos de empenhos inscritos em restos a pagar. Desenvolvedor Versão2025 ~ EnvioBalancete - Contabilidade Atributos7 Regras0 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Restos a pagar Chave de unicidade Exercício + UG + ano empenho + UO + empenho + condição do resto Objeto raiz timestamp + elementos Dependências Empenho; Unidade Gestora origem Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/resto-inscrito-2025 2. Objetivo e finalidade Registrar saldos de empenhos inscritos em restos a pagar. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Resto Inscrito. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição anoEmissaoEmpenho string Sim 4 / 4     Chave   codigoUnidadeOrcamentaria string Sim 5 / 5     Chave   numeroEmpenho string Sim 7 / 7     Chave   despesaLiquidada string Sim     SIM; NAO Chave   valorInscrito number Sim > 0         codigoUnidadeGestoraOrigem string Sim 6 / 6         action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Consultar o catálogo completo de regras desta entidade. Catálogo completo de regras (0) Identificador Descrição Classificação Nenhuma regra formal catalogada. 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-042 Retenção Registrar retenções incidentes sobre pagamentos. Desenvolvedor Versão2025 ~ EnvioDiário Atributos8 Regras0 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Retenções Chave de unicidade Exercício + UG + UO + Empenho + Liquidação + Pagamento + Tipo + Número Retenção Objeto raiz timestamp + elementos Dependências Pagamento; Liquidação; Empenho; Tipo Retenção Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/retencao-2025 2. Objetivo e finalidade Registrar retenções incidentes sobre pagamentos. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Retenção. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeOrcamentaria string Sim 5 / 5     Chave   numeroEmpenho string Sim 7 / 7     Chave   numeroLiquidacao string Sim 7 / 7     Chave   numeroPagamento string Sim 7 / 7     Chave   tipoRetencao string Sim 1 / 1   Tipo Retenção Chave   numeroRetencao string Sim 7 / 7     Chave   valorRetencao number Sim > 0         action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Consultar o catálogo completo de regras desta entidade. Catálogo completo de regras (0) Identificador Descrição Classificação Nenhuma regra formal catalogada. 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-043 Retenção Resto Registrar retenções incidentes sobre pagamentos de restos a pagar. Desenvolvedor Versão2025 ~ EnvioDiário Atributos10 Regras3 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Retenções de restos Chave de unicidade Ano Empenho + UO + Empenho + Liquidação + Pagamento + Número Retenção + Tipo Retenção Objeto raiz timestamp + elementos Dependências Pagamento Resto; Liquidação Resto; Resto Inscrito; Tipo Retenção Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/retencao-resto-2025 2. Objetivo e finalidade Registrar retenções incidentes sobre pagamentos de restos a pagar. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Retenção Resto. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição anoEmissaoEmpenho string Sim 4 / 4 ^[0-9]+$   Chave   codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave   numeroEmpenho string Sim 7 / 7 ^[0-9]+$   Chave   numeroLiquidacao string Item/Chave 7 / 7 ^[0-9]+$   Chave   numeroPagamento string Sim 7 / 7 ^[0-9]+$   Chave   numeroRetencao string Item/Chave 7 / 7 ^[0-9]+$   Chave   valorRetencaoResto number Sim > 0         tipoRetencao string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Retenção Chave   codigoUnidadeGestoraOrigem string Sim 6 / 6 ^[0-9]+$       action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio O pagamento de resto deve existir antes da retenção. O valor retido não deve superar o valor pago. O tipo de retenção deve constar na tabela oficial. Catálogo completo de regras (3) Identificador Descrição Classificação RETENCAO_RESTO_PAGAMENTO_CADASTRADO O pagamento de resto deve existir antes da retenção. Validação RETENCAO_RESTO_VALOR_NAO_EXCEDE_PAGAMENTO O valor retido não deve superar o valor pago. Validação RETENCAO_RESTO_TIPO_VALIDO O tipo de retenção deve constar na tabela oficial. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação A página não publica seção formal de regras; as regras acima são consolidações funcionais para rastreabilidade. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação numeroLiquidacao e numeroRetencao aparecem no Item e no schema properties, mas não constam no required nem no payload. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-044 Saldo Inicial Conciliado Registrar o saldo inicial conciliado das contas bancárias, exclusivamente no mês de janeiro. Desenvolvedor Versão2025 - EnvioBalancete - Contabilidade Atributos7 Regras3 ComplexidadeMédia CriticidadeAlta 1. Identificação funcional Categoria Conciliação bancária Chave de unicidade Exercício + UG + Conta + Agência + Banco + Tipo Conta + CNPJ Gerência Objeto raiz timestamp + elementos Dependências Conta Bancária Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/saldo-inicial-conciliado-2025 2. Objetivo e finalidade Registrar o saldo inicial conciliado das contas bancárias, exclusivamente no mês de janeiro. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Saldo Inicial Conciliado. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição numeroContaBancaria string Sim 1 / 13 ^[A-Z0-9]+$   Chave   numeroAgenciaContaBancaria string Sim 1 / 6 ^[A-Z0-9]+$   Chave   codigoBancoContaBancaria string Sim 3 / 3 ^[0-9]+$   Chave   tipoContaBancaria string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Conta Bancária Chave   cnpjGerenciaContaBancaria string Sim 14 / 14 ^[A-Z0-9]+$   Chave   valorSaldoInicial number Sim           action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir registros duplicados pela chave. A entidade só pode ser enviada no mês de janeiro. A conta bancária deve estar cadastrada para a unidade gestora. Catálogo completo de regras (3) Identificador Descrição Classificação SALDO_INICIAL_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave. Validação SALDO_INICIAL_JANEIRO A entidade só pode ser enviada no mês de janeiro. Validação SALDO_INICIAL_CONTA_BANCARIA_CADASTRADA A conta bancária deve estar cadastrada para a unidade gestora. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação Há uma vírgula ausente entre valorSaldoInicial e action no schema publicado. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-045 Saldo Mensal Extrato Registrar o saldo mensal constante no extrato das contas bancárias. Desenvolvedor Versão2025 - EnvioBalancete - Contabilidade Atributos7 Regras2 ComplexidadeMédia CriticidadeAlta 1. Identificação funcional Categoria Conciliação bancária Chave de unicidade Exercício + Mês + UG + Conta + Agência + Banco + Tipo Conta + CNPJ Gerência Objeto raiz timestamp + elementos Dependências Conta Bancária Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/saldo-mensal-extrato-2025 2. Objetivo e finalidade Registrar o saldo mensal constante no extrato das contas bancárias. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Saldo Mensal Extrato. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição numeroContaBancaria string Sim 1 / 13 ^[A-Z0-9]+$   Chave   numeroAgenciaContaBancaria string Sim 1 / 6 ^[A-Z0-9]+$   Chave   codigoBancoContaBancaria string Sim 3 / 3 ^[0-9]+$   Chave   tipoContaBancaria string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Conta Bancária Chave   cnpjGerenciaContaBancaria string Sim 14 / 14 ^[A-Z0-9]+$   Chave   valorSaldoMensal number Sim           action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir registros duplicados pela chave. A conta bancária deve estar cadastrada para a unidade gestora. Catálogo completo de regras (2) Identificador Descrição Classificação SALDO_MENSAL_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados pela chave. Validação SALDO_MENSAL_CONTA_BANCARIA_CADASTRADA A conta bancária deve estar cadastrada para a unidade gestora. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-046 Transferência Concedida Registrar transferências financeiras concedidas a outra unidade gestora. Desenvolvedor Versão2025 ~ EnvioDiário Atributos10 Regras5 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Transferências financeiras Chave de unicidade Exercício + UG + UG Recebedora + Tipo Transferência + Tipo Lançamento + Conta + Banco + Tipo Conta + CNPJ Gerência Objeto raiz timestamp + elementos Dependências Unidade Gestora Recebedora; Conta Bancária; Tipo Transferência; Tipo Lançamento Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/transferencia-concedida-2025 2. Objetivo e finalidade Registrar transferências financeiras concedidas a outra unidade gestora. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Transferência Concedida. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestoraRecebedora string Sim 6 / 6 ^[0-9]+$   Chave   tipoTransferencia string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Transferência Chave   tipoLancamento string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Lançamento Chave   valor number Sim > 0         numeroContaBancaria string Sim 1 / 13     Chave   codigoBancoContaBancaria string Sim 3 / 3 ^[0-9]+$   Chave   numeroAgenciaContaBancaria string Sim 1 / 6     Chave   tipoContaBancaria string Sim 1 / 1 ^[0-9]+$   Chave   cnpjGerenciaContaBancaria string Sim 14 / 14 ^[0-9]+$   Chave   action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir registros duplicados. O tipo da transferência deve ser válido no exercício. O tipo de lançamento deve ser válido no exercício. A conta bancária deve estar cadastrada. Somente UGs do mesmo município; consórcio apenas a si próprio. Catálogo completo de regras (5) Identificador Descrição Classificação TRANSFERENCIA_CONCEDIDA_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação TRANSFERENCIA_CONCEDIDA_TIPO_VALIDO O tipo da transferência deve ser válido no exercício. Validação TRANSFERENCIA_CONCEDIDA_TIPO_LANCAMENTO_VALIDO O tipo de lançamento deve ser válido no exercício. Validação TRANSFERENCIA_CONCEDIDA_CONTA_BANCARIA_CADASTRADA A conta bancária deve estar cadastrada. Validação TRANSFERENCIA_CONCEDIDA_ESCOPO_CADASTRO Somente UGs do mesmo município; consórcio apenas a si próprio. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Situação: nenhuma divergência documental relevante registrada. 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-047 Transferência Recebida Registrar transferências financeiras recebidas de outra unidade gestora. Desenvolvedor Versão2025 ~ EnvioDiário Atributos11 Regras5 ComplexidadeAlta CriticidadeCrítica 1. Identificação funcional Categoria Transferências financeiras Chave de unicidade Exercício + UG + UG Transferência + Tipo Transferência + Tipo Lançamento + Conta + Banco + Tipo Conta + CNPJ Gerência Objeto raiz timestamp + elementos Dependências Unidade Gestora Transferência; Conta Bancária; Tipo Transferência; Tipo Lançamento Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/transferencia-recebida-2025 2. Objetivo e finalidade Registrar transferências financeiras recebidas de outra unidade gestora. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Transferência Recebida. 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestoraTransferencia string Sim 6 / 6 ^[0-9]+$   Chave   dataTransferencia date Required/Payload   format: date       tipoTransferencia string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Transferência Chave   tipoLancamento string Sim 1 / 1 ^[0-9]+$ Tabela Tipo Lançamento Chave   valor number Sim > 0         numeroContaBancaria string Sim 1 / 13     Chave   codigoBancoContaBancaria string Sim 3 / 3 ^[0-9]+$   Chave   numeroAgenciaContaBancaria string Sim 1 / 6     Chave   tipoContaBancaria string Sim 1 / 1 ^[0-9]+$   Chave   cnpjGerenciaContaBancaria string Sim 14 / 14 ^[0-9]+$   Chave   action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir registros duplicados. O tipo da transferência deve ser válido no exercício. O tipo de lançamento deve ser válido no exercício. A conta bancária deve estar cadastrada. Somente UGs do mesmo município; consórcio apenas a si próprio. Catálogo completo de regras (5) Identificador Descrição Classificação TRANSFERENCIA_RECEBIDA_DUPLICIDADE_NAO_PERMITIDA Não permitir registros duplicados. Validação TRANSFERENCIA_RECEBIDA_TIPO_VALIDO O tipo da transferência deve ser válido no exercício. Validação TRANSFERENCIA_RECEBIDA_TIPO_LANCAMENTO_VALIDO O tipo de lançamento deve ser válido no exercício. Validação TRANSFERENCIA_RECEBIDA_CONTA_BANCARIA_CADASTRADA A conta bancária deve estar cadastrada. Validação TRANSFERENCIA_RECEBIDA_ESCOPO_CADASTRO Somente UGs do mesmo município; consórcio apenas a si próprio. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação dataTransferencia aparece no required e no payload, mas não está declarada em properties nem na tabela Item. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice CTB-048 Unidade Orçamentária (referência duplicada) Revalidar a entidade Unidade Orçamentária já documentada no Lote 1. Desenvolvedor Versão2025 ~ EnvioOrçamento/Diário Atributos4 Regras4 ComplexidadeBaixa CriticidadeMédia 1. Identificação funcional Categoria Cadastro orçamentário Chave de unicidade Exercício + Código Unidade Gestora + Código Unidade Orçamentária Objeto raiz timestamp + elementos Dependências Unidade Gestora Fonte oficial https://docs.tcepb.tc.br/books/entidades-contabilidade/page/unidade-orcamentaria-2025 2. Objetivo e finalidade Revalidar a entidade Unidade Orçamentária já documentada no Lote 1. Atender às exigências funcionais e de prestação de contas relacionadas à entidade Unidade Orçamentária (referência duplicada). 3. Contexto de negócio A entidade participa do fluxo de prestação de contas do módulo Contabilidade e deve ser processada observando a ordem de dependências, a chave funcional e as validações do exercício correspondente. 4. Estrutura de atributos Campo JSON Tipo Obrigatório Min./Máx. Pattern Domínio Chave Descrição codigoUnidadeGestora string Sim 6 / 6 ^[0-9]+$   Chave   codigoUnidadeOrcamentaria string Sim 5 / 5 ^[0-9]+$   Chave   descricaoUnidadeOrcamentaria string Sim 10 / 50         action string Sim     CREATE; UPDATE; DELETE     5. Principais regras de negócio Não permitir duplicidade. A unidade gestora deve estar homologada. Somente prefeituras e consórcios enviam unidades orçamentárias. Prefeitura cadastra UOs vinculadas; consórcio apenas as próprias. Catálogo completo de regras (4) Identificador Descrição Classificação UNIDADE_ORCAMENTARIA_DUPLICIDADE_NAO_PERMITIDA Não permitir duplicidade. Validação UNIDADE_GESTORA_HOMOLOGADA A unidade gestora deve estar homologada. Validação RESPONSABILIDADE_PROTOCOLO Somente prefeituras e consórcios enviam unidades orçamentárias. Validação UNIDADE_ORCAMENTARIA_ESCOPO_CADASTRO Prefeitura cadastra UOs vinculadas; consórcio apenas as próprias. Validação 6. Casos de teste recomendados Cenário Condição Resultado esperado Inclusão válida O registro atende ao schema, às regras e às dependências. Aceite do registro. Chave duplicada Registro com a mesma chave funcional já enviado. Rejeição ou atualização controlada. Campo obrigatório ausente Um campo obrigatório não foi informado. Erro de validação. Relacionamento inexistente A entidade referenciada ainda não foi cadastrada. Rejeição por integridade. Operação DELETE Exclusão solicitada para registro existente. Processamento conforme regras do layout. 7. Observações e inconsistências Inconsistência/observação A entidade já foi documentada como CTB-003; esta ficha preserva a lista fornecida para o Lote 6 sem substituir o cadastro original. Tratamento recomendado: Revisar antes da implementação Inconsistência/observação O payload usa unidadesOrcamentarias, enquanto o schema usa elementos. Tratamento recomendado: Revisar antes da implementação 8. Recomendações de implementação Versionar schemas e regras por exercício. Aplicar idempotência com base na chave funcional. Validar dependências antes de montar o payload. Registrar logs de envio, resposta, rejeição e reprocessamento. Preservar o payload transmitido e a versão do layout para auditoria. ↑ Voltar ao índice Manual Institucional SAGRES Captura 2.0 — Módulo Contabilidade — v1.6.0