Files
SGF/docs/CATALOGUE_ACCOUNTING_CLASSIFICATION_SPEC.md
T
nala f8d57b52aa Preserva classificacao contabilistica aceite e bases locais
Regista aceitacao funcional do primeiro incremento PGC-NIRF e preserva as dependencias documentais e tecnicas existentes. A validacao do calculo fiscal continua separada e pendente. Sem credenciais, bases operacionais ou publicacao.
2026-10-26 13:47:11 +02:00

22 KiB
Raw Blame History

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. 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.