NFE10 – Incoming – NORMPRCH GRCONFQU

[former_member275480]

Bom dia Pessoal,

Em alguns cenários de compras para estoque aqui da empresa, por definição do negócio, a escolha do depósito é feita na entrada da mercadoria.

Trabalhando apenas com o ECC, o pedido fica com o campo depósito em branco e o mesmo é preenchido na MIGO.

Agora com o NFE10 incoming, no processo empresarial NORMPRCH na etapa u201Centrar quantidadesu201D GRCONFQU, o campo depósito não aparece no monitor logístico (nem na opção "configurações" do portal - função similiar a variante do ECC)

Como solução de contorno o usuário preencheu o depósito via VL32N, mas a idéia é ele não precisar usar o ECC, apenas o Monitor Logítico.

Alguma dica de como podemos disponibilizar este campo no monitor?

Obrigado.

Rafael

[henrique_pinto · Accepted solution]

Rafael,

não vejo muita opção a não ser customizar a tela de recebimento logístico do NFE.

Mas, note, que se a idéia é automatizar o processo, essa decisão de escolher o depósito só na chegada da mercadoria vai justamente contra isso. Além do mais, essa decisão vai de encontro às melhores práticas de planejamento de estoque.

Talvez seja o caso de revisar o processo e se adpatar às melhores práticas.

Abs,

Henrique.

[former_member275480]

Henrique,

Entendo seu ponto de vista, mas o Business definiu que a entrada de mercadoria deve ser uma etapa manual no monitor logístico.

Obrigado.

Rafael

[Former Member]

Oi Rafael.

Curiosidade... o que leva/direciona a pessoa no recebimento definir para que depósito o material deverá dar entrada?

@Henrique... quando você diz customização... isso poderia ser feito pelo próprio cliente ou você quer dizer que teria que entrar na priorização da SAP (idea place)?

Abraço

Eduardo Chagas

[bruno_renzo]

Rafael,

Estamos planejando estregar esta funcionalidade até o final do ano.

Por enquanto, vamos entregar no SP10 em março, a possibilidade de preencher o depósito via BAdI no ERP no momento da criação da Inbound Delivery, logo após a simulação.

BAdI J_1BNFE_IN, método CHANGE_SLOC_AND_VALTYPE.

Se esta BAdI for muito cedo, vocês podem fazer um desenvolvimento que chame a BAPI_INB_DELIVERY_CHANGE via RFC puxando dados de campos Z no WebDynpro standard do monitor logístico.

Abraços

[henrique_pinto]

Eduardo,

customização no NFE mesmo, código Z.

Os monitores do NFE são todas em tecnologia Web Dynpro ABAP, e sendo ABAP vc pode fazer extensions às telas standard, adicionando botões e campos que não existem no standard, sem ter que modificar objeto standard de fato (implicit enhancement spot).

A questao é que, pro storage location, teria que salvar esse campo numa tabela Z no NFE e, antes de chamar a MIGO, fazer uma VL32N para adicionar o campo na Inbound Delivery (se é que a ID pode ser criada com storage location em branco). Não sei se essa parte (de salvar na tabela) daria pra fazer sem mexer em código standard. De qualquer maneira, é algo que já foi feito em outros clientes (nao para storage location, para numero de lote, mas a idéia é a mesma - campo Z, salva em tabela, chama VL32N, e depois continua o processo standard), entao nao seria nada novo.

Eu sugeriria uma análise de um bom consultor WD ABAP, já que o Bruno falou que só vai vir mais pro fim do ano...

Abs,

Henrique.

[former_member275480]

Eduardo,

Respondendo a sua pergunta, penso em algumas razões:

Curiosidade... o que leva/direciona a pessoa no recebimento definir para que depósito o material deverá dar entrada?

1 u2013 Responsabilidade

A escolha do depósito está mais para responsabilidade de quem gerencia o estoque (e faz MIGO) do que de quem compra ( cria o pedido), logo o comprador não teria a responsabilidade / necessidade preencher o depósito.

2 u2013 Destinações diferentes para o material comprado

Uma montadora comprando pneu:

O pneu pode ser comprado para a linha de produção ( Industrialização u2013 depósito A), para peças de reposição ( revenda às concessionárias - depósito B) ou para o carro do diretor ( consumo u2013 depósito C)

