Gabriel Franciscon

Opa, Como você mesmo disse que não acontece toda vez, pode ser problema com a SEFAZ autorizadora... De qualquer forma, minha dica é; Tente aumentar o valor da propriedade ACBrNFe1.Configuracoes.WebServices.TimeOut Verifique também essas propriedades OpenSSL (Funciona apenas para certificados A1) ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryOpenSSL; ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpOpenSSL; ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL; ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; WinCrypt (Depende das atualizações do Windows) - Recomendo usar dessa forma ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2;

Segundo o Boletim 007/2019 da Receita Estadual do Paraná informa que o web service de homologação está preparado para receber o grupo de Responsável técnico. Para fins de conhecimento, realizei a emissão de uma NFe através do demo do ACBr no estado do Paraná (PR) e em ambiente de Homologação. Informando o grupo infRespTec e obtive exito na autorização da mesma. Percebi que; CRST e IdCRST ainda não foi implementado. Configuracoes.RespTec.IdCSRT := 0; Configuracoes.RespTec.CSRT := '' O grupo infRespTec é de preenchimento obrigatório porém não é validado infRespTec.CNPJ := '00000000000000'; infRespTec.xContato := 'Nome do responsável'; infRespTec.email := '[email protected]'; infRespTec.fone := '4133330000'; O não preenchimento implica na rejeição: 972 - Obrigatória as informações do responsável técnico. Qualquer valor passado para as propriedades acima serão aceitos.

Hoje está bem complicado acessar o web service de distribuição... Veja o tempo que está levando para acessar pelo navegador, acessando a url do web service. E ah, hoje mais cedo vi relatos aqui no fórum de outras pessoas com o mesmo problema. Aparentemente o web service está sofrendo mesmo...

Bom dia, @walter faria! Acredito que o ISSWeb seria o provedor Fiorilli... Já que olhando o layout de integração, aponta para http://ws.issweb.fiorilli.com.br/. Se for, o ACBr já tem integração com esse provedor funcionando em várias cidades. Basta saber se a cidade em que você deseja emitir NFS-e está listada em: Exemplos\ACBrDFe\ACBrNFSe\ArqINI\Cidades.ini. Se não tiver, você mesmo pode editar o arquivo Cidades.ini, copiar o bloco de uma outra cidade que utiliza o mesmo provedor e mudar apenas o código do IBGE, nome da cidade e UF. Feito isso é só realizar os testes.

Uma dica é tratar esses erros de Web Service inoperante... Eu verifico no except a mensagem e chamo a function novamente. Claro, com um limite de tentativas parametrizável. Normalmente quando o erro é apresentado, na segunda ou terceira tentativa consigo obter exito na conexão com o Web Service. E para o usuário fica transparente (apenas na última tentativa eu exibo a mensagem de erro). Na tela ele fica aguardando com um progressbar.

O obrigatoriedade varia de Estado para Estado, valor da nota, tipo de mercadoria. E sim, se for obrigado a manifestar e o destinatário não manifestou no prazo, pode dar problemas... Atualmente não são todos os Estados que obrigam, mas a ideia é que isso vá se tornando obrigatório de forma gradativa. Na Nota Técnica 2012.002 diz: Após um período determinado, todas as operações com “Ciência da Operação” deverão obrigatoriamente ter a manifestação final do destinatário declarada em um dos eventos de Confirmação da Operação, Desconhecimento ou Operação não Realizada. Então vamos supor um exemplo: Não é obrigado a manifestar o documento fiscal no seu Estado; Mas você realizou um evento de manifesto com a Ciência da Operação. Nesse caso em um determinado prazo* você OBRIGATORIAMENTE deverá realizar um manifesto final. *Esse prazo varia conforme a operação seja interna, interestadual, tipo do evento de manifesto escolhido. Varia entre 15-70 dias.

