Italo Giurizzato Junior

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

Boa tarde Juliana, Se você se refere ao provedor eGoverne, este não disponibilizou os arquivos XSD (Schemas), sendo assim, no arquivo INI desse provedor o campo Validar tem esta com o valor zero. Dessa forma o componente gera o XML e envia sem nenhuma validação. Não devemos utilizar outros schemas que não seja o disponibilizado pelo próprio provedor.

Boa tarde Leonardo, Esse tópico será fechado por ser muito antigo. Favor criar um novo tópico expondo o seu problema de forma clara e precisa e evite usar palavras que possam ofender alguém. Desde já muito obrigado pela compreensão.

Boa tarde Carlos, Você não tem nenhum outro cliente que use certificado A1, para fazer novos testes, inclusive usando o libOpenSSL?

Bom dia a todos, Muitos de nós já deve ter emitido uma Nota Fiscal ou Conhecimento de Transporte e o mesmo foi Denegado, não é verdade? Pois bem, o que vem a ser Uso Denegado, o que fazer quando isso ocorre e como prevenir? Status de um DF-e (NF-e, CT-e) Após enviar um DF-e para a SEFAZ, esta pode Autorizar o Uso, Denegar ou Rejeitar. Autorizar o Uso, é quando todas as informações estão corretas e o emitente e o destinatário não possuim nenhum problema com o Fisco, neste caso o DF-e é armazenado no banco de dados da SEFAZ e a venda ou o transporte por ser realizado. Rejeitado, é quanto alguma informação esta errada, neste caso o DF-e não é armazenado no banco de dados da SEFAZ e o procedimento a seguir é fazer as devidas correções e enviar novamente. Uso Denegado, é quanto todas as informações estão corretas, mas o emitente ou o destinatário possui algum problema junto ao Fisco, neste caso o DF-e é armazenado no banco de dados da SEFAZ, mas a empresa emitente do documento esta impedida de realizar a transação comercial ou prestar o serviço de transporte se este for o caso. O que fazer quando um DF-e é denegado? Inicialmente precisamos saber se o motivo da denegação tem haver com o emitente ou com o destinatário. Se o problema é com o emitente, este deve entrar em contato com a SEFAZ do seu estado e verificar qual é o problema, para que o mesmo seja sanado o mais breve possível. Se o problema é com o destinatário, o emitente deve entrar em contato com o destinatário e solicitar ao mesmo que resolva o problema junto ao fisco. Lembre-se, um DF-e denegado não pode ser cancelado. Como se prevenir? Antes de perder tempo em lançar uma nota / conhecimento e depois descobrir que o destinatário esta com problemas no fisco, será que podemos fazer algo antes? Sim, podemos nos prevenir, a maneira mais simples é, ao cadastrar um novo cliente, basta consultar o seu cadastro junto a SEFAZ. Essa consulta pode ser feita de forma automatizada, os componentes ACBrNFe e ACBrCTe possui um método chamado: ConsultaCadastro. Como usar? No programa exemplo do componente ACBrNFe temos um botão chamado Consulta Cadastro, para realizar a consulta precisamos da UF e do CNPJ/CPF da pessoa que desejamos consultar. Exemplo de código: Documento := Trim(OnlyNumber(Documento)); ACBrNFe1.WebServices.ConsultaCadastro.UF := UF; if Length(Documento) > 11 then ACBrNFe1.WebServices.ConsultaCadastro.CNPJ := Documento else ACBrNFe1.WebServices.ConsultaCadastro.CPF := Documento; ACBrNFe1.WebServices.ConsultaCadastro.Executar; for x := 0 to ACBrNFe1.WebServices.ConsultaCadastro.RetConsCad.InfCad.Count -1 do begin Situacao := IntToStr(ACBrNFe1.WebServices.ConsultaCadastro.RetConsCad.InfCad.Items[ x ].cSit); (...) end; Se o valor da variável Situação for zero significa que a empresa não esta habilitada, logo ela tem algum problema junto com o Fisco. Uma empresa cuja situação seja Não Habilitada as chances de um DF-e ser rejeitado é muito grande, logo devemos entrar em contato com essa empresa e solicitar que a mesma resolva o seu problema com o Fisco. Observação: De forma semelhante podemos usar a mesma rotina acima para o ACBrCTe, pois o retorno é exatamente igual. No Manual da NF-e paginas: 64 até 66, em especial os grupos <infCad> e <ender> temos varias informações que podem agilizar o processo de cadastro, vale a pena conferir. Espero ter ajudado.

