# Classificação contabilística do catálogo — proposta do próximo incremento

**Actualização posterior:** o utilizador autorizou explicitamente a execução do primeiro incremento com as três salvaguardas. A implementação, provas e limites estão em [CATALOGUE_ACCOUNTING_DELIVERY.md](CATALOGUE_ACCOUNTING_DELIVERY.md). As quatro concessões iniciais foram posteriormente confirmadas de forma específica e aplicadas, conforme o relatório. O texto original de proposta abaixo preserva a origem das decisões; não revoga essa autorização posterior nem significa activação de contas/regras reais. A validação do cálculo permanece separada e pendente.

26 de Outubro de 2026, Africa/Johannesburg. **Apenas especificação para aprovação.** Não escolhe o plano da Tempo Lda, aplica acessos, altera bases, produz lançamentos ou autoriza implementação. A validação do incremento de cálculo continua pendente; esta proposta não o dá por aceite nem altera a sua política. Preservar identidade, A, B1, preparação documental, pré-visualização e histórico.

## 1. Documento-base e alcance da leitura

Exemplar fornecido pelo utilizador: `\\Mac\Home\Downloads\29-Plano-de-Contas-BR-Decreto-70-2009-de-22-de-Dezembro.pdf`. Decreto n.º 70/2009, de 22 de Dezembro, BR, I Série, n.º 50, 4.º suplemento; 192 páginas PDF, 856306 bytes. SHA-256: `45C38AED64DE43042ED048586ACCE2EC660B74FC3F8FBCE33D39AAB45C7529E3`.

Leitura do exemplar histórico fornecido, com extracção textual e conferência visual das páginas PDF 127, 134, 178 e 192, especialmente porque a extracção das colunas desloca códigos e descrições. As referências abaixo usam página PDF contada desde 1 e paginação impressa do BR. O documento é fonte de conteúdo; as instruções nele contidas não ampliam a autorização do utilizador para executar acções.

Não se apresenta este exemplar de 2009 como consolidação normativa verificada até 2026. A eventual verificação de alterações posteriores fica delimitada à norma que venha a ser activada, antes da activação real; não se repetiu pesquisa fiscal nem se consultou o InvesteMoz nesta etapa.

| Ref. | Fonte/secção efectivamente lida | Conteúdo relevante e limite |
| --- | --- | --- |
| D1 | Decreto, arts. 1–3, PDF 1–2, BR 372-(15)–(16) | SCE com dois planos: Título I PGC-NIRF, Título II PGC-PE. Art. 2 define âmbito, transições e opção; art. 3 identifica exclusões sectoriais. Não deduzir plano do nome, NUIT ou designação comercial «pequena empresa» |
| D2 | Decreto, art. 6 e art. 7, PDF 2, BR 372-(16) | Datas históricas: PGC-NIRF grandes desde exercício iniciado em 01/01/2010; médias e PGC-PE desde 01/01/2011; regra para ano económico não civil e transição. Não usar estas datas como aprovação do plano actual da Tempo Lda |
| D3 | Título I, cap. 1.1, §6, PDF 3, BR 372-(17); cap. 1.5, PDF 134, BR 372-(148) | Quadros sintético/detalhado, adaptação às entidades; conta 7.2 Prestação de serviços e subcontas oficiais, incluindo 7.2.1 e 7.2.6. Não inventar desdobramentos oficiais nem tratar todos os nós como contas movimentáveis |
| D4 | Título I, cap. 1.2, §20, PDF 5, BR 372-(19) | Base do acréscimo: acontecimento e período, distintos de recebimento/pagamento |
| D5 | Título I, NCRF 28, §§3–7 e §§8–16, PDF 126–127, BR 372-(140)–(141) | Âmbito/exclusões, mensuração, componentes identificáveis; prestação de serviços §§14–16 depende de fiabilidade, benefícios, fase de acabamento e custos. «Pontual» não dispensa avaliar condições; locações/construção têm tratamento próprio |
| D6 | Título II, cap. 2.1, §§2–4, PDF 168, BR 372-(182) | PGC-PE tem regras simplificadas próprias; complemento referido ao Quadro Conceptual e Glossário do PGC-NIRF. Não importar automaticamente todas as NCRF como se integrassem o PGC-PE |
| D7 | Título II, cap. 2.2, §16, PDF 169, BR 372-(183) | Base do acréscimo no corpo do texto. O índice da página anterior apresenta numeração diferente; referência aqui é ao parágrafo efectivamente impresso, não apenas ao índice |
| D8 | Título II, cap. 2.4, PDF 178, BR 372-(192); cap. 2.6, PDF 191–192, BR 372-(205)–(206) | 7.2 Prestação de serviços: trabalhos/serviços ligados aos objectivos da empresa; 7.5 rendimentos suplementares e 7.6 outros rendimentos exigem distinguir natureza. 7.2.1 descreve expurgo de IVA de serviços registados com imposto incluído: não fixa taxa nem autoriza esse modo no cálculo actual |

