SGF/docs/SUPPLIER_PAYABLE_SCOPE.md

# Factura conferida → obrigação a pagar — primeiro recorte sintético

**Execução posterior, 29/10/2026:** [primeiro percurso implementado e provas](SUPPLIER_PAYABLE_DELIVERY.md). Cenário aprovado de execução: **10 000 + 1 600 = 11 600 MZN**, vencimento desconhecido. A marcação de «não implementado» e exemplos 1 160 MZN abaixo conservam o estado da especificação original; não substituem o relatório de execução. Sem aceitação operacional ou migração real.

29/10/2026. `COMMON-PAYABLE-SOURCE-SIM-v1`. **Conferência do existente e delimitação; não implementado nesta passagem.** Orientação expressa da Tempo: uma factura de fornecedor conferida origina uma obrigação, reutilizando os dados; sem pagamento, stock ou lançamento automático. O orçamento entregue e a avaliação da equipa continuam independentes.

**Especificação completada na mesma data:** secções 9–13 detalham a matriz de reaproveitamento, transição com pagamentos históricos, funções, estados e exemplo para confirmação. A orientação comum posterior da Tempo consta da secção 14 e prevalece sobre escolhas técnicas anteriores: vencimento desconhecido gera pendência documental, sem inventar data, apagar dívida ou se tornar, por inferência, uma regra universal que impeça reconhecer o principal. A passagem de responsabilidade é atómica e sem dois saldos activos. Mantém-se exclusivamente documentação nesta actualização.

## 1. O que já existe

Referências Compras relativas a `C:/laragon/www/compras`:

| Capacidade observada | Evidência | Consequência para o recorte |
| --- | --- | --- |
| Factura recebida por fornecedor/ordem, número normalizado e unicidade | `app/Services/InvoiceWorkflow.php::register`; `database/migrations/2026_10_28_000010_create_invoices.php`, unique tenant/fornecedor/número | Reutilizar o registo existente; não criar outro cadastro de factura ou redigitar fornecedor/montantes |
| Conferência exacta de linhas, preços, unidade, imposto e recepções aceites; parcial cumulativa | `InvoiceWorkflow::lines` e `validate` | Reutilizar a conferência; não recalcular documento com a política de IVA de vendas do SGF |
| Actor de validação distinto, revalidação transaccional e auditoria | `InvoiceWorkflow::validate`, `CurrentActor`, `ConflictGuard` | A origem deve identificar a decisão e a fotografia efectivamente conferidas |
| Consumo do compromisso na validação | `InvoiceWorkflow::validate` → `CommonBudget` → núcleo comum | A criação da obrigação não volta a chamar `consume`, reservar orçamento ou gerar stock |
| Factura/linhas preservadas | `app/Models/Invoice.php`, `InvoiceItem.php` | Não editar montantes/data/número da factura através da obrigação |
| Saldo a pagar implícito já existente | `ExternalPaymentWorkflow::outstanding`: total da factura menos pagamentos externos confirmados | É uma dívida já representada implicitamente. Criar uma segunda base independente de saldo produziria concorrência contabilística/funcional |
| Pagamentos externos, conferência, protecção por referência e validação bancária | `ExternalPaymentWorkflow.php` | Preservar; não refazer, executar ou ampliar pagamentos neste recorte |
| Condições de pagamento congeladas como texto na ordem | `PurchaseWorkflow.php`, `snapshot.quotation.payment_terms` | Texto reutilizável como evidência; não é uma data de vencimento estruturada nem autoriza interpretar automaticamente «30 dias» |
| Sem vencimento estruturado ou coluna de versão na factura inspeccionada | Migração 000010, `InvoiceController.php`, `Invoice.php` | Faltam complemento documental de vencimento e identificação explícita da revisão/fotografia da origem |
| Correcções de facturas/notas de crédito ainda fora do circuito entregue | Imutabilidade de `Invoice.php`; limites de `docs/validacao-tecnica.md` | Não inventar um circuito de correcção fiscal/monetária através de uma edição de obrigação |

No SGF, `ServiceReceivables` trata obrigações **a receber de clientes**, exclusivamente no âmbito demonstrado. Não é contas a pagar a fornecedores. `packages/budget-control` trata efeitos orçamentais e não cria dívidas. O novo serviço comum terá responsabilidade distinta, sem transformar estes módulos em outro motor de contas a pagar.

Esta conclusão resulta de leitura de código/migrações/documentação. Não se consultaram bases, credenciais ou dados reais, nem se executaram testes ou migrações nesta delimitação.

## 2. Capacidade comum e responsabilidade única

