SGF/docs/GENERAL_LEDGER_DIRECT_COST_DELIVERY.md

Oficina → custo directo validado → Contabilidade

03/11/2026. COMMON-LEDGER-DIRECT-COST-SIM-v1 implementado localmente após «Autorizar o ciclo sintético proposto», no recorte aprovado. Código, interface, provas e demonstração própria. Não declara aceitação, checkpoint ou conclusão operacional de toda a aplicação.

Percurso funcional

As fixtures novas executam os workflows existentes de oficina, autorização, apontamento, verificação técnica, taxas e cálculo. Não inserem uma aprovação de custo por SQL. O caso seleccionado usa material da empresa 2UN×50=100 MZN e trabalho efectivo 105MIN÷60×100=175 MZN. A composição efectivamente validada é 275 MZN de custo directo conhecido do perímetro seleccionado, sem afirmar custo completo, margem, valorização de inventário ou salário.

DirectCosts::conference reutiliza a validação de actualidade e a composição exacta do serviço proprietário, numa leitura sem bloqueio de escrita. O adaptador CostLedgerSource exige consulta da oficina e dos custos; junta a ordem, cálculo/decisão, origens/decisões técnicas e taxas/decisões seleccionadas. Não chama o writer técnico/financeiro nem processa a outbox.

O mesmo PayableJournal captura, revê e aplica duas linhas: D QA-CUSTO-DIRECTO275 / C QA-COMPENSACAO-ENSAIO275, MZN, regra/período QA explícitos. São contas artificiais para provar a ligação técnica, sem política real de capitalização/PGC. A aplicação não cria dívida, consumo, tempo, preço, movimento de stock ou folha salarial. O percurso comprovado termina com um lançamento, duas linhas, balancete/razão reconciliados e um fecho QA revisto distintamente.

A interface liga perímetro, conferência actual, fontes e versões → impacto/proposta → revisão → aplicação → diário/balancete/razão → conferência e fecho do período. O razão e o diário voltam à ordem de custo, distinguindo-a de uma obrigação financeira. Listas e histórico têm janelas de25; uma selecção fora da primeira página continua acessível por ID autorizado. Não se muda o contexto automaticamente para validar ou lançar. As chaves dos formulários mantêm-se nas repetições idênticas e mudam com o conteúdo; IDs são números e hashes de versão permanecem cadeias exactas.

Actualidade, identidade e limitações deliberadas

gl_cost_sources declara explicitamente a ordem, os dois identificadores lógicos de origem e o período composto. O instalador só aceita um livro SGF QA novo e vazio. O mapeamento é append-only e um trigger confere o âmbito contra a ordem. Não há associação automática de ordens antigas ou dos seis registos protegidos.

A identidade do efeito usa âmbito + tipo + ordem/perímetro, não o ID da nova versão do cálculo. A nova versão muda a fotografia/revisão, mas não autoriza outro reconhecimento do mesmo custo. Fonte, direitos, pessoa, regra, contas, período, origens e versões são revalidados sob a serialização da empresa antes da primeira aplicação. A revisão contabilística exige outra identidade/pessoa; não concede verificação técnica. A confirmação de repetição revalida a autoridade antes de recuperar o resultado existente.

Os 175 MZN conhecidos com taxa material ausente continuam visíveis como incompletos e são recusados como total contabilizável. Uma composição efectiva de 100,0175 MZN também é recusada: não há arredondamento inventado para cêntimos. Origem sucessora sem verificação não herda a anterior; torna o cálculo/fonte pendente. Aritmética monetária é exacta; apresentação usa divisão inteira e resto.

O fecho inclui as fontes de custo explicitamente compostas no seu período. Custo incompleto, não lançado, alterado ou com lançamento desactualizado impede o fecho. Fotografias, versões, decisões e impactos entram no hash de conferência. Mudar o custo depois de o lançar não gera outro lançamento, estorno ou correcção automática: a correcção de custo já lançado está expressamente fora desta autorização. Não existe reabertura.

