# Facturação e recebimentos — matriz de informação para revisão

Especificação posterior de 26 de Outubro de 2026: [primeiro cálculo de factura de serviço](SERVICE_INVOICE_CALCULATION_SPEC.md), com caso mínimo, fórmulas, precisão, arredondamento/reconciliação, fontes oficiais parcialmente verificadas e lacunas explícitas. Apenas proposta, sem activação de taxa ou autorização de emissão.

Plano posterior de 26 de Outubro de 2026: [pré-visualização de rascunho de factura de serviço](DRAFT_INVOICE_PREVIEW_PLAN.md), com apresentação provisória, critérios, decisões e fontes ainda necessárias. Apenas proposta; preserva a preparação entregue e as bases aceites, sem autorização de implementação ou emissão.

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

Estado: especificação apenas. O utilizador indicou que os três exemplos representam informação a contemplar nas facturas e recibos. Isso define uma referência de conteúdo pretendido, não a obrigatoriedade universal de todos os campos nem a validade fiscal dos modelos. Não autoriza implementação, emissão, recebimentos, contabilização, alterações de permissões ou publicação.

Actualização posterior: o utilizador autorizou um incremento delimitado de preparação documental, incluindo dados de emitente/clientes, preparação dos rascunhos e instruções de pagamento do emitente reutilizáveis. Banco/titular/identificadores/moeda/instruções facilitam o pagamento; não perguntam como o cliente vai pagar e não criam recebimento. Foram autorizados por prompt de execução próprio, com confirmação específica das novas concessões. A execução está documentada em [DOCUMENT_PREPARATION_DELIVERY.md](DOCUMENT_PREPARATION_DELIVERY.md). As restantes propostas desta matriz continuam sujeitas a validação e autorização, sem emissão fiscal, recebimento ou contabilização.

Preservar B1 aceite e o checkpoint `8fcd52c`, A (`ca13acb`) e identidade (`26b80df`). As fotografias B1 mantêm o significado «Confirmado internamente — sem validade fiscal». Esta revisão não lhes acrescenta validade, dados ou efeitos retrospectivos.

## Fontes e grau de validação

| Referência | Utilização nesta revisão | Limite |
| --- | --- | --- |
| SGF_TEMPO_Roteiro_v0_9.docx; SERVICES_WORKFLOW_SPEC.md; SERVICES_B_SCOPE.md | Reutilização de dados, distinção entre acontecimentos, captura permanente e pendências | Requisitos de produto e propostas; não são legislação fiscal |
| SERVICES_A_DELIVERY.md e SERVICES_B1_DELIVERY.md, entregas aceites | Fundação existente: cadastro mínimo, rascunhos, decimais exactos e fotografia interna | Não incluem emissão fiscal ou recebimento |
| E1 — Factura.jpg | Na imagem é um **recibo Tempo**, n.º 10, série 2026; linha refere **FT 10/2026** | O nome do ficheiro não determina o tipo documental |
| E2 — Factura.png | **Factura-recibo TVCABO**, n.º 219144 / FR26; detalhe de serviço e informação de pagamento | Exemplo de conteúdo de outro emitente; não define regras para a Tempo |
| E3 — Sem título.jpg | **Factura Tempo FT 11/2026**, com linhas, imposto e condições de pagamento | Não é a factura referenciada pelo recibo E1 |
| Esclarecimento do utilizador nesta sessão | Os exemplos mostram informação que deve ser contemplada em facturas e recibos | Campos aplicáveis por documento/regime ainda carecem de delimitação |

Os exemplos foram lidos visualmente. Não foram copiados para o repositório nem transformados em operações/fixtures. Não transcrever números de contas, referências de pagamento ou assinaturas reais como configuração ou valores por omissão. Texto ambíguo numa imagem deve ser conferido no original, nunca completado por suposição.

**Fontes legais já validadas nesta tarefa: nenhuma.** Não foram fornecidos ou validados diplomas, orientações oficiais ou pareceres aplicáveis ao regime, período e operações da empresa. Esta matriz propõe informação e validações técnicas; antes de chamar um campo obrigatório por lei, associar-lhe fonte oficial, artigo, vigência, aplicabilidade e validação do responsável competente. A taxa observada nos exemplos não constitui validação da taxa aplicável.

## Tipos documentais e acontecimentos

