SGF/docs/SERVICES_B_SCOPE.md

Entrega B — delimitação para revisão

Complemento documental de 26 de Outubro de 2026: matriz de facturação e recebimentos, com campos, origens, momentos, validações e fotografia histórica. B1 mantém-se aceite no checkpoint 8fcd52c. O complemento apenas especifica informação com base em exemplos; não autoriza o restante B/C ou publicação.

Data: 25 de Outubro de 2026 (Africa/Johannesburg).

Estado: proposta de âmbito; não autoriza implementação, migrações, novas concessões, emissão fiscal ou publicação. Base: SERVICES_WORKFLOW_SPEC.md e entrega A aceite em SERVICES_A_DELIVERY.md, checkpoint local ca13acb, antecedido por 26b80df. A permanece encerrada e não é reaberta nesta revisão. Este documento não constitui validação jurídica, fiscal ou contabilística.

Actualização posterior: o utilizador autorizou exclusivamente B1 — confirmação interna, fotografia imutável e captura das pendências — pelo prompt anexado em 25 de Outubro de 2026. A confirmação interna não é emissão comercial/fiscal, reconhecimento ou contabilização. Moeda/tratamento fiscal desconhecidos ficam preservados e não bloqueiam, por si só, esta confirmação interna. A permissão específica foi conferida e confirmada separadamente antes da concessão. Ver SERVICES_B1_DELIVERY.md. As restantes propostas e pendências de B abaixo continuam sem autorização de implementação.

Regras já validadas que B deve preservar

Regra	Consequência para B
Tenant, empresa e unidade distintos; contexto e permissões explícitos	Confirmar ou processar exige autorização própria; os direitos de A não bastam. A pertença ao tenant não concede acesso às empresas.
Clientes e serviços da empresa; rascunhos da unidade	Reutilizar as origens existentes, sem duplicar cadastros ou transferir registos entre âmbitos.
Prestação, documento e recebimento são acontecimentos distintos	Confirmar um documento não confirma automaticamente a execução do serviço, não recebe dinheiro nem liquida saldo.
Histórico e captura durável transaccionais desde A	Consumir acontecimentos preservados, sem reconstruir o passado a partir do último estado do cadastro ou rascunho.
Decimais exactos e ausência de pressupostos fiscais	Não presumir moeda, imposto, contas ou arredondamento. A precisão de entrada de A não aprova uma política monetária/fiscal para B.
Idempotência, contexto/versionamento, auditoria e protecção SQL	Repetições e concorrência não podem duplicar confirmações, eventos ou efeitos contabilísticos.
Provas sintéticas apenas em sgf_tempo_test	Nenhuma demonstração na Tempo Lda/SEGI; manter a aplicação normal e os seus dados.

A arquitectura de contabilidade permanente e o processamento independente da contratação da interface comercial constam da especificação geral. Os mecanismos concretos abaixo ainda são propostas; não estão aprovadas regras de lançamento ou conformidade fiscal.

Âmbito mínimo proposto

1. Pré-validar uma versão exacta do rascunho: origens, dados, contexto, permissões, regras aplicáveis e pendências. Mostrar separadamente bloqueios documentais e bloqueios contabilísticos.
2. Confirmar documentalmente apenas quando os requisitos dessa operação estiverem aprovados e satisfeitos. Criar identidade própria e fotografia histórica imutável; não apresentar uma confirmação interna como factura fiscal sem validação específica.
3. Capturar confirmação, fotografia, auditoria, evento e trabalho durável atomicamente, reutilizando a base de A. Uma confirmação repetida da mesma origem deve recuperar o resultado; alteração de conteúdo/versão deve gerar conflito.
4. Processar eventos por consumidor repetível, com classificação explícita: sem efeito contabilístico justificado, pendente de regra/informação, falha técnica recuperável ou contabilizado segundo perfil aprovado.
5. Quando elegível, produzir lançamentos rastreáveis ao evento, documento e versão das regras, com débitos/créditos equilibrados segundo as regras aprovadas. Persistir o efeito e a marca de processamento na mesma transacção.
6. Permitir consulta do documento histórico, origens, pendências, tentativas e efeitos. Nenhum lançamento definitivo deve ser editável pelo formulário de rascunhos.

Não incluir recebimentos, afectações, correcções financeiras, anulações, reconciliação, fecho ou reabertura de períodos. Estas operações permanecem em C ou exigem delimitação própria. B não deve usar uma rotina de reversão improvisada para compensar decisões ainda pendentes.

Preservação histórica proposta

• A fotografia conserva os dados efectivamente utilizados: identificação das partes exigida pelo tipo documental aprovado, empresa/unidade, origem e versão, linhas, quantidades/preços, moeda, datas aplicáveis, cálculos e versões das regras. Só incorporar campos fiscais depois de definida a sua necessidade.
• Alterações posteriores do nome do cliente, serviço ou rascunho não alteram o documento confirmado. Ligações ao cadastro permitem navegação; não substituem a fotografia.
• Guardar separadamente datas de prestação, documento, registo e reconhecimento quando aprovadas; não inferir uma da outra. Guardar autor e instante de confirmação.
• Fotografias e eventos são imutáveis, com protecção também contra SQL em massa. O estado do consumidor fica em registos próprios, preservando os eventos/outbox append-only de A.
• Consumir eventos antigos de A com classificação explícita. Uma edição de rascunho não se torna receita por existir no outbox. Não alterar nem regenerar esses eventos para simular acontecimentos financeiros.

