strago

Olá pessoal, estava postando esse problema em outro tópico mas achei melhor abrir um novo com o problema que está me tirando do sério. Utilizo o componente ACBrNFe para gerar, transmitir, consultar, enfim, efetuar todo o processo da NFe, na versão OPENSSL e até algumas semanas atrás não tive problemas, porém, de uns tempos pra cá, toda vez que tento consultar a situação de uma nota, ou enviar uma nfe para a sefaz, obtenho uma janela de erro (mterror) com conteúdo em branco, nenhum tipo de resposta é recebido, somente essa mensagem. Para esclarecer melhor minha situação atual ... Certificado digital do tipo A1, renovado recentemente e operando normalmente. DLL´s do do componente para uso do OpenSSL atualizadas com a ultima versão disponível no svn Fontes atualizados e componentes recompilados corretamente. Schemas atualizados. Versão do Delphi 7 Para excluir problemas com o certificado, testei no emissor gratuito e operou normalmente. Peguei exemplo da NFe atualizado e compilei como Capicom e na primeira tentativa funcionou corretamente, recompilei o componente como OpenSSL e recompilei o exemplo, quando consulto o status dos serviços o xml de retorno em nulo (em branco) e não é exibido nenhuma mensagem, seja na tela, seja nos logs. Tentei enviar uma nota gerada pelo exemplo, janela de erro em branco. Voltei tudo para capicom e nada funcionou, entao deixei tudo como OpenSSL. Foi me sugerido um teste com o ACBrMonitorNFe, então gerei uma nota no meu sistema, validei e assinei, copiei o xml e validei no site da sefaz e estava tudo OK, passei para o monitor mantei consultar o status dos serviços pelo monitor SSL e ele retorna um exception em branco, no envio do xml gerado o mesmo problema, quando tentei validar o xml pelo monitor ele retornou erros de validacao e tive que alterar o schema (tipos_basicos) na parte de ISENTO do TIEDest, depois disso ele validava corretamente o xml mas o erro de consulta e envio persiste. não sei mais o que pode ser, uma excessao em branco é dificil de tratar e impossivel de localizar, mas exclui a possibilidade do problema ser na minha aplicacao, pois o erro persiste no exemplo da nfe e no monitor também. Se alguem tiver alguma ideia ficaria muito agradecido. EDIT Baixei a versão CAPICOM do monitor do source forge testei consultar a disponibilidade do serviço WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. - O nome ou o endereço do servidor não pôde ser resolvido - URL:https://homologacao.sefaz.mt.gov.br/nfews/v2/services/NfeStatusServico2 - SOAPAction:http://www.portalfiscal.inf.br/nfe/wsdl/NfeStatusServico2 Consultei a disponibilidade no site da sefaz e esta operando normalmente, testei meu dns e firewall, ambos estão operando sem problemas.

esses erros em branco são tristes .... voce controla o fluxo, depura as etapas e derrepente aparece uma janela de erro em branco com o X vermelho ... nao suja os logs nem nada, o processo é interrompido sem causa aparente, acontence as vezes, mas incomoda e está virtualmente impossivel encontrar o problema, pois cada hora acontece em uma etapa. Com o componente depende do retorno da sefaz pra te retornar algum erro, a dedução logica diz q o problema está no retorno, algo acontece entre o processamento e o retorno e ocorre essa falha, seria interessante o componente distinguir qnd esse tive de falha de comunicacao ocorrer e retornar algo, uma janela de erro em branco pode ser tanta coisa ....

Caminho e senha do certificado configuradas corretamente. Na empresa não utilizo proxy, mas em alguns clientes sim, e o componente sempre é configurado nesses casos. Não testei o ACBrNFeMonitor, somente o exemplo de testes do ACBr e a minha aplicação.

De alguns dias pra cá meus clientes tem reclamado de problemas no envio/consulta de notas e observei esse mesmo problema, hoje começou o retorno 239. Verifiquei a versão do cabeçalho enviado e é mesmo a versão 2.0, então segui o exemplo do colega acima e atualizei os fontes e reinstalei toda a biblioteca mas não obtive resultados positivos. Algo que está me deixando intrigado, com o demo da NFe do ACBr e modo capicom a consulta do status do serviço funciona, assim como envio de nota em homologação e consulta da nota, quando mudo para OpenSSL o arquivo de retorno vem vazio quando mando consultar o status do serviço. Atualizeis as dlls assim que fiz a alteração de capicom para openssl e mesmo assim, continuo com o problema. finalizando, os cabeçalhos de envio continuam com a versão 2.0 Segue em anexo os testes feitos com OpenSSL (PS : o arquivo de retorno nao pode ser anexado porque está vazio) Mensagem de erro no ACBrNFe_Demo quando mando consultar status do serviço com OpenSSL A página XML não pode ser exibida Não é possível exibir a entrada XML usando a folha de estilos. Corrija o erro e clique no botão Atualizar ou tente novamente mais tarde. O documento XML deve ter um elemento de nivel superior. Erro ao processar o recurso 'file:///C:/Producao/ACBr/Exemplos/ACBrNFe2/Delphi/20121123121057-sta.xml' Retorno Completo WS <?xml version="1.0" encoding="utf-8"?>512.00251STATUS 20121123121055-ped-sta.xml

