Italo Giurizzato Junior

Boa tarde renfd, Sim a mensagem que aparece é gerada pelo componente. O que precisa ser visto é: Após o envio, como dito anteriormente é retornado o protocolo de recebimento do lote. O componente se encarrega de consultar a situação do lote. Caso o retorno seja: Lote em Processamento, o componente realiza uma nova consulta. O processo se repete 5 vezes. É possível configurar o numero de vezes e o tempo entre uma tentativa e outra. É preciso checar junto ao provedor a questão do processamento. Tem provedor que quando recebe um lote no modo assincrono só processa o lote na madrugada do dia seguinte. Por outro lado se o lote for enviado modo sincrono o processamento é realizado na hora.

Bom dia zumbi, O ACBrNFeMonitor se utiliza dos componentes ACBr. Portanto se você desenvolve as suas aplicações em Delphi não há necessidade de utilizar o Monitor, use os componentes ACBr diretamente na sua aplicação.

Bom dia Solivan, Parabéns. Caso você tenha o DANFE da NFC-e com o QR-Code gerado em PDF, seria interessante postar também para que o pessoal pudessem ver. E informe qual Report foi utilizado para Gerar o mesmo e se QR-Code foi gerado pela própria impressora ou componente e se este é free ou não.

Bom dia Igor, Vamos ao manual ou melhor a Nota Técnica 2013/004 de Outubro/2013, página 94. Temos os campos: #18 = UFIni - Sigla da UF do Carregamento, que no seu caso é SP #19 = UFFim - Sigla da UF do Descarregamento, que no seu caso é PB #23 = infPercurso - Grupo de Informações do Percurso do MDF-e podendo chegar até 25 #24 = UFPer - Sigla da Unidade da Federação do percuso do veículo - Não é necessário repetir as UF de Inicio e Fim. Vamos imaginar que o caminhão vai sair de SP e passar pelas UF: MG, BA, PE para chegar a PB. Desta forma o grupo infPercurso vai se repetir 3 vezes: UFPer = MG, BA e PE.

Bom dia renfd, Você já tentou entrar em contato com o provedor e informar que esta enviando e só depois de 3 a 4 minutos ocorre o erro ao consultar a situação do lote enviado? Se o erro ocorre ao consultar a situação, significa que o lote foi enviado e foi retornado o protocolo do WebService acusando o recebimento do lote.

Bom dia karluscheidrich, A cidade de Ivoti/RS já encontra-se implementada e utiliza o provedor Tecnos. Qual é o erro que esta ocorrendo?

Bom dia Cesar e Asterix, Cesar, qual é a mensagem de erro completa que aparece ao tentar enviar? O erro ocorre na validação ou no envio? Para saber se ocorre no envio, basta checar se foi gerado o arquivo de envio de lote, se não gerou o problema esta na validação que pode ser a falta de algum schema ou os mesmos estão desatualizados, ou seja você esta usando os schemas da versão 2.00 para validar a versão 3.10 Asterix, MG não disponibilizou as URLs dos WebServices para a verção 3.10, pelo menos no Portal Nacional da NF-e não consta.

Bom dia Solivan, O XML que você postou contem o CPF do destinatário e a TAG indIEDest com o valor 1 indicando que ele é contribuinte e possui Inscrição Estadual. o correto neste caso seria informar o valor 9 indicando que não é contribuinte mas que pode ou não possuir Inscrição Estatual. Na propiedade: nfe.Dest.CNPJCPF Ou você informa o CPF do destinatário ou vazio para que todo o grupo Dest não seja gerado. Quero deixar claro que o grupo Destinatário é opcional se tratando da NFC-e. TAG: indIEDest = [1, 2, 9] componente: TpcnindIEDest = (inContribuinte, inIsento, inNaoContribuinte); 1 = Contribuinte ICMS (informar a IE do destinatário); 2 = Contribuinte isento de Inscrição no cadastro de Contribuintes do ICMS; 9 = Não Contribuinte, que pode ou não possuir Inscrição Estadual no Cadastro de Contribuintes do ICMS; Nota 1: No caso de NFC-e informar indIEDest=9 e não informar a tag IE do destinatário; Nota 2: No caso de operação com o Exterior informar indIEDest=9 e não informar a tag IE do destinatário; Nota 3: No caso de Contribuinte Isento de Inscrição (indIEDest=2), não informar a tag IE do destinatário.

