Fernando Amado

Desculpe, esse resto de semana foi meio corrido, estou atualizando os fontes e vou realizar o teste da geração na segunda feira pela manhã. Mais vendo o código postado acima já resolve o problema, pois o entrave estava com o bloqueio da geração do Bloco M. Obrigado.

Legal Juliomar, fiz a implementação mudando a propriedade que já existia de Veículo para uma genérica dos detalhamentos específicos e coloquei no Fast e no Fortes. Só não alterei nada com relação a combustível pois não tenho afinidade com esse tipo de produto e informação e não conseguiria testar com integridade, além de achar que como são muitos campos ficaria estranho sem quebra. Quando puder avaliar minha alteração, fique a vontade para sugerir mudanças. Abraço Fast.rar Fortes.rar

Seguindo a linha da contribuição do colega, segue a implementação para Fast Report. ACBrNFeDANFEFRDM.pas ACBrNFeDANFEFR.pas

Bom dia Pessoal, Estou com um problema na geração do SPED PIS COFINS na geração do Bloco P. Na Unit ACBrSpedPisCofins.pas ele verifica se o count do registro 145 é igual a 0 e da um exit, no entanto segundo o manual do SPED na sua ultima versão diz o seguinte: Como no caso nosso cliente não presta serviço e não fabrica produto, não geramos esse registro, no entanto a não geração dele acaba impedindo a geração do bloco P por completo devido ao seguinte código: Removi o OR dessa unit e o arquivo foi gerado e validado normalmente. Segue abaixo Unit alterada para caso eu esteja correto subirem ao SVN. ACBrSpedPisCofins.pas

