Ir para conteúdo
  • Cadastre-se

Celso Marigo Junior

Membros
  • Total de ítens

    807
  • Registro em

  • Última visita

  • Days Won

    7

Tudo que Celso Marigo Junior postou

  1. Observe que já utilizamos na resposta o formato de INI: [GRUPO] Chave=Valor Os dados que estão vindo delimitados por | (pipe), são os dados de retorno do SAT. Não podemos garantir que todos irão manter o padrão de retorno.
  2. Seu log do ACBrMonitorPLUS não contém os comandos, verifique se está habilitado para gravar os logs. Imaginei que seu problema fosse tamanho de buffer mesmo. Para minimizar o problema, tente escrever o INI da NFe em um arquivo de texto e passar o path para o arquivo no comando, assim você irá passar sempre o caminho e não o conteúdo do arquivo, reduzindo o tamanho do comando. Veja abaixo: // Comando completo no parâmetro NFE.CriarEnviarNFe("[Identificacao] verProc=DJSYSTEM 8.61 NaturezaOperacao=VENDAS Modelo=55 Serie=005 Codigo=010081...") // Salve o conteúdo do parâmetro em um arquivo de texto // c:\ACBr\ENT.TXT [Identificacao] verProc=DJSYSTEM 8.61 NaturezaOperacao=VENDAS Modelo=55 Serie=005 Codigo=010081 // Passe o comando com o path para o ENT.TXT NFe.CriarEnviarNFe("c:\ACBr\ent.txt") Observei que você está lendo um caracter por vez na resposta, recentemente modifiquei o exemplo dos fontes para ler a resposta até que seja encontrado o terminador, fica melhor de visualizar.
  3. Seu código está baseado no exemplo dos fontes do ACBrMonitorPLUS? Anexe: - Log.txt do ACBrMonitorPLUS contendo o comando enviado e resposta; - Log da excessão completa do Java.
  4. A correção para este erro já está no SVN Rev.: 13182 13/04/2017 [-] Correção na rotina de Consulta de DFes, a consulta, mesmo que passasse Path completo, estava sendo executada usando apenas a chave do DFe, assim o arquivo não estava sendo atualizado. Isso ocorria apenas quando o Path completo não possuia acentos.
  5. As correções citadas em: Já estão disponíveis na versão abaixo do ACBrMonitorPLUS
  6. Acabo de enviar uma nova versão do monitor na área de dowloads, já contendo estas correções.
  7. O erro estava sendo causado devido a um comportamento inesperado dos ultimos refactorings, onde o monitor estava sempre fazendo a consulta usando a chave do endereço, mesmo que fosse passado o path completo. Quando se consulta usando a chave o XML não é atualizado. Acabo de fazer a correção e disponibilizei a mesma para download. Favor testar e postar possíveis problemas.
  8. Disponibilizada nova versão para usuários do SAC.
  9. Sim... temos casos de clientes que preferem centralizar os XMLs em um único local. Basta apontar para caminhos na rede. Observe que se sua rede cair você terá problemas.
  10. Já foi feita uma correção para o problema citado, a nova versão para usuários do SAC, a ser liberada hoje, deverá estar com a correção.
  11. O ACBrMonitorPLUS, apesar de funcionar em rede, em modo TCP, não é recomendado para este tipo de cenário, pois não existe nenhum controle de semáforos ou threads nos componentes.
  12. until

    @siinformatica verifique seu email, acabei de enviar o convite. Em alguns casos vai para o SPAM.
  13. Fiz alguns testes aqui, e não consegui reproduzir o erro. Por padrão o ACBrMonitorPLUS salva todos os arquivos no diretório Logs, no mesmo diretório do executável do monitor, esse local, para os componentes da DFe se chama PathSalvar. Este comando CTE.ENVIAREMAILEVENTO, procura os arquivos em PathSalvar. Então quando você envia o comando com o path completo, será pesquisado primeiro por este path, caso o arquivo não exista, será pesquisado PathSalvar + o que você passou como parâmetro. Pelo seu erro parece que o arquivo não existe em: C:\Atlantis\8\Dados, ou o monitor não está conseguindo acessar o arquivo. Faça um teste, envie CTe.FileExists("c:\Atlantis\8\Dados\1101114117030529433700017257001000000229100000229401-ProcEventoCTe.xml"), antes de enviar o comando CTE.ENVIAREMAILEVENTO, e após isso anexe os logs aqui.
  14. @Maurício Blasque pedi ao responsável pelo componente que analise as alterações.
  15. Parece que já foi feita uma correção para este problema:
  16. until

    @Paulo Castro_23170, você deve ter recebido via email o convite. Verifique o SPAM.
  17. @Rogerio Luna Furlan o exemplo que você usou como base é o antigo. Fiz algumas alterações no exemplo mais novo, e já subi no SVN, estou anexando aqui para ficar mais facil. O problema neste exemplo aqui é que o aplicativo java estava tentando ler a resposta antes de o monitor gerar a resposta completa. Para garantir que ele leia a resposta completa, é necessário verificar o caracter 3, que indica final da resposta. Portanto este exemplo está funcional, fiz varios testes com comandos que retornam respostas bem longas, e tudo funcionou corretamente. JavaNIOSocketExample.java
  18. Anexe o seu trecho de código para que possamos analisar e tentar te ajudar.
  19. Na verdade o retorno vem pelo canal de comunicação do socket que você usou para enviar o comando. Você precisa ler a resposta nele. Veja na pasta de exemplos no diretório do ACBrMonitorPLUS existem um exemplo usando Socket em Java (JavaNIOSocketExample.java)
  20. O ACBrMail não funciona desta forma. Você pode chamar um link Html do tipo mailto para chamar o cliente de email padrão. Mas o componente faz o envio direto sempre.
  21. Tinhamos problemas de fechamento do monitor quando usava a CAPICOM, ou quando algum programa de proteção de algum banco, geralmente o WarSaw fechava a aplicação, calssificando-a como potencialmente perigosa. O que acontece é que resolvemos estes problemas, primeiro assinando os executáveis que distribuímos com o certificado digital da DJSystem, mantenedora do ACBr. O problema da CAPICOM, foi solucionado quando interrompemos o uso da CAPICOM, a partir da versão 1.1.0.0 do ACBrMonitorPLUS. Se o anti-vírus ou warsaw não está fechando a sua aplicação, e você testou usando outra lib para assinatura e comunicação ssl além da CAPICOM, tipo OpenSSL ou WinCrypt, por favor, tente levantar mais informações que podem estar causando o fechamento do aplicativo. O problema não está ocorrendo com frequência com os usuários, portanto provavelmente é algum problema de máquina ou SO. Para verificar se ele está executando, recomendamos o uso do Mutex
  22. @atlantisnanet por favor teste novamente com a versão que acabei de disponibilizar. Fiz alguns ajustes nos paths e carregamento dos eventos.
  23. @jamil o erro ocorreu pois o monitor estava obrigando informar um path para o XML da NFe, neste caso é obrigatório apenas o path do evento. Fiz uma correção no monitor para resolver o problema. Baixe a nova versão no link abaixo:
  24. O @Juliomar Marchetti tem toda razão, observe nos logs abaixo, o comando sem as aspas não funciona, mas bastou delimitar os parâmetros que ocorreu o envio com sucesso. 04/04/2017 16:49:59 - Nfe.EnviarEmail([email protected], \\samba.djsystem.local\Publico\desenvolvimento\celso\35161205481336000137550010000000041059177461-nfe.xml, 1, Seguem DANFE e XML,,) 04/04/2017 16:49:59 - ERRO: Arquivo d:\Desenvolvimento\Pascal\componentes\acbr_trunk2\trunk2\Projetos\ACBrMonitorPLUS\Lazarus\Logs\ \\samba.djsystem.local\Publico\desenvolvimento\celso\35161205481336000137550010000000041059177461-nfe.xml n䯠encontrado. 04/04/2017 16:50:20 - Nfe.EnviarEmail("[email protected]", "\\samba.djsystem.local\Publico\desenvolvimento\celso\35161205481336000137550010000000041059177461-nfe.xml", 1, "Seguem DANFE e XML",,) 04/04/2017 16:50:25 - OK: Email enviado com sucesso
×
×
  • 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.