Italo Giurizzato Junior

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 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.

Boa tarde Natanael, A consulta que o BigWings se refere é o método DistribuicaoDFe do componente ACBrCTe. Lembre-se que esse método do ACBrCTe não serve para baixar da SEFAZ os XMLs dos CT-e emitidos pela transportadora que por algum motivo ela tenha perdido. Agora se a ideia é obter o XML para poder dar entrada no contas a pagar do tomador do serviço de transporte de carga ai você vai conseguir baixar os XMLs usando o método DistribuicaoDFe do ACBrCTe. Vamos a um exemplo: Uma Industria compra matéria prima. Com o DistribuicaoDFe do ACBrNFe ela obtém um resumo da nota, para ter a nota completa se faz necessário enviar o evento de manifestação do destinatário e depois com o DistrubuicaoDFe do ACBrNFe obter o XML completo. Favor ler o seguinte artigo: Como obter o XML do Fornecedor. Com o DistribuicaoDFe do ACBrCTe ela obtém o XML completo do CT-e (não se faz necessário o envio de evento de manifestação do destinatário). O DistribuicaoDFe do ACBrCTe funciona de forma semelhante ao do ACBrNFe.

Boa tarde Leandro, Se não me falha a memória o erro 500 é quando o XML enviado não esta em conformidade com o que o webservice espera receber.

Boa tarde Douglas, Favor entrar em contato com o provedor e relatar o problema que esta ocorrendo no ambiente de homologação.

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

Boa tarde Marcelo, O que você acha de contribuir com o projeto? Adicione os enumeradores que são necessários, faça os testes e estando tudo OK, anexe a unit alterada para que possamos analisar a sua contribuição. Se estiver tudo OK, enviaremos para o repositório.

Boa tarde Armando, Pela URL me parece que mudaram da versão 1 para a versão 2 do layout da ABRASF. Por favor confirme se ocorreu a mudança de versão. Se sim, será necessário incluir essas URLs no Pronimv2.ini e remover essa cidade do Pronim.ini e alterar o arquivo Cidades.ini

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

Boa tarde João, Rejeição 999 - Erro não catalogado, é problema na SEFAZ. Favor entrar em contato com eles e relatar o problema.

Saulo, Vamos aos testes. Copie para dentro da pasta: ...\Exemplos\ACBrDFe\Schemas\NFe os schemas abaixo. e110140NFe_v1.00.xsd e110140NFCe_v1.00.xsd Copie para dentro da pasta: ...\Fontes\ACBrDFe\ACBrNFe o fonte abaixo. ACBrNFe.pas Faça um novo teste de envio de EPEC de uma NFC-e.

Boa tarde Saulo, Veja esse fragmento de código do ACBr: if sModelo = '55' then GerarDestNFe(Evento.Items[i]) else begin GerarDestNFCe(Evento.Items[i]); // No EPEC da NFC-e segundo o schema as TAGs vNF e vICMS estão fora do grupo dest e não // tem a TAG vST. Gerador.wCampo(tcDe2, 'P32', 'vNF', 01, 15, 1, Evento.Items[i].InfEvento.detEvento.vNF, DSC_VNF); Gerador.wCampo(tcDe2, 'P33', 'vICMS', 01, 15, 1, Evento.Items[i].InfEvento.detEvento.vICMS, DSC_VICMS); end; Os especialistas da SEFAZ tiveram a criatividade absurda de criar 2 layouts diferentes para o mesmo tipo de evento. Para o EPEC da NF-e os campos: vNF, vICMS e cST são obrigatórios e estão dentro do grupo dest. Já no caso da NFC-e eles estão fora e só tem os campos vNF e vICMS. Estou estudando uma maneira de resolver o problema de validação da aera especifica do evento, visto que a área genérica é igual para todos os eventos.