Pelo que vi isso não é permitido e é de responsabilidade do desenvolvedor, pois consta no documento de perguntas frequentes de desenvolvedores pagina 9 ( http://www.fazenda.sp.gov.br/sat/duvidas_frequentes/Perguntas_Frequentes_de_Desenvolvedores_do_SAT_v09.pdf ) Acredito que isso nos obriga a manter o equipamento dentro do estabelecimento comercial.

Isso ocorreu comigo quando eu estava com um FortesReport diferente do que está versionado no SVN instalado, pois o instalador que eu tinha não gerava a BPL no local correto e o ACBR não conseguia localizar a BPL do fortes na minha maquina, troquei para o FortesReporte_ce e tudo se resolveu.

Amigo... Revoltas a parte, vou tentar te auxiliar com o seu primeiro problema. A mensagem "SAT em processamento" ocorre quando o equipamento esta processando alguma informação e fica "travado" até terminar de processar, assim que o processamento termina ele volta a funcionar normalmente. Tivemos um problema com essa mensagem em alguns CFes que ficavam travados e não conseguiam ser transmitidos ao equipamento por algum motivo desconhecido, pois não gerava log e nem erro somente esse "SAT em processamento", no entanto executamos o comando de Atualizar Software SAT o nunca mais ocorreu o problema. Quanto ao equipamento guardar os últimos 20 cupons emitidos na memoria não vejo sentido, pois a minha aplicação guarda todos, se eu precisar de algum estão todos lá. Enfim, tente atualizar o software do seu SAT e veja se o problema do SAT em processamento resolve. Abraço

Seu SAT é bematech? pois o erro 13002 é erro de comunicação com o SEFAZ e não erro relacionado ao CNPJ. Para verificar se sua chave está correta, no SGRSAT no site do sefaz logado como SH tem uma opção para validar a chave, se a chave estiver ok lá, não é ela o problema para associar. Verifique se sua internet possui as liberações necessárias para comunicar com o servidor do SEFAZ: PRÉ REQUISITOS PARA O PROCESSO DE ATIVAÇÃO/ASSOCIAÇÃO Para iniciar o processo de ativação e associação do RB-1000 FI recomendamos que sejam verificadas as seguintes configurações: • Caso você esteja ativando ou associação o equipamento em uma rede Ethernet que contenha em sua arquitetura: firewall, proxy ou bloqueio por MacAddress, recomendamos que vocês realize a liberação das portas 80 e 443 no protocolo TCP, tanto para http quanto para https. • Também recomendamos que seja feita a liberação da porta 143 UDP e da URL (ntp.cais.rnp.br). Esta URL será responsável pela sincronização do relógio do equipamento e é fundamental para a realização da ativação e associação do equipamento. • Faça a liberação das seguintes URLs caso seja necessário. Estes endereços serão necessários para que o RB-1000 FI possa realizar a conexão com a SEFAZ. – wssathomolog.fazenda.sp.gov.br – satnacional.fazenda.sp.gov.br

Desculpe se minha pergunta ofendeu, não foi essa a intenção, a ideia é sempre ajudar. Agora vamos tentar ajudar... Aqui também tivemos muitos problemas com a bematech, pois em nosso software foi desenvolvido um servidor DataSnap como um serviço do windows e esse servidor fala com um client (que é uma DLL inclusa em nossa aplicação principal). Assim como você, quando colocavamos com o TANCA funcionava perfeitamente, independente do local da DLL, já com o bematech, tivemos obrigatoriamente que manter a DLL dentro da pasta System32 (caso 32 ou na Syswow caso 64), e na maquina onde está o SAT não pode ter outra cópia da bemasat.dll, se ela estiver na System e também em outro diretório o sistema se perde e não comunica. Outra ação que tivemos que tomar foi com relação a Windows 7, que só funcionava se nossa aplicação principal estiver executando como Administrador. O bemasat.xml tivemos que deixar para detectar a porta automaticamente e não preencher a porta. Realmente a DLL especifica para x64 nunca conseguimos funcionar. Espero que alguma dessas informações te ajudem. Boa sorte na sua vida!

Você tem certeza que está usando a bemasat.dll? pois cada fabricante possui sua dll, e na teoria a dll da bema não vai funcionar no tanca, se funcionou então a dll é da tanca.

As consultas de status estão funcionando? pois normalmente os SAT de desenvolvimento já vem ativado e associado.

O SAT da Bematech RB1000 tem um grande problema com internet na hora de associar a assinatura, se você entrar em contato com o suporte da Bematech a primeira coisa que eles vão te falar é que "A internet não pode ter proxy, firewall, bloqueio, segurança, bla bla bla". Tivemos problemas com alguns clientes que tiveram que solicitar ao técnico da rede para fazer o desbloqueio. Aqui passamos a orientação do manual da Bematech ao cliente e pedimos para que ele veja com seu técnico de rede e infraestrutura. No manual da bematech eles orientam da seguinte forma:

Realmente teve uma falha, da uma olhada nesse tópico: http://www.projetoacbr.com.br/forum/topic/24208-acerto-em-libeay32pas/#comment-156260

Qual versão do Delphi você está usando? Qui tive problemas na Unit libeay32.pas depois do Commit do dia 08/09/2015 devido a troca dos {$ENDIF} para {$IFEND}, no meu Delphi7 não funcionou, voltei tudo para {$ENDIF} e estou usando normalmente.

Resolvido! Meu problema era que eu conectava e enviava o comando no mesmo botão, porém só pegava o retorno depois de enviar o comando, então ele mandava o retorno dos dois comandos na mesma string. fsSock.Connect(fsHost, IntToStr(fsPort)); fsSock.SendString(fsPrefixo + Comando + chrTerminador); Resposta := fsSock.RecvTerminated(5000, #3); Com isso o comando de pegar a resposta encontrava o primeiro limitador e retornava somente a conexão. Adicionei o comando de pegar resposta logo após a conexão e o retorno veio correto. fsSock.Connect(fsHost, IntToStr(fsPort)); Resposta := fsSock.RecvTerminated(5000, #3); fsSock.SendString(fsPrefixo + Comando + chrTerminador); Resposta := fsSock.RecvTerminated(5000, #3); Obrigado pelas dicas e pelo exemplo.

Olá Daniel, Desculpa a demora no retorno, é que tive uns problemas que acabaram me afastando um pouco do projeto. Bom, continuo tendo o mesmo problema, do exemplo que você enviou para o SVN para meu código é que ao invés de usar o TBlockSocket eu estava usando o TTCPBlockSocket, no entanto alterei meu código para usar a mesma função do exemplo e obtive o mesmo resultado. Debugando a função "RecvTerminated" do TBlockSocket quando ele pega a resposta para localizar o limitador, ele pega a string completa com outras informações e acaba vindo junto o limitador duas vezes, ai ele localiza o primeiro e retorna até ele, como mostra a imagem em anexo. Eu tenho que limpar de alguma forma o comando antes de receber a resposta?

Muito obrigado Daniel, vou realizar o teste pelo Lazarus aqui assim que conseguir um tempinho.

Boa tarde Daniel, Estou enviando o EXT sim e meu TimeOut está em 1000 : cmdTCP.SetSendTimeout(1000); cmdTCP.SendString(fsPrefixo + Comando + chrTerminador); Retorno := AnsiToUtf8(cmdTCP.RecvTerminated(1000, #03)); Agora adicionei a unit ACBrConsts em e usei a constante EXt direto de lá para garantir: Resposta := AnsiToUtf8(fsSock.RecvTerminated(1000, ETX)); Mais o problema não está ai, pois o código encontra o Terminador, o meu problema é que ele encontra o Terminador na linha errada, ele está pegando todo o conteúdo que fica no Monitor, quando eu Abro a conexão com o Monitor via socktes ele aparece no quadro de Respostas Enviadas do Monitor: ACBrMonitor/ACBrNFeMonitor PLUS Ver. 0.1.7.3 Conectado em: 27/08/15 08:48:44 Máquina: 127.0.0.1 Esperando por comandos. Na sequencia eu envio meu comando para o Monitor e no quadro de Respostas Enviadas do Monitor aparece meu comando enviado e a resposta corretamente, ficando no quadro o seguinte texto: ACBrMonitor/ACBrNFeMonitor PLUS Ver. 0.1.7.3 Conectado em: 27/08/15 08:48:44 Máquina: 127.0.0.1 Esperando por comandos. ECF.Ativo OK: False O problema é que quando pela minha aplicação eu faço a leitura do retorno ele para no final da linha "Esperando por comandos." como se ele encontrasse o terminador ali. Também não sei se está correto minha aplicação ler essa informação inteira como está fazendo, talvez realmente tenha esse terminador ali no entanto minha aplicação esteja iniciando a captura no momento errado. Já tentei de tudo, mudei a conexão para indy e mesmo assim não foi. Não acredito que o problema esteja no Monitor e sim na minha aplicação, mais realmente não sei mais onde alterar meu código para acertar isso.

Bom dia Isaque, Estou com a ultima versão disponível no Trunk2 pelo SVN. ( Revision: 9824 - Author: dopi - Date: quinta-feira, 27 de agosto de 2015 01:10:52) Tanto no caption quanto nos logs mostram a versão ACBr Monitor Ver.0.1.7.3. E continua dando esse mesmo problema, estava dando ontem e hoje com a nova versão continua o problema.

Olá Pessoal, Estou tendo problemas na leitura da resposta do ACBrMonitorPlus via sockets. Envio o comando e ele executa corrertamente, porém na hora que leio o retorno ele para antes da mensagem, como se o terminador estivesse em lugar errado. Para enviar o comando e ler a resposta faço assim: var Retorno : AnsiString; cmdTCP: TTCPBlockSocket; begin cmdTCP:= TTCPBlockSocket.Create; try cmdTCP.Connect(fsHost, IntToStr(fsPort)); sleep(1000); cmdTCP.SetSendTimeout(1000); cmdTCP.SendString(fsPrefixo + Comando + chrTerminador); Retorno := AnsiToUtf8(cmdTCP.RecvTerminated(1000, #03)); finally cmdTCP.Free; end; Ele executa o comando, no painel do Monitor aparece a resposta, mais dentro da minha variável Retorno aparece apenas: "ACBrMonitor/ACBrNFeMonitor PLUS Ver. 0.1.7.3 Conectado em: 27/08/15 08:48:44 Máquina: 127.0.0.1 Esperando por comandos." Como se o terminador estivesse em local errado. Anexo o log do monitor para auxiliar. LOG.TXT

Tem na documentação do SAT no site do SEFAz (http://www.fazenda.sp.gov.br/sat/downloads/vigentes.asp)

Temos aqui um sistema para farmácias também e estamos mandando normalmente os PBMs e tivemos problemas também com o TANCA, mais o único problema foi com relação ao tamanho da mensagem gerada pelo retorno do PBM que estourava o campo de informação complementar do equipamento. O Cristiano Abbud pelo fórum do fabricante ( http://tanca.com.br/forum/?topic=campo-infcpl ) confirmou o erro no equipamento e já abriu a solicitação da correção do equipamento, que esperamos que logo nos seja disponibilizado. O problema é que o TANCA só aceita 500 caracteres nesse campo ao invés de 5000. Nas outras marcas de equipamento do SAT não tivemos problema. Como "subterfúgio técnico" não estamos enviando o retorno do PBM dentro do campo da informação complementar e a impressão do comprovante estamos gerando via relatório após a impressão do SAT. Só confirmando o que eu falei, seu campo no XML não aceito, na tag <infCpl> está com 553 caracteres.

Depois da correção postada no Trunk2 agora as 12:00 resolveu o problema com o comando CarregarCertificadoSeNecessario; no inicio das funções Validar, Assinar e etc!

Estou com o mesmo erro porém para MDFe na hora de assinar... usando Capicom no delphi 7 e windows 7 with TACBrMDFe(TManifestos(Collection).ACBrMDFe) do begin XMLAss := SSL.Assinar(ArqXML, 'MDFe', 'infMDFe'); Ele da o access violation na linha: (ACBrDFeCapicom) // Lendo Chave Privada do Certificado // OleCheck(IDispatch(FCertificado.PrivateKey).QueryInterface(IPrivateKey, PrivateKey));

Está operando normal no XP, você está colocando junto com a DLL o arquivo bemasat.xml?