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. 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.