| Tipo | Significado funcional proposto | Ligações necessárias | Não inferir |
| --- | --- | --- | --- |
| Factura | Documenta a facturação de bens/serviços segundo requisitos a validar | Empresa/unidade, cliente, linhas, origens e versão; recebimentos por afectação posterior | Que o serviço foi executado, que houve recebimento ou que ocorreu reconhecimento contabilístico |
| Recibo | Documenta um recebimento identificado e as suas afectações, conforme âmbito a validar | Identidade própria, recebimento(s), documento(s) abrangidos e montante de cada afectação | Que o número do recibo é o da factura; que montante igual identifica a factura; que a emissão confirma liquidação bancária |
| Factura-recibo | Representa conjuntamente facturação e recebimento no caso expressamente admitido e aprovado | Identidades dos dois acontecimentos e afectações explícitas, mesmo com uma apresentação conjunta | Que qualquer factura se torna paga ao ser emitida, ou que se pode contar novamente o recebimento num recibo separado |

Admissibilidade, momento de emissão e condições de utilização de cada tipo são pendências legais/operacionais. Uma factura-recibo não elimina a separação interna entre documento, recebimento, afectação e eventual lançamento contabilístico.

## O que os exemplos mostram

- E1: recibo emitido em 15/10/2026, com campo de vencimento também em 15/10/2026; a linha refere FT, série 2026, n.º 10, emitida em 09/08/2026 e com vencimento em 10/08/2026. Mostra valor e valor pago de 6 744,24, pendente 0,00 e total em MZN. As datas do cabeçalho são distintas das datas da factura referida. Não adoptar um vencimento de recibo por ser um campo existente no modelo.
- E3: FT 11/2026, emitida em 12/10/2026, vencimento em 12/11/2026; condição impressa «Pagamento em 30 dias». Preservar ambos os dados observados e sinalizar a compatibilidade para revisão; não deduzir uma convenção de contagem nem corrigir silenciosamente a data. Descrição «Aluguer de Servidor Novembro», quantidade 1, unidade UN, preço/base 5 814,00, imposto apresentado 930,24 e total 6 744,24 MZN. O mês na descrição não fornece, por si só, um período exacto de serviço ou uma data de reconhecimento.
- E2: preço apresentado 2 380,00, IVA identificado como «16 % Inc.», base apresentada 2 051,72, imposto 328,28 e total 2 380,00. O período de serviço indicado é 25/10/2026–23/11/2026; a emissão é 15/10/2026 às 10:50. Traz contrato, pedido de adesão, morada de instalação, indicação de pagamento VISA e extracto de conta. Estes campos têm funções diferentes e não devem tornar-se requisitos universais.
- E1 e E3 têm o mesmo montante, mas identidades diferentes: **o recibo E1 não liquida FT 11/2026**. FT 10/2026 não foi fornecida como documento autónomo; apenas a sua referência aparece no recibo. A associação de E1 a FT 10/2026 fica registada como referência observada, sem inventar o conteúdo da factura ausente.
- «Original», «Duplicado», carimbos, assinaturas e anotações manuscritas são elementos observados de apresentação/evidência. Não provam, por si só, validade legal, autoria electrónica ou data efectiva do recebimento. Uma anotação de entrega/recepção do papel não substitui a data do recebimento financeiro.

## Convenções da matriz

**Base a validar** significa candidato a informação documental, não obrigação legal já aprovada. «Exigir» abaixo refere-se à proposta funcional no momento indicado, sujeita a fechar as decisões. FT = factura; RC = recibo; FR = factura-recibo. «Fotografia: sim» significa conservar o valor utilizado no acontecimento futuro, com origem/versão, sem alterar as fotografias B1 já existentes. Informação desconhecida fica pendente; não vira vazio validado, zero ou valor por omissão.

### 1. Base de facturação a validar legalmente

