Paulo Tenório

Não seria melhor se basear na versão do leiaute no lugar de validar por data?

Existe um problema: Estou gerando em 2017 um SPED Fiscal referente ao mês de Dezembro de 2016 e ele está utilizando o leiaute 2017. A data verificadora deve ser a inicial do período de apuração, correto? Não está acontecendo isso.

Já atualizei e compilei. Até o momento está redondinho.

Desde que todas as lojas tenham a mesma raiz de CNPJ (filiais diretas), é perfeitamente possível e eu faço uso desse recurso para as 10 filiais e a matriz da empresa em que trabalho. Para outras situações, é melhor ter um certificado para cada e utilizar os componentes ACBr individualmente.

Boa tarde amigos, Atualizei o SVN para a revisão 12729 e, após isso, não foi mais possível compilar o monitor.

Para resolver o problema revisei meu código. Agora, crio o socket junto com o formulário que vai emitir ou fazer manutenção na nota e destruo no final. Antes eu criava o socket junto com a aplicação e só destruía ao fechá-la. O problema ainda persistirá quando o usuário finalizar a tarefa com Ctrl+Alt+Del, nesse caso a conexão ficará ativa até que o monitor seja reiniciado e isso pode ser um problema ao atingir 100 conexões TCP/IP. Embora rodando num server 2012 R2, ao atingir 100 conexões TCP/IP o monitor continua recebendo novas conexões mas não responde a nenhuma. A solução definitiva seria a implementação de um collect garbage no componente, que vasculhasse e eliminasse as conexões inativas mas, no momento, não dá para estudar os fontes e implementar.

