Gabriel Rogelin

Olá Italo, boa tarde! Eu acredito que sim, pois esse layout segue para todos que usam o IPM, que é um layout próprio. Isso acredito que aconteceu por terem alterado algumas rotinas no provedor recentemente e acabou ficando esse detalhe, como eles não tinham disponibilizado uma nova documentação, estávamos seguindo o padrão antigo. O que têm hoje no acbr é exatamente o que existia no layout antigo

Boa tarde! Segue o manual. (Pag. 15)Manual S-2.pdf

Bom dia! Verificamos que alguns pagamentos pelo sistema estavam diferentes do que estava no portal da IPM. Entramos em contato junto ao suporte e foi passado um novo manual com a lista de códigos atualizados. Antigo: Atual:

Boa tarde! Após esta alteração deu certo, agora mostra código e descrição do serviço corretamente. Obrigado!

Boa tarde! Segue um xml de teste. Antes esse espaço ficava em branco, exatamente. A descrição do serviço constava apenas em cima, no campo de descriminação dos serviços. Agora, mostra neste campo o código do serviço com um hífen, parece que falta a descrição do serviço. Tudo bem mostrar agora o código nesse campo que antes estava em branco, mas então também mostrar a descrição do código deste serviço, se não parece que falta informação. Ou então manter como antes, não ter essa informação, considerando que já existe a listagem com a descriminação dos serviços acima. Se tiver 2 serviços por exemplo, vai ter a descrimição dos 2 serviços conforme lançado no sistema e abaixo agora vai mostrar 2 linhas com o código do serviço e o hífen, sendo desnecessário repetir essa informação. Xml.xml

Bom dia. Identifiquei uma alteração na impressão do ItemListaServico e sua descrição, porém para o provedor IPM que usamos aqui, mostra apenas o código do serviço. Conforme imagem, após a alteração (Revision 29993), passou a mostrar essa informação, mas para o IPM, sempre mostrou a descrição normal dos serviços conforme gerado no RPS, acredito que a alteração tenha sido feita para algum outro provedor que impactou para o IPM.

Boa tarde! Após o ajuste funcionou perfeitamente. Obrigado!

Bom dia pessoal! Têm alguma novidade sobre o assunto talvez?

xml.xml

Boa tarde! Neste CT-e existem várias notas lançadas e volumes, gerando uma segunda página. O problema é que as chaves das notas não mostra e na segunda página não está saindo os campos relativos a prestação do serviço

Boa tarde! Segue configuração para ser inclusa no arquivo ini. Testado e funcionando perfeitamente. [5001904] Nome=Bataguassu UF=MS Provedor=Fiorilli Versao=2.00 ProRecepcionar=http://45.182.157.6:8086/IssWeb-ejb/IssWebWS/IssWebWS?wsdl HomRecepcionar=http://fi1.fiorilli.com.br:5663/IssWeb-ejb/IssWebWS/IssWebWS?wsdl

Bom dia! Com a alteração funcionou perfeitamente, saindo a via do estabelecimento e do cliente. A rotina ficou ok, tanto para esse TEF que gera a via do cliente e estabelecimento, quanto para outro que testamos aqui que gera apenas uma via e na segunda apenas é copiado as informações da primeira via, então para ambos deu certo. Agradeço pela atenção. Ótima semana a todos!

Sim, acredito ser algo mais antigo esta parte do fonte, justamente por esse motivo chamei vocês que conhecem mais do assunto de TEF. Estamos iniciando também a homologação com o TEF da PayGo para atender de melhor forma os clientes. Vou enviar um vídeo com uma explicação sobre o fonte do componente. Acredito que vai ficar mais fácil a compreensão. https://drive.google.com/file/d/1G0FmO7zzTeJ8G_9FIVDFpuOmsLf9P8Xq/view?usp=share_link Agradeço pela atenção

