Prenchimento dos novos campos <xPed> e <nItemPed>

[alexandre_cristovao]

Ola pessoal,

Estamos com o seguinte problema: na nova versão 2.00 do XML foi disponibilizado campos de informação de interesse do

emissor para controle do B2B. (v2.0) dentro da tag de Produtos e Serviços da NF-e.

Verificamos que o próprio standard preenche (ou pelo menos deveria preencher e não está preenchendo). Na função J_1B_NF_MAP_TO_XML o PERFORM block_h1 no final tem a tem a implementação do código:

* New fields to identify the Purchase Order          "V2.0
 READ TABLE gtab_vbap INTO gt_vbap                   "V2.0
   WITH KEY posnr = wk_item-itmnum.                  "V2.0
     xmli-xped     = gt_vbkd-bstkd.                  "V2.0 PO Number
     xmli-nitemped = gt_vbap-posex.                  "V2.0 PO Item Number
  ENDIF.                                             "V2.0

Porém a tabela gtab_vbap não foi preenchida pois o numero do documento de faturamento ainda está com o código &000000001, quando o envio da nota fiscal é efetuado no momento de gravar a fatura via VF01, assim não preenchendo os campos.

Nos casos onde estamos enviando a nota pelo monitor J1BNFE, como o numero da fatura já foi gravado, os campos são preenchidos pelo standard.

Não encontramos notas para a solução deste problema. Alguém tem alguma dica ? Teremos que usar da BADI para preencher nesta situação?

Obrigado pela atenção e ajuda.

Edited by: a_cristovao on Nov 25, 2010 5:19 PM

Apenas complementando, pois creo que faltou explicar que a tabela gtab_vbap é preenchida por outro PERFORM fill_vbfa apenas quando a it_vbfa[] for inicial. No caso, a IT_VBFA está preenchida com o valor &000000001 para a fatura.

[henrique_pinto · Accepted solution]

Oi a_cristovao,

quando vc fala que vc faturou pela VF01, vc quis dizer que vc nao usou o decouple (i.e. a nota foi enviada imediatamente apos o faturamento), é isso?

Pq mesmo faturando via VF01, se o decouple estiver ativo, call = 1, vc vai ter que enviar a NFe pelo monitor anyway.

Seria esse o problema?

Para nota criada num local de negocio sem decouple, o mapping dos dados do pedido, a partir da ordem de vendas, nao funciona?

Abs,

Henrique.

[alexandre_cristovao · Accepted solution]

Isso mesmo, não utiliza o decouple ou o decouple não foi ativado (CALL RFC = ' ') e foi enviada imediatamente após gravar a VF01

O problema foi que não fez o mapping dos dados do pedido.

Agora, imagine que a nota foi para o monitor e o local de negocio ou a região estava em contingencia, ou deu algum problema de validação no primeiro envio que obrigou a fazer o envio manual pela J1BNFE, neste caso o mapping é feito corretamente, pois a IT_VBFA está preenchida com o valor correto da fatura, e não do primeiro momento &000000001.

[former_member182114 · Accepted solution]

Bom dia a_cristovao,

Este é um ponto que o projeto tem que dar conta.

Quando não se usa o decouple, existem duas situações:

1) NF-e é transmitida junto com a criação. As informações ainda não existem no banco de dados.... Sendo assim: o standard e as BAdI's devem pegar as informações em memória quando existirem.

2) NF-e foi rejeitada, e após RESET para nova transmissão. As informações em memória não existem mais, somente em banco de dados.

Os códigos devem prever as DUAS situações. Se não irá gerar XML's inconsistentes.

Implementando decouple fica mais fácil de implementar as BAdI's, pois as informações estão prontas e salvas no banco de dados.

Dica: Aproveita a "oportunidade" e cai dentro do decouple (tem algumas notas no XX-CSC-BR-NFE para ficar com a versão funcional)

Atenciosamente, Fernando Da Ró

[alexandre_cristovao · Accepted solution]

Ola Fernando,

Estamos seguindo com essa modificação da BADI buscando os valores da memória, e não precisamos tratar no reenvio pelo monitor pois a situação já é tratada pelo Standard.

Todas as notas referentes ao Decouple foram aplicadas como Pre-requisito da nota do XML 2.00.

Porém minha dúvida é se a SAP não deveria dar suporte neste caso, pois trata de uma situação Standard. Tudo bem que ativando o decouple, vai solucionar o problema, mas se existe a opção de deixar o CAL RFC em branco...

Obrigado pela ajuda.

[former_member182114 · Accepted solution]

Bom dia a_cristovao,

Sim, é verdade que o call rfc pode estar em branco mas isso só existe pois não tem como ser mandatório decouple. Tem que ser aplicado em projeto e verificar o que impacta nos processos.

