SGF/docs/CATALOGUE_ACCOUNTING_DELIVERY.md

Classificação contabilística do catálogo — entrega local

Aceitação funcional e encerramento

Em 26/10/2026, o utilizador informou que entrou na aplicação e verificou o percurso. À pergunta de confirmação da aceitação funcional para registar o encerramento e criar o checkpoint Git local, respondeu «sim». Fica aceite e encerrado este primeiro incremento, no âmbito entregue e com os limites documentados abaixo. O checkpoint preserva a implementação e as dependências locais necessárias, sem credenciais, bases ou dados operacionais locais.

A validação do cálculo fiscal permanece separada e pendente. A presença do seu código no checkpoint preserva a base técnica existente; não constitui aceitação fiscal, activação de perfil real, autorização de emissão ou de lançamentos. Nenhum avanço para outro incremento ou publicação foi autorizado.

O texto de entrega seguinte descreve o estado técnico anterior à aceitação; esta secção regista a confirmação posterior, sem alterar as provas.

26 de Outubro de 2026, Africa/Johannesburg. Implementado apenas o primeiro incremento autorizado, com as três salvaguardas de CATALOGUE_ACCOUNTING_CLASSIFICATION_SPEC.md. Não constitui aceitação pelo utilizador; a validação do cálculo permanece separada e pendente.

Funcionalidade entregue

• Propostas imutáveis e versionadas de plano PGC-NIRF, contas empresariais, categorias/regras-base, ligações de serviços a categorias e excepções explícitas por serviço. Reutiliza a_services; não criou outro catálogo de serviços.
• Guardar proposta em preparação, submeter uma versão fixa e validar ou recusar com motivo. Validação não edita conteúdo. Correcção gera outra versão, com referência à anterior, e exige nova submissão/decisão; não herda aprovação. Versão ultrapassada não pode ser submetida ou decidida como se fosse a actual.
• Vigência com início explícito e termo opcional inclusivo. Revisão futura ou pendente não substitui regra válida. Intervalos sobrepostos exigem substituição explícita da versão aprovada; conflitos não escolhem automaticamente o maior número de versão. Substituição aprovada termina o intervalo anterior desde o início da nova vigência, sem alterar a linha histórica; a versão substituída não reaparece silenciosamente quando a substituta termina.
• Categoria fornece regra-base. Só excepção aprovada, vigente e compatível a substitui. Uma excepção vigente com dependência incompatível mostra pendência/conflito, sem fallback silencioso. Ausência de excepção aplicável usa a categoria aprovada vigente. Mudança de categoria é proposta do tipo ligação, não campo editável pela API corrente de serviços.
• Consulta por serviço e data explícita, com origem, conta, versões e pendências. Plano ou conta incompatíveis/agregadores não produzem classificação pronta. Não presume data do computador, taxa de IVA ou reconhecimento.
• Resoluções append-only por operação autorizada, com serviço/versão, regra/categoria/conta/plano/decisão e data de referência preservados. A gravação exige a revisão da classificação consultada e a versão da operação; mudança entretanto gera 409, sem substituir silenciosamente o resultado. Não altera rascunho, fotografia B1 ou cálculo.
• Histórico consultável apenas com consulta contabilística e acesso à operação/unidade actual. Não reconstrói classificação nos registos antigos; histórico vazio significa ausência de captura. Rascunho B1 confirmado recusa captura retroactiva.

Não há lançamentos, débitos/créditos, reconhecimento automático, contas de contrapartida, stock, compras, inventário ou fecho. Perfil/tratamento de IVA continua separado da classificação contabilística. Não foram alterados o núcleo de cálculo, a sua política ou a pré-visualização fiscal.

Fonte e configuração inicial

Decreto n.º 70/2009, exemplar fornecido, cap. 1.5, PDF 134 / BR 372-(148), com hierarquia 7 — Rendimentos e ganhos → 7.2 — Prestação de serviços. Versão de referência: Decreto70/2009-PGC-NIRF-PDF134-BR372(148); SHA-256 do PDF 45C38AED64DE43042ED048586ACCE2EC660B74FC3F8FBCE33D39AAB45C7529E3.

Esse é o subconjunto documental inicial, apresentado como referência agregadora não movimentável. Não se importou o plano inteiro. Desdobramento empresarial só é proposto com código, designação, evidência e aprovação; o sistema não inventa uma conta para a Tempo Lda e recusa usar os códigos reservados 7.2/7.2.1/7.2.6 como novos desdobramentos empresariais. A versão do exemplar de 2009 não é apresentada como consolidação normativa actual verificada. A matriz original identifica também os fundamentos de separação de classificação, reconhecimento e IVA; não se repetiu investigação nem se consultou o portal nesta implementação.

