JJA

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?

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: 12046 Pesquisei 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?

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.

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?

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?

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?

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?

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?

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.

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.

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?

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?

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?