Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    42.692
  • Registro em

  • Última visita

  • Days Won

    1.241

Tudo que Italo Giurizzato Junior postou

  1. Bom dia Ricardo, Favor anexar os XMLs gerado a realizar a consulta.
  2. Bom dia Celso, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr e faça novos testes. O seu arquivo Cidades.ini esta bem desatualizado, esta com apenas 56 kbytes sendo que o que esta no repositório tem 85 kbytes.
  3. Maikon, Vou enviar essa alteração para o repositório.
  4. Bom dia Maikon, Na unit pgnreGNREW.pas a alteração abaixo não resolveria o problema? Gerador.wCampo(tcStr, '', 'documentoOrigem ', 01, 18, 1, GNRE.c04_docOrigem, '', True, 'tipo="' + FormatFloat('00', GNRE.c28_tipoDocOrigem) + '"'); Desta forma não seria necessário alterar o tipo do campo c28_tipoDocOrigem de Integer para String.
  5. Bom dia Edu, Se tratando do MDF-e, com certeza vai funcionar, pois só temos uma SEFAZ que recepciona todos os MDF-e de todas as UF, é a SEFAZ-Virtual do Rio Grande do Sul.
  6. Bom dia Ala, Dessa outra forma não funciona? SSL.SSLType := LT_TLSv1_2; Configuracoes.Geral.VersaoDF := ve300;
  7. Boa tarde Edu, Sim, deveria estar funcionando no ambiente de homologação, mas infelizmente algumas SEFAZ não estão fazendo o dever de casa.
  8. Boa tarde, Veja o fragmento de código abaixo: Gerador.wCampoNFSe(tcStr, '#33', 'CodigoMunicipio ', 01, 0007, 1, OnlyNumber(NFSe.Servico.CodigoMunicipio), DSC_CMUN); Gerador.wCampoNFSe(tcInt, '#34', 'CodigoPais ', 04, 04, 0, NFSe.Servico.CodigoPais, DSC_CPAIS); Gerador.wCampoNFSe(tcStr, '#35', 'ExigibilidadeISS ', 01, 01, 1, ExigibilidadeISSToStr(NFSe.Servico.ExigibilidadeISS), DSC_INDISS); Gerador.wCampoNFSe(tcInt, '#36', 'MunicipioIncidencia ', 07, 07, 0, NFSe.Servico.MunicipioIncidencia, DSC_MUNINCI); Gerador.wCampoNFSe(tcStr, '#37', 'NumeroProcesso ', 01, 30, 0, NFSe.Servico.NumeroProcesso, DSC_NPROCESSO); Note que a tag <CodigoMunicipio> é gerada com o valor atribuído ao campo CodigoMunicipio, já a tag <MunicipioIncidencia> é gerada com o valor atribuído ao campo MunicipioIncidencia. Se ambas as tags estão com o mesmo valor, me leva a crer que a sua aplicação esta atribuindo o mesmo valor a ambos os campos.
  9. Boa tarde Celso, Foi você que acrescentou essa cidade no arquivo Cidades.ini ? Se sim, favor anexar para que eu possa conferir.
  10. Boa tarde Jean, O XML da nota esta sendo salvo em disco? Infelizmente existem provedores que não retornam o XML da NFS-e. Qual é o provedor?
  11. Boa tarde Everton, Você chegou a testar? Eu sinceramente não sei e infelizmente não tenho como testar.
  12. Boa tarde Rafael, Pode ser que o retorno de evento da NF-e seja diferente do retorno de evento do CT-e. Mas acredito que a solução que você encontrou para o CT-e possa ser aplicada também para a NF-e.
  13. Bom dia Natanael, Por favor leia esse artigo: Como obter o XML da Transportadora CT-e.
  14. Ronie, Se não foi autorizado pelo fato de ter ocorrido erro ao enviar, você pode resolver o problema da seguinte forma: 1. Envia o MDF-e 100, já que agora a SEFAZ esta operando normalmente, é bem provável que ele seja autorizado. 2. Tendo o MDF-e 100 autorizado, efetue o cancelamento do mesmo.
  15. Bom dia Ronie, O que tudo indica é que a SEFAZ-MG utiliza os mesmos servidores para recepcionar o CT-e, CT-e OS e o BP-e. Quando a SEFAZ-MG entrou em contingência e o pessoal começou a emitir o CT-e através da SVC-SP (SEFAZ-Virtual de Contingência de São Paulo) os que emitem o BP-e passaram a ter problemas, ou seja, não estavam conseguindo emitir.
  16. Bom dia Ronie, No meu entendimento devemos fazer o seguinte: 1. O MDF-e de numero 100 foi enviado mas a SEFAZ não retornou o resultado do processamento. 2. Quando isso ocorre devemos realizar uma consulta. 3. Podemos ter como resposta: o retorno acusando que o MDF-e foi autorizado, ou foi rejeitado (neste caso devemos fazer as devidas correções e enviar novamente), ou que o MDF-e não consta na base de dados (neste caso devemos enviar ele novamente) ou ocorrer erro de conexão com a SEFAZ. 4. Caso ao consultar ocorrer erro de conexão, ai sim você emite o MDF-e em contingência, mas em vez de só mudar o tipo de emissão, mude também o numero para 101. 5. O MDF-e 101 tem as mesmas informações do 100 mas só que o tipo de emissão é contingência. 6. Ao emitir os próximos MDF-e verifique primeiro se a SEFAZ voltou, se não voltou continue emitindo em contingência. 7. Quando a SEFAZ voltar a operar, devemos enviar todos os MDF-e emitidos em contingência. 8. Consultar a situação do MDF-e 100, para saber se ele foi autorizado ou não. 9. Se sim, devemos cancelar ele, pois o 101 como dito antes tem as mesmas informações do de numero 100. Espero ter ajudado.
  17. Boa tarde Igor, Você esta com todos os fontes de todas pastas atualizados? Esta configurando corretamente o componente com a versão do e-Social atualmente em uso? Esta realizando testes com o programa exemplo do componente?
  18. Olá Pessoal, Muitos tem interesse em obter o XML da transportadora (CT-e) para facilitar a entrada do Contas a Pagar, etc. Segundo a legislação, quem emite um CT-e tem por obrigação legal de disponibilizar o XML assinado e com o protocolo de autorização ao tomador do serviço, assim que a SEFAZ autorizar o conhecimento. Essa disponibilização pode ser feita por e-mail, ou seja, o emitente envia para o tomador o XML via e-mail. Sabemos que isso nem sempre ocorre, por 2 motivos: 1. No cadastro do tomador não consta o endereço de e-mail; 2. A aplicação do emitente não possui esse recurso ou esta desativado. Mas temos uma alternativa. O componente ACBrCTe possui os seguintes métodos: DistribuicaoDFePorUltNSU e DistribuicaoDFePorNSU. Vamos a sintaxe: DistribuicaoDFePorUltNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do ultimo NSU> ) DistribuicaoDFePorNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do NSU> ) Primeiramente vamos entender o que vem a ser esse tal de NSU. NSU - numero sequencial único, é um numero atribuído pelo Ambiente Nacional ao documento ora compartilhado pelas SEFAZ-Autorizadora. Exemplo: o emitente do conhecimento é do Estado de São Paulo, logo o conhecimento é enviado para a SEFAZ-SP esta por sua vez vai compartilhar com o Ambiente Nacional os conhecimentos que foram autorizados, o Ambiente Nacional por sua vez atribui um NSU para cada conhecimento que receber. Vamos agora entender como funciona os dois métodos mencionados acima. O método DistribuicaoDFePorNSU é o mais simples de entender, pois este simplesmente baixa o documento que possui o NSU informado. Note que usei o termo documento, pois o webservice DistribuicaoDFe pode retornar os seguintes tipos de documentos: Conhecimento Completo e Evento Completo. Se o NSU informado no método DistribuicaoDFePorNSU for o NSU de um evento, o que teremos como retorno será o XML do evento e não o XML do conhecimento. Por outro lado o método DistribuicaoDFePorUltNSU nos retorna uma lista com até 50 documentos, cujos NSU são superiores ao NSU informado. Exemplo: DistribuicaoDFePorUltNSU( 35, 12345678000123, 450 ) ===> 450 é o valor do Ultimo NSU. Ao executar o método, como dito anteriormente poderá nos retornar uma lista com até 50 documentos, pois bem suponha que retorne 50, os NSU desse documentos retornados serão, 451, 452, 453, ...., 498, 499, 500. Lembre-se que nessa lista podemos ter Conhecimentos Completas e Eventos Completos. Através de uma propriedade chamada Schema nos traz a informação do tipo de documento retornado. Temos também outras duas propriedades muito importantes, são elas: UltNSU e MaxNSU. A propriedade UltNSU nos informa o numero do NSU referente ao ultimo documento da lista, já a propriedade MaxNSU nos informar o maior NSU existente no Ambiente Nacional. Continuando o exemplo acima, vamos supor que após a execução os valores de UltNSU e MaxNSU são respectivamente 500 e 750. Era de se esperar mesmo que o valor de ultNSU seja 500 pois informamos 450 e foi retornado 50 documentos, logo o NSU do ultimo é 500. A próxima vez que formos executar o DistribuicaoDFePorUltNSU devemos informar o valor 500, para que ele retorne os documentos a partir de 501 que é o próximo da lista. E devemos repetir o procedimento até que o valor de ultNSU seja igual a maxNSU, desta forma vamos ter baixado todos os documentos disponibilizados pelo Ambiente Nacional. Lembre-se que o valor de MaxNSU tende sempre a crescer a medida que novos conhecimentos forem emitidos e compartilhadas com o Ambiente Nacional. O DistribuicaoDFe não serve apenas para que possamos obter o XML da transportadora (CT-e), mas também descobrirmos se existe alguma empresa emitindo conhecimentos contra o nosso CNPJ sem no nosso consentimento. Você descobre isso através do DistribuicaoDFePorUltNSU e pode avisar a SEFAZ enviando o evento de Prestação de Serviço em Desacordo. Para saber mais sobre o Distribuição DFe vide a Nota Técnica 2015/002 versão 1.00a, que se encontra disponível no Portal Nacional do CT-e e com relação ao evento Prestação de Serviços em Desacordo vide o Manual CT-e Visão Geral v3.00a que se encontra no Portal do Conhecimento de Transporte Eletrônico - SVRS. Informação importante, o serviço Distribuição DF-e, é atendido pelo Ambiente Nacional, portanto não tem nada haver com a SEFAZ-Autorizadora do emitente do conhecimento ou do tomador. Se algo falhar nesse processo, a "culpa" é do Ambiente Nacional.
      • 8
      • Curtir
  19. Boa tarde Weslei, Por favor não fique postando em vários lugares. Já lhe respondi em uma outra postagem.
  20. Boa tarde ALA, O problema foi resolvido, pois a sua postagem não deixa claro.
  21. Boa tarde ALA, Você tentou enviar o evento EPEC? Se sim, qual é o erro que ocorreu? Favor anexar o XML do evento gerado.
  22. Boa tarde Rafael, Muito obrigado pela colaboração, ainda hoje estarei enviado para o repositório. Só não entendi porque você deixou fixo o valor "2" para a tag TomadorExterior, basta atribuir o valor snNao ao respectivo campo que no XML será gerado a tag com o valor "2".
  23. Boa tarde Maiquel, Muito obrigado pela informação, já alterei o arquivo INI e ainda hoje estarei enviando para o repositório.
  24. Conforme publicado no portal de notícias da SEFAZ-PA, a partir do dia 02/09/2019 as NF-es e NFA-es do PA passarão a ser autorizadas pela SEFAZ Virtual do Rio Grande do Sul (SVRS). Para mais detalhes veja a notícia completa em SEFAZ-Pará vai deixar de recepcionar as NF-e
  25. Olá pessoal, A SEFAZ do Pará não vai mais recepcionar as NF-e a partir do dia 02/09/2019. A partir dessa data os contribuintes do Pará devem encaminhar as suas notas para a SEFAZ-Virtual do Rio Grande do Sul. Conforme consta a noticia no site da SEFAZ-Pará. Para quem utiliza o componente ACBrNFe, deverá apenas atualizar os fontes recompilar a aplicação e distribuir a nova versão do mesmo para os seus clientes. Para quem utiliza o ACBrMonitor, vamos disponibilizar uma nova versão do mesmo, ai basta vocês atualizarem os seus clientes. Pela noticia da SEFAZ-Pará não teremos um período de transição, logo vamos nos preparar para a correria, pois dia 2 é uma segunda-feira. Detalhe importante não será necessário realizar nenhuma mudança na configuração do componente ou do Monitor, apenas atualizar.
×
×
  • 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...