SGF/docs/SGF_INVOICE_TO_PAYABLE_DELIVERY.md

Factura conferida → obrigação única na interface SGF

03/11/2026. SGF-INVOICE-TO-PAYABLE-QA-v1. Entrega local funcional: preparação explícita de uma fotografia da factura, prévia do impacto e reconhecimento por pessoa distinta, no mesmo livro nativo usado pela factura. Reutiliza SupplierPayables original e packages/payables; não importa uma cópia para o host nem cria outro escritor de dívida.

Experimentar em8071

1. Compras: emitir a ordem da adjudicação QA preparada.
2. Armazém: receber1UN, aceite e conforme, para o artigo/armazém QA.
3. Finanças — documento: registar factura100MZN, base100, imposto0 e quantidade1UN.
4. Finanças — conferência distinta: validar a factura pelo workflow original. Consome o compromisso existente; não reconhece automaticamente uma obrigação.
5. Preparação da obrigação: seleccionar a factura, fundamentar, conferir impacto e confirmar a preparação.
6. Reconhecimento distinto: conferir a proposta exacta, fundamentar, ver impacto e confirmar. Outra identidade QA permite conferência independente.

A demonstração começa sem ordens principais, recepções, facturas, propostas ou obrigações; não contém decisões tomadas pela equipa. Tem uma adjudicação aprovada/reserva100MZN preparada, orçamento QA1000MZN e uma ordem estrangeira apenas para isolamento. O ensaio de integração usou outra base nova. Portas8070/8069/anteriores não foram actualizadas.

Implementação e fronteiras

• /purchasing/obligations e /api/purchasing-obligations: lista com pesquisa literal por número, estado documental, ordenação por ID e páginas25 no servidor. Documento individual apresenta origem/linhas, pendências, propostas, principal/saldo do núcleo e eventos, com páginas independentes25 para propostas/histórico.
• A conferência corrente lê a origem actual, a última captura, a responsabilidade existente e a identidade/permissões nativas; não materializa todo o universo de facturas ou o histórico completo de propostas.
• ReceiptRuntime mantém isolamento de empresa/unidade/origem e os bloqueios administrativos existentes. Os endpoints pertencem expressamente a Compras; o módulo Comercial não lhes dá acesso. A identidade de fonte é a mesma qa-stock-ledger-<tag> da preparação nativa e está fixada na ligação. Alterá-la recusa acesso; não abre outro saldo.
• Preparação incompleta fica pending_source. Preparar não reconhece dívida. A validação exige conta e pessoa distintas; não basta usar outra conta da mesma pessoa. Origem insuficiente ou incompatível permanece preservada, sem segunda obrigação.
• Prévia executa o mesmo comando num savepoint e reverte integralmente; sequências podem avançar. IDs temporários não são apresentados como factos persistidos. O corte cifrado prende actor, pessoa, documento, versão, contexto de sessão, ligação e validade10minutos.
• Confirmar volta a validar permissões, contexto, versão e fonte. O comando do núcleo guarda idempotência, propostas, obrigação, eventos/outbox; a proveniência SGF/fundamento/anterior/posterior entra na mesma transacção nativa. Falha de auditoria reverte tudo. Uma repetição chama novamente o núcleo e verifica elegibilidade actual, em vez de tratar um recibo histórico como autorização de nova execução.
• Principal100MZN reconhecido uma vez, saldo100MZN. Vencimento null, atraso indeterminado: o texto de condições comerciais não inventa uma data. O reconhecimento não repete consumo orçamental, movimento físico, pagamento ou lançamento contabilístico.
• Direitos purchasing_obligations.view/prepare/validate e correspondentes direitos do núcleo só nas novas fixtures55439. Configuração desligada por omissão; catálogo público e concessões reais intactos. Não foi activada importação histórica.

Provas

Prova consolidada: 72 verificações — integração35, repetição com origem alterada3, fronteiras6, guardas6, navegação6, demonstração13 e build/assets3. PHP/JavaScript verificados separadamente. As35 provas funcionais precederam a regra adicional de pertença modular; as6 provas posteriores testaram a fronteira alterada, preservando os factos financeiros, sem repetir a suite válida.

O percurso real de teste emitiu ordem, recebeu material, registou documento pendente e validou-o pelo serviço original. Captura pendente não reconheceu; mudança efectiva para factura validada recusou a prévia antiga e exigiu nova captura. Dois pedidos simultâneos da mesma preparação deram201/200; dois validadores concorrentes deram201/409. Falha forçada na auditoria reverteu obrigação/comando/eventos/outbox, e a operação seguinte recuperou. Houve um só evento de reconhecimento.

Revogação de direitos no host e no núcleo, conta da mesma pessoa, contexto de unidade/módulo, geração de sessão, ligação alterada e identidade de fonte divergente foram recusados. A prova adicional de repetição usa o adaptador original e injecção adversarial de um marcador de validação apenas dentro de transacção revertida; não é uma segunda validação comercial. Recusou origem alterada e preservou exactamente o principal e a evidência anteriores.

As77 verificações anteriores de facturas e83 de geografia foram reutilizadas como provas anteriores preservadas, sem nova execução nem recontagem como testes deste incremento. Sem leitura da base de destino, alteração dos seis registos, limpeza da cache bloqueada, alteração de demos antigas, publicação, aceitação ou checkpoint.

A conferência actualizada da matriz mantém seis módulos,13estágios e98critérios documentados. A inspecção estática do fluxo encontra67fontes e nenhum ciclo obrigatório; não constitui teste operacional adicional. Passaram17 verificações de sintaxe PHP,8 de JavaScript e git diff --check.

Limitações que continuam abertas

Revisão visual não realizada; não se repetiu o navegador bloqueado. Carga sustentada, implantação geral e separação de proprietário/runtime não estão validadas por estes ensaios. O schema sintético é preparado pelo projecto nativo actual, mas o runtime continua fixado ao pacote anteriormente provado; isto não demonstra compatibilidade de instalação no destino.

Pagamento/afectação, histórico importado, reconciliação e contabilização desta nova origem continuam passos próprios. Não há ligação automática ao percurso histórico de11600MZN nem declaração de passagem de responsabilidade de dívidas reais. Correcção/rejeição/notas de crédito e anexos binários de facturas conservam as limitações anteriores.

A demo8071 parte de adjudicação QA preparada. Requisições/propostas/geografia já entregues mantêm demonstrações separadas; ainda não se declara uma instalação única que reúna todas essas fixtures. A aplicação completa e a capacidade de implantação não são declaradas concluídas por este incremento.