| Campo | Origem / reutilização | Momento em que se propõe exigir | Validação proposta / pendência | Fotografia histórica |
| --- | --- | --- | --- | --- |
| Identidade técnica do documento e tipo | Servidor; catálogo de tipos suportados | Criação do registo documental | ID estável; tipo permitido e âmbito explícito; referência interna B1 nunca vira número fiscal | Sim, identidade e tipo |
| Tenant, empresa emitente e unidade | Contexto e cadastros existentes | Desde o rascunho | Contexto autorizado, unidade da empresa; sem transferência por formulário ou SQL em massa | Sim, IDs e identificação usada |
| Denominação do emitente | Cadastro da empresa | Preparação documental; completude antes de eventual emissão | Reutilizar nome; distinguir designação interna de denominação legal a validar | Sim, nome utilizado e versão |
| Identificação fiscal do emitente (NUIT) | Cadastro futuro da empresa | Antes de eventual emissão, se aplicável | Formato, validade e obrigação dependem do regime/fonte; não inferir do nome ou de exemplos | Sim, se utilizada |
| Morada/localidade/país do emitente | Cadastro da empresa/unidade, conforme papel aprovado | Antes da emissão quando aplicável | Distinguir sede, estabelecimento e local da operação; conteúdo exigível por validar | Sim, dados efectivamente usados |
| Identidade do cliente e nome/denominação | Cadastro de cliente existente | Nome basta para iniciar rascunho; identidade estável desde a associação | Não duplicar por unidade; cadastro mínimo não significa aptidão para emissão | Sim, ID, nome e versão |
| NUIT do cliente / identificação alternativa admitida | Cadastro de contraparte, a especificar | Antes da emissão nos casos aplicáveis | Condições por tipo de cliente/operação, formato e alternativas por validar; não exigir por suposição em todo rascunho | Sim, valor e tipo usados |
| Morada/localidade/país do cliente | Cadastro da contraparte | Antes da emissão quando aplicável | Não confundir morada fiscal, correspondência e instalação; requisitos por validar | Sim, papel e valor usados |
| Série, número e identificação legível | Mecanismo documental futuro, por empresa/tipo e regras aprovadas | No momento de atribuição legal a definir | Unicidade, sequência, exercício/série, concorrência, lacunas e momento de atribuição pendentes; não copiar FT/FR26 como convenção universal | Sim; separado do ID técnico |
| Data/hora de emissão | Operação documental futura | Emissão; não preencher como emissão real no rascunho | Fuso, data admissível e retroactividade por validar; não usar instante B1 como emissão | Sim, data e referência temporal |
| Origem: prestação/rascunho/documento e versão | Relações existentes de A/B1 | Preparação e fixação documental | Mesma empresa/unidade; versão actual, origem válida; múltiplas/parciais dependem de decisão | Sim, IDs e versões |
| Serviço/artigo e código utilizado | Catálogo empresarial existente | Escolha da linha; completude documental | Reutilizar serviço; código do exemplo não é chave universal; não criar stock por haver coluna «Artigo» | Sim, ID, código se usado, nome e versão |
| Descrição da linha | Catálogo, prestação e eventual complemento autorizado | Preparação; completa antes de confirmação/emissão correspondente | Descrição inteligível; preservar complemento sem reescrever cadastro partilhado | Sim |
| Quantidade | Prestação/rascunho | Pode ficar pendente em A; completa na confirmação B1 e preparação documental completa | Decimais exactos; sem coerção/arredondamento; regras para casos negativos/correcções fora deste âmbito | Sim |
| Unidade de medida | Referência parametrizável futura do serviço/linha | Quando necessária à interpretação/emissão da linha | Não presumir UN; vocabulário e obrigatoriedade por operação a validar | Sim, código e significado usados |
| Preço unitário e moeda do preço | Rascunho/acordo de serviço | Preparação dos valores; emissão exige definição aplicável | Precisão de A preservada; moeda desconhecida não é MZN; não apresentar valor definitivo sem moeda definida | Sim |
| Modo de preço: imposto incluído ou acrescido | Escolha/regra aprovada e versionada | Antes de apurar base/imposto/total para emissão | Explícito; não inferir do montante ou do formato da impressão; A/B1 ainda não definem esse modo | Sim, modo e regra |
| Moeda documental | Regra/indicação aprovada para o documento | Pode ser desconhecida em A/B1; definir antes de emissão monetária | Código e aplicabilidade; não inferir moeda funcional, câmbio ou política fiscal | Sim; desconhecimento B1 permanece preservado |
| Base tributável por linha e por tratamento | Cálculo futuro segundo regras aprovadas | Apuramento documental | Separar quantidade × preço, descontos, base e incidência; base aritmética de A não é automaticamente base tributável | Sim, componentes e regra |
| Tratamento fiscal, taxa e fundamento | Regra fiscal versionada, validada para empresa/operação/data | Apuramento/emissão quando aplicável | Distinguir tributado, isento, não sujeito ou outro tratamento aprovado; desconhecido nunca equivale a taxa zero | Sim, classificação, taxa/fundamento e versão |
| Montante de imposto e resumo por tratamento | Cálculo futuro | Apuramento/emissão | Escala, modo e ponto de arredondamento a validar; reconciliar linhas/resumo; não somar moedas distintas | Sim, cálculo e resultados aplicados |
| Total documental | Cálculo das componentes aprovadas | Antes de emissão | Base + imposto e demais componentes apenas conforme regra; explicável pelas linhas; não converter B1 em total fiscal | Sim |
| Autor, instante e versões de dados/regras | Sessão e servidor; referências versionadas | Em cada acto relevante | Autor real e autorização; nenhum privilégio associado ao rótulo impresso «admin» | Sim; sem tokens ou segredos |

