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
`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
`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
`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
`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
`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
`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
`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
`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.	Domínio	Chave
`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.	Domínio	Chave
`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.	Domínio	Chave
`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.	Domínio	Chave
`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.	Domínio	Chave
`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.	Domínio	Chave
`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.	Domínio	Chave
`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.	Domínio	Chave
`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
`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
`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
`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
`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
`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
`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

SAGRES Captura 2.0

Documentação Funcional do Módulo Contabilidade — Catálogo completo das 48 fichas

Apresentação

Dashboard das tarefas

Ailton

Odair

Diego

Sem responsável

Objetivos

Fluxo funcional resumido

Índice geral das entidades

Planejamento e orçamento

Cadastros

Receitas

Execução financeira e bancos

Restos a pagar

Retenções e estornos

Integrações

Referências documentais

Ação

1. Identificação funcional

2. Objetivo e finalidade

3. Contexto de negócio

4. Estrutura de atributos

5. Principais regras de negócio

6. Casos de teste recomendados

7. Observações e inconsistências

8. Recomendações de implementação

Programa

1. Identificação funcional

2. Objetivo e finalidade

3. Contexto de negócio

4. Estrutura de atributos

5. Principais regras de negócio

6. Casos de teste recomendados

7. Observações e inconsistências

8. Recomendações de implementação

Unidade Orçamentária

1. Identificação funcional

2. Objetivo e finalidade

3. Contexto de negócio

4. Estrutura de atributos

5. Principais regras de negócio

6. Casos de teste recomendados

7. Observações e inconsistências

8. Recomendações de implementação

Atualização Orçamentária

1. Identificação funcional

2. Objetivo e finalidade

3. Contexto de negócio

4. Estrutura de atributos

5. Principais regras de negócio

6. Casos de teste recomendados

7. Observações e inconsistências

8. Recomendações de implementação

Conta Bancária

1. Identificação funcional

2. Objetivo e finalidade

3. Contexto de negócio

4. Estrutura de atributos

5. Principais regras de negócio

6. Casos de teste recomendados

7. Observações e inconsistências

8. Recomendações de implementação

Conta Bancária Credor

1. Identificação funcional

2. Objetivo e finalidade

3. Contexto de negócio

4. Estrutura de atributos

5. Principais regras de negócio

6. Casos de teste recomendados

7. Observações e inconsistências

8. Recomendações de implementação

Credor

1. Identificação funcional

2. Objetivo e finalidade

3. Contexto de negócio

4. Estrutura de atributos

5. Principais regras de negócio

6. Casos de teste recomendados