# Entrega B — delimitação para revisão

Complemento documental de 26 de Outubro de 2026: [matriz de facturação e recebimentos](BILLING_DOCUMENTS_FIELD_SPEC.md), 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.