Roberto.Godinho

Boa tarde, Estou enviando algumas correções para o provedor ABASE. 1 - Ajuste no retorno da consulta a situação da NFSe, o protocolo retorna com uma barra "/" gerando erros ao salvar arquivo. Efetuado ajustes no método GerarPrefixoArquivo para remove-la. 2 - Ajuste na rotina de tratamento do retorno da consulta da situação da NFSe para identificar corretamente a situação cancelada para o provedor Abase. Gostaria que fosse analisado e adicionado ao SVN. acbrnfse.rar

Boa tarde, Reenviando fontes atualizados com a correção proposta anteriormente. ACBrBancoCecred.pas

Boa tarde, O ACBrExtenso esta convertendo errado quando se tratar de um valor acima do MaxInt(2147483647), no meu teste aqui 2147483648 (2.147.483.648) resultando e um extenso 'Zero'. Como o valor informado excede o limite do MaxInt o trunc esta deixando o valor negativo. Para melhor exemplificar segue print: Para corrigir foi trocado o tipo da variavel inteiro de integer para Int64 Segue anexo a unit alterada, gostaria que fosse analisada e adicionada ao SVN. ACBrExtenso.pas

Bom dia, Algum progresso?

Boa tarde, Estou iniciando a implementação do integrador para o CE e me deparei com um problema quando trata o retorno do Integrador (segue imagem). Notem quem o retorno do integrador na linha 6 foi o erro ocorrido sendo que o mesmo não esta com encode base64, deste modo o retorno está sendo decodificado erroneamente. Deste modo ao tratar o conteúdo do retorno está mostrando continuamente o erro "Resposta do integrador inválida". Como não encontrei nenhum método no ACBr que identifique se o texto ta em base64 preferi postar e ver se alguém tem alguma sugestão pra identificar e tratar esta situação. Lembrando que o valor normal da linha 6 é o retorno do WS encodado, este retorno sem o encode ocorre apenas em alguns caso. Se alguém tiver uma sugestão por gentileza comente abaixo.

Bom dia, Meus componentes estão sempre atualizados e não os uso instalados. Eu vi a sua implementação @Italo Jurisato Junior, mas como expliquei no outro post não resolve o meu problema e do @acgubamg, já tanto a minha alteração ou a do acgu resolvem os problemas de vez. Se puder dar uma olhada no outro post eu explanei e anexei exemplos detalhados do pro que a ultima alteração não serviu.

Boa tarde, Como o Juliomar disse essa é uma forma totalmente errada de enviar a nota. O captcha já é utilizado pra prevenir acesso mecânico ao XML, se você quebrar ele, estará burlando o sistema. Outro dia um cliente usou um desses sites que geram a danfe e baixam o XML como exemplo pedindo que fosse implementado no sistema pra ele poder baixar os XML dos distribuidores dele, usou inclusive o argumento que a assinatura do XML ficava válido, por curiosidade fui validar no validador do RS, de fato ficava válido, mas não era a mesma assinatura, simplesmente era assinado novamente o XML, foi ai que pedi pra ele baixar acessar o site da receita e baixar um XML, depois ir neste site, baixar e comparar os XML pra ver se de fato era válido, acabei com os argumentos dele neste momento. Então é o seguinte: Pode ser feito, pode, deve ser feito, não. Teu sistema é responsável pela validade fiscal dos documentos que ele gerar, se você implementar isso e o cliente de forma ignorante armazenar estes documentos e um dia a receita bater e for verificar isso, vai dar o maior bafafá pro cliente e pra você. Então fica a critério de cada um se vai ou não fazer e como vai fazer. Se você for fazer, mesmo analisando os prós e contras, tenha certeza de colocar um alerta na tela "NÃO TEM VALIDADE FISCAL".

Bom dia. A reclamação do banco Cecred é que não deve ser enviado a linha de detalhe 5 quando não existir multa. No manual Cecred em anexo, está descrito sobre esta linha de detalhe 5, nas paginas 22 item 5.1.6.4 , e página 26 as notas explicativas 14, 15, 16 e 17. Em anexo também o arquivo de remessa gerado e a unit do ACBrBancoCecred com a alteração para atender a requisição do banco Cecred. Peço que por gentileza seja analisado e adicionado ao SVN. atenciosamente, Roberto Godinho ACBrBancoCecred.pas CECRED060200.REM OC201803191029381213.pdf

