JJA
-
Total de ítens
131 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por JJA
-
-
Bom dia Italo,
eu já estou usando o arquivo issDSF.ini que vem no pacote ACBr, sem ele a rotina nem funcionaria, porém entendo que este arquivo está apenas com as configurações padrões para uso dos componentes ACBr, sendo necessário setar alguns parâmetros para que o XML seja gerado corretamente para cada provedor.
Não sei se o meu problema está ligado diretamente ao arquivo issDSF.ini, mas fato é que ao adicionar a assinatura no XML do RPS, este arquivo é XML inválido. A estrutura do XML ficou comprometida, inválida, faltando alguma tag ou outro valor que não faz ser reconhecido a lido por um leitor de XML.
-
Bom dia,
Alguém que usa DSF poderia dar uma ajuda? Disponibilizar ao menos o arquivo issDSF.ini?
-
Bom dia pessoal,
estou tentando implementar NFSe para Campinas, provedor issDSF. Já olhei muitos tópicos sobre este provedor, mas são antigos e também sem muitos dos problemas citados resolvidos.
Já utilizo o Componente para envio para a prefeitura de São Paulo e agora estou implementando para Campinas.
Estou tendo problemas para assinar o RPS, mais precisamente nesta linha:
function TDFeSSLXmlSignMsXmlCapicom.Assinar(const ConteudoXML, docElement, infElement: String; SignatureNode: String; SelectionNamespaces: String; IdSignature: String; IdAttr: String): String; ... // Inserindo Template da Assinatura digital // if (not XmlEstaAssinado(AXml)) or (SignatureNode <> CSIGNATURE_NODE) then AXml := AdicionarSignatureElement(AXml, False, docElement, IdSignature, IdAttr);Ao executar a linha:
AXml := AdicionarSignatureElement(AXml, False, docElement, IdSignature, IdAttr);
as tags de assinatura no XML são adicionados, porém estão todas vazias. Imagino porque os parâmetros "IdSignature" e "IdAttr" estão vazios.
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Reference URI="#rps:28435"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue></DigestValue> </Reference> </SignedInfo> <SignatureValue> </SignatureValue> <KeyInfo></KeyInfo> </Signature> </Rps>
Já estou com certificado carregado. O está faltando para eu setar?
Alguém que hoje utilizar o ACBrNFSe com provedor DSF poderia me dar uma ajuda? Pois na verdade não sei se precisa assinar ou não o RPS. Tentei enviar sem assinar, mas aí me deparo com outro erro. Acredito que grande parte do segredo está no arquivo issDSF.ini. Alguém que está utilizando o provedor DSF poderia disponibilizar para o grupo ACBr o arquivo, pois o que está no repositório do ACBr está cru, precisando setar uma série de informações, e imagino que este arquivo uma vez configurado, atende todas as prefeituras que o provedor DSF atende correto?
Um grande abraço
-
Boa tarde Daniel,
que bacana! Vou testar logo mais. Aproveitando, uma dúvida:
Pelo que eu havia entendido, este problema era aplicado em cima do certificados instalados com criptografia 2048 Bits no qual a libCapicom não conseguia utilizar correto? E no caso a libOpenSSL conseguia. Se sim, este erro não deveria ocorrer usando OpenSSL correto?
-
Pessoal, desculpem as dúvidas amadoras acima, tinha me esquecido de que era só configurar o componente para ele achar o provedor.
Consegui evoluir, mas me deparei com este erro:
Erro Interno: 0
Erro HTTP: 0
Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT: 12046Pesquisei no fórum e vi muita gente com este problema, porém usando provedores diferentes e com config de libs diferentes,. Uns usando CAPICOM, outros DELPHISOAP.
Eu estou usando OpenSSL pois o certificado do cliente é A1.
Vi também que o pessoal alterou alguns parâmetros nos arquivos INI do seu provedor. O problema é que não faço idéia a origem desse erro, logo não saberia o que setar ou dessetar no INI.
Alguém que emite NFSe usando issDSF poderia me ajudar?
-
Acho que já identifiquei o problema:
Na propriedade Provedor, meu componente está com o valor Nenhum, mas este provedor é selecionado automaticamente de acordo com a cidade correto? Eu não seto o provedor na mão no componente.
-
Boa tarde pessoal,
já utilizo o ACBrNFSe para envio de NFSe para a prefeitura de SP.
Para a prefeitura de Campinas, estou utilizando a DLL e o manual que eles disponibilizam, mas estou tendo muitos problemas recentemente com eles.
Como já tenho o ACBrNFSe configurado para a prefeitura de SP e funcionando, imagino que já tenho meio caminho andado.
Pois bem, peguei os schemas da pasta "issDSF" e coloquei na pasta "schemas" da mesma forma que fiz para SP.
Na função GerarLote, estou tendo o seguinte erro de retorno:
TNFSeWClass.GerarXml, não implementado
Tem algo mais que preciso setar para o sistema enviar o RPS para a prefeitura de Campinas?
-
2 minutos atrás, Daniel Simoes disse:
Para certificados A1, você não é obrigado a instalar o Certificado... basta apontar para o conteúdo do PFX, usando ArquivoPFX ou DadosPFX
Olá Daniel,
Então aquele erro de suporte a criptografia 24 só ocorre quando o certificado está instalado?
Neste caso em que está ocorrendo usando o WinCrypt, posso então desinstalar o certificado A1 da máquina e apontar ele no componente ACBrNFe que já funcionará ou o problema está no arquivo PFX mesmo? Ele foi gerado com criptografia 2048 bits e neste caso para usar o WinCrypt, que suporta apenas A1 com criptografia 1024 bits, teria sim que instala-lo usando o programa da valid que converte certificados em 1024 bits?
Não sei se estou viajando, mas hoje eu já aponto o certificado A1 no componente ACbrNFe, mas eu também instalava ele achando que precisava.
-
2 horas atrás, BigWings disse:
Sim.
Se quiser usar OpenSSL com NFe 4.00.
Certo, entendi. Então MingGW é para uso da OpenSSL.
Então se eu for usar WinCrypt, no qual atende tanto Certificados A1 como A3, ele já atende a NFe 4.0 sem precisar do MingGW?
Porém para certficados A1 usando WinCrypt, sou obrigado a instalar o Certificado A1 no padrão 1024bits, pois se mante-lo como 2048 bits, me retorna o erro de suporte a criptografia 24. Está correto?
-
18 horas atrás, BigWings disse:
Incompatibilidade de DLLs provavelmente.
Se você está compilando o ACBr com a diretiva {DEFINE USE_MINGW} ativada, deve usar as DLLs da pasta ACBr\DLLs\XMLSec\MinGW\32.
Senão, usar as DLLS da pasta ACBr\DLLs\XMLSec e ACBr\DLLs\OpenSSL\0.9.8.14
Obrigado, funcionou. Substituí as DLLs e deu certo.
Eu realmente estava confundindo WinCrypt com MinGW, achando que era meio que a mesma coisa.
WinCrypt veio para substituir a CAPICOM, e atentando assim tanto certificados A1 como A3 correto?
MinGW é aquela atualização para usar TLS 1.2 para a NFe 4.0 correto? Neste caso, para usar o ACBrNFe de forma correta para a versão 4.0, obrigatóriamente eu preciso instalar o componente com MinGW?
-
1 minuto atrás, BigWings disse:
Sim, acabei de testar aqui, mudei para winCrypt e deu este erro '24'.
Meu componente estava confgurado para OpenSSL, não dava este erro '24' e agora entendi o porque, como vocês falaram, é porque OpenSSL suporta 2048 bits nos certificados, porém estou tendo problemas na hora de enviar a NFe, está me dando Access Violation na DLL libXMLSec.dll ao assinar a NFe. Começou a ocorrer este erro depois que atualizei o ACBr, meu executável antigo não dava este problema. O que pode ser?
Já respondi lá atrás:
O Juliomar está correto em dizer que WinCrypt atende ambos, mas certificados A1 novos vem com encriptação de 2048 bits, o que WinCrypt e CAPICOM vão acusar o erro "The Cryptographic Service Provider type '24' is not supported.", sendo necessário fazer a conversão do certificado.
Esse problema não existe com OpenSSL.
-
Em 23/10/2017 at 10:12, BigWings disse:
As DLLs da MinGW são usadas quando você define SSLLib como OpenSSL, elas são necessárias para habilitar o acesso a webservices protegidas com TLS 1.2. Se você não vai usar OpenSSL, não precisa do MinGW.
Não.
MinGW é OpenSSL, não substitui a CAPICOM. A substituta do CAPICOM é a WinCrypt.
Ok, entendido.
Então para ter o ACBr atendendo tanto certificados A1 quanto A3, o que devo instalar? O ACBr com WinCrypt para atender certificados A3 e o que mais para certificados A1?
-
Em 16/10/2017 at 12:16, BigWings disse:
Difícil adivinhar, o que você pode fazer é testar usando CAPICOM, que não usará as DLLs MinGW, mas as configurações do Internet Explorer.
Prefira testar informando o arquivo .pfx e a senha.
Para A1 é preferível o OpenSSL. Para A3 eu diria o WinCrypt que não depende das configurações do IE nem da CAPICOM.dll que já foi depreciada pela MS.
Entendi, mas para desenvolver um sistema aonde preciso atenter os 2 casos, qual deles eu faço? Preciso ter apenas 1 executável para atender certificados A1e A3. Qual a melhor instalação para o componente então? Entendendo que MingGW atendendia A3 e OpenSSL A1, como deixar o componente atendendo os 2 tipos de certificado?
Vi que no arquivo ACbr.inc tem a opção de desabilitar OpenSSL, CAPICOM e habilitar MingGW:
{.$DEFINE DFE_SEM_OPENSSL}
{.$DEFINE DFE_SEM_CAPICOM}
{.$DEFINE USE_MINGW}
Para instalar o componente para usar MingGW, preciso necessariamente usar tbém a diretiva {.$DEFINE DFE_SEM_CAPICOM} ?
entendendo que a MingGW substitui a CAPICOM, então teria correto?
Enfim, qual a combinação de Defines usar para deixar o componente trabalhar com os 2 tipos de certificado?
-
14 minutos atrás, BigWings disse:
Apenas para certificados A1 com OpenSSL, que não tem suporte a certificados A3.
BigWings, o que será que errei então na instalação com WinGW para dar o erro de Status erro 500?
Para meus clientes que usam tanto certificado A1 quanto A3, qual a melhor configuração do componente para atender os 2 casos? -
10 minutos atrás, José Manoel disse:
Também estou tendo problemas. Após rodar ACBrNFe.WebServices.StatusServico.Executar tenho a seguinte resposta:
Olá amigo,
noDemo do ACBr também da o erro ao consultar o serviço. No meu caso em particular o erro estava alteração que fiz no arquivo ACBr.inc ativando o MinGW. Acredito que ainda não está 100% esta implantação.
-
Em 09/07/2017 at 13:28, sandrovillas disse:
JJA, as mensagens de erros desapareceram, porem o status vem sem resultados, conseguiu chegar até este ponto, ou já obteve sucesso?
Na imagem que postei o tipo de ambiente aparece como 1 (produção), porém estou informando para Homologação, sei que somente esta liberado
a 4.0 para testes, mas mesmo assim o resultado aparece desta forma.
Bom dia sandrovillas,
acabei de testar aqui o componente atualizado. Consegui evoluir no seguinte ponto:
- Antes não conseguia nenhum resultado no status de serviço, nem em homologação e nem em produção.
Hoje consegui obter sucesso no status de homologação, mas produção continua dando o erro 500.
O que eu mudei:
- Havia alterado o arquivo ACBr.inc para instalar com o tal de MinGW, mas como vi que algumas pessoas estavam conseguindo evoluir com o ACBr 4.0 para SP, então só poderia ser algo que tinha feito.Pois bem, reverti o arquivo ACBr.inc e reinstalei o componente, e agora consegui obter sucesso no status de serviço em homologação, mas em produção ainda sem sucesso.
Agora se surgiu algumas dúvidas:
1) ACBr com MinGW será que está com problemas?
2) ACBr com MnGW serve apenas para atender certificados A3 correto? Se usar A1, nem preciso me preocupar em ativa-lo no ACBr?
3) NFe 4.0 para São Paulo realmente ainda não está disponível para produção?
-
Atualizei os componentes semana passada, mas ainda com o mesmo erro.
Atualizo os componentes com o ACBrInstall.exe agora somente marcando a opção de excluir arquivos antigos. Está correto certo?Não sei mais o que verificar no componente, vi que a URL enviada pelo componente está correta:
https://homologacao.nfe.fazenda.sp.gov.br/ws/nfestatusservico4.asmx
Mas quando entra na função Enviar, retorna o erro 500.
-
Boa tarde,
desculpem reviver este tópico, mas ainda estou com o mesmo problema ao executar o serviço da NFe para versão 4.0.
Estou com meus componentes atualizados e estou testando com a oACBrDemo.
Algúem de SP que já está trabalhando com NFe 4.0 poderia me dar uma ajuda?
Abraço
-
Uma dúvida:
Meu ACBr está compilado para usar a MinGW:
{$DEFINE USE_MINGW}
Mas também não desativei a capicom:
{.$DEFINE DFE_SEM_CAPICOM}
Não era para funcionar a SSLLibcom Capicom mesmo eu compilando o ACBr para MinGW? OU assim que ativo o MinGW, o Capicom para de funcionar?
Porque do jeito que está meu componente, em um cliente meu, mesmo configurado o SSLLib como Capicom, está dando esta mensagem de erro acima, como se a config SSLLib estivesse como MinGW.
O que pode estar errado?
-
Boa tarde,
alguma solução para o erro citado?
Também estou com o mesmo problema.
-
23 horas atrás, Jonathan Schmitt disse:
Sim, é possível pois são métodos diferentes.
Vou fazer mais uns testes e retorno aqui se conseguir resolver.
Com os fontes e os schemas atualizados. Funcionou o status do serviço na versão 4.00 para mim hoje.
Hum, aqui não deu certo. Meus fontes estão atualizados com data de 2 semanas atrás, recompilei usando MINGW alterando o ACBr.inc.
Qual config da SSLlib você está usando?
-
1 hora atrás, André Ferreira de Moraes disse:
São Paulo ainda não divulgou os endereços. Apesar de ser possível deduzir os endereços baseados nos endereços atuais + os novos nomes, os webservices ainda não estão compatíveis com as alterações previstas.
Por exemplo, o Status de Serviço para a versão 4.0 pode ser acessado através do endereço https://homologacao.nfe.fazenda.sp.gov.br/ws/NfeStatusServico4.asmx?WSDL mas o soapAction ainda está no padrão antigo, <soap12:operation soapAction="http://www.portalfiscal.inf.br/nfe/wsdl/NfeStatusServico2/nfeStatusServicoNF" style="document"/> onde está o 2 em destaque, deveria estar 4 e por este motivo não irá funcionar com os fontes atuais do componente.
Certo, então por hora, só aguardar? Como o amigo acima mencionou, pode já ser feita as adaptações tentando enviar a NFe 4.0, mas o status ainda está no aguardo?
-
11 minutos atrás, Jonathan Schmitt disse:
Não consegui.
Mantive o status do serviço na versão 3.10 e prossegui com as alterações da 4.0.
Mas você consegue dar andamento no método enviar sem que componente esteja com StatusServico OK?
Não sabia dessa, por isso estacionei.
-
Também estou com o mesmo problema.
Significa então que a Sefaz SP ainda não tem disponível o ambiente de homologação para NFe 4.0?
Provedor DSF. Problema ao assinar o RPS
em ACBrNFSe
Postado
Boa tarde Italo,
desculpe se minha pergunta for idiota, mas lote RPS não é nada mais que vários RPS juntos? E também mesmo que seja enviado um RPS por vez, ele não precisa obrigatóriamente estar vinculado a um lote? Ou seja:
LOTE 1 = (RPS 1, RPS2, RPS3)
LOTE 2 = (RPS4)
Não seria esta a lógica?