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

Boa tarde, Desculpa estar recomentando o post, apenas removi uma linha de validação que não se faz necessária. pcnNFeR.pas

Boa tarde @Alan Lucas, tem certeza que o teu serviço deve somar no total da nota? Ao meu ver os fontes do ACBr estão corretos, o que está faltando pra você é informar corretamente o campo indTot do serviço. segue nota de teste que fiz aqui e valida corretamente. 41180117493031000124650010001897951230205139-nfe.xml

@tiagosis o XML que você enviou anteriormente estava com quebras de linhas, pra salvar em banco aconselho você salvar ele no formato original. O que eu havia sugerido é que você salvasse em pasta e anexasse os mesmo aqui, mas deixa pra la. Pra tirar suas duvidas será mais fácil você pegar os demos do ACBr e testar por lá, o tipo de retorno que você mencionou "Sempre True" não procede em circunstancias normais e com a falta de detalhes não temos como te ajudar.

Na versão 4.0 deve ser informado o grupo Pag tanto para NFe quanto para NFCe, de uma olhada na NT2016.02 v1.42

Como assim? deixa eu ver se entendi, consultar todos os dados da nota a que você se refere seria informar a chave de acesso e retornar o XML completo, isso? Se for isso então não é possível. Você deve carregar o XML da NFe no componente acbr e usar o método consultar, se encontrar sua nota autorizada, cancelada o componente irá atualizar o arquivo XML com os dados do protocolo retornado.

em Teoria sim, no entanto não aconselho fazer isso de imediato, essa versão ainda tem questões não resolvidas e que carecem de atenção, como ainda tem prazo até o mês 07 aconselho deixar pra entrar com a versão nova mais tarde. Tenho a implementação quase pronta, mas não vou entrar agora, não vale a pena ainda.

Boa tarde, No caso de venda de combustível dentro da UF com ST é obrigatório a geração do grupo ICMSST quando o código ANP for um dos indicados na NT2016.02 Na situação acima, se for ler o XML a TAG ICMSST esta sendo carregada como cst60 quando deveria ser cstRep60, para corrigir o problema foi necessário uma pequena validação no pcnNFeR (Print abaixo) Estou anexando a unit alterada e um XML de exemplo, gostaria que fosse analisado e verificado a possibilidade de adicionar ao SVN. Att Roberto Godinho 41180117493031000124550020000263871168765948-nfe - ICMSST.xml pcnNFeR.pas

Copiar e colar o trecho XML não vai resolver, não tem como identificar se tem algum problema na formação dos mesmo. verifica se não esta configurado pra identar o XML: "acbr.Configuracoes.Geral.IdentarXML" Configura teu acbr pra salvar os arquivos gerados: acbr.Configuracoes.WebServices.Salvar := true; acbr.Configuracoes.Geral.Salvar := true; pega todos os arquivos gerados, inclusive o XML da própria NFe, arquivos de envio e retorno e posta, desta forma fica mais fácil ajudar.

Boa tarde, Tive problemas referente a isto também, no meu caso era remessa de faturamento antecipado, para "resolver o problema" temporariamente estou enviando tPag = 90 e valor = vNF, desta forma esta autorizando, o correto, usando a lógica, é que quando fosse tPag 90 fosse suprimido a tag ou aceitasse valor zerado.

o cstat 588 é presença de caracteres inválidos no XML, esta com o ACBr atualizado? posta um destes XML's pra gente da uma olhada. Pra você ver como está se comportando a consulta da uma depurada no método "TNFeConsulta.TratarResposta" da unit ACBrNFeWebServices, lá você vai conseguir ter uma noção de como é tratado esta situação. a propriedade confirmada é readOnly, trata exatamente os status que passei acima, o fato de não estar vindo confirmada é por causa do retorno da consulta