Pendências que impedem fechar o âmbito de implementação

Decisão necessária	Quem deve validar / efeito enquanto faltar
Significado de confirmação: interna, documento comercial ou emissão fiscal; tipos abrangidos	Utilizador, com validação fiscal competente quando aplicável. Sem definição, não implementar um botão ambíguo de confirmar/emitir.
Campos obrigatórios, identificação fiscal, datas, séries, numeração, unicidade, momento de atribuição e tratamento de falhas/lacunas	Validação fiscal/documental. Um identificador técnico não substitui numeração legal.
Regime, impostos, isenções, evidências e cálculo por linha/documento	Validação fiscal. Ausência permanece pendência, nunca taxa zero.
Moeda documental e funcional, eventual câmbio, escalas e política de arredondamento	Validação contabilística/fiscal. A aritmética exacta de A mantém-se; não converter automaticamente em totais fiscais.
Momento de reconhecimento e sua relação com prestação e documento; datas de competência	Validação contabilística. Confirmar documento não implica reconhecer receita automaticamente.
Plano de contas, classificações, dimensões, regras de débito/crédito e vigência das versões	Validação contabilística. Não inventar contas transitórias ou mapear nomes para contas.
Pode haver documento confirmado com contabilização pendente? Quais bloqueios impedem cada transição?	Utilizador e responsáveis contabilístico/fiscal. Proposta: separar estados e não chamar contabilizado ao que está apenas confirmado.
Período admissível e tratamento de eventos tardios ou datas não autorizadas	Validação contabilística. B deve respeitar restrições aplicáveis sem implementar o fecho de C.
Quem confirma prestação/documento, consulta contabilidade, processa/reprocessa ou gere estes poderes; eventual separação de funções	Utilizador. Novos acessos negados por omissão, sem herança dos direitos de A; aplicação efectiva exige confirmação específica.
Perfil sintético exclusivo de testes para demonstrar lançamentos e recuperação	Utilizador. Deve ser identificado como artificial, isolado de desenvolvimento e incapaz de activar regras reais. Não valida conformidade.

Não é necessário resolver agora as políticas de recebimento, reconciliação ou correcção de C. É necessário definir como impedir que uma confirmação de B seja posteriormente alterada por caminhos não autorizados.

Ecrãs mínimos propostos

• Pré-validação/confirmacão: versão e contexto explícitos, dados históricos a fixar, bloqueios e efeito exacto da operação.
• Documento confirmado: fotografia preservada, origem, identidade, datas e estado documental, sem edição directa.
• Acompanhamento contabilístico: evento, estado, motivos, tentativas e ligação aos lançamentos; reprocessamento apenas autorizado.
• Detalhe de lançamento: regra/versão, origens, moeda, débitos/créditos e evidência de equilíbrio, quando essas regras estiverem aprovadas.

Reutilizar navegação e contexto de A. Não disponibilizar botões financeiros simulados nem expandir o sistema de parâmetros para além dos dados necessários às regras aprovadas.

Provas de aceitação a exigir à implementação futura

1. Documento confirmado conserva a fotografia após alterações de cadastros e rascunhos; SQL em massa não a transfere nem reescreve.
2. Falta de configuração gera recusa ou pendência conforme a matriz aprovada, sem moeda/imposto/conta inventados.
3. Dois comandos concorrentes não confirmam duas vezes a mesma operação. Definir antes a relação permitida entre prestação e documentos; não presumir facturação parcial ou múltipla.
4. Consumidor repetido, concorrente ou interrompido antes/depois do commit não duplica efeitos. Falha técnica distingue-se de pendência de negócio e deixa evidência recuperável.
5. Cada lançamento liga-se ao evento e perfil versionado, é equilibrado nas unidades monetárias aprovadas e não se apresenta como definitivo com configuração insuficiente.
6. Eventos históricos de rascunho conservam o conteúdo e recebem classificação rastreável, sem receita artificial. Activar posteriormente a interface comercial não repete o processamento.
7. Direitos de A não autorizam confirmação/processamento; revogação produz efeito no pedido seguinte. Testar acesso cruzado entre empresas do mesmo tenant, unidades, URLs e tarefas.
8. Prova no navegador com login real sintético em instância isolada; suite e operações destrutivas apenas em sgf_tempo_test. Dados reais e checkpoint A preservados.

Próximo passo

Rever as decisões da tabela antes de redigir o prompt de execução de B. A primeira decisão é o significado da confirmação e se se pretende um ensaio exclusivamente sintético ou uma capacidade documental real com requisitos fiscais validados. A existência deste documento não concede autorização de implementação ou de novos acessos.

Aceitação posterior: em 25 de Outubro de 2026, B1 foi aceite no âmbito demonstrado de confirmação interna, sem validade fiscal nem lançamentos contabilísticos, com checkpoint Git exclusivamente local. O restante B/C continua sem autorização; não avançar nem publicar.