Diogo Loff

Bom dia, conseguiram dar uma avaliada?

Ola conseguiram dar uma avaliada neste item?

Valeu mestre!

Bom dia, segue aqui o que acontece com o fonte original. O XML mandei por e-mail, pois tem dados de cliente. Se estou emitindo a NFe não valido na receita e tento imprimir, ela fica correta: Porem após validar na receita ela fica errada, concatenando a ultima observação na sequencia: Aqui neste exemplo com o fonte original isto somente não acontece se informar uma observação no campo "InfAdic.infCpl". Se eu NÃO informar neste campo, e informar no primeiro "InfAdic.infAdFisco" e depois informar em outros InfAdic.obsFisco, InfAdic.procRef ou InfAdic.obsCont, qualquer um destes vai concatenar na "InfAdic.infAdFisco" após validar o XML. No exemplo estou informando infAdFisco e duas observações no obsCont. Com a customização que fiz este problema não acontece mais.

Opa boa tarde @Diego Foliene! Sim quando a questão do Pipe eu mesmo coloque fixo porque como disse o split não resolvia ai só resolveu pra mim, acredito que da forma como vc fez é o correto. Quando as observações que ficam ali erradas quando tem mais observações em sequencia, vou remover a alteração e te mandar o XML e o print da impressão para você ver o que acontece.

Então @Italo Giurizzato Junior boa tarde! A questão não é os FR3, e sim é a unit responsavel por montar eles. Já fiz meus testes e muitas coisas que ajustava ali já estão contempladas, tem duas situações que gostaria de pedir para ajustarem se possivel, uma eu acho que é falha pois é um campo que na impressão dos Danfse de algumas prefeituras/provedores tem, vocês tem a tag, mas não tem na classe de impressão. A outra é uma sugestão que deixa o bloco do "Descritivo" livre para usar com outras informações, como montar faturas, observações relacionadas aos itens, negociação comercial em fim. Já sugeri outras vezes, mas junto com outras solicitações que vocês não aceitaram, vou tentar novamente, mas olha com carinho. Item 1 (Implementação Faltante): ACBrNFSeXDANFSeFR.pas Provedor por exemplo Sigcorp da prefeitura de Chapecó/SC, na impressão do Danfe da prefeitura eles distingues DATA DA NFSE e DATA DO RPS, inclusive vocês leem a tag na leitura do XML, porem não tem o campo da DATA DO RPS na classe de impressão. Na linha 464 criado o campo no DataSert cdsIdentificacao.FieldDefs.Add('DataEmissaoRps', ftString, 19); Na linha 727 atribuido o campo ao report frxIdentificacao.FieldAliases.Add('DataEmissaoRps=DataEmissaoRps'); Na linha 1059 carregado o campo do objeto LCDS.FieldByName('DataEmissaoRps').AsString := ''; if ANFSe.DataEmissaoRps > 0 then LCDS.FieldByName('DataEmissaoRps').AsString := FormatDateBr(ANFSe.DataEmissaoRps); Observar que o campo já existe no objeto da NFSeX "ANFSe.DataEmissaoRps" ele somente não tem uma tag para impressão, lembrando que a adição desta tag não causa problemas se o report não tiver a mesmoa explicita dentro dele. Item 2 (Sugestão): ACBrNFSeXDANFSeClass.pas Criado propriedade para o componente TACBrNFSeXDANFSeClass chamada "ForcaDetalhamento". Esta propriedade é default Falso para assim não contaminar quem já utiliza. O intuido dela é se for setada como Verdadeira, ela sobrescreve no arquivo ACBrNFSeXDANFSeFR.pas na linha 1549 para forçar que o objeto "Memo13" seja sempre impresso. Este memo13 já existe é o do detalhamento, porem se na impressão os itens são passados de forma tabulada, este memo desaparece, para que é usado este memo, para adição de outras informações, como faturas, obsevações comerciais, etc. frxReport.FindObject('Memo13').Visible := (not ((cdsItensServico.RecordCount > 0) and (frxReport.FindObject('Page2') <> nil)) or (frxReport.FindObject('Page2') = nil)) or (DANFSeXClassOwner.ForcaDetalhamento); Sobre esta parte do detalhamento olha como fica legal se poder forçar na impressão, estou usando o FR3 padrão de vocês. Sem esta opção que citei, se eu quiser usar os itens tabulados a parte ali onde por exemplo esta saindo a forma de pagamento fica invisivel (que é o memo13), inclusive o Danfe estsa quebrando certinho se possuir mais itens e tal. Os clientes acham melhor visual assim e mais completo. Para que tem curiosidade as parcelas ali eu monto em texto corrido com tabs e usando | por exemplo para ficar formatado, isto o proprio ACBr já trata. Agradeço muito se puderem levar em conta estas melhorias. Segue anexo os fontes. Fontes.zip