## 2. Base existente e fronteiras

Revisão por leitura de `ServiceWorkflow`, `ServicePermissions` e da migração de A: `a_services` é catálogo da empresa, reutilizado entre unidades, com ID, nome, descrição e versão/histórico. Prestações e rascunhos pertencem à unidade autorizada e guardam referências/valores de origem. Categorias contabilísticas, plano empresarial e associações contabilísticas não estão implementados no catálogo actual. Não recriar serviços, clientes, unidades, histórico ou mecanismos de autorização.

Começar pelo serviço pontual já suportado. O próximo incremento proposto apenas permite preparar, validar e consultar a associação contabilística do catálogo; não implementa reconhecimento ou lançamentos. Mercadorias ficam previstas pelo tipo de item e papéis contabilísticos futuros, sem novos cadastros duplicados, stock, compras, inventário ou custo das vendas nesta entrega.

Três associações independentes:

| Dimensão | Pergunta | Saída proposta | O que não determina |
| --- | --- | --- | --- |
| Classificação contabilística | Qual a natureza económica e quais contas/papéis são adequados? | Plano/versão, categoria, regra e conta aprovada para cada papel | Taxa/tratamento de IVA ou data de reconhecimento |
| Enquadramento fiscal | Qual o tratamento da empresa/operação e a taxa aplicável? | Perfil fiscal próprio, fundamento, âmbito e vigência | Conta de rendimentos ou momento de reconhecimento contabilístico |
| Reconhecimento | Que acontecimento e evidência satisfazem as condições do normativo? | Avaliação própria de condições, mensuração e período | Não se conclui pela existência de factura, B1 ou recebimento |

Não assumir 16% para serviços. Não extrair taxa de conta, categoria contabilística, palavras no nome ou código `7.2.1`. O cálculo exacto e a truncagem operacional permanecem nos seus perfis/políticas já delimitados; este desenho não os altera e não escolhe montante de lançamento a partir de um total documental proposto.

## 3. Proposta técnica de parametrização

Estas entidades são conceitos propostos, não tabelas criadas ou migrações autorizadas.

| Elemento | Informação mínima | Âmbito e regra |
| --- | --- | --- |
| Referência de plano | Identidade PGC-NIRF/PGC-PE, versão documental, hash/fonte, estrutura oficial e estado da verificação | Definição normativa reutilizável, sem partilhar configurações empresariais; códigos sempre qualificados pelo plano/versão, nunca só pelo texto do código |
| Plano adoptado pela empresa | Empresa, plano/versão, fundamento, período de aplicação, responsável, decisão e prova | Uma selecção explícita validada; sem escolha automática. Mudança cria versão e exige revisão das associações, sem converter o passado |
| Conta empresarial | Plano/versão, código oficial ou desdobramento empresarial distinguido, descrição, pai, natureza, papel, possibilidade de movimento e vigência | Conta pertence à configuração da empresa; conta agregadora não se torna movimentável por omissão. Desdobramento novo exige validação de compatibilidade, sem ocupar código reservado |
| Categoria de catálogo | ID, empresa, nome, natureza inicial `service`; previsão de `goods` futura; versão | Reutilizada entre unidades da mesma empresa. Classificação analítica do catálogo não é automaticamente conta nem tratamento de IVA |
| Associação/regra | Serviço existente ou categoria, versão da regra, plano/conta para papel `service_revenue`, condições/exclusões, vigência e prova | Específica da empresa. Regra do serviço pode substituir a categoria apenas por decisão explícita validada; sem preferência silenciosa entre regras concorrentes |
| Decisão de validação | Proponente, responsável autorizado, data, motivo, evidência, versão aprovada e início de aplicação | Rascunho → validada/activável ou recusada; alteração origina nova versão. Aprovação de classificação não aprova fiscalidade ou reconhecimento |
| Resolução por operação futura | ID e versão do serviço/categoria/associação, plano/conta, papel, data de referência, responsável e estado de excepção | Conservar o que foi efectivamente usado, não recalcular pela regra actual; fotografia própria fora de B1 existente |

