Nota Técnica 2019/001 - Regra de validação 1C03-10

[Marcos Carvalho]

Olá, boa tarde a todos.

Estou com uma dúvida sobre a regra de validação 1C03-10 da Nota Técnica 2019/001.

Peço desculpas caso já exista algum tópico criado, mas pesquisando não encontrei nada, apenas os tópicos de esclarecimento da NT.

 

Estou implementando algumas mudanças em nosso ERP para lidar com essa validação no que diz respeito a informar corretamente a razão social conforme cadastro da SEFAZ.

No momento estou lidando com a possibilidade da existência de caracteres especiais como aspas (simples/duplas), setas "<>", e  o "E" comercial "&". Conforme descrito no manual do contribuinte pág. 130 estou preenchendo com caracteres de escape nestas situações.

Funciona bem, exceto para as aspas que são modificas na assinatura do XML para o caractere real, removendo o código de escape preenchido por mim.

Não encontrei nenhuma configuração no componente ou algo que faria com que esse comportamento fosse modificado. Estou utilizando OpenSSL com xsLibXml2.

 

SSLCryptLib = cryOpenSSL
SSLHttpLib = httpOpenSSL
SSLXmlSignLib = xsLibXml2

 

Há algo que eu consiga modificar para lidar com esse cenário?

Agradeço desde já.

[Lauro Chicorski]

Estou passando por um problema com um cliente que a Sefaz retorna uma razão social com acentuação, entretanto quanto envio a razão social com acentuação ela me retorna uma rejeição informando que aceita somente caracteres UTF-8. Este caso ocorre com a Sefaz de MT, mas alguém passando por este problema?

[claudiomiguelmuller]

No mesmo assunto, qual o tamanho máximo de campo de razão social vocês tem em seus bancos de dados?

Qual será o máximo que as sefaz como um todo têm?

[RicardoVoigt]

3 horas atrás, claudiomiguelmuller disse:

No mesmo assunto, qual o tamanho máximo de campo de razão social vocês tem em seus bancos de dados?

Qual será o máximo que as sefaz como um todo têm?

Por enquanto só podemos se basear na quantidade de caracteres definida no MOC, de 60 caracteres (página 179).

Att

Ricardo

[Lauro Chicorski]

Referente ao problema com o caractere especial entrei em contato com a Sefaz de MT e eles ajustaram a razão social do contribuinte retirando a acentuação, depois disso consegui aprovar a nota.

[claudiomiguelmuller]

Em 10/07/2019 at 12:25, RicardoVoigt disse:

Por enquanto só podemos se basear na quantidade de caracteres definida no MOC, de 60 caracteres (página 179).

Att

Ricardo

Sim, não lembrei do manual.

[Marcos Carvalho]

Em 08/07/2019 at 17:04, Marcos Carvalho disse:

Olá, boa tarde a todos.

Estou com uma dúvida sobre a regra de validação 1C03-10 da Nota Técnica 2019/001.

Peço desculpas caso já exista algum tópico criado, mas pesquisando não encontrei nada, apenas os tópicos de esclarecimento da NT.

 

Estou implementando algumas mudanças em nosso ERP para lidar com essa validação no que diz respeito a informar corretamente a razão social conforme cadastro da SEFAZ.

No momento estou lidando com a possibilidade da existência de caracteres especiais como aspas (simples/duplas), setas "<>", e  o "E" comercial "&". Conforme descrito no manual do contribuinte pág. 130 estou preenchendo com caracteres de escape nestas situações.

Funciona bem, exceto para as aspas que são modificas na assinatura do XML para o caractere real, removendo o código de escape preenchido por mim.

Não encontrei nenhuma configuração no componente ou algo que faria com que esse comportamento fosse modificado. Estou utilizando OpenSSL com xsLibXml2.

 

SSLCryptLib = cryOpenSSL
SSLHttpLib = httpOpenSSL
SSLXmlSignLib = xsLibXml2

 

Há algo que eu consiga modificar para lidar com esse cenário?

Agradeço desde já.

Alguém tem alguma sugestão?

 

Além do problema relatado estou com dificuldades para gerar uma nota em que a razão social tenha acentuação ou cedilha.

Informando o caractere literal (Á ou Ç por exemplo) direto na razão, ao assinar, recebo de volta uma interrogação (?) no lugar desses caracteres.

Informando o caractere de escape (&Aacute; ou &Ccedil; por exemplo) o XML retornado apresenta a razão com caracteres inválidos no lugar.

Debugando, percebo que ao chamar o método LerXML do objeto NotaFiscal é utilizada a função ParseText do ACBrUtil, e dentro dela eventualmente acaba chamando a UTF8ToNativeString, que já me retorna a partir daí os caracteres zoados.

Obs. estou utilizando a configuração ACBr1.Configuracoes.Geral.RetirarAcentos = False para que mantenha o conteúdo que estou passando ao componente.

 

Aproveitando também, gostaria de saber se há alguma forma de enviar o XML que estou gerando sem ter necessidade de mandar o objeto NotaFiscal do componente ler o XML, enviar direto sem passar pelas estruturas de objetos do componente. É possível? Olhando todos os exemplos, demos, etc sempre é indicado montar a nota fiscal através destes objetos, não achei nada diferente.

Essa minha necessidade é para que eu consiga manter o XML da NFe/NFCe exatamente da forma como meu ERP gerou.

 

Agradeço desde já.