Bom dia a todos, Em 02/10/2018 foi publicado no D.O.U o Ajuste SINIFEF 13/18 com previsão de inicio em 01/04/2019, o qual entre outras coisas, institui a faixa de séries especificas para a emissão da NFCe em contingência, esta faixa se inicia na séria 890 até a 989. Conforme foi bastante discutido no fórum, muitos usuários questionaram as SEFAZ quanto a prorrogação deste prazo. No dia 09/04/19 foi publicado no D.O.U o Ajuste SINIEF 06/19, o qual prorrogou a exigência desta série para 01/03/2020. Conclusão A emissão da NFCe em contingência deverá seguir sendo realizada usando a mesma série utilizada em modo normal, ocasionando inclusive rejeição se for utilizada a faixa especifica citada anteriormente. Att.

Bom dia Jose, Para mim é problema na SEFAZ-Virtual do RS.

Bom dia Thiago, Peço que atualize os fontes, note que fiz uma alteração no arquivo Recife.ini, comente as linhas que você acrescentou na unit ACBrNFSeWebServices e faça um novo teste usando o novo arquivo INI do provedor. Fico no aguardo de um retorno.

Bom dia Mateus, Essas empresas são de cidades diferentes, mas atendidas pelo mesmo provedor? Se sim, lembre-se que esses provedores não conseguem manter um padrão para todas as cidades atendidas por eles. Portanto isso é normal ocorrer. Logo a sua aplicação, vai ter que ter uma opção de configuração que determina a geração ou não dessa informação no XML.

Bom dia mcob, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Muito obrigado pelo retorno, vou envia a sua colaboração para o repositório.

Boa tarde Anderson, Ainda não esta disponível o serviço de DistribuicaoDFe para o BPe, acredito que em breve vai estar. Mas lembre-se, quando esse serviço se tornar disponível o emitente do BP-e não vai conseguir baixar o XML, com certeza somente o passageiro. Reimprimir o DABPE em um local diferente não entendi, de um exemplo pratico dessa situação. Quanto a perda, é complicado, como disse antes, esta sendo perdido um documento fiscal, logo o emitente tem por obrigação legal guardar o XML pelo período estipulado na legislação. Sendo assim é importante ter cópia de segurança do XML em um HD externo, Nuvem, Banco de Dados, etc.

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

Daniel, Se levarmos em consideração os nomes dos arquivos XML temos o numero do lote que "prova" que o retorno se refere ao envio. Mas infelizmente no XML de retorno não consta o numero do lote que se encontra no XML de envio do lote. E como a chave da nota que consta no retorno é diferente da chave da nota que consta no lote, a SEFAZ pode alegar que pegamos o retorno de uma outra nota ou outra empresa e estamos comparando com o que foi enviado. Outra informação que podemos comparar é o DigestValue, inclusive são essas duas informações (Chave e DigestValue) que o componente verifica para decidir se vai atualizar o XML da nota enviada com o retorno da SEFAZ (quando a nota é autorizada). E neste caso o DigestValue também é diferente. Existe uma semelhança quanto ao horário de emissão da nota que consta no XML e o do retorno. Na nota temos: 2019-04-09T15:31:02-04:00 No retorno temos: 2019-04-09T15:31:24-04:00 Essa diferença de 22 segundos, pode ser o tempo que o PDV demorou para realmente enviar o lote e mais o tempo de demora de processamento da SEFAZ. Resumindo: tomar como base os nomes dos XML e apenas pelo horário de emissão da nota e o que consta no retorno, não são argumentos fortes para dizer a SEFAZ que ela esta com problemas.