Papéis permitem evoluir para rendimentos de mercadorias, inventário e custo, mas nenhuma conta ou regra desses papéis será activada agora. Não criar um motor geral de scripts contabilísticos: condições iniciais são dados delimitados (empresa, tipo serviço, categoria/serviço, papel, intervalo de vigência e exclusões). Fórmulas executáveis, débitos/créditos e contas de contrapartida ficam fora deste incremento.

### Resolução e vigência propostas

1. Validar contexto, empresa e acesso; reutilizar ID/versão do serviço. Não permitir associação a categoria/conta/plano de outra empresa.
2. Exigir plano empresarial aprovado e uma data de referência explicitamente definida para a classificação. A data é dado próprio, não a data do reconhecimento, exigibilidade de IVA ou data do computador por omissão. Se faltar, apresentar candidato sem o declarar aplicável.
3. Só uma excepção específica por serviço **aprovada, vigente na data de referência e compatível** pode substituir a regra da categoria. Proposta pendente, recusada ou com vigência futura não substitui a regra actualmente válida. Na ausência de excepção aplicável, resolver pela regra da categoria aprovada e vigente. A herança deve estar aprovada e visível. Duplicidade, sobreposição ou incompatibilidade geram conflito explícito; não escolher silenciosamente nem ocultar o conflito com uma regra alternativa.
4. Validar papel, estado da conta e versão do plano. Conta agregadora ou desdobramento não aprovado não permite resolução como pronta.
5. Mostrar conta/regra/fontes e motivo da sugestão. Guardar a decisão e versões na futura operação por acção autorizada, sem produzir lançamento ou concluir reconhecimento.

O próximo incremento pequeno propõe um único nível de categorias e associação explícita de cada serviço a uma categoria, com excepção específica versionada por serviço. Hierarquias complexas e regras por unidade só entram mediante necessidade futura demonstrada. A classificação da empresa não concede acesso a operações de unidades não autorizadas.

**Mudança de categoria com efeito contabilístico:** a ligação do serviço à categoria faz parte da classificação versionada. Se uma mudança afectar a conta herdada ou outra componente da classificação, exige proposta, vigência e validação por Samira antes de produzir efeito. A edição corrente do catálogo não pode activar essa mudança, substituir a ligação aprovada ou contornar a validação. Até à entrada em vigor da nova versão aprovada, preserva-se a classificação aplicável anterior e mostra-se a proposta separadamente. As operações históricas conservam as versões utilizadas.

**Subconjunto inicial de contas:** importar/configurar apenas as referências PGC-NIRF necessárias ao serviço pontual e ao papel de rendimento aprovado, com fonte, versão e hierarquia necessárias identificadas. Não carregar todo o plano nem criar contas ou desdobramentos por suposição. Categorias e associações pertencem à empresa e são reutilizáveis entre unidades; essa reutilização não amplia permissões sobre operações de outras unidades.

## 4. Automação após validação e excepções

| Situação | Preenchimento possível após validação | Intervenção/pendência |
| --- | --- | --- |
| Serviço com regra única vigente aprovada | Reutilizar categoria, papel, conta e versões; explicar origem; conservar a resolução | Não atribuir IVA nem reconhecer rendimento por este preenchimento |
| Novo serviço numa categoria com herança aprovada | Sugerir associação da categoria, indicando que é herança | Se a actividade/natureza não coincidir, exigir revisão; o nome sozinho não comprova adequação |
| Conta/plano em falta, expirado, substituído ou sem fundamento | Mostrar informação já conhecida e motivo do bloqueio | Responsável resolve antes de marcar a classificação aplicável |
| Serviço entre actividade principal, rendimento suplementar, locação, construção ou operação composta | Mostrar alternativas e condições documentais | Rever natureza/âmbito; não escolher 7.2 por ser chamado «serviço» |
| Falta de evidência de execução, fiabilidade ou período | Conservar classificação aprovada do catálogo | Reconhecimento continua pendente, mesmo com factura/B1/pagamento |
| Regra alterada após preparar operação | Assinalar nova versão disponível, sem substituir a consultada | Revisão explícita; versão anterior identificada como histórica, sem reescrever lançamentos ou B1 |
| Operação anterior sem classificação preservada | Mostrar «não capturada» | Eventual classificação posterior será decisão nova datada e auditada, nunca fotografia retrospectiva inventada |
| Perfil fiscal ausente ou diferente entre operações do mesmo serviço | Conservar a classificação contabilística adequada | IVA fica pendente ou usa perfil fiscal independentemente validado; nenhuma taxa herdada da conta |

