Diogo Loff

Ja encontrei o problema segue sugestão: Na Unit ACBrNFeDANFEFRDM.pas procedimento "TACBrNFeFRClass.CarregaInformacoesAdicionais" linha 1492 estava fixo ainda ';' ponto e virgula, troquei pela variavel da quebra . Antes: Campos := Split(';', wObs); Agora: Campos := Split(FDANFEClassOwner.CaractereQuebraDeLinha, wObs); // não atende devido ser char Este seria o ideal, porem o Splti é char, e o caractere de quebra pode ser composto, para resolver meu problema fixei o Pipe "|". Poderia ser um StringReplace antes por #13, para depois usar o split, mas ai ferra com as observações que estão em texto corrido, estas estão já usando #13. Então tem que avaliar melhor uma solução mais completa. Vou deixar para vocês que são feras e conhecem o componente como ninguem. Campos := Split('|', wObs); // deixei fixo. Segue anexo o fonte. Aproveitando neste fonte tem uma adequação que a tempos venho fazendo, não sei se cabe para vocês ajustarem, mas tem realação quando é indicado evento de indicação de transportador que vem sempre a observação com acentuações, na impressão do evento fica tudo bagunçado a parte textual. Caso queiram ajustar. procedure TACBrNFeFRClass.CarregaDadosEventos; linha 1981. Antes: FieldByName('xCondUso').AsString := CondicoesUso; Agora: FieldByName('xCondUso').AsString := UTF8ToNativeString(CondicoesUso); ACBrNFeDANFEFRDM.zip

Bom dia então identificando aqui, acho que é algo com o report em fast ou algum bug. Não lembrava mais como aqueles campos era montados e eles são montados na tag InfAdic como xCampo e xTexto, o Pipe não esta sendo colocado pelo sistema e sim é dentro do ACBr na rotina da unit ACBrDFEDANFeReport procedimento da linha 489. Aqui ele percorre os campos e vai colocando o Pipe, porem na impressão por algum motivo não esta mais quebrando, a versão de Jan/24 na mesma rotina estava colocando ';' IfThen((i = (obsCont.Count - 1)), '', ';'); provavelmente em algum local não esta entendendo mais isto ai. function TACBrDFeDANFeReport.ManterInfContr(ANFe: TNFe): String; // Informações de uso livre do contribuinte com "xCampo" e "xTexto" var i: Integer; begin Result := ''; if FImprimeInfContr then begin with ANFe.InfAdic do begin if obsCont.Count > 0 then begin for i := 0 to (obsCont.Count - 1) do begin Result := Result + obsCont.Items[i].xCampo + ': ' + obsCont.Items[i].xTexto + IfThen((i = (obsCont.Count - 1)), '', CaractereQuebraDeLinha); end; Result := Result + CaractereQuebraDeLinha + ' '; end; end; end; end;

A certo estão padronizando tudo com Pipe isto é ótimo, sempre usei assim, mas para mim eu já não estava tendo problemas até ontem atualizar a versão. Nas observações da NF parou de funcionar o Pipe. Inclusive fazendo testes mesmo forçando não esta aceitando para este campo. Entre Pedido e Qtde de Peças deveria ter quebrado e não impresso os Pipes, a versão que eu tinha era de Jan/24 do ACBr e estava ok. Tive que atualizar devido a mudanças nas tags de credito presumido aqui em SC.

Olá! Pessoal! Mais a titúlo de duvida, até então a versão da NFe que estava usando estava com padrão default sempre sendo a quebra de linha o pipe "|", agora não mais, pelo que vi esta o ";". Bom eu ajustei a propriedade para continuar sendo o pipe pois em todo meu sistema estas informações são gravadas já assim no banco de dados. A pergunta que quero fazer é, existe algum problema continuar usando pipe? Dei uma busca no forum e vi várias discuções uns falando para não usar mais o pipe, outros falando para usar o sLineBreak, em fim mas sem nenhuma explicação do motivo.

Bom dia, não tem problemas assim de quedas, é que casualmente aconteceu um caso e fui verificar. E sim também pelo que pesquisei não tem como recuperar, este evendo que vai para o 91. No fim para estes casos estou somente incrementando a sequencia do evento em caso de falha. Bom valeu então obrigado. Pode encerrar o topico.

Sim foi. Pode encerrar.

Boa tarde @Italo Giurizzato Junior fiquei muito encucado com o que você passou. Fui testar por via das duvidas em outra maquina e funcionou. Acabei descobrindo uma coisa no menu Delphi esta configurado o CodePage como 28591, e em outros delphis aqui da empresa esta 1252. E não sei o porque, no fim estou a um bom tempo batendo cabeça com isto e é uma configuração do Delphi. E porque acontece no cliente, ocorre que as releases são justamente geradas da minha maquina, eu sou responsável pelas releases. Que loucura meu. Bom valeu ai, no fim gerei uma perda de tempo sem tamanho, aqui e para vcs ali....

