Lucas Batista - Alfameta

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

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

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

Bom dia, pessoal! Espero que estejam bem. Estou com uma situação de cliente que emite boleto que possui QR Code e, por conta de usufruir benefício fiscal, precisa fazer integração de pagamento via ECONF quando o cliente paga o boleto por PIX. Ou seja, ocorre de, por exemplo, ser feito venda parcelada em 5x no boleto. O cliente paga 3 boletos com código de barras mas depois paga os 2 últimos usando PIX por meio do QR Code. Nessa situação, a contabilidade orientou a implementar o ECONF (nesse exemplo, meu entendimento é que seriam 2 ECONFs, um para cada PIX). Dúvida: nesse cenário de boleto com qrcode, em cada envio de ECONF eu preciso enviar o cAut do PIX?