3- Capacidade física de estocagem

Existe uma solução de depósito externo sem uso do estoque especial u201COu201D. Ou seja depósito 0001 é interno na planta e depósito 0002 é externo. Na hora do recebimento (MIGO), caso o depósito físico 0001 esteja u201Clotadou201D faz-se o recebimento diretamente no depósito 0002.

Rafael

[former_member275480]

Bruno,

Valeu pela dica.

Temos um excelente WD ABAP PI aqui então muito provavelmente devemos seguir este caminho.

Ainda falando do campo depósito (storage location).

Usando apenas o SAP ECC, as compras para elemento de custo (centro de custo, ativo, ordem interna, etc) não exigem o preenchimento do campo depósito.

Eu tinha visto um caso de uma compra para centro de custo via NFE10 onde o campo depósito foi exigido.

Este é o comportamento do NFE10, mesmo em compras para elemento de custo o depósito é um campo obrigatório ou foi algum erro do usuário ?

Obrigado,

Rafael

[henrique_pinto]

> 1 u2013 Responsabilidade
> A escolha do depósito está mais para responsabilidade de quem gerencia o estoque (e faz MIGO) do que de quem compra ( cria o pedido), logo o comprador não teria a responsabilidade / necessidade preencher o depósito.

Essa questão faz todo o sentido, de fato.

Mas provavelmente ela está baseada em um processo baseado apenas em PO + doc. Mat + fatura/NF.

A partir do momento que vc insere a Inbound Delivery no processo, vc passa a ter um passo intermediário entre o pedido de compras e a entrada em estoque que seria justamente relacionado ao "planejamento de recebimento". Na ID, vc poderia ter alguém da área logística, e nao de compras, definindo antecipadamente qual seria o depósito que iria receber a mercadoria, até mesmo adiantando e otimizando a utilização dos depósitos (alocação pró-ativa e não reativa).

Então, seria uma questão até mesmo independente de automatização da NFe: com a ID implementada, vocês poderiam ter um procedimento de definição de depósito antes do recebimento.

Abs,

Henrique.

[bruno_renzo]

> Este é o comportamento do NFE10, mesmo em compras para elemento de custo o depósito é um campo obrigatório ou foi algum erro do usuário ?

Rafael,

Esta compra para cento de custos tem Goods Receipt, ou é sem GR?

Se for Sem GR, o processo ainda não é suportado pelo nosso sistema, sendo que por compra normal entende-se que deve ter PO -> GR -> LIV, necessariamente nesta ordem.

Se for com GR, sugiro abrir uma mensagem documentando os passos manuais e comparando com o que o NF-e 10 pede.

Abs

[Former Member]

Boa tarde Bruno e Rafael,

Houve alguma evolução quanto a esta questão da VL32N exigir o depósito para executar a EM?

Estamos com este mesmo problema para avisos de recebimento de materiais que não necessitam de depósito (compras diretamente para centros de custo). No nosso caso o material trata-se de ENERGIA ELÉTRICA, processo de compras normais com GR.

A execução no ECC passa pelos seguintes passos:

> PO (sem depósito e sem controle de confirmação) / AVISO (sem depósito) / GR (MIGO não exige depósito nem controle de confirmação) -> processo concluído sem nenhuma restrição do SAP ECC Standard

Já no NFE 10 teríamos:

> PO (sem depósito, com controle de confirmação) / AVISO (criado pelo NFE 10 sem depósito) / VL32N (não executa EM sem depósito)

Entendo assim que este é um comportamento do Standard, não da NFE 10, mas, se o objetivo é automatizar a execução, não entendo o porquê de permitir criar o aviso sem depósito se ocorrerá erro no lançamento da EM.

Ou o NFE 10 consiste a necessidade do depósito no momento da criação do aviso (obedecendo o comportamento da VL32N) ou o ele verifica o lançamento direto para um centro de custo e não exige depósito para este caso (obedecendo o comportamento da MIGO).

[former_member182114]

Bom dia Bruno,

Evite postar em threads respondidas e principalmente já antigas.

Melhor criar uma discussão nova, explicando o que tem passado, e colocando uma referência a esta thread.

Desta forma as discussões ficam mais claras e em suas "épocas".

Atenciosamente, Fernando Da Rós

[Former Member]

Ok Fernando, abrindo outro tópico...