Bom dia @Italo Giurizzato Junior não entendi também como você conseguiu fazer sem nenhuma modificação. No exemplo com o programa de exemplo do ACBrNFSeX conforme coloquei no print, se efetuar a consulta com os dados especificos daquela NFSe acontece erro, observar que no programa exemplo da "X201 Webserver Retornou um XML vaziu". Vou fazer um video aqui mostrando sem nenhuma adequação para lhe enviar, acho que é mais facil.

Segue anexo fiz os dois exemplos diretamente no programa de testes. Um detalhe que não falei, é que estes testes é em produção que estou fazendo, pois só neste que tenho esta situação. Sem alteração que você sugeriu inclusive da erro no programa, que o XML retornou vaziu. XML sem Alteração.zip XML com Alteração.zip E mais alguns detalhes com os debugs que fiz, pelo que vi a conversão que você sugeriu talvez não seria necessária, me parece que tem algo lá no parse "Result := ParseText(Result);" dentro do "TratarXmlRetornado", dentro dele esta entrando na primeira condição, ele esta convertendo ali corretamente para NativeString, e depois quando percorre os caracteres ali que meio que alguma coisa não faz certo, quando no final transforma novamente para UTF8 esta diferente. Bom obrigado pela atenção por enquanto.

Boa tarde senhores, então estou aqui debugando um pouco mais e sinceramente não estou entendendo o que acontece na Betha. Por exemplo removido o código de forçar a conversão que o Italo, passou, neste caso as mensagens voltaram a ficar corretas, porem acontece o ERRO do inicio deste tópico de não entender o XML. Sem a questão de forçar a conversão, dentro da string que retorna, antes de começar o "TratarXmlRetornado" no da mensagem por exemplo temos a palavra "INSCRIÇÃO" e no XML da NFSe temos a paravra por exemplo ESTAÇÃO. Na string da mensagem o ÇÂO esta representado por ção. Na string da NFSe o ÇÂO esta representado por Ã'#$0087'Ã'#$0083'O Na da mensagem que não precisa de nenhum tipo de tratamento, com o fonte sem alteração, a mesma converte correto. Na do XML da NFSe sem alteração o mesmo nem aceita pois da uma exceção dentro de um procedimento "TACBrXmlDocument.LoadFromXml" que basicamente diz que não reconhece o texto. Se força a conversão, não temos mais o erro do XML, porem ele fica todo estranho com ????, e no caso das mensagens elas também passam a ficar com ????. Anexo ambos exemplos, peguei a informação da variavel FRetorno após EnviarDados e antes do SalvarRetornoWebService na função "TACBrNFSeXWebservice.Executar". Retorno XML Mensagem.txt Retorno XML NFe.txt

To fazendo uns testes aqui e agora até as mensagens estão ficando todas atravessadas, por exemplo duplicação de RPS. Este é a string que esta sendo passada na rotina ConverteANSIparaUTF8, antes de converter. Depois de convertido fica cheio de ?????. '<env:Envelope xmlns:env=''http://schemas.xmlsoap.org/soap/envelope/''><env:Header></env:Header><env:Body><ns2:ConsultarSituacaoLoteRpsEnvioResponse xmlns:ns2=''http://www.betha.com.br/e-nota-contribuinte-ws''><ConsultarSituacaoLoteRpsResposta><ListaMensagemRetorno><MensagemRetorno><Codigo>E10</Codigo><Mensagem>RPS já informado.</Mensagem><Correcao>Para essa Inscrição Municipal/CNPJ já existe um RPS informado com o mesmo número, série e tipo.</Correcao></MensagemRetorno></ListaMensagemRetorno></ConsultarSituacaoLoteRpsResposta></ns2:ConsultarSituacaoLoteRpsEnvioResponse></env:Body></env:Envelope>' No sistema acaba ficando assim.

Bom dia, alguem tem alguma dica sobre o item acima?

Oi @Italo Giurizzato Juniorentão como eu faço para configurar para gerar os dados Soap? Qual propriedade do ACBrNFSeX é?

Somente o XML esta assim ou a impressão também esta dessa forma? Então para mim esta somente no XML, pois a impressão eu refaço sempre tenho uma customizada que monta com as informações completas, pois não uso XML de retorno, do mesmo só pego algumas informações, como a chave por exemplo. Então no meu caso sim a impressão sai certa, mas acredito que se utilizasse o XML daria problema, pois até fiz um debug para só tirar a duvida e as variaveis ficam preenchidas com caracteres estranhos. Ao abrir esse XML com o bloco de notas ele indica qual codificação (ANSI ou UTF-8)? UTF-8 e no bloco de notas no lugar ali destas ???? aparece uns quadradinhos.

Boa tarde @Italo Giurizzato Juniorentão ja adequei aqui, já colocamos no cliente e não deu mais problema. Somente uma coisa ficou estranha nos XMLs que tem estes casos é conforme o print abaixo. Pra nós não é um problema, mas ficou estranho, nestes casos é assim mesmo?

Bom dia, o provedor da Prefeitura de Siderópolis / SC não é mais Websis e sim Betha. [4217600] Nome=Sideropolis UF=SC Provedor=Betha Configuração já testada. Obrigado.