Bom acabei ficando doente e não pude responder, hoje nã oestou trabalhando tb. Mas vou fazer o seguinte vou testar todas as opções e tentar ver se consigo eliminar total as customizações. Se ficar alguma coisa mando sugestão se for pertinente, até final da semana que vem respondo.

Boa tarde, galera! Seguinte, esta semana tive que atualizar todos os fontes do ACBr, e com relação ao NFSeX tenho várias customizações no DANFE, queria eliminar isto de forma completa, gostaria de usar os modelos disponibilizados pelo componente como acontece hoje com a NFe que é perfeito. Então a pergunta que tenho a fazer é: Quais dos modelos vocês indicam eu utilizar com base nos que tem disponivel no repositório? Até hoje atendo a várias cidades de diferente provedores, e sempre utilizo o modelo sem qr code com código de autorização pequeno, e outro quando a prefeitura tem o código de autorização grande com qr code. Para meus clientes o que é importante é que a descrição dos serviços, observações e dados de pagamento (faturas) saiam completos. Obrigado A um detalhe eu uso FastReports.

Bom dia, na carta de correção quando a mesma é feita para Ator Interessado não esta apresentando as informações de forma completa. Isto já acontecia antes, porem nunca mandei o ajuste pois estava usando uma versão antiga, agora que atualizei ainda permanece a mesma situação. Anexo dois reports em PDF o sem alteração e o com a alteração. Anexo também o fonte alterado ACBrNFeDANFEFRDM.pas. Neste fonte tem outras alterações que estão sendo tratadas em outro chamado relacionado a quebra de observações da NFe, então se ater somente ao bloco do Evento. procedure TACBrNFeFRClass.CarregaDadosEventos; 1 - Na metade desa rotina tem uma linha assim: if (InfEvento.tpEvento <> teCCe) then begin FieldByName('xJust').AsString := InfEvento.detEvento.xJust; if InfEvento.tpEvento = teInsucessoEntregaNFe then FieldByName('xJust').AsString := InfEvento.detEvento.xJustMotivo; end else begin ....... end Neste precisa colocar na condição do IF para que o mesmo caia no Else quando for Ator Interessado, aqui resolve para aparecer a condição de uso na impressão. if (InfEvento.tpEvento <> teCCe) and (InfEvento.tpEvento <> teAtorInteressadoNFe) then 2 - Ao final do mesmo bloco adicionar para carregar o ator interessado, usado o mesmo campo xJust pois este campo na impressão já vem para este fim, conforme o label quando é impresso. Aqui fixei um, pelo que vi não ha previsão de mais de um, mas talvez já teria que pensar em mais de um interessado. if (InfEvento.tpEvento = teAtorInteressadoNFe) then begin documentoAtor := InfEvento.detEvento.autXML[0].CNPJCPF; FieldByName('xJust').AsString := 'CNPJ: ' + documentoAtor; if (documentoAtor > '') and (length(documentoAtor) < 14) then FieldByName('xJust').AsString := 'CPF: ' + documentoAtor; if (InfEvento.detEvento.tpAutorizacao <> taNaoInformar) then FieldByName('xJust').AsString := FieldByName('xJust').AsString + ' - Tipo Autorização: ' + AutorizacaoToStr(InfEvento.detEvento.tpAutorizacao); end; ObrigadoACBrNFeDANFEFRDM.zip EVENTOS SEM AJUSTE.pdf EVENTOS COM AJUSTE.pdf

