carlos_augusto

Companheiros Eu constatei que no ACBRMONITORPLUS , no Menu : DF-e \ TESTE \ ENVIAR XML NFE existe a opção : ENVIAR XML NFE Podem me dizer os companheiros se esta opção pode ser utilizada para enviar Arquivo XML da NFE em Modo de PRODUÇÃO ? Isto é, este item de Menu foi criado para envio de Arquivo XML também em modo de Produção? Outra questão é se o ACBRMONITORPLUS também tem recursos para importar também Arquivos TXT constituidos de acordo com o Manual que fica em: \\acbr\trunk2\Doctos\Manuais\Layout_TXT_NFe_NFCe_4_00.TXT.ODT. Obrigado

Companheiros Na empresa em que trabalho já tivemos este tipo de problema e conseguimos resolver., Veja este post : Grato

Prezado Sr. Daniel Bom Dia! Eu acabei de visitar o site da Nota Fiscal Eletrônica e constatei que nenhuma Nota Técnica nova foi criada visando corrigir a Nota Técnica 1.60, no tocante à tag :vDESC. Com certeza o ticket que abri no Suporte da Sefaz-SP já deve ter sido esquecido e ninguém vai tomar qualquer atitude , embora tenham prometido solução na resposta da Mensagem : 7662453. O Sr. acha que seria possível implementar algum ajuste diretamente no ACBR para contornar o problema desta TAG ? Agradeço por sua ajuda. Carlos Augusto Franca-Sp

Sr. Amarildo O problema é que o nosso Governo é extremamente lento. Eles não estão submetidos à mesma pressão por resultados práticos que temos aqui no "Mundo Real". Portanto não tenho certeza se eles estão muito preocupados em resolver isto, mesmo sendo uma coisa simples de resolver e sendo claramente um erro deles. Inclusive porque é um Governo que está no fim de mandato. Vamos aguardar! Grato

Companheiros Ontem recebi a resposta da Sefaz relativo à questão da Tag : vDesc. Vejam que eles afirmam que "em breve" poderá ocorrer publicação de nova Nota Técnica excluindo a tag : vDesc da validação. Para quando será o "EM BREVE" deles não dá para termos certeza ? Vamos ficar aguardando! Grato RESPOSTA DA SEFAZ Resposta da Mensagem 7662453 Prezado contribuinte, Nossos serviços autorizadores de homologação estão em conformidade com a NT2016.002 v1.60, disponível no Portal Nacional da NF-e, e o comportamento descrito é previsto pela regra de validação Y01-20. Esperamos que uma nova versão da referida NT seja publicada em breve excluindo o campo vdesc dessa validação. Verificamos também que não há qualquer problema no preenchimento de vDesc com 0.00. Favor confirmar se estão utilizando o PL atual: Esquemas XML NF-e - Pacote de Liberação No. 9 (Novo leiaute da NF-e, NT 2016.002 v.1.60 - b). Publicado em 02/07/2018. Agradecemos seu contato no "Fale Conosco" da Secretaria da Fazenda. Sua opinião é muito importante para nós. Por gentileza, clique no link abaixo e opine sobre este e-mail: Pesquisa de Satisfação Atenciosamente, Secretaria da Fazenda do Estado de São Paulo

Companheiros Recebi ontem uma resposta do CONFAZ sobre o assunto indicando que a solução não deverá vir deles e sim da própria Sefaz. Assim, acessei o "Fale Conosco" da Sefaz-SP e fiz a eles o mesmo questionamento sobre o problema relacionado com a Tag : vDesc em Modo de Homologação. Vamos aguardar agora que alguém da Sefaz nos responda. Grato RESPOSTA DO CONFAZ Prezado senhor, Informamos que em razão desta secretaria não ser órgão consultivo, os pedidos da espécie deverão ser encaminhados diretamente à Secretaria de Fazenda do seu Estado, cujo endereço poderá ser encontrado no site do CONFAZ (www.confaz.fazenda.gov.br) no menu “Secretarias de Fazenda”. Atenciosamente,

