SGF/docs/GENERAL_LEDGER_DIRECT_COST_CORRECTION_DELIVERY.md

Correcção de custo directo275→295 — entrega sintética

03/11/2026. COMMON-LEDGER-DIRECT-COST-CORRECTION-SIM-v1 implementado após «Autorizar a correcção sintética proposta», conforme o recorte apresentado. Inclui código funcional, interface, testes e demonstração própria. Não equivale a aceitação, checkpoint, uso real ou conclusão operacional de toda a aplicação.

Resultado

O cenário novo executa os workflows existentes: oficina/origens verificadas, taxas e composição100+175=275, revisão distinta e lançamento original275. Depois prepara/aprova taxa material sucessora60MZN/UN e cálculo 120+175=295, preservando as versões anteriores. Não fabrica a decisão de custo por SQL.

O núcleo contabilístico comum captura, revê e aplica um par indivisível:

Parte	Débito	Crédito
Estorno do original	QA-COMPENSACAO-ENSAIO275	QA-CUSTO-DIRECTO275
Substituição actual	QA-CUSTO-DIRECTO295	QA-COMPENSACAO-ENSAIO295

O original permanece. O resultado comprovado é três lançamentos/seis linhas, movimentos brutos 845MZN por lado e saldo do custo 295MZN, diferença20. Balancete e razão reconciliam este mesmo livro e ligam à ordem/conferência. A validação do custo ou a outbox não desencadeiam contabilização automática.

Núcleo, SQL e actualidade

Reutiliza correct-prepare/validate/post, tabelas de grupos/resultados, writer, recibos e histórico existentes. Os tipos workshop.direct_cost.reversal/replacement são distintos de journal.reversal/replacement dos fornecedores. Os filtros continuam tipados por cost_order_id ou obrigação de fornecedor; IDs inteiros coincidentes não juntam os domínios.

CostCorrectionSchema só instala em livro SGF QA novo e vazio com a composição de custos presente. Acrescenta marcador de capacidade e constraints diferidas para o par de custos. Confere original, âmbito, grupo, propostas, tipos de origem, período, datas, contas, ligação à mesma ordem/perímetro, revisão de substituição e reversão integral das linhas originais. O estorno deve igualar275 do original; a substituição deve corresponder ao295 capturado/revisto. Não exige igualdade entre os montantes das duas partes. A função antiga de integridade mantém a sua validação de fornecedores e delega apenas resultados explicitamente de custos à nova verificação. Demos/schemas anteriores não são actualizados.

A aplicação pública recusa revisão ou lançamento individual das partes. A base também recusa uma reversão isolada mesmo que equilibrada e com fotografia revista. Fonte/regra/período/âmbito/pessoa/direitos são revalidados sob o bloqueio de empresa antes de aplicar; recibo, dois lançamentos, linhas, histórico e resultado são uma transacção única. Uma falha depois da primeira parte ou depois do resultado desfaz a tentativa inteira.

A identidade do grupo liga ao lançamento original, com unicidade e repetição independente da chave. Uma nova versão de taxa/cálculo muda a fotografia mesmo quando o valor continua295: exige nova captura e conferência. Capturas anteriores ficam no histórico, assinaladas como superadas na interface. Uma correcção aplicada não pode ser repetida como outra correcção do mesmo original neste recorte.

A conferência do período resolve o original pela substituição efectivamente aplicada no grupo, comparando a sua revisão de fonte com o cálculo actual. Não basta que os totais coincidam. Uma fonte alterada depois do par volta a bloquear o fecho e não cria uma cadeia automática de revalorizações. Correcção anterior à data do original, noutro período ou em período fechado é recusada; não há reabertura.

Interface e permissões

O percurso mostra original275, actual295 e diferença20, depois as quatro linhas, fotografias, revisões e fundamentos do grupo. A decisão é conjunta e distinta do preparador. A aplicação conjunta só aparece após aprovação das duas partes. Diário e interface de custos ocultam as acções individuais das partes; o backend mantém a recusa mesmo com pedido manual. Grupos de outras fontes são filtrados no servidor antes da paginação/contagem. Reviews/resultados/actualidade dos grupos visíveis são lidos em conjunto, sem pesquisa individual de todo o histórico por grupo.

Foram reutilizados os três direitos general_ledger.correct_prepare/correct_validate/correct_post, apenas nas fixtures novas: preparador prepara/aplica; validador revê. Com os anteriores são dez direitos contabilísticos distintos / doze concessões contabilísticas por fixture padrão. Não há direitos públicos/reais novos ou supervisão técnica implícita. A fixture de coexistência acrescenta apenas os direitos QA de fornecedor já existentes para o seu teste.

SGF_COST_CORRECTION_QA fica false sem configuração. Requer a opção sintética de custos já protegida, testing/browser-testing, destino efectivo exacto55439/cluster/base/role próprios e marcador de schema. O flag nas settings da nova fixture não altera configurações do destino. A demonstração8054 mantém flag false, schema ausente e os nove grants contabilísticos originais; a tentativa de usar a nova origem nesse modo é recusada. O SGC autónomo continua sem exigir oficina, provado também pela regressão do seu ciclo de fornecedores. Os artefactos financeiros congelados de25 e30 ficheiros não foram substituídos.

Provas