Alguém já trabalhou ou trabalha com remessa de cheques para o bradesco ? Estou com o layout e pensando em transformar em componente, se alguem tiver algo pronto e quiser compartilhar comigo para me poupar um pouco de tempo. Vou modelar o componente para que seja possível agregar layouts de outros bancos no futuro. Abraço

Pergunto denovo ... Está limpando o componente antes do lançamento de outra nota ? A classe de NFe do componente deriva de um TCollection, ou seja, pode haver mais de uma nota armazenada (o que viabiliza o envio de lotes), se você não limpar as NFes do componente pode estar manipulando dados de uma nota já emitida e com isso gerando duplicidade no conteúdo. Mas uma coisa é certa, o problema está no seu código, só resta saber onde.

Eu rodo o ACBr em 3 versões do delphi e não tenho nenhum problema. Delphi 7, Delphi 2010 e Delphi XE Se você utiliza mais de 1 versão do delphi na mesma maquina deve diferenciar os paths, ou pelas variaveis do windows (excluindo todos os paths e criando um arquivo de lote ".bat" para cada versao com o path respectivo) ou usar uma dica postada por um colaborador, de alterar o path dentro da IDE do delphi (deve ser feito em cada versão) Depois é só seguir a sequencia de compilação/instalação dos compos (não esquecendo dos library paths) e boa.

PAF-ECF talvez você consiga utilizar com o ACBrMonitor (gere os txt pelo php para o monitor). NFe esquece, mas tem um projeto PHPNFe, está meio crú mas talvez ajude. Quanto ao resto acredito que não há como utilizar, visto que o php é interpretado e server-side.

