SGF/docs/SGF_RECEIPT_WORKSPACE_COMPLETION.md

Recepção: catálogo integral e histórico navegável

03/11/2026. SGF-RECEIPT-WORKSPACE-COMPLETION-QA-v1. Completa duas lacunas funcionais da interface de Armazém: escolha de artigos além dos100primeiros e navegação pelo histórico além da primeira página. Reutiliza o workflow físico e o writer existentes, sem acrescentar valorização, dívida ou efeitos financeiros.

Experimentar em8075

A nova composição mantém o percurso integrado, o selector paginado de fornecedores e o dossiê. Solicitante prepara uma requisição1UN/100MZN; chefia aprova; Compras e Finanças seguem propostas/avaliações e adjudicação distinta até à emissão da ordem.

Armazém abre a ordem efectivamente emitida. Em cada linha, pesquisa código/nome e escolhe individualmente um artigo da mesma unidade e das ligações conhecidas. QA-CATALOG-0110 é um exemplo além do antigo limite. O histórico permite percorrer páginas e abrir as fotografias originais. Mudar de pesquisa/página limpa a escolha e a prévia; uma resposta atrasada não substitui a escolha mais recente.

A demonstração começa sem requisições principais, ordens ou recepções. Os artigos adicionais são preparação explícita de catálogo QA, não movimentos, associações reais ou decisões já tomadas pela equipa. Três fornecedores, orçamento QA1000MZN e127artigos adicionais preparados; nenhuma localização atribuída.8074 e anteriores permanecem intactas.

Implementação

• /api/purchasing-receipts/orders/{id}/lines/{line}/catalogue: pesquisa literal por código/nome, ordenação código/ID e páginas25ou100 no SQL. Exige o direito existente purchasing_receipts.confirm, a autoridade nativa de Armazém e a linha da ordem autorizada. O cliente não escolhe a unidade por parâmetro.
• A unidade segue a comparação nativa, sem conversão: caixa e espaços externos são normalizados. O filtro respeita as ligações conhecidas de catálogo, abastecimento e peça da ordem, recorrendo aos serviços existentes. Serviços não recebem opções de stock. O workflow original continua responsável pela admissibilidade final completa.
• A projecção contém apenas ID, código, nome, unidade e impressão da escolha; não apresenta custos ou valorização. O formulário usa o modelo assíncrono de escolha já testado, sem reescrever esse mecanismo ou seleccionar o primeiro resultado automaticamente.
• O catálogo só é pedido para linhas marcadas para conferência, evitando um pedido inicial por cada linha da ordem. Desmarcar a linha cancela logicamente a pesquisa pendente e limpa a escolha. A fonte final desta alteração foi conferida no servidor; não se declara interacção visual verificada.
• A prévia captura as impressões dos artigos explicitamente indicados, conferindo a impressão enviada pelo formulário quando presente. A confirmação de uma operação nova bloqueia/reconsulta esses artigos e recusa alterações desde a prévia. O metadado de selecção é separado do payload entregue ao writer original.
• Compatibilidade: clientes anteriores podem omitir item_revisions; uma prévia nova captura as impressões actuais e a confirmação confere-as. Recepção já registada continua recuperação histórica pelo writer, sem novo movimento. Ligações implícitas que já pertenciam à ordem continuam sob autoridade do workflow nativo; este incremento não cria outras associações.
• /api/purchasing-receipts/orders/{id}/history: paginação25 com o direito existente de consulta, preservando origem/unidade. Os controlos do histórico pedem só essa página, sem voltar a carregar progresso, armazéns e catálogo. Detalhes atrasados de outra página não são anexados à página actual.
• O resumo legado items da consulta da ordem fica limitado a25 e não representa o catálogo completo. A interface actual usa a pesquisa por linha. As fotografias/históricos imutáveis e o writer físico permanecem os mesmos.

Provas

Consolidação:41verificações — fronteira funcional27, guardas4, demonstração6, build/assets3 e fonte final1. As provas anteriores do modelo assíncrono e do percurso integrado foram reutilizadas, sem repetir as suas suites.

O novo ensaio preparou uma ordem pelos workflows existentes para exercer a fronteira alterada. Consultou127artigos compatíveis em páginas25/100, atingiu a escolha além100, excluiu outra unidade/tenant, tratou %/_ literalmente e recusou parâmetros inválidos, linha alheia e perfis sem confirmação física. Nenhum direito novo foi criado.

Alteração do artigo após escolha/prévia foi recusada, sem recepção ou movimento. Um pedido legado com unidade incompatível manteve a recusa pelo workflow original na confirmação; a prévia existente não é apresentada como validação integral desse workflow. Duas confirmações simultâneas da mesma prévia produziram201/200 e um só efeito físico.

O histórico de volume tem27recepções que somam exactamente1UN: duas confirmações pela API alterada (0,010 e0,965UN) e25recepções parciais de0,001UN preparadas directamente pelo mesmo writer nativo fixado, somente como fixture de histórico. Não são27novas provas de interface. Páginas25/1 antes da última recepção eram distintas, e o detalhe antigo preservou o artigo/fotografia originais. O pedido legado final concluiu a ordem sem excesso ou duplicação.

Sem facturas, obrigações, pagamentos, contabilização ou localizações criadas por consequência deste incremento. Demonstração e regressão usam bases novas separadas; os ensaios de volume não preenchem o histórico da demo da equipa.

A matriz conferida conserva seis módulos,13estágios e114critérios documentados. A inspecção estática encontra76fontes e nenhum ciclo obrigatório, sem ligações a bases. Passaram9verificações de sintaxe PHP,7de JavaScript e git diff --check; os totais estáticos não constituem novas provas operacionais.

Limitações e preservação

Os ensaios completos deste incremento cobrem o caso consumível emUN. Os filtros de abastecimento/peças reutilizam serviços nativos e não constituem nova regressão integral desses percursos. Custos, conversões de unidade, valorização, catálogo real e pagamentos não foram implementados por arrasto.

Pesquisa paginada e27recepções não validam carga sustentada ou implantação. A revisão visual permanece separada, sem repetir o navegador bloqueado. O schema sintético é preparado pelo projecto nativo actual, com runtime fixado ao pacote provado; separação de proprietário/runtime e instalação geral continuam pendentes.

Sem alterações dos seis registos protegidos, da cache bloqueada, das demonstrações anteriores, de acessos/dados reais ou do pacote de Compras instalado. Sem índices no destino, activação, publicação, aceitação ou checkpoint.