Jump to content

Transforme seu banco de dados
em um app mobile!

botao_e_logo_plugmobile1.png

click.png  

 

 

 

 

 

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

Roberto.Godinho

Membros
  • Content Count

    192
  • Joined

  • Last visited

Community Reputation

23 Excellent

About Roberto.Godinho

  • Rank
    Membro
  • Birthday 01/16/1982

Contact Methods

  • Skype
    roberto.gd

Profile Information

  • Sexo
    Masculino
  • Localização
    Pato Branco

Recent Profile Visitors

1,000 profile views
  1. 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
  2. Boa tarde, Reenviando fontes atualizados com a correção proposta anteriormente. ACBrBancoCecred.pas
  3. 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
  4. 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.
  5. 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.
  6. 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".
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. Boa tarde, anexa o XML da NFe que gerou o erro
  13. 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
×
×
  • Create New...