[ACBR-9555][Agili] Double UTF-8 encoding em DefinirMsgEnvio corrompe série acentuada 'Única' — rejeição X800 maxLength

[Lucas Batista - Alfameta]

Ao emitir NFSe cujo modelo de RPS está cadastrado com série acentuada ("Única") dentro do cadastro de prestador, o provedor Ágili é rejeitado pelo schema:
  
"O elemento 'http://www.agili.com.br/nfse_v_1.00.xsd:Serie' é inválido - O valor 'Única' é inválido dependendo do tipo de dados 'http://www.agili.com.br/nfse_v_1.00.xsd:tsSerieRps' - O comprimento real é maior do que o valor de MaxLength".
  
O valor enviado chega como Única (6 caracteres) em vez de Única (5 caracteres). Tentei cadastrar a série sem acento, mas o servidor da Ágili valida o acento e rejeita com E26 — "Modelo de RPS não encontrado".
 
Causa raiz: o conteúdo do RPS já é gerado em UTF-8 pelo writer libxml2 (TACBrXmlDocument). Em seguida, TACBrNFSeXWebserviceNoSoap.DefinirMsgEnvio aplica NativeStringToUTF8 sobre esse conteúdo que já está em UTF-8 — uma segunda
conversão. Cada caractere acentuado é reinterpretado como cp1252 e reconvertido (Ú = c3 9a → Ú = c3 83 c5 a1), inflando a contagem de codepoints e estourando o maxLength.
  
Correção proposta (restrita ao Agili.Provider.pas): sobrescrever DefinirMsgEnvio na classe TACBrNFSeXWebserviceAgili removendo a segunda conversão (NativeStringToUTF8), já que o conteúdo chega em UTF-8 válido. Como a conversão deixou
de ocorrer no transporte (que atendia indistintamente todos os métodos), os métodos que montam XML por concatenação de strings ANSI (PrepararConsultaNFSeporRps, PrepararCancelaNFSe, GerarMsgDadosSubstituiNFSe) passam a chamar
ConverteXMLtoUTF8 localmente — garantindo a conversão ANSI→ UTF-8 exatamente uma vez, no lugar correto.

Gostaria de uma validação da parte dos avaliadores para checar se essa alteração é segura para uso em produção. Estamos precisando aprovar notas de serviço com urgência para alguns clientes nossos que são prestadores de serviço, e essa alteração foi o modo que encontrei para aprovar a NFS-e para esse cliente prestador em questão.

Em anexo
1. Um pdf de descrição mais detalhada, contendo as procedures e funções alteradas, o fluxo novo e as mensagens exatas de erro ("Alteração Agili.Provider.pdf").

2. \chamado-acbr\arquivos contém o arquivo original e o arquivo modificado para comparação.

3. \chamado-acbr\testes-chamado contém os testes realizados com os xmls gerados para cada cenário. Os testes são:
3.1 Emissão com o arquivo original, usando a série cadastrada com acento no nosso sistema (antes-cadastro-com-acento-arquivo-original-rejeitou)
3.2 Emissão com arquivo original, usando a série cadastrada sem acento no nosso sistema (antes-teste-cadastro-sem-acento-com-arquivo-original-rejeitou)
3.3 Emissão com arquivo modificado, usando a série cadastrada com acento no nosso sistema (depois-cadastro-com-acento-arquivo-modif-aprovou)

Obs: xmls editados para ocultar informações sensíveis.

chamado-acbr-agili-provider.rar

[Diego.Foliene]

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn.

Tarefa ACBR-9555

[Lucas Batista - Alfameta]

Bom dia! Alguma evolução sobre o assunto?

[Lucas Batista - Alfameta]

Boa tarde! Alguma novidade sobre o andamento da análise desse problema?