Proposta técnica: `Finance/Payables`, fonte única versionada, consumida por adaptadores locais de Compras e SGF. Pode ser um pacote separado do controlo orçamental; não duplicar o seu motor em `App/Services` e `App/Modules`. Mantém o princípio de duas composições comerciais sem obrigar a facturação de vendas SGF ou SGF remoto.

- **Compras:** conserva fornecedor, ordem, factura, linhas e decisão de conferência. O adaptador carrega esses dados da aplicação, revalida actor/organização/estado e prepara a origem normalizada. Não aceitar um total ou fornecedor alternativos enviados pelo browser.
- **Payables comum:** é o único proprietário da obrigação, do principal reconhecido neste recorte, do vencimento associado, das revisões documentais e do histórico. Importar não equivale a efectuar pagamento ou lançamento contabilístico.
- **Leitura de saldo em Compras:** para uma origem abrangida pelo novo núcleo, a base do saldo existente deve ser uma projecção da mesma obrigação. `outstanding()` não pode continuar a manter uma interpretação financeira independente dessa origem. Compatibilidade de leitura é parte da transição, sem desenvolver afectações/pagamentos novos.
- **Origem não abrangida:** o percurso existente mantém o comportamento anterior, sem migração/importação em massa. A existência de histórico não autoriza criar ou liquidar retroactivamente obrigações.
- **SGF:** adapta contexto tenant/empresa/unidade e permissões próprias. IDs de fornecedor/factura de Compras não são IDs de clientes, facturas de venda ou empresas SGF por igualdade numérica.

Antes de disponibilizar a obrigação, provar que as consultas para o documento abrangido apontam à mesma identidade/principal. Se o adaptador de leitura de saldo ainda não existir, a capacidade permanece pendente, não se apresenta uma segunda lista de dívidas como funcionalidade concluída. Nenhum comando de pagamento será disponibilizado no cenário novo deste recorte; os circuitos reais existentes não serão alterados por arrasto.

## 3. Dados reutilizados e dados efectivamente em falta

| Origem reutilizada automaticamente | Complemento necessário |
| --- | --- |
| Empresa/contexto, fornecedor e sua referência documental preservada | Correspondência explícita de contexto no host SGF, sem inventar unidade a partir do departamento |
| Identificador/número da factura, ordem, linhas, moeda, subtotal/imposto/total em centavos | Vencimento estruturado, evidência/base e revisão desse complemento |
| Estado `validated`, actor/data da conferência e histórico | Identidade da fotografia validada, incluindo conteúdo material e decisão |
| Condições textuais da ordem quando disponíveis | Confirmar a data sintética em falta; não deduzir calendário, tolerância ou prazo legal do texto livre |

Para a primeira prova: fornecedor fictício, factura fictícia efectivamente conferida pelo circuito Compras, **MZN**, valor proveniente da factura e vencimento explícito no complemento sintético. Pedir só o vencimento/evidência que não existem; não solicitar nova introdução do valor ou do fornecedor.

Não há coluna `invoice.version` entregue. Não atribuir silenciosamente «versão 1 validada» a um campo inexistente. Proposta: revisão de captura imutável no contrato de origem, com hash canónico do documento/linhas e referência da decisão de conferência. A revisão é do registo de origem do núcleo, com proveniência explícita; não simula versionamento nativo da factura. O adaptador deve detectar qualquer mudança material antes de reutilizar essa referência.

## 4. Identidade, repetição e atomicidade

Identidade canónica: organização explícita + namespace/instância da origem + tipo de documento + identificador estável da factura. Revisão/hash/decisão identificam a fotografia; **não** criar uma obrigação nova só porque apareceu outra revisão ou outro hash da mesma factura. Tenant/número da factura isolados não bastam como chave global; preservar também a unicidade comercial já existente em Compras.

Contrato de origem proposto: identificadores de organização/fornecedor/documento/ordem, referência/edição de captura, hash, moeda, total inteiro, decisão/actor/data da conferência, vencimento/complemento/evidência e indicação de ambiente sintético. Chaves técnicas de comando e identidade de negócio são distintas: comandos novos sobre a mesma origem continuam a resolver a mesma obrigação.

Uma transacção local deve revalidar permissões e a origem sob bloqueio, verificar estado/revisão, resolver unicidade e gravar obrigação/referências/histórico/resultado do comando atomicamente. A origem e a obrigação não dependem de publicação de eventos ou conector remoto para este recorte. Repetição idêntica devolve a mesma identidade; mesma chave com conteúdo diferente é conflito; resposta perdida é recuperável. Índices únicos e bloqueios devem impedir duas dívidas em pedidos concorrentes com chaves diferentes.