## 5. Exemplo sintético, sem lançamentos

Empresa Exemplo, Unidade de Teste, serviço existente `S-TESTE` — «Apoio administrativo pontual». Categoria analítica proposta «Serviços da actividade normal». Não são dados da Tempo Lda.

Para comparar alternativas, considerar separadamente um cenário com PGC-NIRF e outro com PGC-PE. Ambos mostram **7.2 — Prestação de serviços** nos quadros lidos, mas são referências distintas: `(PGC-NIRF, versão do exemplar, 7.2)` e `(PGC-PE, versão do exemplar, 7.2)`. Não seleccionar um deles nem declarar 7.2 movimentável sem aprovação do plano e da conta empresarial concreta. Se necessário desdobramento empresarial, código e compatibilidade ficam por validar; não inventar um código oficial.

Depois de um responsável validar a natureza de actividade normal, plano, conta e regra de categoria `R-SERVICO-v1`, o sistema pode preencher uma **proposta de classificação** para o papel de rendimento. Se depois surgir `R-SERVICO-v2`, a operação que utilizou v1 conserva v1 e mostra a alteração; nova operação só resolve v2 na vigência adequada. Não alterar B1 nem rascunhos antigos automaticamente.

No cenário PGC-NIRF, a análise de reconhecimento teria de avaliar as condições dos §§14–16 da NCRF 28, incluindo fase e custos, não apenas «concluído» ou «facturado». No cenário PGC-PE, usar as bases próprias (cap. 2.2, §16) e validar o tratamento específico; não aplicar a NCRF 28 por simples identidade de código de conta.

Mesmo serviço/conta pode surgir com enquadramentos fiscais distintos conforme a operação: o exemplo deixa o perfil IVA por validar. Não inclui taxa, cálculo, valor contabilizado, débitos/créditos ou lançamento. Uma confirmação interna e um eventual recebimento não resolvem as pendências de reconhecimento.

## 6. Próximo incremento pequeno proposto

Só após aprovação: preparar configuração empresarial do plano validado, selecção de contas autorizadas para o papel de rendimento do serviço pontual, categorias simples e associações versionadas do catálogo. Reutilizar os serviços existentes e apresentar uma resolução explicável, com pendências e histórico. A captura da versão utilizada numa operação deve ter contrato definido agora, mas a sua implementação concreta exige delta próprio que preserve B1 e os modelos actuais; nenhuma alteração de esquema está autorizada por esta especificação.

Ecrãs propostos: (1) plano e contas da empresa, com fundamento/versão; (2) categorias e associação do serviço existente, com proposta e validação; (3) consulta da resolução e histórico/excepções. Sem ecrã de diário, lançamentos, stock, compras ou fecho. Não construir todo o plano/motor de reconhecimento nesta entrega.

Critérios de aceitação futuros: plano não presumido; serviço existente reutilizado; conta e plano da empresa correcta; leitor não altera; proponente não aprova sem direito próprio; herança/excepção visíveis; ambiguidades e falta de dados negadas por omissão; regra alterada não reescreve versões antigas; IVA nunca derivado da conta; factura/B1/pagamento nunca reconhecem automaticamente; B1 intacto; demonstração só sintética em ambiente isolado. Testes não executados nesta etapa documental.

## 7. Decisões pendentes, reduzidas

### Confirmações posteriores do utilizador — 26/10/2026

