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.
22 KiB
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
- Validar contexto, empresa e acesso; reutilizar ID/versão do serviço. Não permitir associação a categoria/conta/plano de outra empresa.
- 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.
- 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.
- Validar papel, estado da conta e versão do plano. Conta agregadora ou desdobramento não aprovado não permite resolução como pronta.
- 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
- 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.
- 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.
- 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..approvenã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 deservices.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. - 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.