Companheiros No intuito de buscar solução para o erro que ocorre em Modo de Homologação da Nfe 4.00, pela não informação da Tag : vDesc, fiz um questionamento diretamente no site do CONFAZ(Conselho Nacional de Política Fazendária) , que é quem vai ter que efetivamente solucionar o problema. Espero que alguém do CONFAZ veja o meu questionamento com atenção e responda. Quando eu receber alguma notícia eu reporto aos companheiros. Vejam abaixo texto que postei no "Fale Conosco". Minha intenção inicial era exibir lá parte do arquivo xml da seguinte forma : <cobr> <fat> <nFat>23092</nFat> <vOrig>156.00</vOrig> <vLiq>156.00</vLiq> </fat> <dup> <nDup>001</nDup> <dVenc>2018-07-03</dVenc> <vDup>156.00</vDup> </dup> </cobr> Porém, o site deles não aceita estes caracteres especiais. Grato Carlos Franca-Sp TEXTO POSTADO NO "FALE CONOSCO" DA CONFAZ Obrigado O CONFAZ recebeu sua mensagem e responderá com brevidade. Assunto TAG : vDESC NFE : 4.00 Comentários Prezados Senhores Estamos vivenciando um problema na transmissão da Nota Fiscal Eletrônica 4.00 em Modo de Homologação no Segmento de COBRANÇA. Neste segmento existe a Tag : VALOR DO DESCONTO. Esta Tag, de acordo com o Manual e Notas Técnicas da Nfe 4.00 é opcional. Portanto, se uma Duplicata não tiver descontos e seu valor for igual a ZERO , esta Tag do VALOR DO DESCONTO não será gerada. O problema é que em Ambiente Normal DE Homologação a Sefaz retorna o seguinte erro : "905 - Rejeicao: Campos do grupo Fatura nao informados" A Sefaz, pelo que sei, se manifestou indicando que somente poderá corrigir este erro com a autorização do CONFAZ. Assim, gostaríamos de saber seda parte dos senhores, existe alguma previsão de correção deste erro! Grato

Prezado Sr. Italo Bom Dia! Seguindo suas instruções , fizemos atualização nos Schemas Xml. Mas no primeiro momento não conseguimos efetuar o teste no Ambiente de Homologação Normal devido a um outro problema que está descrito no post : https://www.projetoacbr.com.br/forum/topic/44466-905-rejeicao-campos-do-grupo-fatura-nao-informados/?page=5. Porém, fazendo o teste no Ambiente de Homologação SVC Nacional e obtivemos sucesso. Veja como ficou a informação do Icms Efetivo : <ICMSSN500> <orig>0</orig> <CSOSN>500</CSOSN> <pRedBCEfet>66.6700</pRedBCEfet> <vBCEfet>666.70</vBCEfet> <pICMSEfet>18.0000</pICMSEfet> <vICMSEfet>120.01</vICMSEfet> </ICMSSN500> Agora vamos aguardar a Sefaz resolver o problema no ambiente de Homologação Normal para repetirmos este teste. Grato

Companheiros Fizemos um teste transmitindo pelo Homologação SVC Nacional e obtivemos sucesso . Vejam como ficou o segmento de Cobrança : <cobr> <fat> <nFat>4727</nFat> <vOrig>1000.00</vOrig> <vLiq>1000.00</vLiq> </fat> <dup> <nDup>001</nDup> <dVenc>2018-07-04</dVenc> <vDup>1000.00</vDup> </dup> </cobr> Vejam que até a informação do Icms Efetivo é aceita neste ambiente : <ICMSSN500> <orig>0</orig> <CSOSN>500</CSOSN> <pRedBCEfet>66.6700</pRedBCEfet> <vBCEfet>666.70</vBCEfet> <pICMSEfet>18.0000</pICMSEfet> <vICMSEfet>120.01</vICMSEfet> </ICMSSN500> Agora vamos aguardar a Sefaz resolver o problema no ambiente de Homologação Normal para repetirmos este teste. Grato

Companheiros Acho que me compete aqui lembrar que todas situações que envolvem a geração e transmissão da NFE são complexas e envolvem diversos fatores : - Nosso ERP em Delphi - Os Componentes ACBR; - O Sistema Operacional em uso em nossos clientes; - Governo Federal ( que coordena o projeto da NFE ); - A Sefaz de cada Unidade da Federação ( cada qual com sua capacidade de investir em tecnologia ); - Os Provedores de Internet que nossos clientes utilizam; - etc.. Então, quando nos deparamos com qualquer erro, temos que ter atenção e calma para identificar a causa deste. Com relação aos Companheiros Coordenadores do Projeto Acbr ( srs. Daniel, Italo e outros ) a empresa que trabalho e eu só temos que tecer elogios e fazer agradecimos pela gentileza e parceria dos últimos 9 anos. Graças à iniciativa destes senhores hoje temos como disponibilizar aos nossos Clientes a transmissão da NFE de forma segura e confortável. Lembrando ainda que em ambiente de Código Aberto todos são co-responsáveis e devem ajudar e interagir. Com relação à este erro específico da tag : vDesc, acredito que teremos que esperar por uma solução da Sefaz. Grato