### 2. Requisitos condicionais por documento/operação

| Campo / condição | Origem | Momento em que se propõe exigir | Validação proposta / pendência | Fotografia histórica |
| --- | --- | --- | --- | --- |
| Vencimento (FT; outros tipos só se houver significado aprovado) | Condições acordadas + data, ou indicação autorizada | Preparação de cobrança/emissão quando aplicável | Distinto da emissão; convenção de dias, excepções e alterações a aprovar. Campo de vencimento do RC E1 não o torna universal | Sim, vencimento original; mudanças futuras rastreáveis |
| Condições/prazo de pagamento (FT) | Acordo/parametrização empresarial versionada | Preparação documental | Coerência com vencimento; não impor «30 dias»; explicitar divergências, sem corrigir silenciosamente | Sim |
| Data/período da prestação | Prestação/acordo de serviço | Quando aplicável ao serviço/documento | Separar início/fim, execução, emissão e competência; não extrair período exacto da palavra «Novembro» | Sim, quando utilizado |
| Desconto comercial/financeiro, em taxa e/ou valor | Acordo e regra aplicável | Se existir desconto | Explicitar por linha/documento, ordem, base e efeito no imposto; zeros dos exemplos não aprovam regra | Sim, componentes e regra |
| Motivo/código de isenção ou outro tratamento | Classificação fiscal validada | Quando esse tratamento for utilizado | Fonte, condições, prova e texto exigível por validar; ausência de imposto não prova isenção | Sim, fundamento e versão |
| Adiantamentos, outras contribuições, encargos/outros serviços | Operação de origem e classificação futura | Apenas se ocorrerem e forem incluídos | Não usar campos genéricos para ajustar total; identidade, sinal, moeda e tratamento próprios; evitar dupla contagem | Sim, se integrarem o documento |
| Identidade do recebimento (RC/FR) | Registo futuro de recebimento, distinto do documento | Antes de documentar um recebimento | Não iniciar transferência; distinguir registo, evidência e verificação; novas regras/permissões por aprovar | Sim, ligação e estado observado |
| Data/hora do recebimento (RC/FR) | Acontecimento e evidência de recebimento | Registo/documentação do recebimento | Separar da emissão do recibo, data bancária, registo no sistema e anotações manuscritas | Sim, datas e proveniência |
| Montante recebido e moeda (RC/FR) | Recebimento identificado | Antes de produzir comprovativo | Positividade/precisão, moeda e evidência conforme regras a aprovar; montante declarado não comprova liquidação externa | Sim |
| Meio de recebimento (RC/FR) | Registo/evidência; catálogo a delimitar | Quando documentado o recebimento e conforme operação | VISA é um exemplo, não fornecedor escolhido; não guardar números completos de cartão ou credenciais | Sim, classificação e referência não secreta necessária |
| Referência/evidência da transacção (RC/FR) | Fonte observada/documento comprovativo | Conforme meio e critérios de verificação aprovados | Identificador contextual, origem, acesso e duplicados; QR/referência para pagar não prova que houve pagamento | Sim, ID da evidência/estado; acesso ao original protegido |
| Documentos afectados: tipo, identidade, série e número (RC/FR) | Referência explícita e documento de origem | Antes de confirmar a afectação | Empresa, contraparte, moeda e documento exactos; FT 10/2026 não é FT 11/2026 | Sim, identidade e referência utilizada |
| Valor de cada afectação (RC/FR) | Relação recebimento ↔ documento | Ao distribuir o recebimento | Uma identidade por afectação; controlar montante disponível, saldo elegível e repetição; casos de excedentes/câmbio dependem de regra | Sim, montante, moeda e origem |
| Valor do documento, pago e pendente à data (RC/FR ou extracto) | Documento e afectações elegíveis no instante | Apresentação do comprovativo/extracto | Não editar livremente; distinguir afectação actual de acumulado; preservar data de corte e não confundir com saldo actual | Sim, se apresentados; valores actuais em consulta separada |
| Conteúdo conjunto de facturação e recebimento (FR) | Documento + recebimento + afectação | Só no caso de uso FR aprovado | Completude de ambos, identidade/correlação, atomicidade e repetição; não contar outra dívida ou outro recebimento pela mesma operação | Sim, ambos e suas relações |
| Original/duplicado, exemplar/página e reimpressão | Política de apresentação/reprodução a aprovar | Representação documental futura | Uma reprodução não cria outra emissão/recebimento; etiquetas e exigências legais por validar | Documento e metadados de reprodução, se aplicáveis |
| Identificação do software/textos legais/certificação | Configuração e requisitos oficialmente validados | Se exigíveis na representação/emissão | Não copiar «processado por computador» ou licença de outro sistema como prova de conformidade | Sim, texto/versão aplicados, se usados |

