on 11-03-2009 9:03 PM
Estamos alterando o xml e incluindo a extensu00E3o da Anfavea nos tags infApProd e infCpl. Os valores destes campos devem ser exatamente:
<infAdProd>
<![CDATA[<iditem="ABCXYZ" ped="123"/><div uM="PC"/>
<fabEntrega>123</fabEntrega>
]]>
Ju00E1 foram feitos todos os ajustes na BADI do R/3 para passagem dos valores (IF_EX_CL_NFE_PRINTFILL_HEADER e IF_EX_CL_NFE_PRINTFILL_ITEM ), poru00E9m ao enviar os dados do CDATA para o ambiente PI ele altera os caracteres < e > para & gt; e & lt; .
De acordo com o cliente (uma montadora) o CDATA u00E9 obrigatu00F3rio e deve possuir os valores < e >.
<infAdProd>
& lt;![CDATA[& lt;iditem="ABCXYZ" ped="123"/& gt;& lt;div uM="PC"/>]]& gt;
</infAdProd>
<infCpl>
& lt;![CDATA[& lt;fabEntrega& gt;123& lt;/fabEntrega& gt;
]]>
Realizamos uma alterau00E7u00E3o no PI para a substituiu00E7u00E3o destas tags HTML, poru00E9m, a nota u00E9 rejeitada pela SEFAZ. A alterau00E7u00E3o foi realizada no mapeamento da assinatura (SIGN_signOut_doc_TO_SignedNFe).
Alguu00E9m sabe alguma soluu00E7u00E3o para este problema?
Detalhes da extensu00E3o:
[http://www.anfavea.com.br/documentos/Extens%C3%A3oNF-e_v1.0-00.pdf]
Claudio,
note que o requerimento da montadora em querer exatamente as tags CDATA nao faz sentido. De acordo com o standard XML, qualquer aplicacao XML Compliant deve interpretar tanto as tags CDATA quanto caracteres especiais escapados da mesma maneira.
Para ter o formato correto mas escapado, vc deveria preencher os campos como estu00E1 fazendo na BAdI do ERP mas sem
<![CDATA[
no inu00EDcio e
]]>
no fim. Vc deveria ter algo como
& lt;iditem="ABCXYZ" ped="123"/& gt;& lt;div uM="PC"/& gt;
no conteudo da tag do XML.
Ainda, no proprio manual da SEFAZ, u00E9 dito que caracteres especiais nao podem fazer parte do conteudo das tags XML de uma NFe. Verifique o item 5.3 do Manual de Integracao do Contribuinte. Algumas SEFAZs aceitam as 2 maneiras (CDATA ou escapado), essa que vc estu00E1 testando deve aceitar apenas da maneira escapada, como exigido no manual.
De qualquer maneira, u00E9 possu00EDvel sim implementar essa modificacao como um Z no PI. Dau00ED a saber se a SEFAZ vai aprovar, vai depender de cada estado. Eu fiz um teste interno e a SEFAZ RS aprovou a nota com o CDATA, mas isso pode nao ser verdade para todas as SEFAZs. Estou publicando um wiki ainda nessa semana para mostrar como u00E9 possu00EDvel fazer essa implementacao (a proposta u00E9 exatamente usar esse mapping que vc falou).
Como estu00E1 o XML que u00E9 enviado para o assinador apu00F3s o mapeamento?
Pode ser que seu mapping esteja modificando o XML de maneira indevida.
Abs,
Henrique.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Henrique, boa tarde.
Fizemos a alteração na Badi, conforme voce mencionou e a SEFAZ valida com sucesso a nota. Quando realizamos a mudanças das tags & lt; e & gt; no mapeamento do PI, a nota é rejeitada.
Com relação a alteração do mapeamento, foi customizada conforme a solução do envio de email, ou seja, foi realizada uma cópia do SWCV standard e uma customização foi realzada no mapeamento da SIGN_signOut_doc_TO_SignedNFe. Abaixo segue a customização (UDF) realizada:
int indCDataMaior = 0;
int indCDataMenor = 0;
indCDataMaior = xml.indexOf(lt; );
indCDataMenor = xml.indexOf(& gt;);
if(indCDataMaior > 0){
xml = xml.replaceAll( & lt; , < ) ;
}
if(indCDataMenor > 0){
xml = xml.replaceAll( & gt; , > );
}
return xml;
Obs: o codigo do replace esta com aspas, retirei para postar
Pelo monitoramento é possivel verificar que o mapeamento foi realizado com sucesso, porém a nota é rejeitada pela SEFAZ SP.
Já tentamos várias customizações, porém, todas voltam rejeitadas pela SEFAZ, com exceção da customização realizada na Badi.
Voce poderia me ajudar com alguma outra customização para solucionar este problema?
Obrigado.
Henrique,
Entendi, então a Sefaz recebendo o XML com as tag's da ANFAVEA não recusaria o mesmo? apenas se chegar com caracteres especiais, correto?
Obrigado.
Danilo
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Henrique, boa tarde!
Entendi, para um serviço de mensageria Z no PI, devo identificar um mapeamento sobre o layout da NFe (após a aprovação da Sefaz) e adequar esse java mapping ao processo.
Agora uma dúvida sobre o tipo de interface, o ideal é que seja uma interface assíncrona que irá receber esse Java Mapping? pois caso dê um erro nesse processo, se for uma interface síncrona além de parar o processo (em fila?) não tem como ser reprocessado?
Existe algum problema em enviar os dados de INFCOMP e INFADPROD de uma forma para a Sefaz (dados separados por pipe) e enviar de outra forma para as montadoras (formato XML com CDATA etc)?
No aguardo, obrigado.
Danilo
Edited by: Danilo Santos de Oliveira on Jan 4, 2010 6:47 PM
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Danilo,
vc nao pode alterar o dado do XML da NF-e depois de autorizado pela SEFAZ!
Alias, nem mesmo depois de assinado. Portanto, a unica possibilidade é executar o mapping ANTES da chamada do servico de assinatura. Vc pode até mesmo faze-lo no interface mapping da propria mensagem de request da assinatura, mas depois nao.
E nao, vc nao pode mandar dados diferentes para o XML da SEFAZ e o do B2B, nas tags pertencentes ao layout NFe, tem que ser o mesmo layout. O que vc pode eh criar uma outra msg complementar ao XML da NFe, mas isso é outro case proposto pela ANFAVEA (Complemento da NF-e e nao Extensao do XML da NF-e, que é o que está sendo requerido aqui).
Att,
Henrique.
PS: nao existe fila para msg sincrona. No caso, se houve erro, provavelmente há alteracoes de dados, dai a mensageria teria que reenviar o XML para ser assinado novamente. Tem que ver como a mensageria que vc usa faz o error handling de erros de comunicacao.
Pessoal, boa tarde!
Gostaria de saber se essa solução Sample Java Mapping to create ANFAVEA NFeExtension está atrelada ao SAP GRC, pois tenho o mesmo problema com o CDATA para a ANFAVEA, porém o serviço de mensageria não é o GRC e sim uma solução Z com o PI.
Uma solução Z no PI não teria a interface SIGNN_SignNfe_TO_signIn_doc como menciona o documento.
No aguardo, obrigado.
Danilo
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As Is, sim, pois ela depende de nomes de campos e estruturas relativos ao GRC.
Mas nada impede de ser adaptada à interface da sua solucao, uma vez que ele simplesmente é um mapping executado no PI sobre o layout da NFe (que tem q existir independente da solucao usada).
A unica ressalva eh o ponto de execucao do mapping. Dependendo da sua solucao, nao ha interface assincrona para a assinatura, apenas uma interface sincrona, e o mapping teria q ser executado lá (o que impossibilitaria, contudo, a possibilidade de restart). Vc pode querer revisar os throws das exceptions nesse caso, uma vez que uma exception em uma interface sincrona eh bem indesejavel.
Att,
Henrique.
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.