Sr. Daniel Na verdade o problema descrito neste Post já foi totalmente resolvido. Atualmente, em todos os computadores, independentemente de qual seja o Sistema Operacional estamos conseguindo transmitir a Nfe 4.00 com sucesso. Nos computadores que apresentavam problema resolvemos utilizando esta configuração alternativa ( SSLLIB = libOpenSSL ). Tive apenas a preocupação de postar no último dia 27/06/2018 a solução que encontrei para que também possa beneficiar os demais companheiros. Agradeçemos muito sua atenção. Carlos Augusto Franca-SP

Prezados Companheiros Boa Tarde! Estamos tentando efetuar um teste com os novos campos de ICMS EFETIVO criados pela Nota Técnica 1.60, da seguinte forma: <ICMS> <ICMSSN500> <orig>0</orig> <CSOSN>500</CSOSN> <pRedBCEfet>71.7800</pRedBCEfet> <vBCEfet>717.80</vBCEfet> <pICMSEfet>18.0000</pICMSEfet> <vICMSEfet>129.20</vICMSEfet> </ICMSSN500> </ICMS> O problema é que quando efetuamos a transmissão da Nfe estamos recebendo a seguinte mensagem de erro : The element 'ICMSSN500' in namespace 'http://www.portalfiscal.inf.br/nfe' has invalid child element 'pRedBCEfet' in namespace 'http://www.portalfiscal.inf.br/nfe'. List of possible elements expected: 'vBCSTRet, vBCFCPSTRet' in namespace 'http://www.portalfiscal.inf.br/nfe'. Caminho: NFe[1]/infNFe/det[1]/imposto/ICMS/ICMSSN500/pRedBCEfet Sabem os companheiros o que poderia estar ocasionando este problema? Grato

Prezados Sr. Juliomar Boa Tarde! A nossa situação atualmente é que na empresa temos um grande ERP que já utiliza o componente ACBR para efetuar a transmissão da NFE com sucesso. Este ERP já está devidamente atualizado , inclusive com a versão do Acbr do dia 26/06/2018. O problema é que também temos um outro ERP , de menor porte, em que geramos a NFE em arquivo TXT e importamos no Emissor Público de NFE para transmití-lo. A questão é que agora o Emissor Público é mantido pelo Sebrae. E o Sebrae ainda não disponibilizou nova versão do Emissor e bem como uma versão definitiva do layout TXT da Nfe. Por enquanto não temos tempo hábil para efetuar qualquer mudança nele visando substituir a geração do Arquivo TXT. Assim, é muito bom saber que o Componente ACBR e o AcbrMonitor estão aptos em interagir com o Arquivo TXT. Pois, caso não seja possível continuar utilizando o Emissor Público de NFE , poderemos interagir com os recursos do ACBR , via arquivo TXT mesmo. Grato Carlos Augusto Franca-Sp

Prezados Srs. Ítalo e José Boa Tarde! Conforme lhes reportei anteriormente estavamos experimentando situação em que em determinados computadores, cujo Windows é 32 bits , não conseguíamos transmitir a Nfe. Assim, a configuração sugerida, atribuindo o valor : libWinCrypt à propriedade SSLLib resultava em erro. A solução encontrada foi , depois de diversos testes, utilizar o valor : libOpenSSL à propriedade SSLLib. Desta forma , nestes computadores que apresentavam problemas, conseguimos efetuar o envio da NFE 4.00 corretamente ( pelo menos até que o Governo aceite desta forma ). Esta foi portanto, a solução que encontramos para o problema. Por favor, veja em anexo imagens da configuração para TLS e da configuração utilizando libOpenSSL. Grato Carlos Augusto Franca-Sp

Companheiros Alguém conseguiu encontrar um layout de Arquivo Txt exatamente compatível com o Emissor Público do Sebrae? Estou totalmente confuso e não consigo acertar a composição do Registro W. Nada que faço é aceito pelo emissor. Grato