### 3. Informação adicional parametrizável para gestão/estatísticas

Esta classificação é provisória: um campo pode mudar para condicional se um contrato, actividade ou fonte legal validada o exigir. Não construir agora um motor geral de parâmetros nem tornar todas estas colunas obrigatórias.

| Campo | Origem | Quando exigir | Validação proposta | Fotografia histórica |
| --- | --- | --- | --- | --- |
| Número interno do cliente | Identidade/código do cadastro na empresa | Se usado em pesquisa ou apresentação | Unicidade no âmbito definido; não substituir ID técnico, NUIT ou associação documental | Sim, se impresso/utilizado |
| Contrato e pedido de adesão/encomenda | Referências empresariais futuras | Só para operações que os utilizem | Mesma empresa/contraparte; referência externa com emissor; não implementar contratos recorrentes por causa de E2 | Sim, ligação e referência usadas |
| Morada/local de instalação ou prestação | Cliente/contrato/local da operação | Serviços que precisem dessa distinção | Separar de morada fiscal e de unidade interna; não duplicar o cliente | Sim, se relevante/mostrado |
| Renovação/vigência do contrato/serviço | Acordo e acontecimento próprio | Se houver serviço com vigência | Não derivar automaticamente de emissão ou pagamento sem regra; estado de renovação distinto do recebimento | Sim, informação apresentada |
| Loja/local de atendimento, vendedor e operador | Contexto/identidades e actividade comercial | Conforme necessidade de análise | Loja externa de E2 não corresponde automaticamente à unidade SEGI; operador não significa administrador | Sim, ID/nome usado quando documentado |
| Telefone, email, website e apoio ao cliente | Cadastros/configuração empresarial | Se escolhidos para comunicação/apresentação | Não exigir como dados fiscais por suposição; não copiar contactos de exemplos | Sim, se fizerem parte do documento fixado |
| Logótipo e elementos visuais | Identidade visual configurada | Se usados na representação | Sem alterar significado/tipo; distinguir marca e denominação legal | Versão/activo utilizado, se renderizado |
| Capital social e outros dados institucionais | Cadastro validado do emitente | Se aplicáveis e escolhidos/exigidos | Obrigatoriedade e actualidade por validar; não usar valor de E2 como configuração | Sim, se apresentados |
| Dados bancários, entidade/referência e instruções de pagamento | Configuração própria autorizada | Quando forem apresentadas instruções | Titularidade, moeda, finalidade e controlo de acesso; não importar contas/referências dos exemplos nem pedir credenciais | Sim, dados comunicados naquele documento; segredos excluídos |
| Valor por extenso | Derivado do valor e moeda apresentados | Se adoptado ou exigido após validação | Concordância com montante, moeda, língua e precisão; não é valor independente editável | Sim, se apresentado |
| Observações | Registo autorizado ligado à operação | Se necessário | Não substituir campos estruturados, fundamento fiscal ou decisão; limitar informação pessoal | Sim, texto fixado no documento |
| Extracto: documentos, movimentos, saldo anterior/actual | Consulta derivada de origens e afectações | Se for incluído como informação adicional | Data de corte, sinais, moeda e estados; linhas positivas/negativas de E2 não são prova do plano contabilístico nem novos recebimentos | Sim, se incorporado na representação; não substituir origens |
| Carga/descarga, local e hora | Operação logística, se existir | Só actividade com necessidade identificada | Não impor a serviços por aparecer no template E3; não presumir entrega efectiva | Sim, se utilizados |
| Assinatura, carimbo, recepção do documento e anexos | Evidência específica, não sessão de login | Se existir procedimento aprovado | Distinguir recepção do papel, autorização, recebimento financeiro e assinatura válida; retenção/acesso por aprovar | Referência e metadados da evidência; original protegido |
| QR, portal do cliente, publicidade e rodapé comercial | Configuração de apresentação | Opcional, se autorizado | QR pode ser ligação/instrução, não prova de pagamento; nenhum fornecedor/portal escolhido nesta revisão | Versão do conteúdo/activo, se apresentado |
| Etiquetas analíticas (actividade, centro de custo, projecto, canal) | Referências parametrizadas futuras | Só se houver finalidade de gestão aprovada | Vocabulário e âmbito definidos; não inferir contas nem construir dimensões sem necessidade | Sim se usadas para explicar/classificar a operação; alterações futuras versionadas |