O total permanece em centavos exactos e MZN. Não alterar precisão, arredondamento cumulativo da factura ou IVA; não usar câmbio, valor líquido em vez do total devido ou zero como substituto de dados ausentes. A regra de emissão de venda SGF não intervém.

## 5. Pendências e correcções preservando o original

- Factura não conferida, identidade/organização incompatível, moeda não suportada, montante indeterminado, decisão não recuperável ou vencimento em falta: registar motivo e origem da tentativa como **pendente**, sem abrir outra dívida nem reconhecer valor zero.
- Repetir a mesma pendência não acumula dívidas. Completar o vencimento gera revisão do complemento e permite retomar a mesma origem; não revalidar genericamente a factura nem pedir os dados já válidos.
- Corrigir vencimento/evidência: revisão documental sucessora, com motivo, autor, referência à anterior e histórico; mesma identidade de obrigação, sem reescrever a factura ou aumentar o principal.
- Documento/hash materialmente diferente para a mesma identidade: conflito/pendência explícita. Não somar os dois totais nem substituir o principal por «última versão» automaticamente.
- Correcção de valor, fornecedor ou moeda após constituição: fora da execução inicial. Preservar original e sinalizar necessidade de circuito próprio de documento correctivo/revisão. Um novo exemplar sintético não fica automaticamente conferido. Não implementar estorno, nota de crédito, anulação ou baixa financeira por interpretação desta orientação.

As regras de autorização exactas para revisão documental serão explicitadas no contrato de implementação: reutilizar a elegibilidade de Finanças/consulta e os mecanismos de separação existentes; não acrescentar aprovadores empresariais universais. Para as provas, contas distintas de preparação/conferência/consulta, sem pessoas reais ou concessões reais.

## 6. Primeiro recorte e pontos de integração

1. Um fornecedor e uma factura MZN criados/conferidos pelas fixtures e serviços existentes de Compras, com histórico/orçamento necessários preparados em base QA isolada. Manter uma prova de que a nova ligação, depois da conferência, não acrescenta consumo orçamental ou stock.
2. Adaptador de origem Compras carrega a fotografia; núcleo comum resolve pendências e cria **uma** obrigação com valor/vencimento/origem/histórico. Consulta mínima permite recuperar a obrigação e explicar a sua proveniência.
3. Adaptador SGF demonstra a mesma capacidade comum em contexto sintético explicitamente mapeado. Não apresentar uma factura preenchida manualmente no SGF como demonstração da ligação à factura conferida de Compras.
4. Compatibilidade da leitura do principal/saldo do documento abrangido, sem implementar pagamento. Não extrair ou activar todo o `ExternalPaymentWorkflow` neste passo.
5. Tudo em bases QA novas/separadas das demonstrações da equipa. Sem alterar o núcleo orçamental aceite, as bases de desenvolvimento/produção, concessões ou dados reais. Migrações de implantação ficam propostas separadamente; sem importação automática de facturas antigas.

O gatilho pretendido é a conferência da factura. O desenho de implementação deve assegurar que uma falha na ligação não é apresentada como obrigação constituída: transacção local ou pendência recuperável e visível, conforme o recorte adoptado. Não marcar «a pagar no núcleo» antes de a gravação estar demonstrada. A falta de vencimento não apaga a conferência anterior nem volta a consumir orçamento quando a pendência é resolvida.

## 7. Provas a executar na implementação

| Cenário sintético | Evidência exigida |
| --- | --- |
| Factura conferida → obrigação | Mesmo fornecedor/total/MZN, vencimento explícito, decisão e revisão/hash recuperáveis; nenhum dado material redigitado |
| Repetição, chave diferente e dois pedidos simultâneos | Uma identidade de obrigação e um principal, com unicidade de origem reforçada na base |
| Resposta perdida/falha de histórico | Recuperação idempotente ou rollback; nenhuma dívida órfã ou confirmação fictícia |
| Factura pendente/incompleta ou vencimento ausente | Pendência explicada; sem dívida adicional/zero presumido; retomada conserva a conferência |
| Vencimento corrigido | Revisão sucessora e original recuperáveis; mesmo principal, sem segunda obrigação |
| Montante/hash/fornecedor/moeda incompatível | Conflito ou pendência, sem substituir/somar principal automaticamente |
| Leitura anterior e nova para a mesma origem | Mesmo principal/saldo derivado; nenhuma autoridade financeira concorrente |
| Outra empresa/unidade ou direito revogado | Recusa no servidor e na transacção, incluindo replay |
| Conservação dos efeitos anteriores | Contagens e valores orçamentais/stock/pagamentos/lançamentos antes/depois da ligação inalterados |
| Duas composições | Mesmo núcleo/contrato/resultados e origem comprovada; nenhum Sales obrigatório, motor duplicado ou SGF remoto |

