====== 🚀 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. ----