Nota Fiscal de serviço Município de São Paulo - Acentuação

[bochnia]

Olá!

Estou dedicando tempo aos estudos devido a um problema com a nota fiscal de serviço para o Município de São Paulo. Percebi que há um problema com a conversão "NativeStringToUTF8".
Essa conversão não está funcionando corretamente, pois não está fazendo a transição adequada para "UTF8Encode" e posteriormente para "AnsiString". Isso está resultando na perda de caracteres especiais e na codificação inadequada dos mesmos.

[Juliomar Marchetti]

está usando oACBrNFSeX?

está com que versão do delphi?

[bochnia]

Estou usando.

Delphi 11.3
ACBrNFSeX
 

[Juliomar Marchetti]

então não deveria haver nenhum problema quanto a isso

[bochnia]

Olá!

Estaria funcionando se não for necessário colocar acentuação nas NFs, mas tente colocar acentuação em uma NF veja se funciona.

Existe um erro de conversão, no momento de assinatura gerar o erro de conversão. 

[bochnia]

Se for colocado um carácter especial "ç" na descrição do serviço e a opção  ACBrNFSeX.Configuracoes.Geral.RetirarAcentos:= False;

ao tentar abrir o arquivo gravado no disco, o XML, será apresentando o problema de codificação. 

[Juliomar Marchetti]

12 horas atrás, bochnia disse:

Se for colocado um carácter especial "ç" na descrição do serviço e a opção  ACBrNFSeX.Configuracoes.Geral.RetirarAcentos:= False;

ao tentar abrir o arquivo gravado no disco, o XML, será apresentando o problema de codificação. 

sugere alguma correção na função mencionada?

[bochnia]

Bom dia!

Acredito que a rotina responsável pelo cálculo da assinatura para o envio está realizando uma conversão para o formato ANSI. No entanto, quando o cálculo é efetuado pelo provedor, especificamente no caso de São Paulo, ele não realiza essa conversão, o que acaba gerando uma discrepância nos resultados do cálculo.

[Italo Giurizzato Junior]

Bom dia,

A rotina responsável pela assinatura é utilizada por todos os componentes DF-e, mais o eSocial e Reinf.

Sendo assim, qual quer alteração deve ser feita com muita cautela, pois pode gerar um efeito colateral no demais componentes.

[bochnia]

Bom dia,

A rotina que efetua o cálculo não está funcionando com acentuação, visto que muitos reportam o problema,
e a única solução foi ativar remoção de caracteres especiais.
 

Sei que essa rotina é utilizada em muitos módulos do ACBr.

O teste é muito simples, só adicionar um simples "ç" e ver que o cálculo não fica correto.

Eu acredito que existe uma conversão para ANSI que não é executada no provedor onde reporta fala no cálculo.

 

[Italo Giurizzato Junior]

Bom dia,

Inclui na minha lista de tarefas para analise. TK-4446

[bochnia]

Obrigado.

 

[Italo Giurizzato Junior]

Boa tarde,

Realizei diversos testes.

Se gera o XML sem vogais acentuas e cedilha o XML é assinado, enviado e o provedor não recusa por assinatura invalida.

Por outro se incluir cedilha ou vogais acentuadas, o mesmo é recusado e o motivo é assinatura inválida.

Peguei esse XML recusado pelo provedor e chequei a sua assinatura através do site:

Receita Federal do Brasil - Validador de Assinaturas (fazenda.gov.br)

Ele acusa que a assinatura é valida.

Chego a conclusão que o problema é o webservice do provedor que deve fazer uma checagem diferente.

Logo o componente esta gerando e assinando da forma correta.

Não tem o que ser alterado nele.

[Juliana Tamizou]

Boa @bochnia

Dado o exposto acima pelo Italo, onde claramente consta que trata-se de algo no provedor, seria importante sinalizar a eles a questão e até que eles resolvam, habilitar o parâmetro que remove os acentos no ACBr, desta forma você emite seus documentos sem problemas.

At.

[bochnia]

Olá @Juliana Tamizou @Italo Giurizzato Junior

Vou entrar em contato com o provedor sobre esse problema e retorno aqui.

Obrigado,