As provas ainda não foram executadas neste recorte. Não repetir suites aceites por rotina: reutilizar o orçamento entregue e verificar apenas o delta de integração e as regressões afectadas. A avaliação da equipa em 8003 prossegue em paralelo, sem reset, alteração de contas ou pré-preenchimento desta nova capacidade.

## 8. Estado e continuação

Conferência e desenho concluídos documentalmente. `Finance/Payables`, complemento de vencimento, referência de revisão e adaptação da leitura de saldo **ainda por implementar**, sem migração proposta como já aplicada. Nenhum pagamento, movimento de stock ou lançamento foi criado nesta passagem. Não há nova aceitação funcional ou checkpoint.

Este documento delimita T2 no plano existente; não cria outra matriz global de requisitos. FIS-SGF-13/15/16 mantêm critérios/estados anteriores. A fronteira de correcção monetária e a ausência de vencimento/versionamento nativo são lacunas concretas identificadas, não motivo para reabrir o orçamento entregue ou depender de pessoas reais.

## 9. Matriz consolidada: existente, reutilização e lacuna

| Área | Existe hoje / ficheiros de origem | Reutilização no incremento | Falta / responsabilidade proposta |
| --- | --- | --- | --- |
| Documento de fornecedor | `InvoiceWorkflow::register`, `Invoice`, `InvoiceItem`, migração 000010 | Mesma factura, fornecedor, ordem, linhas e totais conferidos; sem novo cadastro | Adaptador de origem que entrega o documento normalizado a Finance/Payables |
| Conferência | `InvoiceWorkflow::validate`, `CurrentActor`, `ConflictGuard` | Decisão efectiva distinta do autor, revalidada sob bloqueio, com auditoria | Referência estável à decisão/fotografia e distinção explícita face ao reconhecimento no núcleo |
| Dívida e saldo | `ExternalPaymentWorkflow::outstanding` | Reaproveitar total da factura e pagamentos confirmados já associados; conservar resultado | Responsável financeiro explícito e leitor de compatibilidade; nenhuma segunda base de saldo |
| Pagamentos associados | `ExternalPayment`, `ExternalPaymentWorkflow::review`, migração 000012 | Preservar IDs, estado, montante, moeda, actor e histórico; apenas confirmados reduzem o saldo actual | Reconciliação/bindings na futura migração, sem executar ou copiar pagamentos como acontecimentos novos |
| Vencimento | Texto `snapshot.quotation.payment_terms` em `PurchaseWorkflow`; sem `due_on` na factura | Apresentar texto congelado como evidência, sem o reinterpretar | Complemento documental versionado com data explícita, origem/evidência e validação sintética |
| Revisão do documento | Factura e linhas imutáveis pelo percurso entregue; sem coluna `version` | Preservar original e hash material da fotografia validada | Referência da captura no contrato comum, sem fingir versão nativa ou incrementar a dívida por revisão |
| Autorizações | Perfil Finanças/empresa em Compras; memberships e acções empresa/unidade no SGF | Cada adaptador revalida as próprias permissões/contexto | Contrato de actor comum; correspondência explícita dos âmbitos, não equivalência automática |
| Idempotência | Unicidade comercial da factura; pagamentos com referência/hash | Manter restrições existentes | Unicidade da obrigação por origem estável e deduplicação também com chaves de pedido diferentes |
| Histórico | Auditoria Compras, imutabilidade dos modelos | Conservar evidência anterior e ligá-la, sem copiar dados bancários privados | Histórico append-only de tentativas, pendências, decisões e revisões do novo núcleo |
| Orçamento | Núcleo comum aceite, consumo na conferência | Reutilizar prova anterior e manter valores/movimentos | Nenhum efeito adicional na ligação; verificar delta zero |
| Stock e contabilidade | Stock já em Compras; lançamentos gerais não fazem parte desta ligação | Apenas verificar ausência de novos efeitos | Fora deste incremento, sem lançamento implícito nem duplicação de recepção |
| Duas composições | Arquitectura comum aprovada; adaptadores de orçamento já demonstrados | Mesmo padrão de fonte única e contratos locais, sem Sales obrigatório | Implementar Payables e adaptadores num recorte posterior, com QA próprio |

## 10. Origem exacta e contrato de reconhecimento