Utilizo TBlockSocket da Ararat Synapse. fSocket.SendString(Trim(Comando) + #13#10 + '.' + #13#10); Mesmo após o comando "nfe.fim", as conexões permanecem ativas no servidor.

Bom dia amigos, Utilizo o ACBrNFeMonitor Plus há muitos anos sem nenhum problema. Ultimamente a dependência do monitor tem aumentado e tende a aumentar mais ainda com o fim da nota fiscal modelo 1/1A aqui no ES. Tenho enfrentado um problema que pode ser causado por algum descuido meu na programação ou por alguma limitação do programa ou do Sistema Operacional: As conexões TCP/IP vão se acumulando e não são descartadas após o retorno das solicitações, até chegar ao ponto de travar o monitor, que precisa ser encerrado e carregado novamente para voltar a funcionar o trabalho. Existe algum comando que libera automaticamente as conexões inativas ou algum método manual de liberação que me ajude a reduzir ou eliminar esse problema?

Amigo, Existem dois caminhos recomendáveis para quem deseja utilizar o monitor (atualmente ACBrNFeMonitorPlus), seja por qual motivo for. O primeiro é assinar o SAC e ter acesso à compilações semanais, com todas as alterações e inovações acumuladas. O segundo é instalar, configurar e aprender à utilizar o Lazarus e demais componentes necessários para construir seu próprio executável atualizado. A versão aberta terá sempre uma defasagem de meses e isso poderá causar transtornos à você e/ou seus clientes.

Sim Daniel, O retorno é binário. Eu dei uma pesquisada e vi um caso em que, após o uso do método, deve ser feita uma conversão para hexa. Como não vi ganho de performance, vou permanecer utilizando o ACBrPAF1.GetACBrEAD.MD5FromString, não há motivos para reinventar a roda. Obrigado..

O método MD5(buffer) está retornando sempre uma string criptografada.

Testei em uma function FUNCTION Gerar_MD5_Registro(Tabela: TDataSet): AnsiString; VAR NFields, i: Integer; buffer : AnsiString; BEGIN buffer := ''; NFields := Tabela.FieldCount - 1; FOR i := 0 TO NFields DO BEGIN IF (LowerCase(Tabela.Fields.FieldName) <> 'chave') THEN BEGIN IF (NOT(Tabela.Fields.IsNull)) THEN BEGIN buffer := buffer + Tabela.Fields.AsString; END; END; END; Result := FormPrincipal.ACBrPAF1.GetACBrEAD.MD5FromString(buffer); //Result := MD5(buffer); END;

Fiz um teste comparativo entre as duas opções referenciadas aqui. o GetACBrEAD.MD5FromString tem ligeira vantagem de performance na geração do MD-5. Só estranhei o fato da string resultante de um ser diferente da string resultante do outro. Independente do método escolhido, o resultado não deveria ser o mesmo?

Eu tive um problema parecido. Bastou apagar alguns arquivos novos na pasta schemas que resolveu. Parece que existe uma versão que ainda não está totalmente implementada no ACBr. distDFeInt_v1.01.xsd resEvento_v1.01.xsd resNFe_v1.01.xsd retDistDFeInt_v1.01.xsd tiposDistDFe_v1.01.xsd

Há tempos que migrei para o DistribuicaoDFE. Eu adorava o ConsultaDestinadas, atualizava automaticamente a situação das notas e era bem simples e fácil de usar. Como foi avisado que sairia do ar em pouco tempo (não foi divulgada uma data certa), preferi não arriscar. Pode até ser uma falha momentânea mas, aconselho você a atualizar logo o seu sistema pois, se ainda não parou, vai parar em breve e nunca mais voltará a funcionar.

Boa tarde Gilberto. Que eu saiba não há exemplo específico. O uso é idêntico ao do componente NFe, a única diferença é que os comandos são solicitados para serem executados no servidor e o retorno é registrados em arquivo .txt ou via socket. Á sua dúvida é referente apenas ao NFe.DistribuiçãoDFe ou utilização geral?

Aqui, apagando os schemas, não mudou nada. Continuo recebendo a mesma mensagem de rejeição. Resolvido. Após a exclusão sugerida pelo BigWings, precisei reiniciar o ACBrNFeMonitor e reabrií-lo. Voltou a consultar normalmente.

Pois é Juliomar, a mudança que eu esperava era a desativação do ConsultaNFe (que após um teste com o demo verifiquei ainda continua ativo). Baixei os schemas PLNFeDistDFe_102 no Portal da NFe (liberado dia 25/10/2016) acreditando ser o motivo da rejeição e, para minha surpresa, dentro do arquivo compactado só haviam schemas da versão os 1.01 de julho/2016 (pode ter sido um descuido da SEFAZ). O que me deixa mais intrigado é o fato de ter ocorrido após as 16 horas do dia 26/10/2016 e ninguém aqui da comunidade ter se manifestado por estar enfrentando a mesma rejeição. Ou ninguém seguiu a orientação de migrar a forma de consulta ou ninguém a integrou nas rotinas de controle como eu fiz e me tornei tão dependente.

Boa tarde amigos, Desde 24/10/2016 não consigo mais realizar a Consulta de Documentos Fiscais através do ACBrNFeMonitorPlus. Hoje resolvi fazer uma experiência com o Demo do ACBrNFe e obtive o mesmo resultado, o XML é rejeitado pela versão do arquivo XML não ser suportada. Migrei minha aplicação para utilizar a nova forma de consulta porque a antiga iria ser desativada. Para minha surpresa, o Consulta NFe Destinadas funciona normalmente ainda. Alguém está passando por isso ou sabe me orientar sobre como corrigir ou é caso de mudança no código do componente para passar a utilizar outra versão de arquivo XML? Obrigado.

Boa tarde amigos, Desde o dia 26/10/2016 venho recebendo uma mensagem de erro no retorno da SEFAZ: ERRO: Rejeicao: Cabecalho - Versao do arquivo XML nao suportada Rejeicao: Cabecalho - Versao do arquivo XML nao suportada. Recompilei o ACBrNFeMonitorPlus e o problema permanece. Atualizei os schemas e nada resolveu. Alguém pode me dar uma orientação sobre como resolver? Obrigado.

Eu tive vários problemas com mapeamento no Windows. Ficou mais eficiente fazer tudo por socket, até porque, o objetivo do servidor é centralizar tudo. O que o cliente precisa, pede ao servidor e manipula o retorno.

Tomara que sim, vamos aguardar mais manifestações. Por mais que eu vasculhe o repositório para entender todos os recursos existentes, nunca deparei-me com o que deseja. Eu, por exemplo, carrego num componente ACBrNFe com LoadFromString o retorno de um LoadfromFile solicitado ao ACBrNFeMonitorPlus e executo o preview para oferecer essa funcionalidade. Pode ser que esse seja o único caminho.

É só acrescentar ssl_openssl_lib na uses da unit ACBrDFeOpenSSL.

Bom dia amigos, Hoje, 14/10/2016, após a atualização do SVN para a revisão 12479, o Lazarus indica uma falha de identificação de objeto: ACBrDFeOpenSSL.pas(966,15) Error: Identifier not found "d2iX509bio"

Resolvido. Obrigado Daniel.