Cabe abrir um chamado em XX-CSC-BR-NFE, porém siga em paralelo com esta solução.

A todos os projetos que estão passaram pelo layout 2.0 sugeri que incluíssem este tópico, mas neste momento concordo que fica bem difícil de garantir ele com a obrigação chegando.

Você chegou a testar seu sistema mandando uma nota em memória e depois a mesma nota retransmitida ? Os XML's ficaram iguais ? Dica: Para passar pelo validador e ter o XML que será rejeitado pela Sefaz use uma data de saída muito antiga... Dará erro 220. Só pra ficar tranquilo...

Atenciosamente, Fernando Da Ró

[alexandre_cristovao · Accepted solution]

Oi Fernando,

Estamos aguardando resposta do chamado, qualquer novidade posto aqui.

Não entendi sua frase:

 A todos os projetos que estão passaram pelo layout 2.0 sugeri que incluíssem este tópico, mas neste momento concordo que fica bem difícil de garantir ele com a obrigação chegando.

Poderia explica-la melhor ? Esse tópico que se refereu é o Decouple ? Qual seria essa obrigação?

Sim, fizemos os testes enviando uma nota em memória e não são preenchidos os campos, e depois em uma nota retransmitida, são enviadas as tags, sem nenhuma outra modificação via BADI. Essa é a diferença entre os XMLs.

Os campos não são obrigatórios, apenas um dos nossos clientes de B2B que solicitou o preenchimento para todos os seus pedidos. Acreditava que o Standard daria esse suporte, mais entendo que apenas funciona para os locais de negocio com Decouple ativado, o que questiono pois pelo processo desenhado ainda não foi possível definir / ativar o decouple. Além que devem ser realizadas outras modificações da BADI, pois outras informações já estão buscando da memória e temos que modificar para buscar das tabelas (passar do modo mais dificil para o mais fácil da implementação, conforme vc mesmo comentou, rsss).

Obrigado pela ajuda e atenção.

[former_member182114 · Accepted solution]

Bom dia a_cristovao,

Também escrevendo do jeito que fiz, ficou confuso mesmo.

- Tenho recomendado a todos os que estão fazendo o projeto da obrigação que é o layout 2.0, para também incluírem no projeto a utilização de decouple para aproveitar os ciclos de testes necessários para o layout 2.0

Agora quanto a passar a ler do banco de dados é um erro de projeto dar Go-Live sem preever a retransmissão, pois é natural de acontecer e não estou falando de decouple implementado.

Ex.: Digamos que 10 campos são lidos da memória e preenchidos no XML, esta memória só existe no contexto da transação que está criando (VF01 p/ exemplo), se tiver um erro de validação no GRC a nota é rejeitada e deve-se fazer um reset, corrigir e enviar. O contexto da memória não terá mais a VF01 para os 10 campos, então já deveria ler do banco de dados.

Ou seja, sem decouple = trabalho dobrado (memória + database)

com decouple = somente database

Atenciosamente, Fernando Da Ró

[Former Member]

Oi Alexandre,

Você já teve algum retorno da SAP?

Pois estou passando pelo mesmo problema.

[henrique_pinto]

A resposta já foi dada: implemente o decouple (Call RFC = '1', '2' ou '3').

Ou você tem alguma razão de projeto que impede essa ativação?

[Former Member]

Oi Henrique,

Realmente a resposta já foi dada, mas, como o Alexandre, também estou procurando uma solução onde o deouple não seja implementado (CALL RFC = '  '), para que as notas sejam enviadas automaticamente após o faturamento (VF01).

[henrique_pinto]

Olá Benedito,

acredito que implementar o decouple seja a solução standard da SAP.

Caso vc nao deseje fazê-lo, meu entendimento é que você deverá buscar uma solução customizada (Z) para atender. Vou deixar os demais colegas comentarem.

[bruno_renzo]

Já tentou aplicar a nota 1507362?

[]s

[alexandre_cristovao]

Fernando,

Muito obrigado por toda ajuda, vamos rediscutir a ativação do Decouple neste Local de Negocios, e já estamos incluindo mais este desenvolvimento da BADI.

Mas ainda sim esperamos uma solução Standard para o campo.

Bruno,

Sobre a nota, verificamos que ela apenas modifica a origem do dado do campo do atual vbkd-bstkd para vbap-eannr, para os casos onde uma ordem é gerado de vários pedidos diferentes, por exemplo o item 10 da nossa ordem de venda A foi gerado do pedido X item 10 do cliente, já nosso item 20 foi gerado do pedido Y item 10 do cliente, situação não muito comum por aqui, e que não resolve nosso problema, pois continua buscando da mesma forma e não encontrará informação da memoria naquele momento.

Mesmo assim, obrigado pela indicação, pois devemos aplicar caso o cliente resolva agrupar N pedidos do mesmo cliente em 1 ordem de venda.