Ir para conteúdo
  • Cadastre-se

Everton M Gava

Membros
  • Total de ítens

    54
  • Registro em

  • Última visita

Tudo que Everton M Gava postou

  1. Acredito que o problema esteja ocorrendo em pcnEnvEventoNFe, nesse trecho de código: Copy(sDoc, 4, 11). No meu caso a série dos documentos que estou tentando fazer a ciência da operação é 920. a function é a TEventoNFe.GerarXML Resumindo: Eu tenho um CNPJ e estou dando ciência em uma NF-e série 920 emitida por um CPF
  2. Boa tarde, o destinatário é uma PJ, cujo CNPJ é 24746687000177, que está sendo passado para o campo: infEvento.CNPJ := OraDsEmpDFeCH_CNPJ.AsString; Porem , o XML é gerado sem os três primeiros digitos do CNPJ, sendo enviado somente 46687000177. Estou investigando essa questão. Interessante que eu tenho mais de 45 CNPJ's de outras empresas e filiais e utilizo o mesmo trecho de código para atribuir o CNPJ para o evento e todos funcionam.
  3. O destinatário é uma pessoa jurídica e usa um certificado que contem o CNPJ. Arquivos estão em anexo 290041-ped-eve.xml 290041-eve.xml
  4. Estou passando pelo mesmo problema. Ciência da Operação e Desconhecimento da Operação em notas emitidas por CPF contra CNPJ estão retornando esse erro: "Rejeicao: CPF Emitente difere do CPF do Certificado Digital".
  5. Boa tarde, conforme o colega comentou acima, os CTe OS são retornados em conjunto com os CTe. Após os meus testes (e após a atualização do meu ACBr) consegui recuperar os CTe OS também. Obrigado, problema resolvido.
  6. Boa noite Italo, De acordo com os meus testes preliminares, os CT-e OS não retornam na distribuição DFe.
  7. Bom dia, tenho uma dúvida relacionada ao CT-e OS. Esses arquivos são retornados pelo método DistribuicaoDFePorUltNSU do componente ACBrCTe ?
  8. À titulo de informação. Eu tinha duas nota na fila de transmissão com esse problema. Ambas sem pagamento, ou seja, sem a tag <cobr>. Às 09:35 as duas foram transmitidas. Parece que houve algum tipo de problema na SEFAZ na implementação da regra de validação.
  9. Obrigado Ricardo. É isso mesmo. Vimos aqui a mesma coisa, encontramos essa mesma tabela. O tópico pode ser encerrado.
  10. Boa tarde pessoal, Estou com uma NFe na fila de transmissão e a mesma está me retornando o seguinte erro: Informado NCM Inexistente [nItem 2]. A princípio, não encontrei nenhuma modificação nas tabelas. XML em anexo 43180803941052000827550000002919151450218174-nfe.xml
  11. Boa tarde, entrei em contato com a SEFAZ RS e eles me informaram o seguinte: "O evento 610110 - Prestação de Serviço em Desacordo deve ser transmitido para a SEFAZ que autorizou o CT-e. Isso é independente do estado do tomador de serviço. No caso descrito abaixo, o CT-e foi autorizado pela SEFAZ SP. Então, o evento também deve ser transmitido para a SEFAZ SP.". Eu também tentei efetuar a transmissão para a SEFAZ SP e ocorreu o mesmo problema. O meu cliente acabou tomando outras medidas com relação a esse CTe. " Depois desse caso, não apareceram mais casos como o descrito acima: Emitente de SP, tomador de SC. Vou aguardar acontecer mais algum caso e relato aqui o que ocorrer. Obrigado!
  12. Outra questão que pode ser relevante: Estou utilizando o Windows 64bits. Resumindo: quando compilo o programa para a plataforma 32bits: OK. quando compilo o programa para a plataforma 64bits: ocorre o problema relatado acima!
  13. Senhores, boa tarde. Estamos migrando alguns sistemas que utilizam o componente ACBrNFe de 32 para 64 bits, utilizando o Delphi 10.2. Pois bem, estou utilizando uma versão do ACBr baixada do repositório hoje (26/04/2018). O componente está configurado da seguinte maneira: o arquivo ACBr.inc está configurado da seguinte maneira: Quando efetuo a compilação para 64bits o meu sistema acusa o seguinte erro (Ao que me parece, não estão sendo carregadas as DLL's do OpenSSL): Quando efetuo a compilação em 32bits, a compilação transcorre sem nenhum problema, sendo efetuada a transmissão normalmente. Alguem pode me dar alguma dica com relação à isso? Obs: já li todo o conteúdo relacionado nos tópicos abaixo e não consegui resolver o meu problema:
  14. Bom dia, Italo Vou contatar as SEFAZ dos dois estados para tentar resolver o impasse. Isso está incoerente no meu ponto de vista, pois se eu devo utilizar a SVC-RS para enviar os meus eventos, as notas autorizadas em outras SEFAZ devem estar sincronizadas com esse ambiente. Obrigado!
  15. Como o tomador está no estado de SC, deverá encaminhar o evento para a SEFAZ Virtual do RS. No entanto, me parece que o documento não existe para a SEFAZ RS. Lembrando que o mesmo foi autorizado pela SEFAZ-SP. Já está autorizado a aproximadamente 40 dias (lembrando que eu tenho 45 para vincular o evento de prestação em desacordo). Isso me parece falta de sincronização de dados entre as secretarias estaduais!
  16. A transportadora é do estado de SP e o tomador é do estado de SC. O tomador está encaminhando o evento 610110 para a SVRS, no entanto, sempre obtenho a resposta "Rejeição: CT-e nao consta na base de dados da SEFAZ" Alguém poderia me ajudar sobre isso?
  17. Bom, a questão da URL foi resolvida, agora está encaminhando para a SEFAZ Virtual RS. Surgiu outra questão: <cStat>217</cStat><xMotivo>Rejeição: CT-e nao consta na base de dados da SEFAZ</xMotivo> No entanto, o CT-e é válido no ambiente de produção|! 62-ped-eve-soap.xml 62-eve-soap.xml
  18. Italo É o tomador do frete em SC quem está enviando o evento. No entanto, está enviando para a URL incorreta acredito eu (https://nfe.fazenda.sp.gov.br/cteweb/services/cteRecepcaoEvento.asmx). No caso, como o tomador está localizado em SC, deverá encaminhar para a SEFAZ VIRTUAL DO RS (https://cte.svrs.rs.gov.br/ws/cterecepcaoevento/cterecepcaoevento.asmx). Vou verificar se é isso mesmo.
  19. A UF do tomador é 42 - SC. Alterei para enviar para SC e ocorre o mesmo problema (anexei os arquivos). Acho que pode ser a URL do webservice... 61-eve-soap.xml 61-ped-eve-soap.xml Acho que em SC, eu tenho que utilizar a URL da SVRS - (SEFAZ virtual do RS).
  20. Bom dia, em anexo, os arquivos soap 61-eve-soap.xml 61-ped-eve-soap.xml
  21. Prezados, boa tarde. Estou tentando vincular o evento 610110 - Prestação de Serviço em Desacordo a um CTe e estou obtendo o seguinte retorno: 677 - Rejeição: Órgão de recepção do evento inválido. Em anexo o XML do CTe, o XML do envio do evento e o XML com a resposta do webservice. Estou utilizando os dois primeiros caracteres da chave de acesso para preencher a informação cOrgao, no entanto, obtenho sempre a mesma informação! Alguém pode me dar uma luz? 60-ped-eve.xml 60-eve.xml 35180213547711000122570010008742821470101446-cte.xml
  22. Bom Dia, estou com o mesmo problema relatado acima. Estou migrando o sistema de Delphi 2005 para Delphi 10.2. Criando um projeto sem nenhum componente ACBr e funciona. Adicionando o ACBrNFe, dá a mensagem de erro relatada. Utilizo ACBrNFe e ACBrCTe. Acredito que seja algo relacionado ao OpenSSL. Alguém passou por esse problema?
  23. Bom dia. Durante o fim de semana, parece que a situação piorou. Estou recebendo <resNFe> com dois dias de atraso!
  24. Está ocorrendo aqui também!
  25. Bom dia, Por aqui, o problema persiste. Para exemplificar: nota emitida contra o CNPJ da empresa no dia 09/02/2017 às 12:06:48. O resumo foi retornado somente hoje às 08:00 da manhã, logo em seguida, foi efetuada a ciência da operação. Estou no aguardo da próxima execução do DistribuicaoDFe para verificar se o XML completo foi retornado. Parece que está ocorrendo um "delay" entre a inserção da NFe no ambiente nacional e a sua disponibilização no Distribuição DFe. A execução da Distribuição agora, está retornando os eventos, os resumos e os XML's emitidos/vinculados ontem ao meio dia, ou seja, um "delay" de aproximadamente 20h entre a inserção do evento/resumo/NFe na base nacional e o seu encaminhamento para distribuição (estou executando a chamada ao webservice de hora em hora). Mais alguém está notando o problema?
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...