Boa tarde, Me diz uma @RicardoVoigt, você utilizou os fontes do ACBr como estão hoje ou usou a unit que enviei acima? Utilizando os fontes do acbr obtenho o resultado que você mencionou, a minha alteração foi justamente pra tratar esta situação.

Na verdade não é bem assim Ricardo, o tratamento no ACBr é feito quando for informado cst60, neste caso ele vai analisar os valores e determinar o cst correto, no entanto se você informar cstRep60 ele não irá entrar nesta validação, neste caso corretamente uma vez que nem todas as condições são tratadas na validação supracitada. PS: Desculpem-me por não ter acompanhado o post a quase um mês, estava de férias e precisando esquecer o trabalho um pouco.

Bom dia, Eu continuo tendo problemas com essa rotina, visto que as alterações feitas não suprem minha necessidade quando na leitura de notas de combustível, eu fiz a alteração que ao meu ver resolve todos os problemas referente a leitura da tag ICMST, isso no dia 07/02 e ainda esta parada. Se o @BigWings ou @RicardoVoigt puder dar uma olhadinha eu agradeceria.

Bom dia, não é este o caso jovem, note que na NT dependendo do ANP exige a tag ICMSST mesmo não destacando o ICM da UF Destino outros ANPs exigem o ICMS60, mesmo no caso do seu exemplo se tratar de uma venda interna onde não gera icms da UF Dest. Em anexo coloquei um XML onde tem o exemplo com os 2 tipos de ANP gerando ICMSST e ICMS60. 41180217493031000124550050000027651607355953-ProcNFe.xml

Boa tarde, anexa o XML da NFe que gerou o erro

Bom Dia @Italo Jurisato Junior, Não é possível validar da mesma forma Italo, no print abaixo, note que ambos os produtos são combustiveis, 1 deles o ANP exige ICMSST e outro ICMS60, ambos tem retenção, portanto a validação do cst41 pode ser descartada, já a validação do vBCICMSSTDest não pode ser usada devido ao fato de, quando for venda na UF, este valor vir zerado. Lendo o campo é a forma mais segura de identificar este campo, entendo que não é um campo, no entanto o leitor vai ler o grupo "<ICMS>" e identificar os valores dentro deste grupo independente do CST, desta forma o meio que achei de diferencia-los é exatamente lendo o grupo <ICMSST> como sendo um campo apenas a titulo de identificar sua existência ou não. Outra forma seria validar através do Código ANP como abaixo, no entanto achei menos viável. class function TValidaUtils.ValidaICMSSNxANP(ACodAnp: Integer): Boolean; const cCOD_ANP: array [0..61] of Integer = ( 210203001, 320101001, 320101002, 320102002, 320102001, 320102003, 320102005, 320201001, 320103001, 220102001, 320301001, 320103002, 820101032, 820101026, 820101027, 820101004, 820101005, 820101022, 820101031, 820101030, 820101014, 820101006, 820101016, 820101015, 820101025, 820101017, 820101018, 820101019, 820101020, 820101021, 420105001, 420101005, 420101004, 420102005, 420102004, 420104001, 820101033, 820101034, 420106001, 820101011, 820101003, 820101013, 820101012, 420106002, 830101001, 420301004, 420202001, 420301001, 420301002, 410103001, 410101001, 410102001, 430101004, 510101001, 510101002, 510102001, 510102002, 510201001, 510201003, 510301003, 510103001, 510301001); var i: Integer; begin Result := False; for i := 0 to High(cCOD_ANP) do if ACodAnp = cCOD_ANP[i] then Exit(True); end; Estou anexando o XML utilizado no teste acima, se alguém tiver uma sugestão melhor por gentileza comente abaixo. 41180217493031000124550050000027651607355953-ProcNFe.xml

envia o XML pra gente dar uma olhada