**Origem elegível:** registo `invoices` da mesma empresa, `status=validated`, `validated_by`/`validated_at` recuperáveis e decisão de auditoria correspondente; ordem emitida MZN e fornecedor/linhas/valores pertencentes ao mesmo contexto. Usar o exemplar efectivamente conferido, incluindo snapshot da contraparte na ordem, não a ficha corrente para reescrever a história. O adaptador deve recusar uma linha preenchida manualmente no SGF que apenas afirme ser «factura conferida de Compras».

O principal da obrigação é `invoices.total_minor`, com `subtotal_minor` e `tax_minor` preservados como componentes documentais. Não usar o subtotal de uma dotação sem IVA como valor devido ao fornecedor. Valores são inteiros em centavos MZN e vêm do servidor; não aceitar principal/fornecedor alternativo no comando de reconhecimento. Conservar arredondamento cumulativo da factura e não aplicar a política de IVA de vendas do SGF.

**Referência estável proposta:** `source_namespace` + `source_instance_id` persistente + `source_company_id` + `document_type=supplier_invoice` + `document_id`. A instância conserva identidade através de backup/restauro; clonar uma base para QA exige namespace de teste explícito, não alterar a identidade para contornar unicidade. A revisão não integra a chave que cria outra dívida: é uma fotografia sucessora da mesma origem. Manter ainda a identidade comercial empresa/fornecedor/número normalizado e, futuramente quando aplicável, edição/série documental. Um segundo ID local com a mesma identidade comercial fica em conflito para conferência, não gera outra obrigação nem é fundido automaticamente.

**Fotografia de origem:** número/data/ordem/fornecedor/empresa/moeda, componentes monetários e linhas materiais, referência da validação, actor/data e hash canónico. Ordenar campos/linhas por critérios estáveis; excluir token de sessão, chave de pedido, consulta actual, pagamentos posteriores e timestamps técnicos sem significado material do hash documental. Uma alteração desses campos técnicos não cria revisão material. A revisão de captura pertence ao núcleo; deve estar identificada como tal porque a factura actual não tem versão nativa.

**Vencimento:** data `YYYY-MM-DD` explícita no complemento, associada à fotografia, com evidência/fundamento e revisão. Não derivar da data da factura, da data actual ou do texto livre por uma regra inventada. Na primeira prova, a data é um pressuposto sintético indicado para confirmação. Data desconhecida permanece `null`, nunca hoje/zero/«30 dias» por omissão. Não confundir vencimento com data de emissão, conferência, reconhecimento ou pagamento.

**Quatro factos diferentes:** conferência valida a factura contra as origens; reconhecimento constitui a obrigação no núcleo e liga a origem; pagamento constitui/liquida um acontecimento financeiro distinto; lançamento reconhece um efeito contabilístico segundo regra própria. Este incremento só propõe o segundo a partir do primeiro. A data do reconhecimento é auditada como data da operação no núcleo e não se apresenta como data de competência contabilística/fiscal. Datas e decisões anteriores mantêm-se.

## 11. Estados, funções e correcções

| Estado proposto | Significado | Efeito sobre principal/saldo |
| --- | --- | --- |
| Origem pendente | Factura ainda não conferida, prova insuficiente ou contexto incompatível | Não constituir obrigação nova; conservar origem/motivos, sem valor zero presumido |
| Complemento pendente | Factura conferida e valor conhecido, mas vencimento/evidência em falta | Guardar uma única candidatura de origem; não somar outro principal. O saldo implícito de Compras continua visível e autoritativo até à passagem |
| Pronta para reconhecimento | Origem e complemento completos/compatíveis, preparados e ainda sem decisão no núcleo | Nenhum pagamento, baixa ou novo efeito orçamental |
| Reconhecida | Decisão sobre a revisão exacta, obrigação única e responsabilidade financeira transferida atomicamente | Principal proveniente da factura; saldo lido exclusivamente pelo responsável comum para esta origem |
| Revisão documental pendente | Proposta de correcção de vencimento/evidência | A revisão aprovada anterior continua aplicável; não alterar principal/data efectiva em silêncio |
| Conflito | Mesma identidade com conteúdo material incompatível, pagamentos inconciliáveis ou associação ambígua | Não gerar segunda obrigação nem substituir/somar principal; sinalizar conflito sem apagar dívida anterior |

«Vencida/não vencida» é uma classificação por data de consulta explícita, separada destes estados e não uma liquidação. Com vencimento desconhecido, classificação desconhecida. «Liquidada/anulada/reduzida» não são comandos deste recorte. Registos históricos já pagos podem conservar essa situação na futura reconciliação, sem a migração executar pagamento ou produzir novo evento de liquidação.