Boa tarde Juliomar. Esse funcionamento eu entendi. O fato é justamente que o componente não faz a leitura da 29 até a 56, pois a 30 está em branco. Se olhar a marcação no fonte que eu fiz vai entender. A leitura da segunda via começa na 29, mas a próxima linha(30) está em branco, então já sai do loop, mantendo apenas a primeira linha da segunda via. LinhaComprovante := Trim(LeInformacao(29 , I).AsString); while (LinhaComprovante <> '' ) do begin fpImagemComprovante2aVia.Add( AjustaLinhaImagemComprovante(LinhaComprovante) ); Inc(I); LinhaComprovante := Trim(LeInformacao(29 , I).AsString); end; Só adiciona se têm informação em todas as linhas da segunda via, e como pode ver no comporvante não têm informação na linha 30.

Seria isso que precisa? logTef.txt ACBr_TEF_Disc_001.tef

Bom dia! A impressão da segunda via neste comprovante Comprovante Venda ELGIN.txtTEF está tendo problema. A primeira via carrega normal até a linha 28, após isso, incrementa mais um, buscando a informação da linha 29, que é o início da segunda via, mas a próxima linha é em branco, e por esse motivo não pega mais nenhuma linha. Sendo assim, a impressão da segunda via sai apenas com a primeira linha. Não poderia sair da rotina se a linha for em branco, isso para esse comprovante, então não sei qual a melhor prática para ajustar isso, pois acredito que para os demais TEFs que foram testados a segunda linha da segunda VIA sempre teria alguma informação. Anexei as imagens e comprovante para melhor entendimento.

Boa tarde! Alteração do link de Gravataí RS [4309209] Nome=Gravatai UF=RS Provedor=IPM Versao=1.01 ProRecepcionar=https://gravatai.atende.net/?pg=rest&service=WNERestServiceNFSe De homologação não consegui, não sei se segue igual ou mudou também. Mas a de produção está funcionando agora com essa.

Boa tarde! Concordo perfeitamente com isso, esse é o funcionamento que deveria seguir. A quantidade do produto vendido é uma, a quantidade de volumes é outra. O problema é tirar um costume que vêm de outro sistema. Não vamos nos desgastar com essa questão. Vamos conversar novamente com o cliente, tentar fazer com que seja compreendido o uso da quantidade de volumes e mudar o preenchimento para que informe os volumes de fato que estão sendo transportados e que seja um número inteiro. Em última situação, vamos realizar o ajuste local nos fontes do acbr para contornar essa questão. Agradeço a atenção e ajuda de todos no tópico. Pode fechar!

Bom dia Victor, sou programador faz alguns anos, sei que zeros a esquerda não muda nada em um campo do tipo inteiro, conheço os manuais e sei como funciona toda essa parte. Quando eu recebi essa questionamento de imediato já imaginei o tamanho da complexidade da alteração, inclusive no meu sistema que o campo é do tipo inteiro também. O fato é, a SEFAZ permite, pois vai estar dentro do espeicifado para o campo que é numérico, por mim, entendo perfeitamente; O problema é perder cliente por esse motivo. Verifiquei qual era o sistema anterior, e eles usam TecnoSPED, que trabalha desta forma conforme a imagem que anexei. Olá Italo. A quantidade de volumes deste cliente não chega a 1. Por isso precisa do 0 a esquerda. Seria por exemplo 0200 que iria no Xml. Ele não pode colocar 0,200 de forma alguma, pois a regra de validação é clara que não pode ser decimal. O que precisaria é permitir o zero a esquerda justamente por que a sefaz não deixa ter virgula. TecnoSPED funciona desta forma, gerando no xml com 0200. Se não for possível atender tudo bem, já vamos informar as empresas que solicitaram e perder estes clientes que necessitam desta situação. Como já mencionei, entendo a complexidade e possível quebra de código para algumas aplicações. De fato é uma situação complicada e como têm outros que fazem, ficamos nesse impasse. Só preciso de uma parecer se vai ou ser possível contornar a situação de alguma forma.

O manual já olhei. Informa que é numérico, de 1 a 15, mas não proibe o uso de zeros na esquerda, ou seja, o fato de ser numérico não necessáriamente é obrigátorio ser inteiro. Pode aceitar do 0 ao 9 normalmente, é o que acontece com o sistema anterior do cliente, se não aceitasse a nota seria rejeitada. Estou batendo nesse ponto pois vamos perder alguns clientes que migramos por esse motivo, eles precisam que tenha essa possibilidade, e isso não vai contra o manual da NFe.

