SGF/docs/SGF_SUPPLIER_INVOICE_MATCHING_DELIVERY.md

Conferência de facturas de fornecedor na interface SGF

03/11/2026. SGF-SUPPLIER-INVOICE-MATCHING-QA-v1: registo de dados do documento recebido, conferência exacta com ordem/recepção e validação financeira por identidade distinta, no mesmo livro nativo. Reutiliza InvoiceController, InvoiceWorkflow e CommonBudget originais, fixados pelo manifesto já testado; não acrescenta outro cálculo de conferência ou escritor orçamental.

Demonstração8070

• Compras: emitir a ordem da adjudicação QA já aprovada.
• Armazém: conferir/receber1UN da ordem efectivamente emitida.
• Finanças — preparação: registar documento recebido pendente.
• Finanças — revisão distinta: conferir e validar a factura.
• Outro validador QA: identidade distinta para ensaios de concorrência.

O contexto principal começa com adjudicação preparada de1UN/100MZN, reserva100MZN e nenhuma ordem emitida, recepção, factura ou consumo inicial. Um tenant estrangeiro tem uma ordem preparada exclusivamente para recusa de acesso; não aparece nas consultas do contexto principal. Os perfis automáticos são exclusivos do launcher privado em loopback.8070 não substitui ou reconfigura8069/anteriores.

Percurso de ensaio: emitir a ordem, aceitar a mercadoria, registar a primeira factura de0,400UN/base40MZN/imposto0/total40 e validá-la com outra identidade. Depois registar0,600UN/base60/imposto0/total60 e validar. O número e a data vêm do documento recebido; os campos começam vazios. A data tem de respeitar as regras do workflow original, incluindo a emissão da ordem e o exercício corrente. Os preços/unidades/impostos de origem são mostrados e reutilizados pela conferência, sem redigitação obrigatória. Não há aplicação da política de IVA de vendas SGF.

Registo e validação

Registar preserva um documento pendente; não consome orçamento. A conferência verifica fornecedor/ordem, linhas distintas, quantidade aceite ainda não facturada, unidade, preço, taxa e totais, sem tolerância configurada. Uma validação distinta volta a conferir os dados e chama o consumo original do compromisso. Facturas parciais usam o arredondamento cumulativo original. Não há outra reserva, compromisso ou movimento de stock.

Cada comando tem prévia com impacto e fundamento individual. A prévia executa o controlador/workflow original num savepoint de rollback obrigatório; não persiste factura, linhas, auditoria ou consumo. Sequências podem avançar; os IDs temporários de registo não são apresentados como definitivos. A validação mostra explicitamente o montante a consumir no orçamento antes da confirmação.

Confirmação revalida permissão, função nativa, origem, empresa/unidade, geração do contexto, revisão das dependências e validade de dez minutos. A revisão inclui ordem/linhas, requisição/aprovações, fornecedor, conflitos declarados, recepções, correcções físicas efectivas, facturas e movimentos/consumos orçamentais relevantes. Mudanças exigem nova conferência; as regras originais são sempre reaplicadas na execução.

Factura/linhas/decisão/consumo e recibo sgf.invoice.command ficam na mesma transacção nativa. O recibo inclui contexto SGF, versão do pacote, autor, fundamento, chave, hash e fotografia do documento/resultados. Falhar esse recibo desfaz também os dados e a auditoria nativa. A mesma chave/conteúdo recupera o resultado histórico, sem novo consumo; outro conteúdo é recusado. Dois validadores com a mesma base produzem uma confirmação e uma recusa409. Uma prévia antiga de outra factura fica inválida quando muda a quantidade já validada.

Os direitos purchasing_invoices.view/prepare/validate foram apresentados antes da preparação e concedidos apenas nas fixtures novas. Ter direito de validação não permite aprovar a própria factura. Compras/Armazém não recebem consulta económica das facturas. O acesso usa a mesma requisição/ordem de origem e as permissões nativas; não se editam listas de IDs depois da emissão/recepção. A lista de ordens tem páginas25 e o histórico de conferência tem páginas15, com estados e autores preservados.

Provas

Consolidação técnica: 77 verificações —45 do percurso, quatro de fronteiras, seis das guardas/módulo, seis da navegação React,13 da demonstração e três de build/assets.

As45 incluem ordem emitida na interface SGF → recepção efectiva → duas facturas parciais validadas, registo antes da recepção recusado, divergência de total/preço/linha/quantidade, número normalizado repetido, auto-validação, âmbito estrangeiro, direito revogado, prévia adulterada, falha injectada e recuperação no registo/validação. Duas sessões de preparação com a mesma chave recuperaram um documento com201/200; dois validadores distintos obtiveram201/409. Consumos finais4000+6000=10000 em unidades monetárias menores, um compromisso original, duas facturas validadas, nenhum stock adicional, obrigação automática ou pagamento.

Uma factura concorrente de0,700UN/70MZN foi registada quando ainda havia1UN disponível e permaneceu pendente. Após validar a primeira parcial de0,400UN, a sua prévia anterior recebeu409 e uma nova conferência recebeu422 por exceder a quantidade restante. O original não foi apagado, reescrito ou considerado validado por conveniência.

As45 provas válidas não foram repetidas. Quatro sondas adicionais, sem novas decisões persistentes, comprovaram recusa após nova geração do contexto, versão do fornecedor e ligação de origem, mantendo facturas/consumos/auditoria intactos. Suites de associações, geografia, pagamentos e lançamentos anteriores foram reutilizadas, não reexecutadas.

Manifesto complementar do escritor orçamental: os três ficheiros do núcleo coincidem entre a árvore de trabalho e as cópias QA/demonstração. Uma sonda autónoma de reflexão em runtime atingiu o limite de30s; os diagnósticos privados foram preservados e não se declara essa identificação em runtime verificada. A comparação complementar é de ficheiros, sem repetir comandos financeiros ou alterar as77 provas. Não constitui medição do tempo das operações, validação de implantação ou prova de um bloqueio transaccional.

Fronteiras preservadas

Este bloco não reconhece automaticamente uma obrigação, não paga, não contabiliza e não emite um documento fiscal. O consumo é exclusivamente o efeito orçamental já existente no workflow original. O anterior cenário comum de obrigação11600MZN mantém a sua prova própria; não se declara que estas facturas100MZN já foram ligadas a essa composição ou a uma fonte histórica SGF viva.

Correcção/rejeição de facturas registadas, notas de crédito, anexos binários originais e políticas fiscais reais continuam separados. A factura pendente incompatível permanece com evidência e motivo de recusa; não se criou um mecanismo correctivo por edição directa. Datas entre exercícios, outras moedas e tolerâncias adicionais não foram introduzidas.

As dependências da ordem seleccionada são materializadas para a revisão; grandes históricos de facturas por ordem não tiveram carga validada. Revisão visual, carga sustentada, instalação geral e capacidade de implantação permanecem pendentes. Nenhuma migração/concessão foi aplicada no destino, nenhum direito público alterado e nenhuma versão de Compras activada/publicada. Os pacotes anteriores e o trabalho simultâneo em Compras foram preservados. Sem alterações aos seis registos protegidos, à cache bloqueada, às demonstrações anteriores, aceitação presumida ou checkpoint.