on 09-22-2014 2:49 PM
Bom dia,
gostaria se possível de ajuda com o seguinte problema: queremos inicializar alguns valores durante a criação da NF (como código FCI), o que obtemos utilizando a BadI J_1BNF_ADD_DATA. No entanto, esta desativa a existente CL_NFE_PRINT (métodos Fill_Header e Fill_Item), necessaria para adicionar dados complementares durante a criação do XML outbound.
Alguém saberia dizer como podemos fazer ambos funcionarem ao mesmo tempo (não encontrei outra Badi que pudesse usar durante a criação da NF), ou até mesmo o porque desta regra (como descrito na nota OSS 1860433)?
Obrigada,
Gabriela
Bom dia Gabriela,
Para desativar o comportamento descrito você teria que alterar o código standard, removendo a verificação de implementação (na função J_1B_NF_MAP_TO_XML).
Eu imagino que o motivo pelo qual você só possa ter uma BAdI sendo executada por vez é que podia ocorrer conflito entre as implementações.
[]'s
JN
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Oi
A ativação da badi J_1BNF_ADD_DATA desativa automaticamente a badi CL_NFE_PRINT (métodos Fill_Header e Fill_Item).
Acho que nem preciso dizer... se você modificar o standard e tiver algum problema não terá o suporte da SAP.
O jeito é migrar completamente o seu código. Sei que pode ser complicado... já vi clientes com 3.000 linhas de código na badi e foram tantas pessoas que mexeram que o risco de fazer isso é grande.
Abraço
Eduardo Chagas
Gabriela,
O mais correto é seguir o que o disse: migrar a BAdI p/ a J_1BNF_ADD_DATA. Caso você se depare com alguma informação que esta não possua, sempre existe a possibilidade de usar dirty assigns.
Aqui na empresa ainda usamos a CL_NFE_PRINT, pois no primeiro momento, a aderência da nova BAdI não era tão boa.
[]'s
JN
Interessante, Jose Nunes, eu acho mais aplicável no nosso caso então preencher o campo da NF que queremos durante a geração do XML utilizando esta tática, ao invés do contrário, ou seja: deixamos de usar a J_1BNF_ADD_DATA e mantemos a CL_NFE_PRINT, porque temos muito mais campos sendo preenchidos durante a geração do XML do que durante a criação da NF e que não adiantaria existirem na NF porque não estão sendo capturados pela J_1B_NF_MAP_TO_XML (a nao ser que sejam preenchidos nas estruturas fornecidas por esta Badi).
Obrigada pelas dicas!
Oi Gabriela
Assim... como uma exclui a outra... você teria que aplicar as regras que você tem na fill_header e fill_item na *add_data.
Só que isso não será uma tarefa simples. Pois o *add_data envolve a aplicação de diversas notas pois ela trata também da persistência dos dados. Isso quer dizer... as informações que hoje você altera via badi e ficam somente no xml passam a ficar nas tabelas do SAP.
Além disso nem todos os campos que hoje você pode alterar via fill_header e fill_item podem ser alterados na *add_data.
O lado bom é que você tem algora alguns campos que são levados para o xml via configuração e que antes você precisava tratar via badi.
Abraço
Eduardo Chagas
Entao, Tiago, como há campos no XML que no momento apenas podem ser preenchidos via os métodos da Badi CL_NFE_PRINT, uma solução que eu encontrei foi criar um enhancement na função J_1B_NF_OBJECT_UPDATE, que é chamada durante a criação da NF, e lá preencher os campos que eu preciso, ao invés de usar a Badi J_1BNF_ADD_DATA, para permitir que a CL_NFE_PRINT continue sendo chamada na geração do XML outbound.
Muito obrigada a todos pela discussão.
User | Count |
---|---|
6 | |
5 | |
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.