uma outra possibilidade é você não estar limpando as notas existentes no componente antes de carregar outra e transmitindo assim . EX : Crio a nota Nº 100 valido/assino e mando carregar o xml dessa nota 100 logo em seguida ( nesse caso, o componente já está com a nota 100 carregada e voce mandou carregar o xml gerando uma segunda nota no componente, não olhei os fontes pra ver como ele trata isso, mas se o componente mantém as duas notas e você transmite, está enviando dados duplicados a sefaz (que teria que rejeitar uma delas).

ta usando bibliotecas de runtime ? a mensagem de erro que voce postou é referente a "discrepância" entre versões de bpl. EX: Compilo um projeto meuteste.exe com a teste.bpl ver 1.0, faço alterações no bpl e nao recompilo o executável meuteste.exe, ele vai tentar carregar a bpl, mas como ela foi alterada gera uma exceção como a que você postou. Quanto ao ultimo post, tem muitos componentes de terceiros instalados ? eu costumo receber uma mensagem de erro quando tento carregar imagens em diversos componentes, mas a origem do problema é um componente de png que eu utilizo, a mensagem não atrapalha o funcionamento do sistema e só é gerada em design time, em runtime a app roda "lisa". Qual a versão do delphi ?

A questão do EAN (GTIN) É meio Off-Topic, mas de interesse geral. O governo tentou com o projeto da NF-e, "amarrar" a análise de estoque/tributação/entrada e saída de mercadorias utilizando inicialmente o NCM, infelizmente para o governo e para nós, o NCM não serve para tal finalidade pois um único NCM abrange uma enorme variedade de produtos distintos. A Solução foi apresentada com a inclusão e posterior obrigatoriedade dos códigos EAN (Códigos de Barra) que estão presentes na maioria dos produtos industrializados e são "únicos" para cada produto, independente do país. A questão não é QUANDO será obrigatória a informação do EAN, pois isso é um fato, mas sim "O que faremos com produtos que não possuem EAN válido ?" Existem inúmeros exemplos de produtos "legais" industrializados ou não que não possuem um EAN. Setor alimentício, um KG de comida não pode ser registrado no GTIN, Concreto usinado (produto resultante da mistura de Agua (não possui EAN), Brita (Não possui EAN) e Cimento (Possui EAN)), Doce de Leite da Vovó da Esquina que é vendido em "lotes" de 24 unidades para o mercado local, esse também não possui EAN. Enfim, a meu ver, essa "amarração" tão sonhada pela sefaz é mais um tiro no pé, pois NUNCA vai funcionar 100%, pode ajudar eu concordo, mas ainda assim, não vai ser 100% eficaz e nem 100% confiável e obrigar produtos como os descritos acima a possuirem um código EAN válido é inviável. Portanto, eu acredito que a sefaz irá sim obrigar o uso do EAN de produtos que possuem um registro no GTIN e os demais irá passar em branco ou possivelmente com um coringa 7899999999999 para os produtos que não possuirem EAN. Salvo aos desavisados que possivelmente usarão o coringa em 99% de todos os produtos, que a sefaz poderá aplicar multas por conta dessa má utilização, como ja vem fazendo com alguns "erros" em NF-e emitidas desde 2009.

O problema de sua proposta é que o aumento de requisições de suporte seria praticamente exponencial e inversamente proporcional a arrecadação, ou seja, a equipe do suporte teria cada vez mais trabalho e o faturamento seria cada vez menor gerando uma demanda de mão de obra qualificada, que é cara e infelizmente não é onipresente, reduzir o preço para ganhar no volume só funciona nos casos onde você tem uma estrutura subaproveitada o que não é o caso da DJSystem, pelo o que o Daniel diz, a DJ já está operando a pleno vapor e uma enxurrada de novos "cliente" exigiria um aumento significativo de pessoal. Os preços não estão assim tão salgados (tirando o fato do limitador de perguntas), eu cobro em média um salário mínimo por mês dos meus clientes de pequeno e médio porte, sacrificar o rendimento de 1 cliente para que eu possa sanar problemas que venham a ocorrer para TODOS é um preço mais que aceitável e é ainda mais vantajoso se você optar por um plano de longo prazo, 3 meses de rendimento de 1 cliente a R$ 545,00 cobrem 12 meses de suporte a biblioteca. Acredito que se for removido o limite de perguntas ou ao menos dobrado o suporte tende a crescer em pouco tempo. Obs: Talvez uma forma de contornar as questões de limite de pergunta seria um aumento no limite de acordo com o plano, mensal (15 perguntas), trimestral ( 60 perguntas plano ), semestral (180 plano ) anual (500 perguntas plano ).

Ótima dica... Experimentei em meu desktop e no meu notebook ... ambos rodam o Delphi 7, Rad Studio 2010 e Rad Studio XE sem problemas. Pacotes instalados em todas as versões. ACBr, JEDI, ZEOSLIB, RXLIB, FORTES REPORT ... O importante para aqueles que queiram utilizar o a dica, é lembrar de remover o PATH do usuário, e excluir os "caminhos" dos delphis do PATH global do windows. substituir os paths removidos do windows nos .bat descritos Caso haja problemas com a instalação do ACBr com mensagens de erro referentes a plataforma do bpl (Can´t load ....bpl %1 não é um arquivo win32 válido) basta copiar as dlls do projeto na pasta system32 ou SysWOW64.

Pelo SVN você baixa todos os arquivos do projeto, e é interessante manter uma rotina de atualização dos fontes. A instalação do componente segue o exemplo de instalação dos demais... definir os paths no librarypath do delphi abrir e compilar o synapse abrir , compilar e instalar o acbrcomum, acbrdiversos, acbrserial, acbrboleto, etc. não esqueça de colocar as pastas dos componentes que instalar no librarypath do delphi.

Googla ele, se não me engano está hospedado no sourceforge

a configuração do componente é essa mesmo, 2 of 5 interleaved, aparentemente o problema está no componente, se eu conseguir um tempo essa semana vou dar uma olhada nos fontes e verificar se o calculo está sendo feito corretamente. Enquanto isso, se os senhores puderem efetuar alguns testes para que fique mais claro o problema e a origem, testem esse site http://evandro.net/codigo_barras.html e podem também comparar os dados gerados usando como referência esse site http://www.macoratti.net/vbcodbar.htm

Imprimindo em laser ou jato de tinta ? verificou se a saida está realmente no padrão FEBRABAN (I25 ou "Interleave 2 of 5") ? No boleto geralmente não aparece a numeração do código de barras e sim a linha digitável que são duas coisas distintas, ambas são formadas pelos mesmo dados, porém, são diferentes entre si, se os testes de sucesso foram efetuados com a LINHA DIGITAVEL" e as falhas com o CODIGO DE BARRAS, talvez o problema esteja no componente, peço que verifiquem essas informações, juntamente com o banco no qual estão gerando os boletos para que o problema seja encontrado no componente e solucionado. PS: Existem pelo menos um outro tópico a esse respeito, onde o codigo de barras retorna erro, o banco em questão é o ITAU.

O problema é ... Todos que estão ativamente envolvidos no desenvolvimento do projeto também não tem tempo, e no final o problema que você está encontrando não tem relação direta com a versão do delphi que você está usando e sim com o procedimento de instalação. O delphi não está encontrando o .bpl da synapse Você informou os paths do ACBr no library path do delphi ? Onde ficam salvos seus .dcp e .bpl ? verifique se existe o synapse.bpl na pasta Caso ja exista, delete o arquivo, abra novamente o pacote synapse e de Build e depois Compile (NÃO INSTALE) e tente instalar os outros pacotes normalmente.

é bem provável que eu vá precisar trabalhar com concentradores ainda esse ano, mas ainda não sei qual será utilizado. Eu tenho interesse em ajudar no desenvolvimento do componente, assim que eu souber mais sobre como será o meu calvário e qual cruz eu terei q carregar eu volto a postar e quem sabe pedir esse material sobre o Gilbarco e Companytec.

Na verdade não há obrigatoriedade, alguns bancos pedem que se faça a homologação para evitar problemas. Como eu disse antes, no caso do bradesco, o processo é bem tranquilo, você só imprime alguns boletos e manda pra agencia testar, se houver algum problema eles vao te informar e você corrige, quando eu desenvolvi o meu emissor de boletos para o bradesco a única sugestão que me fizeram foi a retirada do "código do cedente" do boleto o resto estava tudo em ordem. Nunca trabalhei com o Itau, vou ficar lhe devendo essa. Só por curiosidade, você está usando o ACBrBoleto ? os fontes estão atualizados ? Experimente pegar o código de barras e testar no site que eu postei, veja se ele forma a linha digitável igual a do componente e se os dados aparecem no site. Mais uma coisa, quando você efetua o pagamento pelo internet banking (que é a situação que funciona) você está utilizando o codigo de barras ou a linha digitavel ? ja testou ambos no IB ?

infelizmente, por pior que pareça, está aparentemente correta. Estamos falando de um banco específico ou de vários bancos ? Você chegou a solicitar a homologação do boleto junto ao banco ? (o procedimento geralmente é simples e não oneroso, o Bradesco por exemplo, pede que seja gerado 10 boletos fictícios para que eles façam uma análise, e retornam o resultado da homologação, geralmente com algumas sugestões como "Retirar o código do Cedente" (para evitar que o sacado efetue o deposito do valor em conta e não pague o boleto em si, gerando transtornos para quem trabalha com negativação dos boletos), etc. Caso você queira testar, acesse esse site, ele efetua os calculos seguindo o algoritimo utilizado pela febraban http://evandro.net/codigo_barras.html PS: o Valor da linha digitável É diferente do valor do código de barras, um não pode ser usado no lugar do outro EX: Usar a numeração do codigo de barras no campo linha digitavel e vice versa

Aceita palpites ? verifique os CST de ICMS, PIS e CONFIS de cada produto Me parece que os produtos nao tem quantidade e valor Pelo que eu entendi, a mensagem diz que, produtos com o mesmo "codigo" devem ser tratadas pelo mesmo regime (ICMS/PIS/COFINS), talvez, haja discrepância entre os itens. EX: 17 - Gasolina - CST ICMS 40 CST PIS 00 CST COFINS 00 (Meramente ilustrativo) 17 - Gasolina - CST ICMS 00 CST PIS 010 CST COFINS 010 (Meramente ilustrativo) o mesmo item foi lançado com regimes diferentes de tributação. Me parece que seja isso. Outra possibilidade, que está explicito na mensagem, cada produto deve ter somente UM dos dois campos informados (VL_BC, QUANT_BC), verifique se ambos estão preenchidos, e corrija mantendo somente um.

Estranho, ja analisou a tarja pra ver se esta saindo no padrão da febraban ? a numeração da tarja é composta por vários dados do cedente e do boleto, como codigo do cedente (numero da agencia e conta), valor, etc. Se não souber como fazer, gere um boleto e mande o codigo da tarja por aqui ou por PM que eu vejo se ha algum problema.

Os boletos foram gerados pelo mesmo software emissor ?

Pelo que eu andei lendo, muita gente já homologou o PAF-ECF usando o ACBr sem problemas. Eu vi um usuário do fórum postando um roteiro de homologação, mas não lembro bem o tópico, da uma procurada