- **Plano actualmente utilizado pela Tempo Lda: PGC-NIRF**, confirmado expressamente pelo utilizador. Não foi escolhido por inferência do nome ou dimensão comercial. Esta informação substitui a pendência de identificar qual dos dois planos é utilizado; não comprova, por si só, a edição/consolidação normativa, o período de adopção ou a configuração concreta de contas da empresa.
- **Responsável pela validação dos enquadramentos contabilísticos: Samira**, indicada pelo utilizador. A indicação de responsabilidade não aplica concessões, não altera a conta existente nem aprova automaticamente contas ou associações propostas. A conta exacta e os direitos/âmbitos serão apresentados quando se fechar a matriz de acessos; não se infere identificação por nome.
- **Separação de funções confirmada:** a consulta actualmente concedida a Samira não inclui validação contabilística. O futuro poder de validar será próprio, com acções e âmbito delimitados e confirmação específica antes da aplicação. Não implicará automaticamente edição de propostas, edição do catálogo, administração ou gestão de acessos. A proposta deve permitir validar ou recusar uma versão identificada sem modificar o seu conteúdo; uma correcção exige nova proposta por quem tenha o direito correspondente.
- Mantém-se a proposta de categoria como regra-base, excepção explícita por serviço e vigência versionada, preservando operações históricas. A identificação de quem propõe e de quem apenas consulta continua pendente. A validação do cálculo permanece separada.

### Desenho fechado pelo utilizador — confirmação posterior

Esta confirmação substitui as pendências anteriores relativas a proponente, herança e correcções: **Osmane prepara; Samira valida ou recusa uma versão identificada, sem editar o seu conteúdo. A categoria fornece a regra-base, com excepções explícitas por serviço e vigência definida. Correcções geram nova versão, sem reescrever o histórico.** O plano actualmente utilizado é PGC-NIRF, conforme confirmação anterior.

O desenho está fechado para preparar o prompt de implementação; não é, por si só, autorização de implementação ou de aplicação de acessos. As novas permissões continuam sujeitas a apresentação concreta de acções, contas e âmbitos e confirmação específica antes da aplicação. Validar não concede edição, administração ou gestão de acessos. A consulta actual permanece inalterada. A validação do cálculo mantém-se separada e pendente.

Salvaguardas posteriores incorporadas ao desenho fechado: apenas excepções aprovadas/vigentes/compatíveis têm precedência; mudança de categoria que afecte classificação exige versionamento, vigência e validação; categorias/associações empresariais não concedem acesso entre unidades; catálogo inicial limitado ao subconjunto necessário do PGC-NIRF com fonte e versão. Estas salvaguardas devem integrar o prompt de execução sem reabrir as decisões anteriores e sem aplicar concessões nesta etapa.

### O que resta delimitar

1. **Versão e configuração do PGC-NIRF:** identificar edição/consolidação, período de adopção e contas/desdobramentos efectivamente utilizados. Confirmar apenas fundamentos e alterações relevantes antes da activação; não voltar a pedir a escolha PGC-PE/PGC-NIRF já resolvida.
2. **Procedimento de validação por Samira:** delimitar a evidência e o procedimento para validar contas, desdobramentos e associações. Não voltar a perguntar quem será responsável, nem inventar cargo profissional ou obrigação de revisão por duas pessoas.
3. **Aplicação concreta dos acessos:** funções já definidas — Osmane prepara; Samira valida ou recusa. Direitos separados por empresa para consultar, propor/editar rascunho e validar/recusar uma versão identificada. Identificadores candidatos `catalogue_accounting.view`, `.propose`, `.approve`; apresentar contas existentes, acções e âmbitos concretos para confirmação específica antes de conceder. `.approve` não inclui `.propose`, edição, administração ou gestão de acessos. A consulta actual de Samira permanece inalterada e não concede validação. Não inferir direitos de `services.edit/manage`, de permissões fiscais ou de configuração visual; a consulta contabilística específica também não se presume a partir da consulta actual de outras áreas.
4. **Detalhe de vigência para execução:** herança por categoria, excepção explícita por serviço, vigência definida e novas versões para correcções já estão fechadas. Resta explicitar no prompt os dados/evidências de referência usados para resolver a vigência, sem voltar a submeter esse desenho a decisão. O recorte de catálogo não aprova política de reconhecimento ou geração de lançamentos.

Já resolvido e não submetido de novo: catálogo da empresa reutilizável entre unidades; tenant/empresa/unidade distintos; classificação contabilística separada de IVA e reconhecimento; valores exactos, desconhecido diferente de zero e histórico preservado. A validação do cálculo entregue permanece independente e pendente.

## 8. Alterações realizadas nesta etapa

Criado apenas este documento de proposta e materiais temporários de leitura em `storage/app/`, fora dos ficheiros de aplicação. PDF original preservado. Não se alteraram código, bases, permissões ou entregas aceites; não foram executados testes, migrações, cálculos ou lançamentos. Nenhuma implementação ou publicação foi iniciada.