beestock:releases.notes:releases.notes.beestock.2026.1.30.2 [SZ Soluções Wiki]

Essa página está em modo somente de leitura. Você pode visualizar a fonte, mas não alterá-la. Informe-se com o administrador do Wiki, caso você ache que isso está incorreto.
====== 🚀 Release Notes v1.30.2 - 28/02/2026 ======

----

===== 📌 Resumo da Release =====

  *  6 Melhorias aplicadas em performance, usabilidade e segurança operacional.  
  *  9 Correções garantindo estabilidade e padronização entre Web, Coletor e relatórios.  

----

===== ✨ Melhorias =====

**01. BEES-3223, BEES-3195, BEES-3201 e BEES-3245: [Nova Funcionalidade] – Gestão por Carga e Controle de Docas**

=== SITUAÇÃO/REQUISITO ===

O cliente utiliza no ERP o conceito de Montagem de Carga, agrupando múltiplos pedidos antes da separação, porém o BeeStock operava apenas por documento individual, sem controle consolidado por carga, gerando riscos de mistura em docas incorretas e perda de rastreabilidade, tornando necessária a integração do número da carga como elemento central do processo, com bloqueio de alterações estruturais após o início da operação.

=== SOLUÇÃO ===

Foi implementada a entidade “Carga” no BeeStock por meio do campo loadNumber na API de saída, com criação do Monitor de Cargas para atribuição de Doca e liberação controlada da separação, garantindo que pedidos com carga integrada só iniciem após essa definição, incluindo validações críticas de integridade (Carga x Doca e 100% dos volumes conferidos), bloqueio de alterações estruturais no ERP após o início da carga, priorização do picking por agrupamento de carga e manutenção da retrocompatibilidade para pedidos sem carga.

----

**02. BEES-3215: [Nova Funcionalidade] – Geração de PDF do Pedido de Venda (Exportação)**

=== SITUAÇÃO/REQUISITO ===

O cliente necessita enviar, nas operações de exportação, um PDF do Pedido de Venda com detalhamento completo dos itens comercializados. Atualmente, esse documento é gerado manualmente, causando retrabalho, risco de erros e ausência de padronização. Como o Documento de Saída já está integrado ao BeeStock, torna-se necessário automatizar a geração do PDF diretamente pelo sistema, garantindo rastreabilidade, fidelidade às informações do pedido e controle por parâmetro no Tipo de Documento.

=== SOLUÇÃO ===

Implementada nova funcionalidade no BeeStock para geração automática de PDF do Pedido de Venda a partir da tela de Documento de Saída, condicionada ao parâmetro “Permitir Geração de PDF do Pedido de Venda” no Tipo de Documento. O PDF é gerado dinamicamente, sem limite de itens, contendo cabeçalho da filial e detalhamento completo (código, descrição, quantidade e QR Code do código de barras). A geração não altera o status do documento, respeita permissões de usuário e permite nova emissão sempre que houver alterações no pedido.

----

**03. BEES-3248 e BEES-3240: [MELHORIA] – Devolução Parcial de Picking com Confirmação Manual**

=== SITUAÇÃO/REQUISITO ===

O cliente realiza vendas com envio prévio de múltiplos itens para escolha no momento da entrega, podendo ocorrer retorno parcial ao estoque. No fluxo padrão do BeeStock, a confirmação de separação é enviada automaticamente ao ERP, impedindo o controle manual do faturamento conforme o modelo operacional do cliente. Era necessário permitir devolução parcial sem disparar integração imediata, garantindo que apenas os itens efetivamente vendidos sejam faturados.

=== SOLUÇÃO ===

O campo “Quantidade Separada” passou a ser editável e obrigatório, permitindo devolução total ou parcial, com validações (maior que zero e não superior ao saldo separado).
Quando o parâmetro “Controle de Etiquetas Seriadas por Depósito” estiver ativo, devolução parcial não é permitida.

