Limitar tamanho do XML no ERP

[Former Member]

Colocamos a NFE em produção dia 01/04/2010. Está tudo indo bem.

Tivemos um problema (que já havia ocorrido na homologação) que segundo o nosso consultor de PI é bem raro de acontecer e não tem muito o que fazer para resolver a não ser um GAMBIAIXON..rsrs

O problema em questão é que acontece (as vezes) do nosso ERP gerar uma única NF com mais de 500K (tamanho de LOTE máximo aceito pelo SEFAZ). O que causa isso com certeza não é a quantidade de itens pois já ocorreu em notas com 900 itens, 450, 300.. etc.

Quando isso ocorre a geração de lotes no GRC pára, e no monitor das NFe´s todas ficam com o status assinado. Isso acontece porque o GRC não consegue criar um lote para essa nota, já que o tamanho máximo de lote configurado é menor do que a nota e isso trava todas as outras gerações de lotes.

A gambiarra pra resolver é que gente pára o JOB no GRC (PROCESS REPORT u2013 job responsável por gerar os lotes no GRC que roda em looping) vai no monitor do GRC e aumenta o tamanho do lote para 2000K por exemplo e reinicia o job. Desta forma é gerado um lote de tamanho maior do que o aceito pela SEFAZ, que rejeita este lote. Em seguida voltamos o tamanho do lote para 500KB estornamos a nota e criamos outras duas...(simples né???? Rsrs).

Contei essa história toda para saber se algum de vocês sabe de alguma maneira de restringir no ERP o tamanho do XML de uma NF, mas pelo tamanho físico do arquivo XML e não pela quantidade de itens (hoje já temos um limite de 900 itens por nota fiscal)????

Queria implementar um controle no ERP que não permitisse gerar notas cujo XML tivesse mais de 400KB e que quando esse tamanho fosse atingido criaria uma outra nota automaticamente. Será que eu me fiz entender??rsrs

Se alguém da lista souber algo que possa nos ajudar.. agradeço.

Segundo nosso consultor, esse fato (o ERP gerar uma nota maior que o tamanho máximo do lote) não deveria travar o GRC. Este deveria ser capaz de, pelo menos, rejeitar a nota e deixar que as demais continuassem o processo normal. Segundo ele, isso seria um erro no produto GRC que a SAP já estaria tratando.

Se eu encontrar uma solução, posto aqui para todos.

Obrigado pela atenção.

Fabio Rebelo

[henrique_pinto]

Fabio,

o grande problema é que a priori vc nao tem como saber o conteudo do XML no ERP, pois somente após assinado vc tem o XML final. Assim, pra ter 100% de certeza vc teria que fazer algo no retorno da assinatura (e.g. se o tamanho eh maior que 500k jah dah erro, retorna esse erro pro R/3 e nem joga na tabela de lote, /XNFE/NFEBAT).

Uma opcao menos impactante seria vc analisar quais as causas mais comuns do estouro de tamanho. Provavelmente eh algo a nivel de item (header por maior q fosse nao deveria gerar esse impacto); daí vc analisa, pode ser algo em cima dos campos de texto de tamanho variavel (e.g. etc), pode ser os campos opcionais q sao criados pra alguns cenarios apenas (e.g. informacao de II, DI, Adicao etc.). De posse dessa analise, dai vc pode desenvolver verificacoes na exit da propria VF01/VF04 baseado nesses achados. Por exemplo, vc observou que qdo o infAdProd sai grande demais, dah pau. Dai vc ve o tamanho dos infAdProd e diz qual seria o numero maximo de itens recomendado pro tamanho medio dos InfAdProd dessa nota. E por aí vai.

Abs,

Henrique.

[former_member182114]

Bom dia Fabio,

Este "travamento" foi corrigido no GRC através da SAP Note 1447771 (SP14), com ela a nota será enviada para Sefaz sozinha e provocará uma rejeição de lote que a contém. Daí o usuário poderá pedir a inutilização na J1BNFE, tudo sem intervenção técnica.

Complementando sobre a informação no ERP...

Vejo isto como um desenvolvimento bem complexo pois existem regras que só existem na BAdI de transmissão (CL_NFE_PRINT), e o que você pretende é na criação... Ou seja, além de prever tamanhos que estão ocultos na própria existência das tags (deve-se tratar coisas como monta essa tag ou nao?) também o tamanho das BAdI's, além de fazer esta "quebra" de notas por processo (SD/MM...).

Acho que com a nota a necessidade cai em "prioridade", de qualquer forma se quiser acho seria legal fazer umas estimativas por amostragem... e tratar implementar nos processos em que podem ocorrer este "estouro".

Atenciosamente, Fernando Da Rós

Edited by: Fernando Ros on Apr 5, 2010 9:48 PM

PS: O consultor PI de vocês deu um boa forma de resolver o incidente de forma rápida, só acrescentaria na configuração Qtd.NFe = 1, para evitar que no lote se misture com NF-es Ok, depois voltar para 50 e 500.000

Edited by: Fernando Ros on Apr 5, 2010 9:53 PM

[Former Member]

Fernando,

Muito obrigado pela sua rápida e assertiva resposta...

Fiquei tão animado com a rapidez na resposta e com o sucesso na aplicação da solução que já saí aplicando nota no ambiente de homologação, fazendo testes, migrando para a produção e repassando para a lista de Basis que esqueci de te agradeceer...

Era exatamente isto que eu precisava. Agora não me preocupo mais em parar o faturamento de madrugada por causa deste problema.

Isso vai me econimizar muitas noites de sono... Valeu mesmo!!!!!!!