Precisa Informatica

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.

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!

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.

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!

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

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

Retificando, ocorre a diferença na geração do PDF. at.te Edson.

StdCall, x86, na verdade não muda a fonte, altera o tamanho do quadro "Identificação do Emitente" ocasionando quebra de linha.

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

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

Obrigado, funcionou com o desejado com o #13 + #10. ate.te Edson.

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

Boa tarde! Somente para confirmar que já enviei a REINF em produção e está tudo ok. Muito obrigado!

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! Testei aqui e tudo certo. Muito Obrigado! Boa tarde! Certo, muito obrigado pelo retorno.

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"

Obrigado, @Diego Foliene.

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.