Antes da Conferência: o sistema ajusta automaticamente a quantidade esperada para conferência e a integração envia apenas o saldo efetivamente conferido.
Após a Conferência: é gerada nova integração via estrutura pickingConfirm, atualizando o campo checkedQuantity conforme a quantidade final válida no pedido.

----

**04. BEES-3246 e BEES-3247: [MELHORIA] – Devolução Parcial de Picking com Confirmação Manual**

=== SITUAÇÃO/REQUISITO ===

No modelo operacional do cliente, a mercadoria pode sair fisicamente antes da definição final da venda, exigindo registro de dados logísticos (motorista, horário, observações) sem que o faturamento ocorra automaticamente. O fluxo padrão do BeeStock não contemplava esse controle intermediário, sendo necessário permitir pré-expedição com rastreabilidade e liberação manual do faturamento.

=== SOLUÇÃO ===

Implementada ação de Pré-Expedição no Documento de Saída, permitindo registrar motorista, documento, data/hora e observações, sem gerar integração ao ERP. O documento permanece em Pendente de Doca até que o usuário execute a ação “Liberar Faturamento”, disponível apenas quando o parâmetro de confirmação manual estiver ativo. Somente após essa ação o sistema envia o pickingConfirm ao ERP e altera o status para Pendente de Faturamento, aguardando retorno da nota fiscal.

----

**05. BEES-3226, BEES-3225 E BEES-2615: [MELHORIA] – Evoluções no Processo de Cross-Docking**

=== SITUAÇÃO/REQUISITO ===

O processo de Cross-Docking no BeeStock apresentava inconsistências operacionais, ausência de feedback ao usuário e limitações funcionais, gerando retrabalho e insegurança na execução. Foram identificados problemas como cancelamento manual de pedidos vinculados, impossibilidade de fechamento de volume via coletor, informação incorreta de saldo disponível para alocação e ausência de mensagens na confirmação de separação.

=== SOLUÇÃO ===

Implementado cancelamento automático do pedido de cross-docking ao cancelar o documento de entrada vinculado.
Disponibilizado fechamento de volume também no coletor, respeitando validações operacionais e mantendo a funcionalidade no WEB.
Ajustado o Monitor de Pendências de Alocação para considerar corretamente saldo reservado de cross-docking e refletir a Alocação Prevista (%).
Incluídas mensagens de confirmação, alerta e sucesso/erro no processo de “Confirmar Separação”, garantindo rastreabilidade e segurança operacional.

----

**06. BEES-3256: [Melhoria] – Integração do Campo “Controlar Vencimento” via API de Produtos**

=== SITUAÇÃO/REQUISITO ===

Atualmente, no BeeStock, o campo “Controlar Vencimento” (bol_control_expiration_date) pode ser definido apenas manualmente no cadastro do produto. O cliente Beauty Color identificou a necessidade de permitir que essa definição também seja realizada via integração com o ERP, garantindo padronização cadastral e eliminando ajustes manuais após sincronização de produtos.

=== SOLUÇÃO ===

Incluído o campo controlExpiration (boolean) no endpoint products, com default false.
Quando enviado como true, o sistema marca automaticamente o campo “Controlar Vencimento” no cadastro do produto (bol_control_expiration_date = true).
Quando enviado como false ou não informado, o campo permanece desmarcado.

A integração passa a contemplar tanto criação quanto atualização de produtos, mantendo o comportamento manual já existente no WMS.

----

===== 🐞 Correções =====

**07. BEES-3242: [Correção] – Inconsistência de Status na Devolução de Picking**

=== SITUAÇÃO/REQUISITO ===

No BeeStock, ao realizar Devolução de Picking Total com volume criado (não finalizado), os itens eram alterados para Devolvido, porém o Documento permanecia como Pendente de Conferência, gerando inconsistência entre cabeçalho, itens e volumes.

=== SOLUÇÃO ===