## Preço, imposto e total: significado a explicitar

O preço de A/B1 é um preço proposto sem modo fiscal aprovado. Esta revisão não o converte retroactivamente em preço com imposto incluído ou acrescido.

- **Acrescido:** num exemplo artificial com uma só taxa, sem descontos/encargos, base = quantidade × preço sem imposto; imposto = base × taxa; total = base + imposto, sujeito à política de cálculo ainda por validar. E3 mostra 5 814,00 + 930,24 = 6 744,24, compatível aritmeticamente com 16% acrescido. Isso não determina o regime/taxa aplicáveis a outra operação.
- **Incluído:** no mesmo caso simplificado, preço bruto = base + imposto; para taxa r, base exacta = bruto ÷ (1 + r), antes da política de arredondamento aprovada. E2 apresenta 2 051,72 + 328,28 = 2 380,00 e explicita imposto incluído. A divisão exacta de 2 380 por 1,16 tem mais casas que as impressas; a imagem não revela o algoritmo, ponto ou modo de arredondamento.
- Descontos, múltiplos tratamentos, encargos, adiantamentos, câmbio e eventuais retenções precisam de regras próprias antes de integrar os cálculos. Não inferir a sua aplicabilidade, sinal ou incidência da presença de um campo num modelo.
- Guardar valores de entrada, modo, resultados e versões das regras aplicadas. Escala de armazenamento, precisão de cálculo, arredondamento por linha/documento e apresentação são decisões diferentes. Não inferir «duas casas em todos os cálculos» das duas casas impressas.
- Nunca somar montantes de moedas distintas nem apresentar uma soma de preços sem moeda como total monetário definitivo. Diferenças de arredondamento devem ser explicáveis segundo regra aprovada, sem ajuste silencioso.

## Identidade, recebimento e afectação

Modelo conceptual proposto, sem migração ou implementação nesta etapa:

1. Cada documento tem ID técnico estável e referência legível contextualizada por empresa, tipo, série e número. A série não é presumida como ano em todos os sistemas. A apresentação de E2 não determina como separar a série FR26 de outros identificadores.
2. O recebimento tem identidade própria, moeda, montante, datas, origem/evidência e estado. Um RC/FR liga-se ao acontecimento efectivamente documentado; não cria outro recebimento ao ser impresso, repetido ou importado.
3. A afectação tem ID próprio e liga recebimento a documento exacto com montante/moeda. Suportar conceitualmente pagamentos parciais e distribuição por documentos sem duplicação; a cardinalidade legal/operacional de recibos, recebimentos e adiantamentos deve ser aprovada antes de implementar.
4. Controlar, conforme política aprovada, soma das afectações por recebimento e saldo elegível do documento, concorrência e idempotência. Repetição de importação/referência não identifica automaticamente a operação sem fonte e âmbito. Excedentes, diferenças cambiais e correcções permanecem pendentes.
5. Documento com referência externa ainda não resolvida fica pendente. Em E1, conservar «FT / 2026 / 10» e procurar apenas essa identidade no âmbito certo. Sem FT 10/2026 disponível, não associar FT 11/2026 nem criar uma factura completa fictícia.
6. Em FR, ligar explicitamente o componente documental, o recebimento e sua afectação. Se for aprovado um caso de recebimento integral imediato, garantir atomicidade e repetição segura sem duplicar efeitos num recibo separado. A imagem, por si só, não aprova o caso de uso nem comprova reconciliação externa.
7. Saldo operacional, evidência de recebimento, emissão fiscal e contabilização são estados distintos. Extracto ou total pendente zero não demonstra reconciliação bancária ou conformidade contabilística.