Bom dia, Por favor preste mais atenção ao postar, pois esse tópico se refere ao componente ACBrMDFe que não tem nada haver com NFC-e. Poste novamente o seu problema no tópico correto que se refere ao componente ACBrNFe. O tópico será fechado por ser muito antigo.

É a primeira vez que alguém relata esse tipo de problema: a SEFAZ rejeitar uma nota e a chave não ter nada haver com a nota enviada. Se isso ocorreu, chego a conclusão que o problema é na SEFAZ.

Isso eu percebi, mas você não respondeu a minha pergunta.

Bom dia, A sua aplicação roda em uma rede local? Ou em um servidor fora do estabelecimento comercial que chega emitir notas de varias empresas?

Bom dia Wagner, O cliente da sua cliente não pensou na hipótese que ele pode receber um CT-e e uma NF-e com o mesmo nome, ou seja, 10500.xml e ao salvar o segundo XML vai ocorrer a sobreposição. Página 130 do Manual do CT-e versão 3.00 temos: 6.2 Padrão de Nomes para os Arquivos Visando facilitar o processo de guarda dos arquivos pelos legítimos interessados, criou-se um padrão de nome para os diversos tipos de arquivos utilizados pelo sistema CT-e. São eles: • CT-e: O nome do arquivo será a chave de acesso completa com extensão “-cte.xml”; (...)

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Lopes, Vai ai uma dica: Como e quando usar o SVC - SEFAZ-Virtual de Contigência

Bom dia mysyfy, Com essa alteração não vai gerar efeito colateral ao consultar os eventos: 2050, 2060 e 3010? Visto que esses três eventos que mencionei também devemos informar o nrInscEstab.

Boa tarde Ângelo, Os componentes ACBrNFe, ACBrCTe, ACBrMDFe o LoadFromFile (por exemplo) que se utiliza do LoadFromString possui um parâmetro que determina se é apendas para carregar o XML ou se é para gerar o XML novamente, veja: function LoadFromFile(const CaminhoArquivo: String; AGerarNFe: Boolean = False): Boolean; function LoadFromStream(AStream: TStringStream; AGerarNFe: Boolean = False): Boolean; function LoadFromString(const AXMLString: String; AGerarNFe: Boolean = False): Boolean; function LoadFromIni(const AIniString: String): Boolean; Note que somente o LoadFromIni não tem o parâmetro AGerarNFe os demais tem e o seu valor padrão é False. Como o Elton disse, o LoadFromString (que é utilizado pelo LoadFromFile e LoadFormStream) tem por objetivo carretar o XML de terceiros, ou seja, não foi gerado pelo componente. Neste caso o componente checa se o XML esta assinado ou não, caso não esteja será assinado, validado e por fim salvo em disco, dai o motivo do SaveToFile. Já o LoadFromStringIni tem como objetivo carregar os dados do evento que se encontram em um arquivo INI, gerar o XML, assinar, validar e salvar em disco. Logo não devemos em hipótese nenhuma remover o SaveToFile. Se esta ficando dois XML na pasta referente ao mesmo evento, isso significa que a sua aplicação esta gerando e salvando o XML com uma nomenclatura e o componente com outra. Se você adotar a mesma nomenclatura, mesmo o componente salvando novamente só teremos um arquivo, visto que o Windows não aceita dois ou mais arquivos com o mesmo nome.

Bom dia Anderson, Para imprimir o DABPE é necessário ter o XML, caso contrario não tem como, uma vez que as informações a serem impressas se encontram no XML. Agora se o funcionário deletou o XML, deve ser punido pois rasgou um documento fiscal com validade jurídica.

Boa tarde Guto, Muito obrigado pela contribuição, vou analisar a sua implementação mais a do Jefferson.