Sr. José Júnior Verifiquei o Arquivo ACBR.INC que está na pasta ACBR\TRUNK2\FONTES e constatei que ele já está com esta diretiva : {$DEFINE USE_MINGW} ( veja arquivo em anexo ). Por outro lado, eu fiz o seguinte teste : Acrescentei no meu projeto as units do Acbr : - AcbrNfe.Pas - AcbrNfeNotasFiscais.pas E fui debugando à partir da chamada do método : ASSINAR. Inicialmente o foco vai para a unit : AcbrNfe.Pas no seguite código : procedure TNotasFiscais.Assinar; var i: integer; begin for i := 0 to Self.Count - 1 do Self.Items.Assinar; end; na sequência o foco vai para a unit : System.Classes na seguinte porção de código : destructor TRecall.Destroy; begin if Assigned(FReference) then FReference.Assign(FStorage); Forget; inherited; end; Assim, temos 2 situações distintas: 1)-PRIMEIRA CONFIGURAÇÃO : acbrNota.Configuracoes.Geral.SSLLib = libWinCrypt : O Acbr faz a assinatura do arquivo xml normalmente 2)-SEGUNDA CONFIGURAÇÃO : acbrNota.Configuracoes.Geral.SSLLib = libOpenSSL: O Acbr apresenta erro na linha : if Assigned(FReference) then FReference.Assign(FStorage); Observação : Mesmo erro já referenciado anteriormente. Assim não consigo mais imaginar o que posso fazer para resolver este problema. Curiosamente , utilizando o AcbrMonitor (última versão disponibilizada no site) eu consigo enviar a Nota Fiscal sem qualquer tipo de problema. Se utilizarmos os Programa AcbrNfe_Demo que vem junto com a instalçação do Acbr também ocorre erro ( veja o erro em anexo ). A solução vai ser , nos computadores onde constatarmos que o sistema não consegue transmitir nota fiscal, nós vamos gerar o arquivo xml e importar no AcbrMonitor e efetuar a transmissão. Grato Carlos Augusto Franca-Sp ACBr.inc

Utilizando o Demo... Observei que quando insiro na pasta do Demo a dll libxmlsec-openssl.dll, ele fecha o Demo e não continua o envio e em algumas vezes, ocorre o erro acima.

Senhores, Segui as recomendações do José Junior, porém, o mesmo erro ocorre. Veja abaixo os passos que segui. 1º Consigo transmitir pelo ACBrMonitor. 2º Chequei novamente se dll's do ACBR não estão presentes em outras pastas do pc; 3º Apaguei todas as dll's da pasta da minha aplicação; 4º Inseri apenas as dll's do ACBR; 5º Inseri apenas algumas obrigatórias para o funcionamento básico da minha aplicação (que não tem o mesmo nome das dll's do ACBR). Existe mais alguma coisa, que eu possa fazer?

José Junior, Primeiramente, muito obrigado! Sua solução deu resultado, uma vez que, o ACBR Monitor passou a transmitir e cancelar NF-e. Não fechou mais em nenhum teste. Me desculpem, mas isso reforça minha ideia de que, o ambiente pode interferir, contudo, deve existir algo que falta ou está incorreto, que causa o erro. Minha aplicação continua com o problema: "Access violation at address 5003C596 in module 'rtl160.bpl'. Read of address 58F30BFE". Lembrando que: Em estações de 32 bits: Não consigo transmitir NF-e com libWinCrypt e libOpenSSL Em estações de 64 bits: Não consigo transmitir NF-e com libOpenSSL Setando libOpenSSL, minha aplicação apresenta o erro de "Acess violation" descrito acima. Alguma ideia?

Italo, O ambiente de desenvolvimento (gerador da aplicação), obviamente, não é o ambiente de testes. Ou seja, as DLL's, BPL's, foram testadas em ambientes distintos, portanto, ainda temos ambientes "não contaminados", contudo, a falha permanece, tanto no ACBRMonitor, quanto na nossa aplicação. E sobre formatar e utilizar ambiente de teste limpo, já fizemos (conforme citado anteriormente). Averiguamos que o erro (em nossa aplicação), ocorre na assinatura do XML (contudo, testamos com vários certificados, descartando problemas de certificado digital). A questão é que caso tivéssemos cometendo um erro, provavelmente não funcionaria em nenhum ambiente, porém, por hora, temos problemas em ambientes de 32 bits, por isso, estamos mantendo contato, tentando, encontrar alguma sugestão que possa apontar algo que esteja faltando ou que estejamos falhando, para solucionar o problema definitivamente. ACBR Monitor: Fecha a aplicação, sem qualquer mensagem de erro. Nossa aplicação: "Access violation at address 5003C596 in module 'rtl160.bpl'. Read of address 58F30BFE". Estou enviando gif do procedimento no ACBRMonitor e arquivos de LOG do mesmo. LOG.TXT LOG_COMP.TXT