Manifesto e hashes. Bases exclusivas para regressão, concorrência, coexistência e demonstração; nenhuma prova destrutiva usa a base da equipa.

Evidência	Resultado
Workflow efectivo	275 original e295 sucessor pelos workflows; um par aplicado, relatórios845/295 e fecho QA revisto; originais/fontes/outbox/direitos exactos
Serviço e integridade SQL	7 cenários /30 verificações: impactos assimétricos, recusa de partes isoladas, seis fronteiras de falha, SQL contra órfão, versões, pessoa/direitos, período fechado e ausência de cadeia implícita
Segurança de contexto	8 verificações: tenant/empresa/unidade estrangeiros mas elegíveis e quatro direitos correntes revogados; probes com rollback
Pós-verificação das interfaces	Captura superada continua visível no histórico; páginas de custo, diário genérico e ciclo legado ocultam aplicação isolada, mesmo para partes antigas revistas mas não aplicadas; só leitura
HTTP real	58 verificações: CSRF419, contexto antigo/errado, recusas403/409/422, quatro linhas, revisão/aplicação conjunta, proibição de partes, repetição e relatórios/fecho
Concorrência	6 processos reais: leitor antes da libertação, grupo desactualizado409 após commit de versão, um par e um fecho após nova conferência
Coexistência com fornecedor	Dois domínios de correcção no mesmo schema/livro; seis lançamentos/doze linhas, bruto1025 por lado, grupos/filtros separados e fecho conjunto
SGC autónomo	23 verificações actuais do ciclo original de fornecedor, com rollback, no núcleo generalizado
Modo275 anterior	Fonte actual exactamente igual à fotografia lançada; pacote do único adaptador de período preservado; flag/schema novos ausentes, nove grants e recusa403
Demonstração nova e formulários	23 verificações, incluindo5 em VM do JavaScript renderizado; sem comandos de negócio, um original275 e nenhum grupo/fecho inicial
Demonstração8054	Fingerprint exacto de fontes/outbox/direitos, flag desligado e schema novo ausente; só leitura

As seis falhas injectadas foram after_header, after_lines, after_event, after_correction_first, after_correction_result e after_receipt. A tentativa de finalizar uma parte pelo writer interno, em probe adversarial, foi recusada pela constraint diferida GL_COST_CORRECTION_PAIR_REQUIRED; o rollback restaurou o livro. A aplicação recuperada criou só um resultado completo.

Na concorrência, o titular reteve o bloqueio de empresa e confirmou taxa/cálculo de versão3, mantendo295. O leitor terminou antes da libertação vendo apenas o original275 e nenhuma correcção aplicada. O aplicador que aguardava recusou409 após o commit. Nova captura/revisão gerou outro grupo imutável; dois aplicadores recuperaram o mesmo resultado e dois fechos a mesma versão2. São dois grupos preparados e um aplicado, não duplicação de aplicação. Foram observadas cadeias até ao titular e esperas transactionid/tuple. Original275, cálculos1/2 e registos anteriores da outbox permaneceram iguais; os novos registos de versão3 são os sucessores explícitos do ensaio, todos ainda captured_no_accounting.

Na coexistência, ordem de custo e obrigação de fornecedor partilharam o mesmo ID inteiro. O custo conserva três lançamentos/nove eventos e bruto845; o fornecedor, após a sua correcção técnica já autorizada60/60, conserva três lançamentos/nove eventos e bruto180. O foco da ordem devolve apenas um grupo de custos. Custo actual295, outbox e saldo financeiro de fornecedor60 ficaram intactos. A origem do fornecedor é recepção sintética controlada, não importação viva SGF. Esta prova também exercita a validação SQL antiga e a nova no mesmo livro.

Provas válidas anteriores são reutilizadas e conferidas por hash. Não foram repetidas suites de stock, fiscalidade ou demais módulos. Sintaxe PHP/JavaScript e git diff --check dos dois repositórios constam do manifesto. SGF não tem PHPStan/Pint instalados; código nativo de aplicação não mudou e a qualidade estática anterior não foi repetida. Não se acrescentaram dependências. Os formulários foram exercitados em VM/DOM/rede simulados e por HTTP; isso não constitui execução num navegador nem revisão visual.

Demonstração e limites

http://127.0.0.1:8055/qa/cost-demo. Base/sessão/cookie/assets próprios, só loopback. Começa com original275 realmente lançado e custo sucessor295 validado, sem grupo de correcção ou fecho inicial. Preparar o par, rever noutra função, aplicar e consultar diário/balancete/razão; depois conferir e fechar QA. Não reiniciar o exemplo da equipa nem as demonstrações anteriores.

Mantêm-se pendentes e separados: revisão visual, carga sustentada e capacidade de implantação; contas/políticas reais e composição operacional integral dos seis módulos. Não houve novos ensaios de1.000/5.000/10.000, índices ou declaração de capacidade a partir destes casos.

Sem cadeias adicionais de revalorização por arrasto, correcção em período fechado/reabertura, stock valorizado/contabilizado, salários/CIF, operações fiscais/monetárias reais, concessões/migrações no destino, activação de Compras, publicação, push, aceitação ou checkpoint. Os seis registos, cache bloqueada, dados/acessos reais, checkpoints, provas e trabalho alheio foram preservados.