Controle interno... Infelizmente O Ambiente Nacional não disponibiliza os eventos que o próprio destinatário criou. Pois intende-se que o destinatário deverá ter armazenado os eventos que ele mesmo cria. Sim, todos os CPF/CNPJ que estiver dentro dessa tag, tem acesso ao XML sem a necessidade de realizar o manifesto. Mas aí vem a pergunta; O fornecedor colocaria o CNPJ da contabilidade do seu cliente na nota fiscal que ele irá emitir? É bem provável que não; por 2 motivos. Existem muitos sistemas que ainda não tem essa opção de informar CPF/CNPJ nessa tag. O Fornecedor pode não querer colocar o CNPJ da contabilidade do seu cliente na nota fiscal dele. Então eu acredito que pro seu caso, o mais correto seria mesmo o destinatário realizar os manifestos, obter os XML's e no inicio de cada mês enviar para contabilidade. Vou deixar abaixo uma tabela de como funciona a questão de quem tem acesso aos Eventos, Resumos, NFe. *Terceiros são os que constam na tag <AutXML>

Não está fazendo nada de errado... A lógica é essa mesmo. O tipo do evento pode ser dois (Ciência ou Confirmação) em ambos os casos, você terá o XML da nota fiscal. Dando ciência, possibilita o fornecedor cancelar a nota fiscal sem que você dispare outro evento. Dando confirmação, o fornecedor não pode cancelar enquanto você não disparar um evento de Operação não realizada. No meu caso: Eu baixo todos os resumos/eventos/NFe pelo método DistribuicaoDFePorUltNSU Realizo o manifesto com a Ciência da Operação de todos os resumos encontrados.* Executo novamente o passo 1 (Agora terei o XML da NFe dos resumos manifestados acima) Dessa forma, tenho XML completo das notas fisccais. Quando o cliente recebe a mercadoria fisicamente, ele vai realizar o recebimento pelo sistema, nesse momento eu disparo um evento de Confirmação da Operação. No final do mês quando o cliente vai exportar os XML's das notas fiscais de entrada. Eu verifico se tem notas que tem apenas o evento de Ciência da Operação, nesse caso obrigo o cliente a realizar um manifesto (Confirmação, Operação não realizada ou Desconhecimento) Ou seja, no final do mês TODAS as notas ficais que foram emitidas contra o CNPJ do cliente, estão devidamente manifestadas com uma manifestação final. Pois em alguns estados o cliente/destinatário é obrigado a manifestar a nota fiscal. *Na nota técnica diz; Após um período determinado, todas as operações com “Ciência da Operação” deverão obrigatoriamente ter a manifestação final do destinatário declarada em um dos eventos de Confirmação da Operação, Desconhecimento ou Operação não Realizada.

@maiko_bito, Após o XML completo da nota estar disponível, o destinatário ainda pode enviar outro evento de manifesto. Imagine transtorno que ia dar se o destinatário confirmasse a operação por engano e depois disso não pudesse mais mudar de ideia... Seria impossível cancelar a nota fiscal. Ou seja, mesmo que o destinatário informe a confirmação da operação, ele ainda pode dizer em outro momento que a operação não foi realizada... Atualmente não existe nenhuma "trava". A única coisa que não é possível fazer é manifestar com a Ciência da Operação em um documento que já teve sua manifestação final (Confirmação ou Desconhecimento)

Se a nota fiscal estiver manifestada como "Confirmação da Operação" não será possível realizar o cancelamento enquanto não realizar um outro evento de manifesto informando a opção "Operação não realizada" (sim é possível confirmar e depois dizer que não foi realizada) Sobre a outra questão, é bem isso que o nosso amigo, @windsoft falou, (eu mesmo estou com um caso assim, conforme a print abaixo) na maioria dos casos o contador realiza o manifesto, afinal ele também precisa do XML das notas fiscais de entrada. Se for isso que está acontecendo, você ou o seu cliente deve informar ao contador que quem deve realizar o manifesto é o destinatário e mais ninguém! Se comprometendo assim, no inicio de cada mês o seu cliente enviar os XML's das notas de saída e de entrada do mês anterior...