Sr. Italo Sim , o objetivo é resolver o problema verificado nos computadores 32 bits. Eu tentei efetuar um debug utilizando as configurações de assinatura digital da SSLLIB = LibOpenSSLconforme indicado na imagem acima. E tentei debugar para achar o ponto exato em que ocorre o erro. Constatei que o erro está exatamente em : acbrNota.NotasFiscais.Assinar; E o erro é exatamente o que anteriormente aparecia : Access violation at address 5003C596 in module 'rtl160.bpl'. Read of address 85255C8B Se mudarmos para a configuração para para SSLLIB = libWinCrypt este erro não acontece. E tomamos por padrão colocar a RTL160.bpl em todos lugares possíveis ( junto com o exe, e até nas pastas Windows\System. Grato Carlos

Senhores, Consulta Status Serviço OK Transmissão 4.0 Homologação: Problema, inclusive no Monitor Parâmetros: ACBR Monitor: Fecha a aplicação, sem qualquer mensagem de erro (repetimos inúmeras vezes e ocorre o mesmo). Nossa aplicação: "Access violation at address 5003C596 in module 'rtl160.bpl'. Read of address 58F30BFE". Gostaria de um auxilio, pois, precisamos implementar a NF-e 4.0 e existe o impeditivo de utilizar libWinCrypt e ocorrer erros e com a opção libOpenSSL, estamos encontrando esse problema. Ao que me parece a rotina de cancelamento também está com o mesmo problema. O erro de senha, que tinha relatado anteriormente, foi solucionado. Tratava de um problema no certificado que estava sendo utilizado. Desde já agradeço e aguardo.

Sr. Italo Semana passada após seu comentário nós apagamos a instalação do Acbr toda, fizemos novo download e reinstalamos. Após este procedimento tudo fuincionou. Grato

Prezados Senhores Italo e Rafael Sinceramente eu estou desanimado! Efetuamos todos os testes imagináveis, com formatação, reinstalação de Sistema Operacional, atualização. Porém, existem alguns computadores 32 bits onde não funciona a transmissão da Nfe, conforme relatei anteriormente. Minha última tentativa para resolver estes computadores de 32 bits foi reproduzir no nosso sistema uma situação que existe no AcbrMonitor. No ACBRMONITOR , quando existe opção por marcar a propriedade : SSLIB = LibOpenSSL , ele utiliza somente os campos de : - Nome do Certificado - Senha do Certificado Já se SSLLIB = libWinCrypt o AcbrMonitor envia apenas a: - Série do Certificado Fiz o ajuste e configuramos o sistema para considerar SSLIB = LibOpenSSL. O sistema então passou então a conseguir efetuar consulta de Status do Serviço corretamente ( anteriormente só dava erro ) , mas na hora do envio da Nota Fiscal agora aparece um erro de "Senha do Certificado Inválida". Coloquei um ShowMessage para conferir se o sistema estava passando corretamente a senha e constatamos que está sendo passada exatamente a senha que foi cadastrada quando da aquisição do certificado. Assim, voltamos ao ponto de partida e não temos como resolver o problema destes computadores. Por acaso os senhores teriam mais alguma sugestão para resolver o problema. Grato

Companheiro Para não haver dúvida, baixamos hoje os Schemas do próprio site do Acbr. Fizemos a transmissão e persiste o erro. Porém, se geramos arquivo xml assinado através do AcbrNfe e o transmitimos através do Emissor Público de Nfe do Sebrae não acontece o erro. Erro Verificado: 1871 - Element '{http://www.portalfiscal.inf.br/nfe}indPag': This element is not expected. Expected is ( {http://www.portalfiscal.inf.br/nfe}tPag ). Sabe o senhor como resolver este problema? Questiono isto porque este tipo de situação onde em uma Nota Fiscal existem itens que gerem Pagamentos e outros que são é muito comum. Grato