| Função sintética | Preparação/consulta permitida | Separação exigida na prova |
| --- | --- | --- |
| Preparador | Seleccionar factura existente, preparar complemento de vencimento/evidência e submeter revisão exacta | Não aprova a sua preparação nem altera o documento original |
| Validador | Conferir origem/complemento e reconhecer ou devolver fundamentadamente a revisão preparada | Identidade distinta do preparador; não editar a proposta para a aprovar |
| Consulta | Consultar origem, valor, vencimento/pendência, decisão e histórico | Sem criação, alteração, redução, anulação ou pagamento |

Estas são funções do ensaio, não novos cargos obrigatórios nos clientes. Reutilizar actores elegíveis de Finanças em Compras e direitos próprios no SGF; a autorização de validar uma factura não confere automaticamente poderes de gestão de acessos, pagamento ou lançamento. Revalidar membership, âmbito e direito dentro da transacção, mesmo em replay. Uma mesma pessoa representada nos dois hosts não conta como duas identidades para se auto-validar.

Correcção documental cria sucessor com `previous_revision`, motivo, autor, conteúdo, decisão e data. Sem sobrescrita da factura, fotografia ou decisão anterior. Alterar vencimento exige nova revisão documental exacta; mudar o hash/valor/moeda/fornecedor não é mera correcção de vencimento. O primeiro recorte recusa substituição financeira/redução/anulação/baixa e mantém a obrigação anterior visível até existir circuito próprio aprovado. Um novo exemplar do promotor/utilizador não herda a conferência do anterior.

## 12. Transição que preserva pagamentos associados

O primeiro cenário de construção é novo e sintético, sem pagamento. A futura migração de históricos é especificada para impedir perda de dívida ou dupla dedução, **não será executada neste incremento**:

1. Inventariar por factura a identidade comercial, total conferido, pagamentos associados e estados/revisões. Confirmar que não existe já binding da mesma origem à obrigação comum. Não transportar detalhes bancários cifrados para relatórios ou assumir que hash prova pagamento.
2. Reconciliar o saldo anterior: total da factura menos a soma dos pagamentos `confirmed`, exactamente como `outstanding()` hoje. `pending`/`rejected` não reduzem esse saldo, mas mantêm histórico e ligações. Não marcar pendentes como confirmados por importação.
3. Criar/recuperar a obrigação com o **principal original**, ligar os acontecimentos históricos confirmados uma única vez pela sua identidade estável e conservar os IDs/decisões existentes. Não criar obrigação apenas pelo saldo residual e depois deduzir novamente os mesmos pagamentos.
4. Conferir igualdade exacta do saldo antes/depois, integridade da moeda/organização e ausência de pagamentos sem origem. Excesso de pagamentos, divergência monetária ou correspondência ambígua ficam em conflito; não limitar automaticamente a zero, inventar crédito ou pedir novo pagamento.
5. Na mesma transacção de passagem, activar o binding de responsabilidade e fazer a leitura legada da origem delegar no núcleo. Antes da passagem, só o saldo legado é autoritativo; depois, só a projecção comum. O registo da factura continua como original documental, não como outro ledger concorrente. Não somar as duas representações em relatórios.
6. Serializar passagem e qualquer escritor antigo de pagamento para não perder confirmação concorrente. Esta coordenação e o adaptador de leitura têm de ser demonstrados antes de ligar históricos com pagamentos; se faltarem, essa migração fica explicitamente pendente, sem afectar o âmbito sintético novo.

Unicidade deve ser imposta pela base tanto em `organisation/source/document` como no binding do pagamento histórico. A repetição através de outra chave de comando recupera a mesma obrigação e os mesmos bindings. Conteúdo diferente na mesma identidade gera conflito. Em falha de histórico/resultado de comando, rollback da transacção; após perda de resposta, devolver a identidade já comprometida. Não criar dívida na primeira gravação e «corrigir duplicados depois».

Critérios adicionais de aceitação propostos, a juntar aos da secção 7:

