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)

• • Lista de grupos numerados (grupo 1, grupo 2, etc.)

• • Cada grupo contendo:

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

Saída esperada

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

• Geração de novos pedidos (NUMPED) para os demais grupos
• Após a quebra, a API de recálculo de cabeçalho deve ser chamada passando todos os NUMPED gerados (Incluindo o NUMPED original do grupo 1) como parâmetro

• Retorno em JSON contendo:

• • numped_original

• • Lista de numped_gerados

• • Mensagem de sucesso ou erro

Regras de Negócio

Obrigatoriedade de integridade:

• Todos os itens do pedido original devem ser contemplados na soma dos grupos.
• Se houver divergência de quantidade total por item (a mais ou a menos), ou item inexistente, a requisição será rejeitada integralmente.
• O NUMSEQ serve para identificar exatamente a que linha da PCPEDI aquele registro se refere, para copiar os dados corretos quando houver mais de um item no mesmo pedido.

Divisão de item permitida:

• Um mesmo item pode ser dividido entre grupos, desde que a soma das quantidades nos grupos seja igual à quantidade do item no pedido original.

Processamento de grupos:

• O grupo 1 será usado para atualizar o pedido original (NUMPED permanece).
• Os demais grupos gerarão novos pedidos, com novo NUMPED, via SEQUENCE.
• As tabelas PCPEDC e PCPEDI devem ser replicadas para os novos pedidos, com os dados originais mantidos, exceto {{NUMPED, }}os itens e suas respectivas quantidades.

Bloqueios:

• A tabela PCBLOQUEIOSPEDIDO do pedido original deve ser replicada para os novos pedidos, mantendo os mesmos bloqueios.

Regras adicionais da quebra padrão (rotina 336):

• 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