Certo @Italo Giurizzato Junior hoje não consigo mais, mas vou ver se amanhã já aplico esta adequação, e gero uma versão para o cliente que esta com bastante problemas. Ai solicito para o pessoal do suporte acompanhar e observar. Dando uma semana +/- eu responto os resultados. Obrigado.

Betha: Cocal do Sul/SC IPM: Morro da Fumaça/SC Sobre o componente o mesmo esta atualizado, até o meu relato aqui coloquei os dois exemplos mas da IPM já tem um mês por ai que não tem mais acontecido mesmo. Acabei de olhar no fonte e realmente você mudaram ali no retorno. Até conversei agora com o suporte para confirmar e realmente no IPM não esta mais ocorrendo, só esta acontecendo com Betha. Aqui no exemplo é Cocal do Sul na Betha, provavelmente deve acontecer em qualquer municipio do Betha que tenha a mesma situação, pois pegamos um cliente recente ali quase cada nota que emite é este erro ai. Talvez aplicar a mesma correção do IPM no caso da Betha possa resolver.

Bom dia! Seguinte estou com um problema para recuperar XML de evento de indicação de transportadora. Ocorre o seguinte quando durante o envio de um XML para a sefaz, se neste meio tempo cai a internet e digamos que lá na sefaz validou mas não retornou ao sistema, temos o erro de duplicação se tentarmos enviar novamente. Sempre que isto acontece seja na NFe ou nos Eventos de Cancelamento e Carta de Correção, eu faço a consulta do XML da NFe e ele me retorna todas estas informação e assim eu recupero os XML para salvar no sistema. O que esta ocorrendo agora, desde que mudou a questão da Carta de Correção para Indicar Transportadora, onde agora o Orgão é o 91 (ambiente nacinoal), entrou em vigor este mês. Se ocorre o mesmo problema não estou conseguindo recuperar este evento em específico, assim acabo ficando com o evento pendente no sistema. Até olhei nos exemplos do ACBr e não achei nada também. Tem alguma solução para isto, como que o pessoal tem feito nestes casos?

Bom dia, Juliomar! Certo então não imaginava que é algo em relação a manter versões antigas, pois ao meu ver a propria prefeitura esta mandando o arquivo em formato errado, bom eu vou esperar se surge alguma ideia ou solução, enquanto isto vou continuar a indicar o caminho para o cliente corrigir na prefeitura.

Boa tarde, então como fiz no relato ali no chamado original, que não esta dando de abrir, a questão não é do meu sistema e sim da prefeitura, vou tentar sintetizar novamente. O problema ocorre quando pegamos um cliente novo por exemplo que emitia NFSe diretamente pelo porta seja da Betha ou do IPM de sua prefeitura. Lá dentro tem o cadastro dos tomadores também, ocorre que muitos destes cadastros tem acentuação e qual o problema que ocorre. Empresa passa a emitir a NFSe pelo sistema, no sistema envia tudo sem acentuação tudo certo no RPS, porem o cadastro do tomador já foi feito anteriormente lá na prefeitura com acentuação, quando volta a NFSe ela esta vindo com os dados deste cadastro de lá e não com o que foi enviado. E assim acontece o erro, o RPS validou mas para o sistema não pois supostamente deu um erro e o mesmo fica ali preso. Ocorre que estive vendo no fonte do ACBrNFSeX e lá quando recebe o retorno tem uma conversão para UTF8 e ali acontece o problema, mas não estou dizendo que o ACBr esteja errado queria ver como contornar isto, vendo o arquivo gerado pela prefeitura se removido esta validação, o mesmo no cabeçalho do XML esta UTF-8, porem se abir o arquivo em um editor como Notepad++ o mesmo esta como ISO8891, então acontece uma incosistencia aqui, imagino que é erro destes sistemas, mas é complicado demais, pois tanto a Betha como a IPM solicitam que seja a prefeitura que solicite a verificação, já tentamos reclamar mas esta bem complicado. Qual a solução no momento, sempre que acontece isto pedimos ao nosso cliente entrar no site da prefeitura e corrigir o cadastro do tomador lá dentro, assim tem resolvido o problema, porem gera outro muita reclamação do cliente de ter que estar arrumando cadastros, então queria ver se tem mais alguem passando por isto e se tem como achar uma alternativa a resolver isto pelo componente?

Oi bom dia, eu fiz um tópico sobre um problema que estou tendo com Encoding na Betha e IPM, alguem poderia me ajudar? Abri este outro tópico pois o original por algum motivo aqui na minha maquina não esta abrindo e não consigo ver.

Então mestre era isto mesmo, eu até havia dito acima que estava com a UF certa, e estava sendo setada no componente a certa.... mas depois debugando mais a fundo detectei uma rotina um pouco antes de enviar aqui do meu sistema, que estava lendo a empresa/filial errada, e pegando os dados de outra empresa. Valeu ai pela atenção.

Ola boa tarde, já conferi a questão da UF e esta tudo correto. Vou tentar hoje ou no máximo amanhã simular a questão para enviar os dados SOAP verificar.

Sim eu uso sim, blz vou verificar como extrair isto para enviar.