Dev Telluria
-
Total de ítens
91 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Dev Telluria
-
-
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!
-
Fizemos as alterações e deu certo!
Muito obrigada.
-
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!
- 1
-
Claro, segue anexo dos arquivos.
-
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
-
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.
-
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?
-
Estamos analisando a partir desse retorno!
-
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.
-
O modelo da balança é Toledo Prix 8217
-
Estou verificando o modelo das balanças, para ajudar na análise.
-
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?
-
18 horas atrás, José M. S. Junior disse:
Boa tarde, favor atualizar com a última versão baixada pelo fórum, nessa ultima versão de build, agora já esta ok o ajuste.
Obrigado @José M. S. Junior!
Agora está correto!
- 1
-
31 minutos atrás, José M. S. Junior disse:
Isso não vai interferir é por que não está sendo gerada pelo nosso server de build.
Convenção é STDCALL no seu caso, segue abaixo a versão correta:
ACBrBoleto32.zip 2 MB · 0 downloads
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!
- 1
-
15 minutos atrás, José M. S. Junior disse:
Boa tarde @Dev Telluria,
Até que seja resolvido o problema no buid da lib, estou disponibilizando aqui a versão da lib compilada localmente por aqui.
Favor testar com essa lib, estou disponibilizando a versão MT e ST 32bits, utilize conforme a versão da sua aplicação:
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)
-
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.
-
3 horas atrás, José M. S. Junior disse:
Boa tarde,
Realmente não está atualizando com o fonte alterado na versão disponibilizada da lib. Estamos verificando o que está ocorrendo.
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.
-
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.
-
2 minutos atrás, José M. S. Junior disse:
Estranho, pois a versão da lib foi gerada depois de atualizado o fonte no repositório com o ajuste, vamos gerar outra versão para teste...
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.
-
49 minutos atrás, José M. S. Junior disse:
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.
-
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")
-
42 minutos atrás, José M. S. Junior disse:
Bom dia,
Por favor atualize a lib novamente para testes, creio que resolvemos nessa versão.
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.
-
21 horas atrás, José M. S. Junior disse:
Referente as notas no arquivo ini, a documentação estava desatualizada, favor testar preenchendo conforme documentação atualizada. Mas de qualquer forma estamos corrigindo para não ocorrer o erro atual.
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?
-
4 minutos atrás, José M. S. Junior disse:
Poderia anexar o log.txt da lib, se possível...
Segue log em anexo.
Cliente com erro "Versão do leiaute do arquivo de entrada do sat não é válida"
em Dúvidas gerais
Postado
O cliente só liberou o acesso para amanhã cedo, assim que possível retorno a versão. Obrigada!