Os adaptadores adicionais conservam a resposta/hash anterior quando existe apenas a fonte Sales: a nova composição de custos não envolve silenciosamente o pacote de conferência de vendas noutro hash. Os filtros de custo usam cost_order_id, separados de sales_invoice_id e do obligation_id de fornecedores. O SGC autónomo continua sem exigir oficina e recusa a origem de custo não composta. Os artefactos autónomos anteriores de25 e30 ficheiros não foram substituídos.

Uma prova adicional compôs custo275 + fornecedor60 no mesmo livro, usando uma recepção sintética controlada de fornecedor do recorte já autorizado, sem importação viva. A ordem e a obrigação financeira tiveram o mesmo ID inteiro: os filtros conservaram um lançamento/três eventos de cada tipo, sem misturar os montantes. O resultado conjunto foi dois lançamentos/quatro linhas,335MZN por lado e um fecho QA. Custo/outbox ficaram iguais e a posição de fornecedor permaneceu60; não se criou pagamento ou stock. A guarda de obrigações admite também esta composição Cost-QA, com a mesma validação efectiva de base/role/cluster; direitos de consulta/decisão de fornecedor foram acrescentados apenas nessa fixture de integração. Isto não demonstra a composição completa de Compras ou todos os seis módulos.

Guardas e direitos

SGF_COST_LEDGER_QA fica false sem configuração. A extensão da guarda aceita apenas testing/browser-testing com opção explícita, PG loopback55439, cluster esperado, base payable_sgf_<12hex> e role não elevada payable_history_sgf_<mesmo id>, sem redireccionamento de ligação e com destino efectivo conferido. As regras anteriores de sgf_tempo_test ficam preservadas; não se utilizou essa base para estes testes.

Só as bases novas recebem as funções SQL sgf_wo_environment/sgf_dc_environment vinculadas ao seu próprio nome/role/cluster. Os ficheiros SQL/migrações originais e os destinos existentes não foram alterados por esta instalação. O arranque não instala CostSchema, não migra nem concede acessos.

Perfil sintético	Direitos reutilizados
Preparação	workshop.view; direct_costs.view/prepare; general_ledger.view/prepare/post/period_prepare/period_close
Validação	workshop.view; direct_costs.view/validate; general_ledger.view/validate/period_validate
Consulta	workshop.view; direct_costs.view; general_ledger.view
Técnico / verificador	Direitos técnicos existentes, separados; sem Contabilidade implícita

São sete direitos contabilísticos distintos / nove concessões contabilísticas, apenas nas novas fixtures. Direitos de contexto empresa/unidade são explícitos. Cinco actores sintéticos declarados; o utilizador auxiliar do construtor fica sem grants. Não há nomes de pessoas reais no código funcional ou novos direitos públicos/reais.

Provas

Manifesto e hashes. Bases de prova e demonstração da equipa são distintas.

Prova	Resultado
Percurso efectivo completo	275 validado pelos workflows → um lançamento/duas linhas → relatórios → fecho QA; repetição com a mesma e outra chave sem duplicação
Regressão de custos	9 cenários /27 verificações, com rollback: parcial175, valor sem cêntimo exacto, versões/direitos/pessoa, quatro fronteiras de falha e identidade estável
HTTP real	51 verificações: CSRF419, recusas403/409/422, contextos, proposta/impacto, revisão, repetição, diário/razão e fecho
Isolamento e verificação técnica	10 verificações: contextos estrangeiros elegíveis de tenant/empresa/unidade, três direitos revogados e sucessor técnico efectivamente criado pelo workflow mas não verificado; tudo revertido
Concorrência	6 processos reais; detalhes abaixo
Compatibilidade de fornecedores	8 cenários /74 asserções do writer numa base nova; provas anteriores preservadas
Coexistência custo + fornecedor	IDs coincidentes, filtros/eventos separados,275+60=335MZN no mesmo writer e fecho conjunto; custo/outbox e saldo financeiro preservados
Compatibilidade Sales	Fonte actual comparada exactamente à fotografia comercial lançada; resultado/hash da conferência de período apenas com Sales igual ao anterior; balancete existente continua2400MZN por lado; só leitura
SGC autónomo	Recusa explícita do custo sem origem composta, sem schema de oficina exigido ou proposta criada
Demonstração e formulários	22 verificações HTTP/VM, incluindo4 dos formulários renderizados; zero comandos de negócio; prova privada de preservação da fixture
Pós-verificação de apresentação	Diário identifica ordem de custo, filtro retém1lançamento/3eventos, razão conserva origem e links; só leitura

