NF-e Número aleatório na BAPI_INCOMINGINVOICE_CREATE

[Former Member]

Boa tarde,

Cliente tem um processo que utiliza a BAPI BAPI_INCOMINGINVOICE_CREATE para criar/iniciar o processo da NF-e. Mais retorna que o campo de valor aleatório não foi informado. Pesquisei algumas notas (até a 1411196) e posts antigos mais nada ajudou. Alguma luz?

Cliente está no SP 16 SAPKH60016.

Obrigado

Sequeira

[Former Member]

Pessoal, boa tarde.

Estamos com o mesmo problema.

Estamos no SAPKH60010 e a BAPI_INCOMINGINVOICE_CREATE não tem estes campos na estrutura.

Sabem me informar qual foi a SAP Note liberada para este caso ? Pesquisei no Marketplace e não encontrei...

Obrigada!

Fernanda.

[Eduardo_Rubia]

Fernanda,

Creio que a BAPI_INCOMINGINVOICE_CREATE não tenha sido estendida para contemplar os campos de cabeçalho de NF-e, não.

E, salvo engano, não o será, pois arquiteturalmente esta BAPI não "interage" com a NF-e em si - apenas a cria a partir do NF type informado no header da interface.

Dessa forma, além das sugestões passadas pelos colegas acima, vejo 2 outras abordagens que podem ser consideradas:

1) chamar a J1B2n em modo bcd e suprir os campos faltantes após o commit da MIRO com NF-e

ou

2) não informar NF-e type na BAPI da MIRO, e após o commit da MIRO, chamar a BAPI_J_1B_NF_CREATEFROMDATA para criar a NF-e com todos os dados desejados.

Abs,

Eduardo

[Former Member]

Obrigada pelo retorno Eduardo !

Aqui acabamos adotando o enhancement no include LJ1BBF2F.

[Former Member]

Eduardo,

Penso que, na opção 2, não informar NF-e type na BAPI da MIRO vá deixar a tabela RBKP sem esta informação. Se houver um cruzamento por este dado haverá uma inconsistência...

A pergunta é: porque a SAP não reconstrói essa ponte?

Abçs,

Levi Luis 

[Former Member]

Concordo...já não foi o primeiro cliente que tratei desta forma, infelizmente.

[Eduardo_Rubia]

Oi, Levi.

Seu entendimento está correto, na opção 2 a RBKP ficará sem a informação da categoria de nota. Mas ainda será possível chegar da fatura na NF olhando a referência na J_1BNFLIN (assumindo que a interface customizada tenha suprido essa informação). Por isso a opção 1 é melhor, IMHO.

Quanto ao porquê da SAP não construir esta ponte de maneira standard, no meu entendimento é justamente pelo que comentei anteriormente: a BAPI_INCOMINGINVOICE_CREATE é uma abstração da MIRO, e na MIRO a única conexão com a nota fiscal é o NF type (portanto, é este o único campo disponível na interface da BAPI).

Todas as outras infos específicas de NF (random # por exemplo) são supridas dentro da tela da NF, que é gerada apenas após os dados da fatura terem sido alimentados - não existem campos de Brasil (exceto NF type) na MIRO.

Por isso, talvez não faça sentido (pelos princípios arquiteturais) criar campos específicos na BAPI da MIRO, pois isso violaria um princípio de correspondência entre as 2 tecnologias (transação dialog e BAPI).

Abraço!!

[Former Member]

Olá, Eduardo

Obrigado pelo retorno.

Deixa explicar o que fizemos aqui. Talvez possamos ter uma ponte para o pessoal que precisa de uma solução par esse tipo de cenário...

Notamos aqui no ambiente do cliente que a BAPI_INCOMINGINVOICE_CREATE1 possui os campos abaixo em seu cabeçalho:

'ZZDOCNUM9'       - Tipo emissão e Nº aleatório (concatenados)

'ZZCDV'                  - Dígito verificador

Como aqui no nosso cenário estamos trabalhando um Intercompany, as informações da NF-e de Saída está na mesma base (tabela J_1BNFE_ACTIVE) onde escriturarei a NF-e de Entrada, consigo ler as informações destes dois campos para complementar na BAPI.

Então, para atender o cliente, fizemos o seguinte:

1) Mapeamos os campos a serem preenchidos na BAPI_INCOMINGINVOICE_CREATE1, inclusive os campos acima. Informamos uma categoria de NF-e indicada pela área Fiscal - com estas informações o SAP tenta gerar a NF-e de entrada para escriturá-la na Planta de recebimento. Ocorre que há a configuração de campos obrigatórios para esta NF-e de entrada, que pede a informação dos dois campos (Nº aleatório e Dígito verificador)

2) Notamos que essas informações (Nº aleatório e Dígito verificador) não são passadas para a montagem da NF-e, mesmo que a BAPI_INCOMINGINVOICE_CREATE1 possua os dados preenchidos em seu cabeçalho.

3) Colocamos um enhacement na include LJ1BIF02, no Form NF_HEADER_CREATE. Os campos 'ZZDOCNUM9' e 'ZZCDV', vindos da  BAPI_INCOMINGINVOICE_CREATE1, serão populados na estrutura ls_active chamando novamente a função  J_1B_NFE_DATA_TRANSFER para enviar essas informações para a geração da NF-e a ser escriturada.

Tem funcionado aqui...

Abraços!

[Former Member]

Aqui na empresa temos o mesmo problema.

Pra resolver fiz o seguinte:

1- Um append na estrutura BAPI_INCINV_CREATE_HEADER com os campos necessários:

ZZAUTHCOD

ZZDOCNUM9

ZZCDV

2- Adicionei um enhancement no include LJ1BBF2F

e recupero os dados necessários da memória e movo paa a estrutura de validação da nf.

FIELD-SYMBOLS: .

if not lc_header-ZZDOCNUM9 is initial and

not lc_header-ZZAUTHCOD is initial.

• NF-e: nº log

move: lc_header-zzauthcod to int_header-authcod.

endif.

endif.

3- Depois de criado a fatura, executo um batch input no J1b2N para modificar os campos do log.

Sílvio Miranda

[former_member182114]

Bom dia Pessoal,

Poderiam abrir chamado à SAP solicitando uma opção de forma standard?

Se ninguém "pedir" às vezes temos que repetir a solução em todo cliente.

Atenciosamente, Fernando Da Ró

[former_member474470]

Boa tarde Fernando, saberia me dizer se houve chamado para isso ? estamos com o mesmo gap.

Grato. Joao Espindola.

[former_member474470]

o chamado foi aberto mas enquanto nao é respondido seguimos com a seguinte solução:

1- export to memory valores de CDV, DOCNUM9 e AUTHCOD antes da chamada da BAPI.

2- import from memory dos valores a atribudo aos seguintes destinos atraves de assign em enhancement no include LJ1BBF2F

   SAPLJ_1B_NFE)WK_ACTIVE-CDV

   SAPLJ_1B_NFE)WK_ACTIVE-DOCNUM9

   SAPLJ_1B_NFE)WK_ACTIVE-AUTHCOD e INT_HEADER-AUTHCOD

3- caso nao atualize nao usar SHDB da J1, e sim a FM J_1B_NF_DOCUMENT_UPDATE.

Joao Espindola.