Bom dia Solivan, É possível você postar como anexo o XML que esta sendo rejeitado pela SEFAZ?

Thaine, Sim, você pode enviar apenas uma CC-e com varias correções basta colocar o trecho: with ACBrCTe.EventoCTe.Evento.Items[0].InfEvento.detEvento.infCorrecao.Add do begin grupoAlterado := sGrupo; campoAlterado := sCampo; valorAlterado := sValor; nroItemAlterado := iNumItem; end; dentro de um loop e a cada execução dele, os valores de sGrupo, sCampo, sValor e iNumItem são alterados para a próxima correção.

Boa tarde Joel, Toda contribuição é bem vinda. Você pode realizar as alterações, correções necessários para que o componente funcione 100%. Depois você post como anexo os fontes que foram alterados, para que possamos avaliar e disponibilizar para os demais colegas.

Boa tarde Thaine, Note que: Chave, sCNPJ, sGrupo, sCampo, sValor, iNumItem e iNumLote são variáveis. No caso Chave é a chave do CT-e que vai receber uma Correção; sCNPJ é o CNPJ do emitente do CT-e; sGrupo é o nome do grupo onde contem o campo ( sCampo ) que vai ter o seu valor ( sValor ) alterado. Se o campo faz parte de uma lista temos que indicar a sua posição na lista ( iNumItem ), o primeiro da lista é sempre 1. Já iNumLote é o numero do lote de evento a ser eviado. Aconselho você baixar e ler a Nota Técnica 2013/013, mais precisamente as páginas que se referem a carta de correção. E no Anexo VII você tem uma lista com os nomes dos grupos e campos impedidos de sofrerem alteração por carta de correção. Como exemplo: Grupo: rem = remetente Campo IE = Inscrição Estadual Você não pode fazer uma carta de correção para corrigir a IE de um remetente.

Boa tarde Joel, Correto, o conteudo de: ACBrNFSe1.WebServices.EnviarSincrono.NFSeRetorno.ListaNfse.CompNfse[0].Nfse.XML Compreende apenas o conteudo do grupo Nfse, já o que é salvo em disco é acrescentado o grupo CompNfse e dentro dele o grupo Nfse. O motivo é porque se a NFS-e foi cancelada os dados referente ao cancelamento ficam em um grupo separado e fora do grupo Nfse. O XML então salvo em disco segue a estrutura contina no manual Versão 2.0 da ABRASF página 33 onde é declarado o tipo complexo tcCompNfse.

Boa tarde info02serraf, A versão do XML de eventos não foi alterado, portanto continua com a versão 1.00 o que mudou foi a versão dos demais XML para 3.10

Boa tarde Alexandre, A vários meses eu, juntamente com o Juliomar iniciamos o processo de reestruturação da pasta Pacotes. Note que tanto a pasta Exemplos como Fontes, possuem uma pasta especifica para cada componente. Por outro lado a pasta Pacotes que contem os fontes para instalação dos componentes estavam misturados. Com a permissão dos Administradores e outros Moderadores demos inicio a reestruturação. É preciso agora remover da pasta ACBrNFe2 os pacotes de instalação dos componentes NFS-e, CT-e, MDF-e e outros. Mas para isso é preciso concluir as alterações no programa de instalação: ACBrInstall. Qual você vai utilizar para instalar, tanto faz, ambos vão funcionar.

Boa tarde Acca90, O componente esta configurado corretamente? Ele foi alimentado com os dados pertinentes a nota de serviço?

Boa tarde mepissolato, A chave de acesso que você se refere é a chave de 44 digitos? Se sim, o XML da NFC-e esta sendo salvo em disco? Se sim, ao carregar o mesmo através do LoadFromFile a chave será armazenada na propriedade ID. Para obter o conteudo basta: schave: Copy(ACBrNFe.NotasFiscais.Items.NFe.inFNFe.ID,4,44); O copy é necessário pois na propriedade ID temos o literal "NFe" como prefixo da chave. Espero ter ajudado.

Bom dia Rafael, Primeiramente, se você realizou alguma alteração nos fontes para que ocorresse o envio, por favor post como anexo somente os fontes alterados, para que eu possa disponibilizar para todos. Segundo, o componente salva na pasta RPS, os XMLs individuais de cada RPS. Na pasta Ger é salvo o arquivo de envio de lote contendo todos os RPS que compõe o lote, também é salvo nesta pasta o arquivo de retorno contendo todas as NFS-e. Por fim na pata NFSe, é salvo os XMLs individuais de cada NFS-e. Espero ter ajudado.

