Italo Giurizzato Junior

Boa tarde Weslei, Por favor não fique postando em vários lugares. Já lhe respondi em uma outra postagem.

Boa tarde Nilton, Que eu saiba não temos um componente só para gerar a imagem do QR-Code. O que temos é uma unit chamada ACBrDFeReport que contem o método: PintarQRCode onde passamos a string e o nome do componente imagem que se encontra no Form de impressão.

Boa tarde ALA, O problema foi resolvido, pois a sua postagem não deixa claro.

Boa tarde ALA, Você tentou enviar o evento EPEC? Se sim, qual é o erro que ocorreu? Favor anexar o XML do evento gerado.

Boa tarde Weslei, Favor atualizar os fontes e faça novos testes, note que fiz alteração no arquivo INI do provedor.

Boa tarde Rafael, Muito obrigado pela colaboração, ainda hoje estarei enviado para o repositório. Só não entendi porque você deixou fixo o valor "2" para a tag TomadorExterior, basta atribuir o valor snNao ao respectivo campo que no XML será gerado a tag com o valor "2".

Boa tarde Maiquel, Muito obrigado pela informação, já alterei o arquivo INI e ainda hoje estarei enviando para o repositório.

Olá pessoal, A SEFAZ do Pará não vai mais recepcionar as NF-e a partir do dia 02/09/2019. A partir dessa data os contribuintes do Pará devem encaminhar as suas notas para a SEFAZ-Virtual do Rio Grande do Sul. Conforme consta a noticia no site da SEFAZ-Pará. Para quem utiliza o componente ACBrNFe, deverá apenas atualizar os fontes recompilar a aplicação e distribuir a nova versão do mesmo para os seus clientes. Para quem utiliza o ACBrMonitor, vamos disponibilizar uma nova versão do mesmo, ai basta vocês atualizarem os seus clientes. Pela noticia da SEFAZ-Pará não teremos um período de transição, logo vamos nos preparar para a correria, pois dia 2 é uma segunda-feira. Detalhe importante não será necessário realizar nenhuma mudança na configuração do componente ou do Monitor, apenas atualizar.

Tenta com libCapicom.

Qual é a configuração que você esta usando no que diz respeito a: SSLLib, CryptLib, HttpLib, XMLSignLib e SSLType ?

Bom dia, Favor atualizar os fontes e faça novos testes.

Bom dia Luiz, O problema é que todos os Webservices de todas as SEFAZ deveriam estar configurados para a versão 1.2 do TLS, mas infelizmente isso não esta ocorrendo. Ao enviar para a SEFAZ-Virtual de Contingencia se fez necessário mudar para o LT_TLSv1_2 visto que o Webservice do SVC esta configurado para a versão 1.2 do TLS. Ao enviar "normal", ou seja, para o Webservice da SEFAZ-MG devemos mudar a configuração do SSLType porque o Webservice não esta configurado para a versão 1.2, provavelmente para a versão 1.1 A sua aplicação terá que ter uma tela de configuração onde você possa definir qual o valor de SSLType para o envio Normal e para o SVC. Quanto a problemas de versões do Windows, estude a possibilidade de usar o OpenSSL. Só existe um porem quanto o OpenSSL, ele não funciona com certificados A3.

Bom dia Celente, Favor anexar o seu arquivo INI do provedor Ginfes para que eu possa comparar com o meu.

Boa tarde Everton, Vai ser necessário debugar a sua aplicação do porque ele não esta atualizando o XML com o protocolo antes de imprimir o DANFE.

Boa tarde a todos, Me parece que sim, visto que o layout do XML do evento EPEC da NF-e é diferente da NFC-e. O que eu fiz foi renomear o XSD que valida a parte especifica do evento no caso EPEC para a NF-e e criar um novo XSD para a NFC-e. Na unit do componente ele detecta o tipo de evento e o modelo de documento para decidir como será montando o nome do XSD de forma correta.

Boa tarde, Você poderia mostrar exatamente o comando que esta executando para imprimir o DAMDFE ? Pois no seu caso me parece que esta sendo impresso abre e fecha apostrofe no lugar do protocolo.

Boa tarde Celente, Favor atualizar novamente, veja que fiz uma alteração no arquivo INI do provedor BHISS. Verifica se agora vai funcionar esse provedor.

Boa tarde ALA, Qual é o valor de SSLType?

Boa tarde Windel, Por favor abra o XML com-lot.xml Note que na razão social consta o carácter "&". Talvez seja ele que esteja causando o erro. Tente novamente sem esse carácter.

Boa tarde Maiquel, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório. Fiz uma alteração no arquivo INI do provedor que acredito que vá resolver o erro do atributo a mais. Atualize os fontes e faça novos testes.

Boa tarde Marcos, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Paulo, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Felipe, As notas que o seu cliente perdeu, são notas que ele emitiu? Se sim, a única solução é entrar em contato com a SEFAZ e chorar muito para convencer eles a fornecer os XMLs das notas dentro de um determinado período. Agora se o seu cliente tem costume de enviar os XMLs das notas para o Contador e se este não deletou, basta entrar em contato com ele e solicitar os XMls.

Boa tarde Cleiver, Por favor entre em contato com essa empresa de Software contábil e diga que quem esta errado são eles, uma vez que a definição do conteúdo da tag descEvento que consta no schema usando para validar o evento em questão as palavras estão sem acento e sem o cedilha. Veja o fragmento do Schema: e110112_v1.00.xsd <xs:element name="descEvento"> <xs:annotation> <xs:documentation>Descrição do Evento - “Cancelamento por substituição”</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:enumeration value="Cancelamento por substituicao"/> </xs:restriction> </xs:simpleType> </xs:element> Resumindo: o XML gerado pelo componente ACBrNFe esta em conformidade com o Schema e que por sinal esta sendo aceito (autorizado) pela SEFAZ. Eles que consertem a rotina do Software deles.