Páginas filhas
  • DT 4.4 - Integração da Renovação do Pedido de Venda dentro do processo de Separação de Mercadoria (Expedição e WMS)

01. DADOS GERAIS

Produto:

TOTVS Distribuição e Varejo

Linha de Produto:

Linha Winthor

Segmento:

Distribuição

Módulo:

3 - Vendas

9 - Expedição

12 - Contas a Receber

14 - Faturamento

17 - WMS

País:Brasil
Ticket:DMAISNEG-30
Requisito/Story/Issue (informe o requisito relacionado) :

DMAISNEG-30, DMAISNEG-1483,
DMAISNEG-1142, DMAISNEG-22,
DMAISNEG-388, DMAISNEG-24,
DMAISNEG-299, DMAISNEG-300,
DMAISNEG-902, DMAISNEG-873,
DMAISNEG-23, DMAISNEG-297

02. SITUAÇÃO/REQUISITO

Adaptar o processo do ERP Winthor para que caso haja a necessidade de renovar a data de validade dos pedidos junto a Supplier, que o usuário consiga reenviar os pedidos rejeitados para uma nova análise. Também, adaptar as rotinas envolvidas no processo de expedição/WMS e faturamento a fazer a validação da data de validade dos pedidos aprovados/rejeitados pela Supplier, barrando-os caso um ou mais pedidos estejam rejeitados.


Critérios de Aceitação

  • Preparar a rotina 336 - Alterar Pedido de Venda para que reenvie pedidos junto a Supplier para uma nova análise, caso esses pedidos encontram-se vencidos e/ou rejeitados;
  • Preparar a rotina 901 - Montar Carga para que valide, no ato da montagem de carga, se aquele pedido está com a data de validade vencida e/ou rejeitada pela Supplier, sendo que se estiver em um desses cenários, o processamento da rotina deve barrar a interação com aquele pedido;
  • Preparar a rotina 902 - Emitir Mapa de Separação por Rua para que valide, no ato da emissão do mapa, se aquele pedido está com a data de validade vencida e/ou rejeitada pela Supplier, sendo que se estiver em um desses cenários, o processamento da rotina deve barrar a interação com aquele pedido;
  • Preparar a rotina 931 - Emitir Mapa de Separação por Pedido para que valide, no ato da emissão do mapa, se aquele pedido está com a data de validade vencida e/ou rejeitada pela Supplier, sendo que se estiver em um desses cenários, o processamento da rotina deve barrar a interação com aquele pedido;
  • Preparar a rotina 1757 - Gerar WMS para que valide, no ato de gerar WMS, se aquele pedido está com a data de validade vencida e/ou rejeitada pela Supplier, sendo que se estiver em um desses cenários, o processamento da rotina deve barrar a interação com aquele pedido;
  • Preparar a rotina 1752 - Gerar Mapa de Separação/Abast. Corretivo para que valide, no ato de gerar o mapa de separação, seja por pedido, carregamento e/ou qualquer outro processo, se aquele pedido está com a data de validade vencida e/ou rejeitada pela Supplier, sendo que se estiver em um desses cenários, o processamento da rotina deve barrar a interação com aquele pedido;
  • Preparar a rotina 1402 - Gerar Faturamento para que valide, no ato de faturar o carregamento, se há algum pedido com a data de validade vencida e/ou rejeitada pela Supplier, sendo que se estiver em um desses cenários, o processamento da rotina deve barrar a interação com aquele pedido;
  • Preparar a rotina 1406 - Gerar Faturamento por Pedido para que valide, no ato de faturar o pedidos, se aquele pedido está com a data de validade vencida e/ou rejeitada pela Supplier, sendo que se estiver em um desses cenários, o processamento da rotina deve barrar a interação com aquele pedido;
  • Preparar a rotina 1294 - Gestão Financeira - Integrações Techfin para que possua um Painel de Acompanhamento, onde o usuário consiga monitorar e reenviar pedidos e NF's de saída que estejam vencidos e/ou rejeitados;
  • Gravar log's de integração de envio e retorno dos reprocessamentos dos pedidos, apresentando tais informações na rotina 1294 - Gestão Financeira - Integrações Techfin.

03. SOLUÇÃO

Ajustada as rotinas 336 - Alterar Pedido de Venda e 1294 - Gestão Financeira - Integrações Techfin, sub-menu Painel de Acompanhamento do ERP Winthor para que consiga reenviar e acompanhar a reanálise dos pedidos junto a Supplier que estejam vencidos e/ou rejeitados. Alterado também as rotinas 901 - Montar Carga, 902 - Emitir Mapa de Separação por Rua, 931 - Emitir Mapa de Separação por Pedido, 1757 - Gerar WMS, 1752 - Gerar Mapa de Separação/Abast. Corretivo, 1402 - Gerar Faturamento e 1406 - Gerar Faturamento por Pedido para validarem, independente no momento da posição do pedido (em montagem, separação, geração WMS, faturamento e etc.), se ele está vencido e/ou bloqueado, uma vez que não deve-se permitir o faturamento e posterior envio dessa NF a Supplier para aprovação.

