Histórico da Página

01. DADOS GERAIS

02.

...

SITUAÇÃO/REQUISITO

Implementar uma API que permita a quebra de um pedido existente em múltiplos pedidos, com base em uma estrutura segregada de itens recebida via JSON. A API deve atualizar o pedido original com um dos grupos enviados e gerar novos pedidos para os demais, replicando dados e respeitando regras já aplicadas na quebra feita pela rotina 336.

Entrada da API

• JSON contendo:

• • Número do pedido original (NUMPED)

...

• • • Código do item
    • NUMSEQ
    • Quantidade

Saída esperada

• Atualização do pedido original com os itens do grupo 1

...

• Não há necessidade de bloquear ou liberar algum pedido automaticamente. Pode mandar a mesma POSICAO do pedido original

Restrições de quebra

• Caso o Pedido esteja na posição M (montado), a quebra só será realizada caso os pedidos tenham origem B (balcão) ou R (balcão reserva).

Validações de emissão de mapa

• Por enquanto não vamos configurar permissões para quebrar pedidos com expedição iniciada. Então vamos começar com a regra mais básica, que é NÃO PERMITIR A QUEBRA com o mapa de separação emitido. Já existem validações para esse cenário na 336, através da permissão 12 da 530. Verificar qual campo da PCPEDC é validado na permissão 12 e validar o mesmo nessa API. Se o mapa já tiver sido emitido, a API deve abortar a quebra e devolver uma mensagem, avisando ao usuário que após a emissão do mapa não é possível quebrar o pedido.
• Além disso caso o do campo DTWMS esteja preenchido, a quebra não é realizada.

Gravar campos de rastreio nos novos pedidos (NUMPEDORIG e demais que a 336 já grava, se tiver mais algum)

No fim da quebra, a API deve chamar a API de recálculo de cabeçalhos para atualizar os dados de cabeçalho de todos os pedidos gerados.

03. SOLUÇÃO

Criado um novo end-point http://<ipWTA>:<portaWTA>/winthor/venda/v0/pedido/quebrarpedido para realizar a quebra de um pedido.

...

04. DEMAIS INFORMAÇÕES

...