Ir para conteúdo
  • Cadastre-se

Dev Telluria

Membros
  • Total de ítens

    91
  • Registro em

  • Última visita

Tudo que Dev Telluria postou

  1. O cliente só liberou o acesso para amanhã cedo, assim que possível retorno a versão. Obrigada!
  2. Bom dia! Estamos com um problema em um cliente, onde ele tenta emitir qualquer nota e retorna o erro "Versão do leiaute do arquivo de entrada do sat não é válida". A versão configurada no cliente é a 0.08, onde nos outros clientes está funcionando normalmente. Tentamos atualizar a DLL mas não tivemos sucesso. Poderiam ajudar? Em axexo coloquei o Logs do ACBrLibSAT que retornou no cliente e o INI da venda. Obrigada! CFe001.INI ACBrLibSAT-20230921.log
  3. Fizemos as alterações e deu certo! Muito obrigada.
  4. Boa tarde! Verificamos em nosso sistema, e realmente não passamos o campo referente ao regime tributário. Vamos fazer alguns testes aqui e qualquer coisa retorno novamente. Muito obrigada!
  5. Claro, segue anexo dos arquivos. CFe002.INI Cliente-CFe002.INI
  6. Bom dia! Estamos com um problema em um cliente, onde ele tenta emitir qualquer nota e a funçao EnviarDadosVenda está retornando Nulo ou o erro "Não informado o código do produto". Já verificamos várias coisas, e não conseguimos detectar onde pode está falho o código do produto ou outro campo. Poderiam ajudar? Em axexo coloquei os Logs do ACBrLibSAT e ACBrSat que retornou em desenvolvimento e também que retornou no cliente. Obrigada! ACBrLibSAT-20230831.log ACBrSat20230831.log Cliente-ACBrSat20230830.log Cliente-ACBrLibSAT-20230830.log
  7. Entendi, o caso é que sempre utilizamos a convenção de chamadas StdCall em nosso projeto, inclusive a versão que estava rodando sem problemas era a '.198' e o retorno para o método StatusServico é: "[Status]\r\nCStat=107\r\nCUF=31\r\nDhRecbto=08/03/2023 08:27:53\r\nDhRetorno=\r\nMsg=Servico em operacao\r\nTMed=1\r\nVerAplic=14.5.03-OR3\r\nVersao=4.00\r\nXMotivo=Servico em operacao\r\nXObs=\r\ntpAmb=2\r\n" Ao saber que iria ocorrer a alteração da URL de consulta para NFCe MG resolvemos atualizar também a dll e dependências e ao utilizar a convenção StdCall da versão '.225' tivemos aquele retorno com aqueles caracteres estranhos no início, ocasionando erro. Retorno versão '.225' StdCall: "˜é‚&Ñ£\u0003'¸\0\0\0tat=107\r\nCUF=31\r\nDhRecbto=06/03/2023 16:34:11\r\nDhRetorno=\r\nMsg=Servico em operacao\r\nTMed=1\r\nVerAplic=14.5.03-OR3\r\nVersao=4.00\r\nXMotivo=Servico em operacao\r\nXObs=\r\ntpAmb=2\r\n" Devido a isso observamos que projetos em C# aceitavam as duas convenções de chamadas e resolvemos fazer um teste também para a convenção Cdecl, e obtivemos o retorno sem os caracteres estranhos. Em resumo, depois da versão StdCall '.198' que utilizavamos sem ocasionar erro, colocamos a '.218' e em todas versões após essa que testavamos o retorno era com caracteres estranhos.
  8. Boa tarde, Notamos que iria ocorrer uma alteração na URL de consulta para NFCe de Minas Gerais e então resolvemos atualizar a dll ACBrNFe32 e dependências. Utilizamos a dll versão '.224' localizada em \bin\MT\StdCall E na chamada do procedimento StatusServico() obtém o retorno : "˜é‚&Ñ£\u0003'¸\0\0\0tat=107\r\nCUF=31\r\nDhRecbto=06/03/2023 16:34:11\r\nDhRetorno=\r\nMsg=Servico em operacao\r\nTMed=1\r\nVerAplic=14.5.03-OR3\r\nVersao=4.00\r\nXMotivo=Servico em operacao\r\nXObs=\r\ntpAmb=2\r\n" E ao utilizar a dll com a conveção Cdecl em \bin\MT\Cdecl obtém o retorno: "[Status]\r\nCStat=107\r\nCUF=31\r\nDhRecbto=06/03/2023 16:27:14\r\nDhRetorno=\r\nMsg=Servico em operacao\r\nTMed=1\r\nVerAplic=14.5.03-OR3\r\nVersao=4.00\r\nXMotivo=Servico em operacao\r\nXObs=\r\ntpAmb=2\r\n" Está com algum erro a dll de \bin\MT\StdCall? E apenas a atualização da dll com as dependências já resolve a questão da nova URL de consulta ou é necessário também o arquivo ACBrNFeServicos.ini?
  9. Olá pessoal! Abrimos um tópico no mês de Agosto referente a um problema onde ocasionalmente a função LePeso() está retornando o valor 9. Foi orientado enviar o log da balança para analisar o problema, mas tivemos uma dificuldade em conseguir pegar o log no cliente. Por essa demora o tópico acabou sendo fechado. Estou reabrindo para que possa ser analisado o que poderia ser esse valor 9. Em anexo já está o log da balança do cliente. O modelo da balança é Toledo Prix 8217. logs.txt
  10. O modelo da balança é Toledo Prix 8217
  11. Estou verificando o modelo das balanças, para ajudar na análise.
  12. Bom dia pessoal! Estamos com um problema ocorrendo em mais de um cliente, as vezes a função LePeso() está retornando o valor 9, o que não tem nada a ver com o peso que está na balança, estamos na dúvida se isso é um código de erro ou o que pode ser esse valor 9. Mas segundo a documentação, os códigos de erro são apenas -1 e -10. O que poderia ser esse valor 9?
  13. Obrigado @José M. S. Junior! Agora está correto!
  14. Boa noite @José M. S. Junior! Essa versão funcionou! Gerou o arquivo corretamente! Iremos utilizar essa versão provisória até voces resolverem a questão da disponibilização da lib. Vou deixar este tópico aberto até esteja tudo normalizado! Muito obrigado pela atenção!
  15. Boa tarde @José M. S. Junior. Estamos utilizando a versão ST. Realizamos o teste com essa versão que vc disponilizou e agora está dando erro na inicialização da biblioteca: Segue em anexo o arquivo ini de configuração e o log. Outra coisa que verifiquei é que esse build que vc gerou está com o número da versão 0.2.0.157 (que é bem anterior a essas que estávamos testando) ACBrLib.ini ACBrLibBoleto-20220520.log
  16. Bom dia. Certo. Realmente, achei aqui o commit do José Junior de 2 dias atrás que deveria ter resolvido o problema: Peço desculpas pela minha insistencia, mas é que realmente estamos com muita urgencia nesse caso... E já estamos atrasados com nosso cliente, pois informamos um prazo mais curto pensando que o Daycoval já estaria 100% homologado no ACBr. Peço por favor que, se possível, seja priorizado a resolução desse problema de disponibilização da lib com a correção.
  17. Boa noite! Verifiquei no projeto de vocês no GitHub, na master, no arquivo https://github.com/ProjetoACBr/ACBr/blob/master/Fontes/ACBrBoleto/ACBrBancoDaycoval.pas (linhas 483 e 509), o seguinte trecho da procedure "TACBrBancoDaycoval.GerarRegistroTransacao400": Verifiquei que função DefineTIpoInscricao retorna apenas um caractere. Acredito que não possa alterar o retorno dela pois tbm é usada pra outros bancos. Então fiz uma alteração na linha 483 acrescentando um zero à esquerda, como vi que já era feito em outros bancos, ficando assim: Peço por favor que, se possível, analisem o pull request que enviei e disponibilizem uma nova versão com a correção para que possamos testar novamente.
  18. Boa tarde! Alguma posição referente ao meu último questionamento? Verificamos que vcs disponibilizaram a versão 0.2.0.179, baixamos e tentamos utilizar ela, mas continua com o mesmo comportamento errado.
  19. Está bem! Obrigado! Aguardamos seu retorno. Caso seu teste continue gerando correto, é possível olhar no código fonte se há alguma configuração que talvez estejamos passando errado que possa gerar essa posição com um caractere e não dois? (Não faz muito sentido), mas é estranho pq na versão anterior que gerava o valor errado estava formatando corretamente.
  20. Dessa vez a versão da lib está correta, eu conferi no log gerado: E mesmo nessa versão está gerando o arquivo assim: Segue em anexo o log e o arquivo de remessa gerado. 4VV18051.TXT ACBrLibBoleto-20220518.log
  21. Boa tarde! Favor desconsiderar a mensagem anterior.... Havia 2 arquivos da DLL com versões diferentes na máquina de testes e estava pegando a versão errada. Porém, o problema agora é outro: Ele está colocando essa posição como "2" em vez de "02", o que está fazendo com que todas as posições após essa comecem um caractere antes, aí a linah fica com 399 posições em vez de 400. (Acontece dessa forma tanto na versão "0.2.0.177" quando na "0.2.0.178")
  22. Acabamos de testar na versão "0.2.0.178" e continua gerando a posição com o valor errado. Vcs testaram gerar o arquivo com os INI que enviei? Verificaram o conteúdo do arquivo gerado? No caso está ficando errado na LINHA 4 do arquivo (referente ao título 2), na posição 2 a 3.
  23. Bom dia! Referente ao registro de NFe, realizamos o teste gerando o arquivo INI conforme a nova documentação e o erro de "Out of Memory" parou de ocorrer. Obrigado! Enviamos o registro gerado para honologação junto ao banco e estamos aguardando o retorno. Quanto à questão do tipo de inscrição que continua gerando errado, tem alguma posição?
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.