O plano actualmente utilizado pela empresa foi confirmado como PGC-NIRF, mas datas de adopção, contas empresariais e enquadramentos concretos serão propostos por Osmane e validados/recusados por Samira no circuito. Não foram criadas propostas ou aprovações reais para preencher essas lacunas por suposição.

Acessos confirmados e efectivamente aplicados

Após conferência das contas existentes e confirmação específica do utilizador, aplicadas exactamente quatro concessões na Tempo Lda, tenant 1/empresa 1, sem unidade:

Conta existente	Direitos novos	Acções
ID 1 — Osmane Nala	catalogue_accounting.view, catalogue_accounting.propose	Consultar, preparar novas versões, submeter e guardar resoluções nas operações de unidades já autorizadas
ID 2 — Samira Nal	catalogue_accounting.view, catalogue_accounting.approve	Consultar e validar/recusar versões submetidas, sem editar/preparar

Nenhum .approve foi dado a Osmane, nenhum .propose a Samira; não se acrescentaram direitos de unidade, gestão de acessos, emissão ou reconhecimento. Todos os direitos anteriores permaneceram iguais. Verificação posterior das concessões.

O código aplica permissões, não privilégios por nome/email. A ferramenta local de concessão recebe IDs explícitos e requer pertenças/direitos de consulta existentes; não cria contas ou pertenças. Novas concessões continuam a exigir apresentação e confirmação específicas. A gestão geral existente não ganhou automaticamente capacidade de delegar estes novos direitos.

Migração e preservação

Delta apresentado antes de aplicar: 2026_10_26_040000_create_catalogue_accounting.php cria ca_proposals, ca_submissions, ca_decisions, ca_resolutions, ca_commands, relações compostas, unicidades, checks e triggers. A restrição de âmbito de permission_grants foi alargada para aceitar os três identificadores empresariais, sem os conceder na migração.

Aplicada primeiro em sgf_tempo_test, depois em sgf_tempo_dev pelo wrapper e proprietário separados. Verificado que era a única migração pendente. Sem reset/fresh de desenvolvimento. Conteúdos existentes e ficheiros do cálculo foram comparados por hashes; permaneceram iguais. As cinco tabelas novas em desenvolvimento continuam com zero linhas, mesmo após os quatro acessos. Preservação da migração; preservação após concessões.

Relações compostas e guardas de inserção recusam referências de outra empresa e capturas de outra unidade/operação. Triggers append-only impedem actualização, transferência em massa e apagamento de propostas, decisões, comandos e resoluções. Submissões/decisões também verificam versão e transição na base. Não se declara isso como RLS ou protecção contra administrador da base. Auditoria e comandos são transaccionais; alterações autorizadas são serializadas pelo bloqueio da empresa, com revalidação de contexto/permissões. O contexto do navegador não constitui autorização.

Testes, compilação e navegador

Suite dirigida inicial: 61 testes / 783 asserções, passada, cobrindo classificação, A, B1, identidade, isolamento e guardas. Após a protecção adicional da revisão consultada, repetidos apenas os testes afectados de classificação: 9 testes / 397 asserções, passados. Compilação final Vite 8.3.5 passou. Não se alteraram ferramentas ou dependências, não se repetiu o cálculo fiscal como nova validação.

Cobertura nova inclui separação de funções; recusa e nova versão; submissão/decisão antigas; repetição de comandos com conflito de conteúdo; herança e excepções pendentes/recusadas/futuras; início de vigência; sobreposição e substituição explícita; mudança de categoria sem bypass pela edição do catálogo; conta agregadora; conta/plano incompatível; referências alheias; revogação no pedido seguinte; isolamento de unidades; transferência em massa e inserção directa cruzada; B1 preservado; data em falta; captura de classificação diferente da consultada recusada. Não houve implementação ou geração de lançamentos.

Prova concorrente adicional: dois processos PHP sobrepostos, um aprova e outro recusa a mesma versão. Um recebeu 200 e o outro 409; existe uma única decisão. Recibo da concorrência.

No Edge, instância http://127.0.0.1:8001, ligada apenas a sgf_tempo_test, sessão/cache isolados e CSRF activo. Login real com duas identidades sintéticas distintas, não actingAs como substituto da demonstração. Não se usaram contas reais ou operações fictícias na Tempo Lda. Registo da observação.

Percurso observado:

1. Login do preparador sintético → Empresa Horizonte — Demonstração → Unidade Central — Demonstração → Classificação contabilística.
2. Na categoria sintética aprovada, Preparar nova versão → alterar designação/condições → indicar início 01/11/2026 → seleccionar explicitamente a versão aprovada substituída → indicar fundamento → Guardar proposta em preparação → Submeter versão. Não havia controlos de validação para esse utilizador.
3. Consultar o serviço para 01/11/2026 enquanto a nova proposta aguardava validação: continuou a resolver a categoria v1 aprovada.
4. Sair; login da identidade sintética validadora → mesma empresa/unidade → consultar conteúdo fixo → motivo → Validar esta versão. Recusar outra proposta submetida com motivo. Não havia formulário de preparação, botão de correcção ou captura para a validadora. Prova visual.
5. Consultar o serviço em 31/10/2026: categoria v1. Em 01/11/2026: categoria v2 aprovada. Na secção de operações autorizadas, carregar a prestação sintética → Consultar histórico preservado: conservava a categoria v1 e referências originais, mesmo após a aprovação de v2. Histórico preservado.
6. Sair. A instância de prova foi encerrada; os testes seguintes só recriaram sgf_tempo_test. A aplicação normal manteve a sua ligação.

A guarda final de revisão foi validada por testes HTTP de aplicação: consultar, aprovar outra regra, tentar guardar a revisão antiga → 409; consultar novamente e guardar → sucesso; repetir o comando → mesmo resultado sem duplicação. A prova visual anterior continua a documentar preparação/decisão/vigência/histórico; não se atribui ao navegador uma demonstração posterior de gravação com o novo token de revisão.

Utilização normal

Actualizar a página/sessão após as concessões e seleccionar Tempo Lda. O menu Classificação contabilística aparece para ambos. Não é necessário seleccionar unidade para preparar/validar classificações empresariais; é necessária unidade autorizada para consultar ou guardar resoluções de operações.

Osmane prepara primeiro a versão documental/período do plano e submete; Samira confere e decide. Depois podem ser propostos e validados a conta empresarial documentada, categoria e ligação ao serviço. O sistema não resolve uma classificação por omissão enquanto faltarem aprovações compatíveis. Se a conta de movimento ou a aplicabilidade estiverem por confirmar, conservar pendência; não usar a referência 7.2 como substituto automático.

Para operação autorizada, escolher serviço e data → Consultar classificação. Para preservar a resolução, carregar operações da unidade, seleccionar a operação e Guardar resolução na operação. Se versão ou regras mudaram, consultar/rever antes de guardar; não tentar sobrescrever a história. Samira consulta resoluções sem receber poder de captura ou edição pela validação.

Ferramentas mantidas por caminhos explícitos no wrapper:

powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 test --stop-on-failure --filter=CatalogueAccountingTest
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 npm run build

Repetir a demonstração apenas por fluxo de testes: parar scripts/browser-proof.ps1 stop antes de recriar testes; partir de base de testes vazia produzida pelos testes; scripts/browser-proof.ps1 start, seguido de sgf.ps1 php scripts/accounting-fixture.php --env=testing. Preparadores recusam dados existentes e não os apagam para prosseguir. sgf.ps1 php scripts/accounting-concurrency.php --env=testing demonstra decisões concorrentes. As credenciais sintéticas ficam no ficheiro local protegido já usado pelo preparador e não são publicadas. A verificação de portas não termina processos de outro projecto. O uso de Bypass é apenas no processo PowerShell, sem alteração global.

Ficheiros deste incremento e limites

• Núcleo: app/Modules/Services/CatalogueAccounting.php, Http/CatalogueAccountingController.php e rotas.
• Interface: resources/js/CatalogueAccountingWorkspace.jsx, integração/legendas em app.jsx e estilos próprios em app.css.
• Migração: 2026_10_26_040000_create_catalogue_accounting.php.
• Testes: tests/Feature/CatalogueAccountingTest.php, tests/Support/CatalogueAccountingFixture.php.
• Ferramentas/provas: scripts/accounting-fixture.php, accounting-concurrency.php, accounting-concurrency-worker.php, accounting-preservation.php, catalogue-accounting-access.php e docs/proofs/accounting-*.
• Documentação: especificação, este relatório, AGENTS e README. Alterações preexistentes foram preservadas; nenhum checkpoint Git foi criado sem pedido.

Limites: referência histórica fornecida não comprova consolidação normativa actual; contas, datas e regras reais ainda precisam de propostas e validação de Samira. Apenas PGC-NIRF e o papel inicial de rendimento de serviço; sem motor de reconhecimento, diários, contrapartidas, stock/compras ou gestão geral de novas concessões. Sem lançamentos, alteração fiscal, publicação ou avanço para outro incremento. Este relatório não aceita entregas em nome do utilizador.