Como temos inúmeras rotinas envolvidas no processo de expedição/faturamento para validar se o pedido está vencido e/ou rejeitado, separaremos, aqui por módulo, para facilitar o deixar mais simples o entendimento, uma vez que a validação de pedido rejeitado/vencido é a mesma para todas as rotinas.

Clique nos Menus abaixo

Nos menus abaixo segue as funcionalidades de integração do Pedido de Venda usando o processo de Separação de Mercadoria (Expedição e WMS)

    Após as etapas de criação do pedido de venda utilizando a cobrança específica para o processo do Mais Negócios, bem como as integrações de envio e retorno ou edição dos pedidos, conforme explicado nos link's DT 4.2 - Integração do Pedido de Venda e DT 4.3 - Integração da Alteração e Cancelamento do Pedido de Venda, entramos na etapa do processo de expedição de mercadoria, envolvendo as rotinas do módulo 9 - Expedição.

    Aqui, a validação implementada, foi relacionado ao vencimento do pedido e/ou pedido rejeitado pela Supplier. De tempos em tempos, todos os pedidos autorizados pela Supplier são reanalisados e se por ventura, a instituição, julgar que há problemas relacionados ao pedido, ela pode enviar, por meio da integração entre a Supplier e o ERP Winthor, dados para tornar o pedido bloqueado e, consequentemente, não renovar a data de validade do pedido. Isso está explicado com mais detalhes na guia Solicitar Reanálise do Pedido, dentro desse mesmo artigo.

    Sendo assim, se um pedido estiver com esse tipo de problema, deve ser barrado no processo de expedição. Logo, as rotinas abaixo, não podem permitir a montagem de carregamento e/ou emissão de mapa de separação, seja por pedido ou por rua. Segue abaixo a exemplificação do processo implementado, quando um pedido encontrar com problemas:

    • Rotina 901 - Montar Carga

      Aqui será representado o processo de montagem de carregamento com um ou mais pedidos com problemas junto a Supplier.




      Note no gif acima que ao tentar prosseguir com a montagem de carregamento é ilustrado ao usuário que há a necessidade de reanalisar o pedido junto a Supplier. Logo, se o pedido não estiver reanalisado e aprovado, não será possível o processo de montagem de carregamento com esse pedido.



    • Rotina 902 - Emitir Mapa de Separação por Rua

      Aqui será representado o processo de emissão de mapa de separação de um carregamento com um ou mais pedidos com problemas junto a Supplier.




      Note no gif acima que ao tentar prosseguir com a emissão do mapa é ilustrado ao usuário que há a necessidade de reanalisar o pedido junto a Supplier. Logo, se o pedido não estiver reanalisado e aprovado, não será possível o processo de montagem de carregamento com esse pedido.



    • Rotina 931 - Emitir Mapa de Separação por Pedido

      Aqui será representado o processo de emissão de mapa de separação de um carregamento com um ou mais pedidos com problemas junto a Supplier.




      Note no gif acima que ao tentar prosseguir com a emissão do mapa é ilustrado ao usuário que há a necessidade de reanalisar o pedido junto a Supplier. Logo, se o pedido não estiver reanalisado e aprovado, não será possível o processo de montagem de carregamento com esse pedido.


    Importante!

    Vale reforçar que, de tempos em tempos, conforme a data de validade de cada pedido autorizado pela Supplier, os pedidos são analisados e reanalisados. Se nesse intervalo de digitar um pedido, liberar um pedido, montar o carregamento ou emitir o mapa de separação, ocorrer algum problema na Supplier, será enviado, por meio do processo da integração, o bloqueio do pedido e a sua respectiva não renovação.

    Logo, se o processo logístico do Parceiro demorar mais do que a data de validade do pedido e simultaneamente ocorrer o vencimento do pedido sem a renovação em virtude de bloqueios, poderá ocorrer esses cenários exemplificados acima. 

    Na dúvida quanto a data de validade dos pedidos, o Parceiro deve entrar em contato com a Supplier.

    Após as etapas de criação do pedido de venda utilizando a cobrança específica para o processo do Mais Negócios, bem como as integrações de envio e retorno ou edição dos pedidos, conforme explicado nos link's DT 4.2 - Integração do Pedido de Venda e DT 4.3 - Integração da Alteração e Cancelamento do Pedido de Venda, entramos na etapa do processo de WMS, envolvendo as rotinas do módulo 17 - WMS, caso o parceiro utilize esse módulo. Se ele não utilizar o WMS do ERP Winthor, essa etapa pode ser descartada.

    Aqui, a validação implementada, foi relacionado ao vencimento do pedido e/ou pedido rejeitado pela Supplier. De tempos em tempos, todos os pedidos autorizados pela Supplier são reanalisados e se por ventura, a instituição, julgar que há problemas relacionados ao pedido, ela pode enviar, por meio da integração entre a Supplier e o ERP Winthor, dados para tornar o pedido bloqueado e, consequentemente, não renovar a data de validade do pedido. Isso está explicado com mais detalhes na guia Solicitar Reanálise do Pedido, dentro desse mesmo artigo.

    Sendo assim, se um pedido estiver com esse tipo de problema, deve ser barrado no processo de WMS. Logo, as rotinas abaixo, não podem permitir a montagem de carregamento e/ou emissão de mapa de separação, seja por pedido ou por rua. Segue abaixo a exemplificação do processo implementado, quando um pedido encontrar com problemas:

    • Rotina 1757 - Gerar WMS 

      Aqui será representado o processo de geração de WMS com um ou mais pedidos com problemas junto a Supplier.




      Note no gif acima que ao tentar prosseguir com a geração de WMS é ilustrado ao usuário que há a necessidade de reanalisar o pedido junto a Supplier. Logo, se o pedido não estiver reanalisado e aprovado, não será possível seguir o processo de WMS com esse pedido.



    • Rotina 1752 - Gerar Mapa de Separação/Abast. Corretivo

      Aqui será representado o processo de emissão de mapa de separação de pedido ou carregamento, envolvendo o processo de WMS com um ou mais pedidos com problemas junto a Supplier.




      Note no gif acima que ao tentar prosseguir com a emissão do mapa de separação dentro do WMS é ilustrado ao usuário que há a necessidade de reanalisar o pedido junto a Supplier. Logo, se o pedido não estiver reanalisado e aprovado, não será possível seguir o processo de WMS com esse pedido.


    Importante!

    Vale reforçar que, de tempos em tempos, conforme a data de validade de cada pedido autorizado pela Supplier, os pedidos são analisados e reanalisados. Se nesse intervalo de digitar um pedido, liberar um pedido, montar o carregamento ou emitir o mapa de separação, ocorrer algum problema na Supplier, será enviado, por meio do processo da integração, o bloqueio do pedido e a sua respectiva não renovação.

    Logo, se o processo logístico do Parceiro demorar mais do que a data de validade do pedido e simultaneamente ocorrer o vencimento do pedido sem a renovação em virtude de bloqueios, poderá ocorrer esses cenários exemplificados acima. 

    Na dúvida quanto a data de validade dos pedidos, o Parceiro deve entrar em contato com a Supplier.

    Após as etapas de criação do pedido de venda utilizando a cobrança específica para o processo do Mais Negócios, bem como as integrações de envio e retorno ou edição dos pedidos, conforme explicado nos link's DT 4.2 - Integração do Pedido de Venda e DT 4.3 - Integração da Alteração e Cancelamento do Pedido de Venda, entramos na etapa do faturamento, envolvendo as rotinas do módulo 14 - Faturamento

    Aqui, a validação implementada, foi relacionado ao vencimento do pedido e/ou pedido rejeitado pela Supplier. De tempos em tempos, todos os pedidos autorizados pela Supplier são reanalisados e se por ventura, a instituição, julgar que há problemas relacionados ao pedido, ela pode enviar, por meio da integração entre a Supplier e o ERP Winthor, dados para tornar o pedido bloqueado e, consequentemente, não renovar a data de validade do pedido. Isso está explicado com mais detalhes na guia Solicitar Reanálise do Pedido, dentro desse mesmo artigo.

    Sendo assim, se um pedido estiver com esse tipo de problema, deve ser barrado no processo de faturamento. Logo, as rotinas abaixo, não podem permitir o faturamento dos pedidos/carregamento. Segue abaixo a exemplificação do processo implementado, quando um pedido encontrar com problemas:

    • Rotina 1402 - Gerar Faturamento

      Aqui será representado o processo de geração do faturamento de carregamento com um ou mais pedidos com problemas junto a Supplier.




      Note no gif acima que ao tentar prosseguir com o faturamento do carregamento é ilustrado ao usuário que há a necessidade de reanalisar o pedido junto a Supplier. Logo, se o pedido não estiver reanalisado e aprovado, não será possível o processo de faturamento com esse carregamento.



    • Rotina 1406 - Gerar Faturamento por Pedido


      Aqui será representado o processo de geração de faturamento por pedido com problemas junto a Supplier.




      Note no gif acima que ao tentar prosseguir com o faturamento do pedido é ilustrado ao usuário que há a necessidade de reanalisar o pedido junto a Supplier. Logo, se o pedido não estiver reanalisado e aprovado, não será possível seguir o processo de faturamento desse pedido.


    Importante!

    Vale reforçar que, de tempos em tempos, conforme a data de validade de cada pedido autorizado pela Supplier, os pedidos são analisados e reanalisados. Se nesse intervalo de digitar um pedido, liberar um pedido, montar o carregamento ou emitir o mapa de separação, ocorrer algum problema na Supplier, será enviado, por meio do processo da integração, o bloqueio do pedido e a sua respectiva não renovação.

    Logo, se o processo logístico do Parceiro demorar mais do que a data de validade do pedido e simultaneamente ocorrer o vencimento do pedido sem a renovação em virtude de bloqueios, poderá ocorrer esses cenários exemplificados acima. 

    Na dúvida quanto a data de validade dos pedidos, o Parceiro deve entrar em contato com a Supplier.

    Importante!

    No processo de integração entre o ERP Winthor e a Supplier, em segundo plano, há vários serviços de atualização automática. Um deles, que vale destacar aqui, é de atualização da renovação automática da data de vencimento do pedido. Logo, o usuário, não precisa preocupar em solicitar a renovação de todos os pedidos que ainda não foram faturados, uma vez que é automático. O processo de solicitar manualmente uma reanálise é aplicado nos casos de pedidos que já estão bloqueados a um certo tempo ou pedidos que não foram autorizado, em um primeiro momento, pela Supplier.

    A data de vencimento dos pedidos poderá ter validades diferente para cada Cliente/Parceiro. Geralmente, os pedidos, valem entre 2 a 5 dias úteis. 

    Assim sendo, haverá apenas pedidos sem a renovação de data de validade, quando por algum motivo o pedido não pode ser liberado, seja por bloqueio do cliente na Supplier, seja por falta de pagamento de outras parcelas e uma séries de eventos que a Supplier julgará procedente ou improcedente para renovar os pedidos automaticamente dentro do ERP Winthor. Assim, caso queira saber todos os motivos, o Cliente/Parceiro deverá entrar em contato com a Supplier para entender o motivo da rejeição da renovação do pedido.


    Para solicitar uma reanálise do pedido junto a Supplier poderá utilizar as rotinas 336 - Alterar Pedido de Venda ou 1294 - Gestão Financeira - Integrações Techfin sub-menu Painel de Acompanhamento, conforme já explicado nos links DT 4.3 - Integração da Alteração e Cancelamento do Pedido de Venda sub-menu Rotina 336 - Alterando pedidos (no caso da rotina 336 - Alterar Pedido de Venda) ou DT 3.3 - Rotina 1294 - 2. Mais Negócios - Usabilidade dos menus e sub-menus. sub-menu Painel de Acompanhamento (no caso da rotina 1294 - Gestão Financeira - Integrações Techfin).

    No link da rotina 336, apesar do exemplo ilustrar uma alteração do pedido, também é valido o mesmo processo para reenviar a Supplier uma nova análise daquele pedido e verificar se irá autorizar ou não o ticket.

    Já no link da rotina 1294, basta o usuário localizar o pedido/nota fiscal pelo seu respectivo número ou por um determinado período e ao localizar, clicar no botão Reenviar. Feito isso, basta aguardar alguns minutos, na própria rotina e se o registro não apresentar mais, após pesquisar novamente, quer dizer que o mesmo foi autorizado pela Supplier. Se persistir na plataforma, deverá analisar o retorno, por meio do Histórico, pois o pedido poderá estar em uma condição comercial que restringe a aprovação.

    Mas, como saberemos se o pedido não foi autorizado pela Supplier? Como saberemos se ele está vencido ou não? Para isso, bastará acessar a rotina 336 - Alterar Pedido de Venda e fazer as verificações, conforme ilustrado a seguir.








    Ao final do processo da reanálise dos pedidos junto a Supplier, independente se o pedido foi bloqueado na expedição, WMS ou faturamento, o usuário poderá acompanhar os log's de reintegração dos pedidos, caso o usuário solicite junto a instituição essa renovação.

    Segue abaixo, um exemplo de um pedido que foi rejeitado pela Supplier no ato da liberação do pedido. Logo foi solicitado a renovação e aprovação do pedido





    Conforme pode-se observar no gif acima, foi exemplificado todo o processo de renovação de um pedido que apresentou problema. Daí pode-se acompanhar todo o processo de através das rotinas 336 - Alterar Pedido de Venda e 1294 - Gestão Financeira - Integrações Techfin


    04. DEMAIS INFORMAÇÕES

    Importante!

    As versões estarão disponíveis para download no CCW. 

    https://centraldecontrole.pcinformatica.com.br/

    Mantenha suas rotinas sempre atualizadas!

    05. ASSUNTOS RELACIONADOS