Neste item coloquei uma sugestão da parte dos eventos para converter o encoding. Não precisa mais, de alguma forma na versão nova esta vindo correto, provavelmente foi ajustado em outro ponto.

Aqui esta perfeito, no seu caso se ali esta dando erro de acessviolation é sinal que o objeto não esta vindo correto, provavelmente ficou alguma coisa errada na atualização dos fontes e instalação do componente. Ou também você tem algum path lá no libary do Delphi apontando para alguma versão do ACBr diferente.

Então não tive nenhum problema assim, atualizei os fontes ontem, somente mesmo esta questão da quebra das observações que esta meio estranha, fora isto nada. Geralmente estes erros assim de AccessViolation após atualizar o ACBr é porque faltou algum passo na atualização. Eu por exemplo sempre removo o ACBr de dentro dos pacotes do delphi, depois executo o bat para remover todos os dcu e depois rodo o instalador. Por exemplo nesta versão comparada a que eu usava em janeiro teve modificações nas libs por padrão a capicom não esta mais ativa e inclusive da um erros no componente, eu tive que abrir as unit por exemplo que usa o ACBrNFe e atualizar o componente, pois estava dando erros de properties, salvar novamente a tela e recompilar.

Boa tarde, peguei mais uma situação e fiz outra correção em outro arquivo que segue anexo ACBrDFeDANFeReport. Na função TACBrDFeDANFeReport.ManterInfAdFisco(ANFe: TNFe): String; linha 442. Tem uma verificação assim: if infAdFisco > '' then begin if ANFe.InfAdic.infCpl > '' then Result := infAdFisco + IfThen(Copy(infAdFisco, Length(infAdFisco), 1) = CaractereQuebraDeLinha, '', CaractereQuebraDeLinha + ' ') else Result := infAdFisco; end; Ela somente verifica se tem a infCpl preenchida para forçar a quebra de linhas nas observações, porem tem mais blocos posteriores a este, e se por acaso eu tenho algum outro preenchido mas o "infCpl" não, acaba ficando tudo na mesma linha. Modifiquei assim: function TACBrDFeDANFeReport.ManterInfAdFisco(ANFe: TNFe): String; // Informações de interesse do fisco var infAdFisco: string; obsSequencia: Boolean; begin Result := ''; infAdFisco := RemoverQuebraLinhaFinal(ANFe.InfAdic.infAdFisco); obsSequencia := (ANFe.InfAdic.infCpl > '') or (ANFe.InfAdic.obsFisco.Count > 0) or (ANFe.InfAdic.procRef.Count > 0) or (ANFe.InfAdic.obsCont.Count > 0); if infAdFisco > '' then begin if obsSequencia then Result := infAdFisco + IfThen(Copy(infAdFisco, Length(infAdFisco), 1) = CaractereQuebraDeLinha, '', CaractereQuebraDeLinha) else Result := infAdFisco; end; end; Criei uma variavel boolean somente para simplicar a comparação e coloquei todos os que estão baixo (ANFe.InfAdic.infCpl > '') or (ANFe.InfAdic.obsFisco.Count > 0) or (ANFe.InfAdic.procRef.Count > 0) or (ANFe.InfAdic.obsCont.Count > 0); Na atribuição inicial da variavel removi a quebra de linha do final, pois pode ser que esteja vindo do sistema com #13#10 no final e se vir assim irá acabar ficando com duas quebras após a mofidicação. Eu conferi as outras rotinas e elas todas estão adicionando a quebra sempre que possuirem dados, somente nesta que é uma das primeiras que não estava correto. Também removi um espaço em branco que estava sempre colocando ao final. ACBrDFeDANFeReport.zip

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?