Bom dia! Estamos com uma situação aonde é preciso informar a quantidade de volumes no xml da NFe (qVol) com zero no início, por se tratar de uma quantidade que seria fracionada na situação de alguns clientes, teria que gerar conforme imagem, este é o xml do sistema anterior de um cliente. Por ser inteiro esta informação no componente, não aceita zeros no início. Lembrando que não queremos quantidade fracionada, até por que conforme manual a sefaz não vai aceitar. A questão é permitir o zero antes da quantidade, o que não infringe as regras de validação e atende a necessidade dos nossos clientes. Abaixo um exemplo de xml do sistema anterior

Olá! Agradeço a atenção, funcionando perfeitamente.

Segue a unit que fiz a alteração, só foi alterado essa parte da busca da observação da nota, para que se preencher o campo de OutrasInformacaoesImp a prioridade seja deste campo e não do xml da NFSe. Caso não for possível atender desta forma, tudo bem, vou alterar a cada atualização do Acbr, mas penso que tornando a prioridade de impressão da observação do que é passado manual na aplicação é melhor para os usuários, pois não depende do que vêm do Xml do provedor, que no caso do Abaco não é interessante ao usuário. ACBrNFSeXDANFSeRLRetrato.pas

Boa tarde Italo, pode ser que não tenha explicado muito bem. O código do Acbr está exatamente conforme falou, ele sempre vai priorizar o que está no xml da NFSe, caso não tenha informações no campo OutrasInformacoes do xml da NFSe, vai pegar do que estou passando na propriedade OutrasInformacaoesImp do componente. O funcionamento é esse. Mas no provedor Abaco, conforme anexei imagem, eles retornam no campo de OutrasInformacoes a informação que é enviada na descrição do serviço, ou seja, quando eu imprimir essa NFSe, o componente vai dar prioridade a observação que veio do provedor, que é a descrição do serviço e não o que o cliente digitou no campo de observações dentro do sistema. Estou passando na propriedade OutrasInformacaoesImp as informações que o cliente digita no lançamento da nota, só que não muda nada, continua pegando do que está no Xml do provedor, o provedor não deveria retornar no campo de OutrasInformacoes o nome do serviço que mandei no RPS. Considerando a situação, o que eu tive que fazer foi inverter o código, para dar primeiro prioridade ao que está no componente, que estou passando manual na propriedade OutrasInformacaoesImp e caso não passe nada, aí sim buscar do xml. Em resumo, a ideia é priorizar o que informar manualmente, se não informar nada, aí pega do xml da NFSe. Isso resolveria a situação. Ex: No RPS é gerado o campo de descrição do serviço normal na tag Discriminacao, que é Servico Teste NFSe Abaco O provedor retorna o xml da NFSe com a tag OutrasInformacoes preenchida com Servico Teste NFSe Abaco Faço a impressão da nota e nas observações mostra o nome do serviço: Servico Teste NFSe Abaco, pois o componente está considerando o que está no xml da NFSe, e não o que passei em OutrasInformacaoesImp

Boa tarde! Estou com uma situação que acontece no provedor Abaco. Ao gerar o RPS, não é informado a tag de observações, até por que o provedor não aceita essa informações no envio do RPS. O problema acontece no retorno do xml da NFSe, pois no retorno vêm com o campo de observação preenchido, mas com a descrição do serviço, então ao imprimir a NFSe, o campo de observação fica com o nome do serviço. O ideial seria pegar a observação que foi preenchida no sistema, então foi configurado para preencher no campo de observações do componente (OutrasInformacaoesImp), mas como ele da prioridade a observação que está no xml, não resolve. Imagem abaixo mostra exatamente o que acontece, no RPS temos apenas o nome do serviço, no retorno do provedor, vêm o campo de OutrasInformações com a descrição do serviço, o que ao meu ver não faria sentido, mas o provedor funciona assim. Minha questão diante a situação é a seguinte, têm como alterar esta parte do fonte para que sempre de prioridade ao que passar na propriedade do componente OutrasInformacaoesImp e não ao que está no xml? Então se tiver passado para o componente alguma observação, considera esta observação, se não, ai sim busca do xml. Isso iria resolver para outras situações também, aonde provedores não retornam a observação da forma ideial para o emissor.