## Decisões pendentes

| Decisão | O que é necessário fechar |
| --- | --- |
| Fontes legais e responsável pela validação | Regime da empresa, tipos documentais admitidos, operações/períodos abrangidos, fontes oficiais com vigência/artigos e validação fiscal competente |
| Campos obrigatórios por tipo/caso | Denominação, NUIT, moradas, identificação de cliente particular/empresa, dados do serviço, textos e eventuais excepções; separar mínimo de rascunho e aptidão para emissão |
| Identidade documental e representação | Séries/numeração, atribuição, sequência/lacunas, data/hora, exemplares, duplicados, software/certificação, impressão e arquivo quando aplicáveis |
| Preços e descontos | Modo incluído/acrescido por âmbito aprovado, descontos, encargos, incidência, taxas/fundamentos, moeda e arredondamento; não adoptar valores dos exemplos como regra |
| Datas e condições | Emissão, vencimento, prazo/convenção de dias, período do serviço e datas de recebimento; tratamento da divergência entre prazo e data sem alteração silenciosa |
| Recibo e factura-recibo | Condições de utilização, data, meios/evidências, referência da factura, recebimentos parciais/múltiplos, adiantamentos, excesso e prevenção de dupla documentação |
| Gestão e estatísticas | Quais campos adicionais devem existir no primeiro caso de uso, quais aparecem no documento e quais ficam só em consulta; evitar cadastro obrigatório excessivo |
| Fotografia e protecção de dados | Conteúdo fixado, versões, retenção/acesso às evidências, elementos visuais e tratamento posterior sem alterar origem; nenhum segredo no histórico |
| Permissões futuras | Quem prepara/verifica dados, emite, regista recebimento, afecta ou gere esses poderes; direitos de A/B1 não os concedem; aplicações exigem confirmação própria |
| Contabilidade | Plano de contas, reconhecimento, moeda funcional, câmbio, datas/períodos e regras de processamento continuam pendentes; não são resolvidos pelo layout dos exemplos |

## Próximo incremento pequeno proposto — preparação e verificação documental

**Proposta para aprovação, sem execução autorizada:** enriquecer apenas os cadastros e a preparação do rascunho com o subconjunto de campos que vier a ser aprovado, e mostrar uma verificação de completude documental separada da confirmação interna B1.

Antes do prompt de implementação, aprovar: (a) primeiro tipo/caso de uso, propondo FT de serviço pontual; (b) lista exacta de campos e origem, incluindo denominação/morada/identificação fiscal nos casos validados; (c) datas/período/condições necessários; (d) como registar o modo de preço proposto e as pendências de moeda/imposto, sem motor fiscal; (e) permissões de edição desses novos dados, sem herança presumida. Recibos e FR ficam especificados, mas não implementados nesse pequeno incremento.

Resultado verificável proposto: reutilizar o cliente criado só com nome, completar os dados aprovados uma vez, seleccionar esse cliente num novo rascunho e mostrar «dados por completar», «dados preenchidos, validação pendente» ou outro rótulo aprovado. **Nenhum estado deve dizer «apto para emissão fiscal» enquanto faltarem regras/fontes validadas.** Não emitir, numerar fiscalmente, produzir PDF de factura, receber, afectar valores ou contabilizar.

Manter os documentos B1 existentes imutáveis; enriquecimento posterior dos cadastros não lhes acrescenta dados. Se for necessária uma fotografia mais rica em operações futuras, especificar nova versão do esquema, compatibilidade e migração aditiva antes de implementar. Não reconstruir ou promover confirmações B1 aceites a facturas.

Provas futuras desse incremento: reutilização sem duplicação de clientes; campos condicionais sem bloquear o início do rascunho; desconhecido distinto de zero/preenchido; datas distintas; acesso cruzado recusado; fotografia B1 inalterada; nenhuma emissão, novo recebimento ou lançamento. Só preparar o prompt executável depois de aprovado este subconjunto e os direitos correspondentes.