Bom dia Leandro, Muito obrigado pela colaboração. Já realizei as alterações e disponibilizei. Reforçando: Não temos as URLs tanto do ambiente de homologação quanto de produção para os Estados: AM, CE e MG Não temos as URLs do ambiente de produção para os Estados: MS e PR

Bom dia Edson, O componente segue o que esta estabelecido no manual. A SEFAZ ao retornar o resultado de uma consulta sobre a situação atual de uma NF-e, a estrura do XML retornado é: Informações sobre a autorização da NF-e; Lista de eventos (se houver) vinculados a NF-e; Por outro lado quando você enviou uma carta de correção, o componente salvou um XML contendo os dados de envio e o retorno da SEFAZ acusando a vinculação deste evento a NF-e em questão. E ao enviar uma solicitação de cancelamento para a mesma NF-e, o componente salvou um outro XML contendo os dados de envio e o retorno da SEFAZ acusando a vinculação deste evento a NF-e em questão. Portanto você tem os XMLs de cada evento separadamente. Para a SEFAZ, quando solicitamos uma consulta, ela entende que queremos um histórico completo referente a NF-e consultada, ou seja, a sua autorização e a lista de eventos caso existam. Mas nada lhe impede de desenvolver uma rotina própria para extrair desse retorno somente o que deseja.

Bom dia a todos, Enviei para o SVN uma atualização dos fontes do componente ACBrNFe. As alterações se referem a inclusão de novas URLs para o Estado de PE que disponibilizou os WebServices de Autorização e Retorno de Autorização. Desta forma o componete ACBrNFe esta apto para enviar lotes de NF-e na versão 3.10 para quase todos os Estados brasileiros. Esta faltando apenas: Produção / Homologação AM AM CE CE MG MG MS -- PR PR No caso de MS as URLs do ambiente de homologação já foram liberadas. Para realizar as alterações no componente estou me baseando nas URLs publicadas no Portal Nacional da NF-e.

Bom dia Demostenes, Qual é o Modelo de Documento Fiscal que ocorreu o erro ao enviar na versão 3.10? Para qual UF você esta tentando enviar? Você esta usando os schemas corretos para a versão do Documento Fiscal desejado?

Jairo, Por favor atualize os fotes e teste novamente.

Boa tarde maikews, Segundo a legislação, a Nota Fiscal hoje é um arquivo eletrônico no formato XML, assinado digitalmente pelo emitente e protocolado pela SEFAZ autorizadora do mesmo. Portanto o XML nas condições acima é um Documento Fiscal válido Juridicamente, logo não se trata de um arquivo XML qualquer. Na legislação consta também que o Emitente é obrigado a disponibilizar o XML assinado e protocolado de forma imediata ao destinatário da mercadoria assim que ele obter o protocolo de autorização da SEFAZ. E se uma transportadora for envolvida no transporte dessa mercadoria, ela também tem o direito de receber o XML da NF-e. No meu entendimento a maneira mais simples de disponibilizar um arquivo de computador a outra pessoa, é simplismente envia-lo por e-mail. O Destinatário e a transportadora no caso tem a obrigação de solicitar o arquivo junto ao emitente, principalmente o Destinatário, pelo simples fato de que ambos, emitente e destinatário devem possuir e guardar pelo tempo legal (5 anos) o XML da NF-e para fins de fiscalização. Caso o emitente se recuse a disponibilizar, o destinatário pode e deve no meu entendimento denunciar junto ao Fisco a atitude do mesmo. A SEFAZ não pode e não vai disponibilizar o XML de um transação comercial para Deus e todo mundo. Veja bem não estamos falando de um XML qualquer, trata-se de um documento fiscal. Não estou criticando ninguem apenas interpretando a legislação.

Joel, Relaxa. A alteração que fiz foi drastica, como não tenho XML de exemplo de todos os provedores, eu tinha e tenho a conciencia de ter esquecido de algo. É por isso que quando alguem diz que a impressão esta incompleta eu pesso o XML para testar e efetuar as correções. Procure checar diariamente se existem atualizações, pois a qualquer momento eu posso enviar uma correção ou melhoria do ACBrNFSe ou de outro componente. E falando nisso, mandei mais uma atualização para o SVN, agora de pouco.