Ação

Cadastrar as ações orçamentárias da unidade gestora, com descrição, tipo, meta e unidade de medida.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

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.

Programa

Cadastrar os programas orçamentários e sua associação ao objetivo do milênio.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O payload publicado utiliza a coleção 'programas', enquanto o schema define a coleção raiz como 'elementos'.

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.

Unidade Orçamentária

Cadastrar as unidades orçamentárias vinculadas às unidades gestoras.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O payload publicado utiliza a coleção 'unidadesOrcamentarias', enquanto o schema define 'elementos'.

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.

Atualização Orçamentária

Registrar alterações orçamentárias realizadas por decreto ou ofício sobre dotações e fontes de recursos.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O schema lista 'dataAtualizacao' como obrigatório, mas esse atributo não aparece na relação de propriedades nem no payload publicado.

O tipo do campo tipoDecretoOficio está declarado como integer, embora o enum e o payload usem textos DECRETO/OFICIO.

Há uma vírgula aparentemente ausente entre codigoPrograma e codigoAcao no schema publicado.

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.

Conta Bancária

Cadastrar contas bancárias utilizadas pela unidade gestora.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A chave publicada inclui Código Unidade Gestora, mas o atributo não aparece no item/schema da página.

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.

Conta Bancária Credor

Cadastrar as contas bancárias dos credores.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A chave publicada inclui Código Unidade Gestora, mas o atributo não aparece no item/schema da página.

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.

Credor

Cadastrar pessoas físicas ou jurídicas que atuam como credores da unidade gestora.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O payload usa cpfCnpjCredor, nomeCredor e tipoCredor, enquanto o schema define cpfCnpj, nome e tipo.

A chave publicada inclui Código Unidade Gestora, mas o atributo não aparece no item/schema da página.

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.

Decreto Ofício

Registrar decretos e ofícios que fundamentam atualizações orçamentárias.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A propriedade está grafada como 'protolocoLei' na documentação.

O tipoDocumento é declarado como integer, mas o enum e o payload usam DECRETO/OFICIO.

O schema exige codigoUnidadeGestora, mas essa propriedade não aparece na lista de propriedades.

Há uma vírgula aparentemente ausente antes da propriedade action no schema publicado.

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.

Despesa Extra

Registrar despesas extraorçamentárias, seus credores, contas contábeis, fontes de recursos e eventual vínculo com receita extra.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O schema exige cpfCnpjFornecedor, mas a propriedade e o payload utilizam cpfCnpjCredor.

A tabela usa codigoCO, enquanto schema e payload usam co.

O payload possui exercicio e dataDespesaExtra, mas essas propriedades não constam no schema.

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.

Dotação 2025-2026

Cadastrar dotações orçamentárias para os exercícios de 2025 e 2026.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

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.

Dotação 2027

Cadastrar dotações orçamentárias a partir de 2027, com referências opcionais a emendas.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O payload publicado repete codigoEmendaParlamentar no mesmo objeto.

Os novos campos de emenda são propriedades opcionais e não compõem a chave publicada.

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.

Emenda Impositiva

Cadastrar emendas impositivas, seus autores, beneficiários, finalidade e valor.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A lista required exige valorEmenda, mas a propriedade e o payload usam valorEmendaImpositiva.

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.

Empenho 2025-2026

Registrar empenhos emitidos nos exercícios de 2025 e 2026.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

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.

Empenho 2027

Registrar empenhos a partir de 2027, incluindo referência opcional à emenda parlamentar.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O schema required usa cpfCnpjFornecedor, enquanto a tabela e o payload usam cpfCnpjCredor.

A principal alteração identificada em 2027 é a inclusão de codigoEmendaParlamentar.

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.

Estorno Despesa Extra

Registrar estornos de despesas extraorçamentárias.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A chave textual publicada menciona Número Receita Extra, embora os atributos se refiram a Despesa Extra.

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.

Estorno Empenho

Registrar estornos de valores empenhados.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

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.

Estorno Liquidação

Registrar estornos de liquidações do exercício.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

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.

Estorno Liquidação Resto

Registrar estornos de liquidações de restos a pagar.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

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.

Estorno Pagamento

Registrar estornos de pagamentos vinculados a empenho e liquidação.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A chave textual menciona Número Estorno Liquidação, mas o item/schema não possui esse campo.

O payload usa a coleção estornosPagamento, enquanto o schema define elementos.

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.

Estorno Pagamento Resto

Registrar estornos de pagamentos de restos a pagar.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A chave e a tabela do item incluem numeroLiquidacao, mas o required do schema não exige esse campo.

O schema exige dataEstornoPagamentoResto, embora a tabela resumida do item não o liste.

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.

Estorno Receita Extra

Registrar estornos de receitas extraorçamentárias.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O required do schema inclui dataEstornoReceitaExtra, mas a propriedade não está declarada e o payload não a informa.

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.

Estorno Resto

Registrar estornos de valores inscritos em restos a pagar.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O schema exige dataEstornoResto, mas essa propriedade não aparece no bloco properties.

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.

Estorno Retenção

Registrar estornos de retenções incidentes sobre pagamentos do exercício.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A chave, a tabela do item e o payload usam numeroRetencao, mas o schema não declara nem exige essa propriedade.

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.

Estorno Retenção Resto

Registrar estornos de retenções vinculadas a pagamentos de restos a pagar.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A chave e a tabela do item incluem numeroLiquidacao, mas o required do schema não exige esse campo.

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.

Liquidação

Registrar liquidações de empenhos, com dados opcionais ou obrigatórios de nota fiscal conforme o elemento e subelemento.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

O schema declara action como propriedade, mas não o inclui na lista required.

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.

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.

Liquidação Resto

Registrar liquidações de restos a pagar não processados.

1. Identificação funcional

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

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.

6. Casos de teste recomendados

7. Observações e inconsistências

A regra LIQUIDACAO_RESTO_LIQUIDACAO_CADASTRADA parece referir-se à própria liquidação de resto; exige revisão semântica 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.

Movimentação entre Contas Bancárias

Registrar transferências entre contas bancárias da unidade gestora.

1. Identificação funcional

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

5. Principais regras de negócio

• Não permitir duplicidade.
• Conta de origem deve estar cadastrada.
• Conta de destino deve estar cadastrada.

6. Casos de teste recomendados

7. Observações e inconsistências

dataMovimentacao consta em required e no payload, mas não aparece em properties.

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.

Norma Orçamentária

Registrar leis e normas que autorizam o orçamento e alterações orçamentárias.

1. Identificação funcional

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

5. Principais regras de negócio

• Não permitir duplicidade.
• Tipo de lei deve ser válido.
• Protocolo deve existir no banco do TCE.

6. Casos de teste recomendados

7. Observações e inconsistências

A tabela do item usa autorizacaoPercentual, mas schema/payload usam tipoAutorizacao.

A chave publicada repete a expressão Código Unidade Gestora.

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.

Ordenador

Cadastrar ordenadores de despesa da unidade gestora.

1. Identificação funcional

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

5. Principais regras de negócio

• Não permitir duplicidade.
• Nome deve corresponder à Receita Federal.

6. Casos de teste recomendados

7. Observações e inconsistências

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.

Pagamento

Registrar pagamentos de liquidações do exercício.

1. Identificação funcional

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

5. Principais regras de negócio

• Não permitir duplicidade.
• Liquidação deve existir.
• Soma dos pagamentos não pode exceder o valor liquidado.

6. Casos de teste recomendados

7. Observações e inconsistências

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.

Pagamento Resto

Registrar pagamentos de restos a pagar.

1. Identificação funcional

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