on 06-17-2011 10:06 PM
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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!!
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!
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
User | Count |
---|---|
16 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.