Precisa Informatica
-
Total de ítens
361 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Precisa Informatica
-
-
Em 10/04/2024 at 17:11, Renato Rubinho disse:
Parece correto sim.
Perfeito, é a melhor coisa sempre manter erros diferentes em tópicos específicos.
O problema nesse caso específico é que o problema do outro tópico é geral na Lib e pode ser que ele esteja influenciando este caso aqui.
Não tenho cenário de testes aqui, mas nosso amigo @antonio.carlos vai verificar assim que possível.
Por enquanto, se quiser verificar se resolve, não conheço sua linguagem, mas segue uma sugestão.
Tente fazer a assinatura da função sem a atribuição ByVal na eProtocolo e veja se muda algo.
Public Function ConsultarReinf(eProtocolo As String
Boa tarde, Renato.
Essa questão do método de consultar era erro meu aqui.
O parâmetro eProtocolo estava na passagem Long, mas ele tem de ser String.
Ficou assim então:
Private Declare Function Reinf_ConsultarReinf Lib "ACBrReinf32.dll" (ByVal eProtocolo As String, ByVal buffer As String, ByRef bufferSize As Long) As Long
Agradeço a atenção!
-
1
-
-
13 minutos atrás, Renato Rubinho disse:
Boa tarde,
O problema do outro tópico foi resolvido?
Se estiver com a lib incorreta, os métodos podem não funcionar ou se funcionarem podem haver anomalias.
Boa tarde!
Quanto ao problema do outro tópico, não está resolvido. Respondi agora a pouco ali...
Mas acredito que esteja com lib correta. Peguei essa DLL 32 que marquei no print.
Acabei abrindo esse outro tópico aqui para não misturar os dois problemas.
-
14 minutos atrás, Renato Rubinho disse:
Boa tarde,
Seguem considerações:
1. Evite utilizar as dlls na SysWOW64 ou System32, apague também esta que você copiou.
2. Copie novamente a dll, atente-se a pegar da pasta StdCall, cole na pasta onde está o seu exe compilado ao invés de colar na SysWOW64.
3. Se você estiver utilizando chamadas Single thread, cuidado para NÃO pegar a Lb da pasta MT
Ok. Eu apaguei lá da SysWOW64 e como estou com o projeto no estágio de desenvolvimento, coloquei na pasta do executável da IDE do VB6.
Então, ocorreu a mesma coisa que antes: consegui inicializar a DLL, porém, deu o mesmo erro que já tinha dado antes
Por hora eu adicionei um tratamento de erro na minha função para ignorar esse erro e conseguir prosseguir...
-
Boa tarde!
Após o envio do R-1000 efetuado com sucesso através do método Reinf_EnviarReinf, tive um erro de "Overflow" ao chamar Reinf_ConsultarReinf para consultar o número de protocolo. (ver anexo)
Já até aumente minha variável "bufferLen" que é usada no retorno da chamada, mas mesmo assim não adiantou. Alguém tem alguma sugestão do que possa ser?
Obrigado!
-
18 horas atrás, Renato Rubinho disse:
Boa noite,
Pesquise em todas as unidades do computador e confirme se não existe uma outra cópia da ACBrReinf32.DLL que possa estar influenciando.
Boa tarde!
Eu fiz isso de retirar a DLL de todos os lugares, de modo que quando fui usar o método de inicializar já me deu "File note Found: ACBrReinf32.DLL"(ver anexo).
Depois disso coloquei a DLL somente na C:\Windows\SysWOW64, daí consegui inicializar, mas dá então esse retorno: "49 - Bad DLL calling convention".
-
Boa tarde!
Estou com um problema ao chamar via VB6 a função Reinf_CriarEventoReinf da ACBrReinf32.DLL - Versão 1.0.0.25.
Ao passar na linha(ver img1 no anexo) que invoca a função da DLL me dá o retorno: "49 - Bad DLL calling convention".
Eu já verifiquei e estou usando a DLL do tipo StdCall, a indicada para VB6.
Só que apesar do erro, notei que o ACBrLib funciona conforme o esperado, pois retorna o código 0 (ver img2), bem como cria o XML(img3) do evento na pasta que foi previamente indicada.
Porém fico "travado" nessa linha do código da chamada da função com esse erro e não consigo avançar...
Olhando o LOG no nível 4(ver img4) também não me aponta nenhum erro.
Alguém pode, por favor, verificar se tem algum problema na chamada desse método da DLL?
Segue prints em anexo.
Obrigado!
-
Bom dia, existem alguma chamada no ACBrLib para capturar o CPF digitado no PinPad?
at.te
Edson
-
Em 07/11/2023 at 13:35, Daniel InfoCotidiano disse:
boa tarde @Precisa Informatica
Nas configurações da DANFce, existem algumas opções. Mas pelo que verifiquei apenas alguns ajustes para itens e logo
https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca16.html
OK, Obrigado, pode Fechar.
-
Boa tarde,
Ao enviar um E-mail usando a Lib "ACBrMail32.dll" com uma lista de destinatário, separados por ";", e um endereço no meio da lista não for um e-mail válido, o envio vai para os próximos ou aborta o envio neste ponto?
at.te
Edson
-
39 minutos atrás, Precisa Informatica disse:
StdCall, x86,
na verdade não muda a fonte, altera o tamanho do quadro "Identificação do Emitente" ocasionando quebra de linha.
Retificando, ocorre a diferença na geração do PDF.
at.te
Edson.
-
1
-
-
20 minutos atrás, Alexandre de Paula disse:
Qual linguagem? Cdecl ou StdCall? x86 ou x64?
Ocorre o mesmo no programa exemplo?
Pergunto para podermos simular aqui.
Obrigado.StdCall, x86,
na verdade não muda a fonte, altera o tamanho do quadro "Identificação do Emitente" ocasionando quebra de linha.
-
3 horas atrás, Alexandre de Paula disse:
Bom dia,
Você usa LIB, Monitor ou componentes? Estão atualizados? Qual a versão?
Obrigado
Usamos a LIB.
está atualizado. Versão 0.4.6.254.
O que notamos é que se chamarmos na sequencia, ou seja Gera, Envia e Imprime, a impressão sai com uma configuração e se usar geração PDF ou apenas uma rotina que carrega o xml e Imprime a impressão sai com outra configuração, usando os mesmo parâmetros do .INI
at.te
Edson
-
2 minutos atrás, Daniel InfoCotidiano disse:
boa tarde @Precisa Informatica
Nas configurações da DANFce, existem algumas opções. Mas pelo que verifiquei apenas alguns ajustes para itens e logo
https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca16.html
sim, pelo manual só tem ajustes para a linha dos itens.
-
Bom dia, existe configuração para mudar a Fontes do Cabeçalho do NFCe, usando a LIB?
at.te
Edson.
-
Bom dia,
na impressão do DANFE NFe os fontes configurados saem diferentes quando impresso na sequencia de geração da NFe e quando impresso por rotina de reimpressão e geração do PDF.
Usamos o mesmo comando com as mesmas chamadas (NFe_Imprimir), deixando pegar da impressora configurada no .INI
segue exemplos da mesma nota, emitida na geração e reemissão.
Temos que fazer alguma configuração ou processo antes de emitir na sequencia da geração?
at.te
Edson
-
5 horas atrás, Alexandre de Paula disse:
Bom dia,
Normalmente em envio de email os arquivos são enviados como anexos. Você pode usar a função MAIL_AddAttachment.
Já a quebra de linha usando o MAIL_AddAltBody vai enviar como texto simples mesmo então o "Enter" (#13+#10) deve funcionar normalmente.
Caso use o MAIL_AddBody pode enviar um HTML como texto da mensagem, nesse caso as TAGs HTML normais de quebra de linha <BR> e parágrafo <P>.
Obrigado, funcionou com o desejado com o #13 + #10.
ate.te
Edson.
-
1
-
-
Boa tarde,
tem como inserir no corpo da Mensagem ao enviar E-Mail, os dados de um arquivo ou montar de forma que possa quebrar linhas?
at.te
Edson
-
Em 10/10/2023 at 14:12, Precisa Informatica disse:
Boa tarde!
Eu estou testando aqui, até o final da tarde te confirmo todos os retornos. Mas pelo que me parece está tudo ok.
Muito obrigado.
Boa tarde!
Somente para confirmar que já enviei a REINF em produção e está tudo ok.
Muito obrigado!
-
2
-
-
Em 06/10/2023 at 17:48, Renato Rubinho disse:
Boa tarde @Precisa Informatica
Foi gerada a nova versão do Monitor com a correção da leitura do R9011 e implementadas leituras do R9001, R9005 e R9015.
Por favor atualize sua versão, verifique se o problema foi resolvido e, se possível, nos informe se foi o resultado esperado.
Boa tarde!
Eu estou testando aqui, até o final da tarde te confirmo todos os retornos. Mas pelo que me parece está tudo ok.
Muito obrigado.
-
2
-
-
6 horas atrás, Diego Foliene disse:
Bom dia!
Foi gerada nova compilação do ACBrMonitor englobando ajuste visando sanar a falta do protocolo de envio na resposta do Monitor.
https://www.projetoacbr.com.br/forum/files/category/16-acbrmonitorplus-pro/
Por favor, queira atualizar e realizar novos testes.
Boa tarde!
Testei aqui e tudo certo.
Muito Obrigado!
3 horas atrás, Renato Rubinho disse:Boa tarde @Precisa Informatica
Complementando, este item ainda está em desenvolvimento e assim que for finalizado, avisaremos aqui também.
Boa tarde!
Certo, muito obrigado pelo retorno.
-
3
-
-
Citar
Veja o método a seguir, na documentação do monitor, para consultar o protocolo.
https://acbr.sourceforge.io/ACBrMonitor/ReinfConsultarReinf.html
Outra coisa importante de comentar é que ao utilizar o método "Reinf.ConsultarReinf" do ACBRMonitor, no seu retorno está vindo a seguinte mensagem:
"ERRO: Propriedade RetConsulta disponivel apenas ate a versao 1_05_01, utilize a RetConsulta_R9011 para versoes posteriores"
-
1 hora atrás, Diego Foliene disse:
Boa tarde!
Realmente, se conferirmos no programa exemplo do componente nativo, é possível observar que dentre outras modificações, foi adicionado no programa exemplo, na rotina de leitura do retorno:
Add(' **dadosRecepcaoLote'); Add(' dhRecepcao....: ' + FormatDateBr(dadosRecepcaoLote.dhRecepcao, 'dd-mm-yyyy')); Add(' protocoloEnvio: ' + dadosRecepcaoLote.protocoloEnvio);Essas informações não são lidas no retorno do Monitor.
Criada a #TK-4496 para adição das mesmas no retorno do ACBrMonitor.
Obrigado, @Diego Foliene.
-
Em 23/09/2023 at 18:27, Renato Rubinho disse:
Boa tarde,
A nova versão do Reinf que mudou.
Até a versão 1.5 ele era síncrono, você enviava o evento e já recebia o retorno com o resultado do processamento.
Exceto pelo R2099, que já era assíncrono, você recebia um número de protocolo e precisava consultá-lo para obter o resultado do processamento.
Agora, na versão 2.1.2, todos os eventos são assíncronos, você vai enviar, pegar o protocolo e consultar o resultado do processamento.
Veja o manual a seguir para entender a diferença entre as versões.
Veja o método a seguir, na documentação do monitor, para consultar o protocolo.
https://acbr.sourceforge.io/ACBrMonitor/ReinfConsultarReinf.html
Boa tarde, @Renato Rubinho.
Até a versão 1.5 ele era síncrono, você enviava o evento e já recebia o retorno com o resultado do processamento.
Certo.
Agora, na versão 2.1.2, todos os eventos são assíncronos, você vai enviar, pegar o protocolo e consultar o resultado do processamento.
Só no que tange a pegar o protocolo, eu não consigo mais pegar via arquivo de saída .txt, sendo necessário capturar o XML de retorno na pasta de retorno (ver img em anexo) e "capturar" o número de protocolo para posteriormente consultar pelo método "Reinf.ConsultarReinf", é isso?!
-
Boa tarde!
Estou adequando um sistema ERP feito em VB6 que já utilizava o ACBrMonitor para o envio do REINF na versão 1.5. Sempre que eu enviava nessa versão, o ACBrMonitor me trazia o retorno no arquivo de saída com todos os dados como código/mensagem de retorno, numero de protocolo. Retorno o qual eu jogava numa string e pegava o que eu necessitava...
Agora quando aponto para a versão 2.01.02 e faço o envio dos eventos, não recebo mais o retorno nesse "padrão", agora ele vem dizendo somente que "O lote esta aguardando processamento." (ver imagem em anexo), e não tem nem o número de protocolo para posteriormente conseguir consultar... Então, notei que na pasta C:\ACBrMonitorPLUS\Logs (pasta de arquivos webservices) está vindo um arquivo XML no formato "protocolo + -rec.xml" com os dados de código/mensagem de retorno, numero de protocolo, etc...
Então, gostaria de que alguém me confirmasse, por favor, se a partir de agora o ACBrMonitor irá funcionar dessa maneira ou se é eu que não configurei algo correto no ACBrMonitor para vir o "tipo de retorno" como vinha/vem apontando para a versão 1.5.
Desde já agradeço.
Erro na Reinf_CriarEventoReinf - ACBrLib
em ACBrLIB
Postado
Boa tarde!
Descobri o que estava causando o problema aqui.
Estava passando na chamada do método de criar evento dois parâmetros indevidamente.
Creio que tenha sido efeito de um Replace que fiz no código e afetou coisas que não deveriam...
Estava assim:
Reinf_CriarEventoReinf(eArqIni, buffer, bufferLen)
E o correto assim:
Reinf_CriarEventoReinf(eArqIni)
Desculpe o transtorno!
Muito obrigado.