Ajustado o fluxo para garantir consistência de status:

  * Devolução total cancela/ajusta volumes não finalizados e atualiza corretamente o status do Documento.
  * Devolução parcial mantém coerência entre itens, volumes e documento.
  * Bloqueio de devolução para volumes finalizados ou documentos já integrados ao ERP.
  * Documento devolvido pode ser reprocessado sem vínculos residuais.
  * Garantida integridade operacional e rastreabilidade do processo.

----

**08. BEES-3241: [Correção] – Integração “Confirma Devolução” não enviada em devoluções parciais subsequentes**

=== SITUAÇÃO/REQUISITO ===

No BeeStock, ao realizar devolução parcial de picking item a item, apenas a primeira devolução gerava integração “Confirma Devolução” ao ERP. As devoluções subsequentes atualizavam o status internamente, porém não enviavam nova integração, causando divergência entre WMS e ERP.

=== SOLUÇÃO ===

Ajustada a lógica para que cada devolução confirmada (mesmo em momentos distintos) gere e envie uma integração independente do tipo “Confirma Devolução”, com o respectivo checkedQuantity do item devolvido.
Removida a limitação que vinculava o disparo apenas à primeira devolução da ordem.

Garantida consistência entre WMS e ERP em devoluções parciais múltiplas.

----

**09. BEES-3281: [Correção] – Otimização da Busca de Endereços no Recebimento**

=== SITUAÇÃO/REQUISITO ===

No BeeStock, a rotina de sugestão de endereços no recebimento via coletor (CIA) reutilizava a mesma query da geração de inventário, incluindo JOIN com fichas de inventário.
Esse JOIN não é necessário no recebimento e causava degradação severa de performance (~1.300.000 registros retornados com JOIN vs ~12.000 sem JOIN), impactando diretamente o tempo de resposta na conferência física.

=== SOLUÇÃO ===

Removido o JOIN com fichas de inventário exclusivamente na rotina de recebimento via CIA, mantendo a lógica intacta para geração de inventário.
A busca de endereços no recebimento passa a considerar apenas filtros essenciais (filial, depósito, bloqueios, regras de armazenagem e ocupação), garantindo:

  * Redução significativa do tempo de carregamento no coletor
  * Isolamento da regra de inventário (sem impacto funcional)
  * Manutenção das validações de endereços válidos e elegíveis

Resultado: ganho expressivo de performance sem alteração das regras de negócio.

----

**10. BEES-3236: [Correção] – Saldo Alocado Negativo**

=== SITUAÇÃO/REQUISITO ===

No BeeStock, ao realizar separação parcial de um item, posteriormente alterar sua alocação e, em seguida, cancelar o item/documento, o sistema estava gerando saldo alocado negativo (-500).
O problema ocorria porque o cancelamento subtraía tanto o saldo já separado quanto o saldo remanescente da nova alocação, sem recompor corretamente o estoque disponível.

=== SOLUÇÃO ===

Ajustada a lógica de cancelamento para que:

  * O saldo já separado seja retornado ao campo Disponível.
  * O saldo ainda alocado seja desconsiderado corretamente e também devolvido ao Disponível.
  * Não ocorra dupla subtração no campo Alocado.

Com isso, o cancelamento passa a recompor integralmente o estoque (separado + alocado), evitando saldo negativo e garantindo consistência entre disponível e alocado para novas expedições.

----

**11. BEES-3249: [Correção] – Data Início Armazenagem sobrescrita ao Finalizar Armazenamento**

=== SITUAÇÃO/REQUISITO ===

No BeeStock, ao finalizar o armazenamento de um documento de entrada com múltiplos itens, a Data Início Armazenagem estava sendo indevidamente substituída pela Data Fim Armazenagem.
O comportamento ocorria quando o último item era armazenado e o processo era concluído, gerando perda da informação original de início do armazenamento.

=== SOLUÇÃO ===