- Vencimento desconhecido: uma pendência com `due_on=null`; não inventar data nem apagar o saldo anterior; completar/revalidar retoma a mesma origem.
- Duas propostas/pedidos com chaves diferentes e a mesma factura: uma obrigação; decisões concorrentes não aprovam duas revisões incompatíveis.
- Alteração de vencimento após preparação: decisão sobre revisão antiga é recusada; original permanece recuperável. Alteração material do documento não herda reconhecimento.
- Mesmo número com espaços/caixa diferentes e mesmo fornecedor: respeitar normalização/unicidade comercial; não criar segunda dívida por outro caminho de importação.
- Proponente/validador ou âmbito revogado durante espera: recusa após bloqueio; nenhum efeito parcial; replay também verifica autorização.
- Falha antes/depois do commit e recuperação: apenas um principal, uma decisão efectiva e um binding por origem.
- Reconstituição histórica proposta: pagamentos confirmados ligados uma vez, pendentes preservados sem dedução; valores antes/depois iguais. Esta prova pertence à preparação de futura migração, não a pagamentos executados no primeiro recorte.
- Nas duas composições: mesma implementação e fotografia de origem verificável, sem sessão no núcleo ou dependência de Sales/SGF remoto; nenhum reset da demonstração orçamental e nenhum efeito adicional nos seus movimentos.

## 13. Exemplo numérico para confirmação — não executado

Empresa **Horizonte Sintética**, fornecedor **Fornecedor Alfa Sintético**, ordem **OC-SIM-001**, factura **FT-SIM-001** emitida em **29/10/2026** e conferida por actor sintético distinto. Base **1 000,00 MZN**, imposto documental **160,00 MZN**, total **1 160,00 MZN**. Os 160,00 são um valor já conferido nesta hipótese de documento, não uma conclusão sobre taxa/dedutibilidade fiscal ou uma operação a recalcular no SGF.

| Passo proposto | Resultado esperado |
| --- | --- |
| Seleccionar a factura conferida | Reutilizar fornecedor, ordem, data, base/imposto/total, linhas e decisão; principal candidato 116000 centavos |
| Vencimento inicialmente desconhecido | Pendência explícita, data nula, sem obrigação adicional/zero; dívida implícita de 116000 continua preservada |
| Preparador indicar **28/11/2026**, evidência «Condição sintética acordada para o ensaio» | Criar revisão do complemento, sem alterar a factura. A data é fornecida explicitamente; não foi calculada por regra automática de 30 dias |
| Validador distinto reconhecer a revisão exacta | Uma obrigação de **1 160,00 MZN**, saldo **1 160,00**, vencimento 28/11/2026; binding de responsabilidade único e histórico |
| Repetir com a mesma ou outra chave | Recuperar a mesma obrigação; dívida continua **1 160,00**, nunca 2 320,00 |
| Tentar outro total para FT-SIM-001 | Conflito; principal/original preservados, sem nova dívida |
| Propor vencimento **30/11/2026** com fundamento e validar sucessor | Nova revisão documental; principal permanece **1 160,00** e a data/revisão anteriores continuam recuperáveis |

**Exemplo apenas de futura reconciliação histórica:** se a mesma factura tiver pagamento associado **confirmado de 300,00 MZN** e outro **pendente de 100,00 MZN**, o saldo anterior e posterior deve ser **860,00 MZN**. O principal comum continua 1 160,00; os 300,00 são ligados uma vez; os 100,00 pendentes não são deduzidos. Não criar principal 860,00 e voltar a deduzir 300,00, nem importar como dívida nova de 1 160,00 ignorando o pagamento. Nenhum desses pagamentos será criado ou executado na primeira prova.

**Para confirmação do recorte:** proposta de reconhecimento por validador sintético distinto da origem/revisão exacta, com vencimento explícito ou desconhecido sinalizado conforme a orientação posterior da secção 14; correcções apenas documentais de vencimento/evidência; alterações monetárias e migração de facturas com pagamentos ficam fora da execução inicial. Não se presume autorização de utilização real. Orçamento e avaliação da equipa mantêm-se inalterados.

## 14. Orientação comum de produto da Tempo — 29/10/2026

**Confirmação expressa posterior da Tempo, na mesma data:** no cenário sintético, principal reconhecido e vencimento pendente podem coexistir. Sem data de vencimento sustentada, `due_on=null`, situação de atraso **indeterminada** e `days_overdue=null`; não usar zero, data da factura, data de reconhecimento ou data actual como substitutos. A interface apresenta «Principal reconhecido — vencimento pendente» e «Atraso indeterminado». Não classificar automaticamente como vencida/não vencida, nem calcular dias de atraso. Este critério não activa pagamentos, cobranças, juros ou lembretes.

**Critério de aceitação adicional:** reconhecer a obrigação sintética de 1 160,00 MZN com data desconhecida, avançar a data de consulta e recuperar o registo; principal e identidade mantêm-se, vencimento e dias de atraso continuam nulos e não surge classificação de vencida. Só após guardar uma revisão com data sustentada é possível classificar por uma data de consulta explícita, preservando a situação documental anterior. Trata-se de prova futura especificada, não executada nesta actualização.