Na concorrência, a transacção titular reteve o bloqueio da empresa e preparou/aprovou uma taxa sucessora com o mesmo valor50, mas versão2. Um leitor terminou antes da libertação, vendo o estado confirmado de275 e nenhum lançamento. O aplicador aguardou no bloqueio real; após o commit da nova versão respondeu 409. O valor igual não dispensou nova conferência. O ensaio criou e validou cálculo2 e nova captura/revisão contabilística. Dois aplicadores concorrentes recuperaram o mesmo lançamento, e dois fechos concorrentes recuperaram o mesmo fecho/versão2. Foram observadas as cadeias de bloqueio até ao titular e esperas transactionid/tuple. Originais técnicos, cálculo1 e registos anteriores da outbox ficaram iguais; os novos registos de custo são os sucessores explícitos do ensaio, todos ainda captured_no_accounting.

As quatro falhas injectadas (after_header, after_lines, after_event, after_receipt) desfizeram lançamento, linhas, histórico e recibo da tentativa; a repetição posterior concluiu sem duplicação. Os fingerprints antes/depois do percurso integral e HTTP conferem ordens, entradas/verificações, comandos de oficina, taxas/cálculos/decisões/comandos/eventos/outbox de custos, direitos e autoridade de obrigações. O mapeamento também tem prova específica de imutabilidade.

Tentativas de preparação dos helpers que falharam antes de comandos de negócio — chave de ordenação da outbox e import de uma classe no harness — foram corrigidas e preservadas como diagnóstico, sem reset; não são contadas como provas aprovadas. O primeiro probe da demonstração omitiu a geração de contexto e recebeu409; o cliente de teste passou a enviar o token, sem alterar guardas da aplicação. Uma correcção posterior dos rótulos do diário teve pós-verificação só de leitura.

Os formulários usam VM/DOM e rede simulados sobre o JavaScript efectivamente renderizado; isso não é execução num navegador. Sintaxe PHP/JavaScript e git diff --check constam do manifesto. Não se acrescentaram dependências. SGF não tem PHPStan/Pint instalados; não se declara execução dessas ferramentas. A análise estática nativa válida anterior é reutilizada no seu âmbito, sem repetir ficheiros nativos de aplicação que não mudaram.

Demonstração e pendências

http://127.0.0.1:8054/qa/cost-demo, base/sessão/cookie/assets privados próprios, só loopback. Parte de oficina, taxas e custo275 realmente validados; sem proposta contabilística, lançamento ou fecho iniciais, para decisões individuais da equipa. Não reiniciar ou consumir este exemplo em testes destrutivos. Os perfis de Contabilidade consultam evidência técnica, sem adquirir poderes de técnico/verificador.

Continuam separados: revisão visual, carga sustentada e capacidade de implantação; contas/políticas reais e composição operacional completa entre módulos. Não se mediram novos volumes1.000/5.000/10.000, criaram índices ou validou capacidade a partir deste cenário. As demonstrações existentes continuam independentes; esta entrega não prova uma única instalação operacional com todos os seis módulos.

Sem valorização/lançamentos de stock, salários/CIF/lote industrial, preço de venda derivado do custo, operação fiscal/monetária real, correcção de custo já lançado, reabertura, migração/concessão no destino, activação de Compras, publicação, push, aceitação ou checkpoint. Seis registos, cache bloqueada, provas/checkpoints anteriores e trabalho alheio preservados.