Ajustada a rotina de finalização para que a Data Início Armazenagem permaneça inalterada após o encerramento do processo.
A Data Fim Armazenagem passa a ser registrada apenas em seu campo específico, preservando a integridade histórica das datas e a rastreabilidade da operação.

----

**12. BEES-3176: [Correção] – Bloqueio de Desalocação com Plano de Corte Gerado**

=== SITUAÇÃO/REQUISITO ===

No BeeStock, ao desalocar documentos com Plano de Corte gerado (antes ou após finalização do corte), o sistema permitia a operação, causando inconsistências: falha ao finalizar corte, impossibilidade de gerar novo plano ou erro de comunicação. Em alguns casos, apenas a exclusão manual do plano resolvia.

=== SOLUÇÃO ===

Implementado bloqueio de desalocação quando existir Plano de Corte vinculado ao documento:

  * Com plano gerado (não finalizado):
Mensagem: “Desalocação não permitida. O documento possui um Plano de Corte gerado. Para desalocar, é necessário excluir o Plano de Corte existente.”

  * Com corte já finalizado:
Mensagem: “Não é possível desalocar o documento. O Corte de Cabos já foi finalizado para este documento.”

Garantida integridade do processo de Corte de Cabos e prevenção de inconsistências operacionais.

----

**13. BEES-3209: [Correção] – Permissão Indevida de Separação com Endereço Inválido**

=== SITUAÇÃO/REQUISITO ===

No BeeStock, ao informar um endereço inválido durante a separação e pressionar Enter, o sistema ignorava a leitura incorreta e permitia a continuidade do processo.
Com isso, era possível finalizar a separação e liberar divergência sem validação adequada, além de não gerar a integração de Confirma Separação, causando inconsistência operacional.

=== SOLUÇÃO ===

Implementado bloqueio imediato quando informado endereço inválido ou código de barras inexistente:

  * Impede avanço no processo de separação.
  * Exibe mensagem de erro orientativa ao operador.
  * Não permite finalizar separação ou liberar divergência sem validação correta do endereço.

Garantida validação obrigatória do código de barras e integridade da integração de Confirma Separação.

----

**14. BEES-3196: [Correção] – Impressão de Quantidade “0” na Etiqueta de Checklist em Conferência Parcial**

=== SITUAÇÃO/REQUISITO ===

No BeeStock, ao realizar conferência parcial de produto com saldo alocado em múltiplos endereços, a etiqueta de checklist era impressa com uma linha adicional exibindo quantidade 0.
O problema ocorria quando o item era fracionado em dois volumes (ex.: 4 + 6), gerando informação indevida na primeira etiqueta.

=== SOLUÇÃO ===

Ajustada a lógica de geração da etiqueta de checklist para:

  * Considerar apenas quantidades efetivamente conferidas no volume.
  * Descartar linhas com quantidade igual a 0.
  * Manter consistência quando o produto possuir múltiplos endereços de alocação.

Garantida impressão correta das etiquetas, sem informações indevidas ou inconsistentes.

----

**15. BEES-3208: [Correção] – Formatação Incorreta da Quantidade na Etiqueta de Embalagem Fracionada (Coletor)**

=== SITUAÇÃO/REQUISITO ===

O cliente identificou que, no BeeStock, ao imprimir Etiqueta de Embalagem Fracionada (Entrada e Saída) via coletor, a “Qtde. da Embalagem” era exibida incorretamente quando o parâmetro Quantidade Fracionada estava desativado.
Exemplo: quantidade 72 era apresentada como 720.000 na tela, embora a impressão ocorresse corretamente.

=== SOLUÇÃO ===

Ajustada a formatação da quantidade no coletor para:

  * Respeitar o padrão numérico correto quando o parâmetro de fracionamento estiver desativado.
  * Exibir valores inteiros sem casas decimais indevidas (ex.: 72 → 72; 1200 → 1.200).
  * Manter coerência entre visualização em tela e impressão da etiqueta.

Garantida consistência visual e prevenção de erro operacional na conferência.

----