Origem: oito regras de produto propostas expressamente pela Tempo para SGF e Compras. São referência do desenho comum, separadas de obrigações fiscais específicas; não constituem prova de implementação, conformidade fiscal, aceitação funcional ou activação operacional. O incremento em preparação continua limitado à obrigação a fornecedor; pagamentos, recebimentos, cobranças e lançamentos não entram por consequência desta orientação.

| Regra comum | Aplicação ao desenho | Âmbito de implementação |
| --- | --- | --- |
| 1. Documento, dívida e liquidação separados | Factura é origem documental; reconhecimento é facto próprio; comprovativo, encomenda e reserva não provam liquidação nem dívida reconhecida | Neste recorte: factura conferida → obrigação única. Não criar estado «paga» por constituição/importação |
| 2. Condições explícitas | Guardar moeda, vencimento, condições e, quando aplicável, prestações; desconhecido visível e sem datas inventadas. Banco/instrução não é dinheiro | Neste recorte: MZN, complemento de vencimento/condições e pendências. Modelação completa de prestações fica futura; não inventar uma prestação ou plano por omissão |
| 3. Liquidações e afectações parciais | Várias liquidações por documento e uma liquidação para vários documentos compatíveis; saldo deriva de afectações, sem edição directa. Excesso permanece não afectado | Evolução futura do núcleo; não implementar agora pagamentos/recebimentos, afectações, reembolsos ou créditos. Preservar a dívida/pagamentos históricos numa futura transição |
| 4. Confirmação e reconciliação distintas | Registo proposto, confirmação com evidência e reconciliação com caixa/banco são factos diferentes; upload não marca factura paga | Preservar essas distinções no contrato/histórico; não acrescentar reconciliação neste recorte |
| 5. Protecção contra duplicação | Repetição recupera o resultado; origens, referências e afectações têm identidade e unicidade inclusive em concorrência | Neste recorte: unicidade da obrigação por factura, independentemente da chave de pedido; conteúdo incompatível gera conflito |
| 6. Correcções rastreáveis | Confirmados não são apagados; correcção/reversão explícita liga ao original e conserva motivo/autorização/histórico. Mercadoria, factura e dinheiro têm circuitos distintos | Neste recorte: revisões documentais e conflitos sem sobrescrita. Reversões monetárias, devoluções, anulações e baixas não são activadas |
| 7. Cobrança e aprovação | Acompanhar vencidos, prestações e contestação; lembretes, juros, descontos e bloqueios exigem configuração; separar poderes quando o circuito exigir | Neste recorte: consulta de vencimento conhecido/desconhecido e funções sintéticas. Não enviar mensagens, cobrar encargos ou impor bloqueios por omissão. Circuito completo de contestação/cobrança fica futuro |
| 8. Um núcleo e responsabilidades | Compras fornece a factura conferida; Vendas o documento do cliente; Finance gere obrigações/recebíveis/liquidações; contabilidade trata os acontecimentos próprios sem repetir stock/orçamento | Fonte única Payables, adaptadores locais e responsabilidade financeira única. Não copiar o motor nem ligar obrigatoriamente Sales ou SGF remoto |

**Precisão sobre vencimento e estados:** a proposta técnica anterior que exigia completar o vencimento antes de constituir a obrigação não se transforma em regra de produto. Se a origem/valor/decisão forem suficientes para reconhecer o principal, o desenho deve suportar **obrigação reconhecida com vencimento desconhecido**, `due_on=null`, pendência visível e classificação de atraso desconhecida. A pendência não impede recuperar a mesma identidade nem autoriza inventar data, apagar dívida ou duplicar o principal. Incompletude material da origem, montante, moeda ou autorização continua pendência/conflito de reconhecimento, distinta da falta de data. O estado «complemento pendente» da secção 11 passa a ser dimensão documental independente; pode coexistir com reconhecimento, sem um segundo saldo.

O exemplo de 1 160,00 MZN mantém principal e impostos do documento. Se reconhecido antes de se conhecer o vencimento, continua 1 160,00 com data nula/pendência; completar 28/11/2026 gera revisão documental da **mesma obrigação**. Não é uma nova dívida nem pagamento. Uma encomenda/reserva anterior permanece outro facto e não é promovida a obrigação por si só.

Esta orientação não revoga dados, decisões, pagamentos ou provas já preservados. As limitações existentes — incluindo dívida implícita de Compras, falta de versão nativa e funcionalidades de liquidação ainda não comuns — continuam identificadas. As capacidades futuras serão demonstradas por incrementos próprios, sem ampliar já esta entrega.