Quando o destinatário realiza um evento de manifesto (Ciência, Confirmação, Operação não realizada ou Desconhecimento) é criado um NSU e o mesmo é disponibilizado para o emitente do documento fiscal, conforme o fluxograma abaixo. Ou seja, por mais que o evento de manifesto deva ser gerado pelo destinatário, o emitente da nota fiscal consegue ter acesso a esse evento criado através do Web Service de DistribuicaoDFe. Com isso, o emitente do documento fiscal poderá realizar consultas nesse web service e capturar os eventos criados pelo destinatário e "anexar" a nota fiscal que foi criada. Dessa forma o emitente da nota vai saber se o destinatário reconheceu/confirmou ou desconhece essa nota fiscal.* *Até onde eu sei não é obrigatório o emitente buscar os eventos criados pelo destinatário. Mas como citado pelo nosso amigo acima, se o o destinatário informar o Desconhecimento da Operação, o emitente tem que se explicar com o fisco.... E dessa forma o emitente saberá se algum destinatário realizou um manifesto com o desconhecimento da operação. De uma olhada na Nota Técnica 2014/002 v1.02b que fala sobre o Web Service de distribuição

Estou com o mesmo problema. Ao enviar um evento de ciência de emissão, confirmação da operação, etc. Ele cria o arquivo *-ped-eve.xml mas não consegue receber o retorno da SEFAZ em alguns casos (timeout por exemplo**) consequentemente, não teremos o arquivo *-eve.xml com o retorno. **Já aumentei o tempo do timeout. Mas mesmo assim o problema ainda ocorre em alguns casos. Sei que o problema de instabilidade está no Ambiente Nacional. Atualmente faço a mesma coisa que nosso amigo acima. Se der rejeição 573 (duplicidade de evento) eu considero como realizado. Porém fazendo isso, não tenho acesso ao protocolo e o XML de retorno do evento. Conforme o exemplo abaixo No primeiro evento que eu criei (Ciência da Emissão) tive sucesso em obter o retorno. Já no segundo evento (Confirmação da Operação) deu erro de timeout ao obter o retorno. Então na segunda tentativa de mandar o mesmo evento; recebi o retorno 573... Considero como realizado porém sem ter o protocolo. Mas a pergunta que eu faço é, existe alguma forma de obter a consulta de eventos que eu mesmo criei? Lembrando que o método Consultar não resolve pois são notas fiscais emitidas por terceiros e não retorna os eventos criados.

Bom dia, Ítalo! Consigo sim, inclusive fiz vários testes de: Envio de lote de RPS Consulta de lote Consulta situação do lote Consulta NFSe por RPS Cancelamento Uso o componente com a propriedade "ConsultarAposEnvio" = True e não tive nenhum problema. O único "problema" não é com o ACBr e sim com o WebService; A demora para a nota aparecer no site e consequentemente consultar após o envio.

Olá, fazendo a homologação com os provedores: SJP e IssCuritiba me deparei com duas alterações que tive que fazer nos arquivos SJP.ini e IssCuritiba.ini SJP.ini (Adicionado a URL para o parâmetro LinkNFSe) SJP.ini [LinkNFSe] Producao=https://nfe.sjp.pr.gov.br/servicos/validarnfse/validar.php?CCM=%InscMunic%&verificador=%CodVerif%&nrnfs=%NumeroNFSe% Homologacao=https://nfe.sjp.pr.gov.br/servicos/validarnfsehomologacao/validar.php?CCM=%InscMunic%&verificador=%CodVerif%&nrnfs=%NumeroNFSe% IssCuritiba.ini (Alterado a URL de homologação) ISSCuritiba.ini [URL_H] Como estava: RecepcaoLoteRPS=https://pilotoisscuritiba.curitiba.pr.gov.br/nfse_ws/NfseWs.asmx Depois de alterado: RecepcaoLoteRPS=https://piloto-iss.curitiba.pr.gov.br/nfse_ws/NfseWs.asmx