Italo Giurizzato Junior

Bom dia Vinicius, sProtocolo := ACBrNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[X].RetInfEvento.nProt; sStat := IntToStr(ACBrNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[X].RetInfEvento.cStat); sMotivo := ACBrNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[X].RetInfEvento.xMotivo; dhEvento := ACBrNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[X].RetInfEvento.dhRegEvento; sDataHora := DateTimeToStr(dhEvento); onde [X] varia de zero até a quantidade de eventos retornados -1.

Bom dia, No seu caso, não existe a intensão de salvar o XML em disco e sim no banco de dados?

Bom dia Marcelo, Vamos analisar 2 arquivos que são retornados pelo Web Services, para essa analise você pode abri-lo através de um navegador: 6-rec-soap.xml <== este é o retorno do envio do lote, note que temos uma TAG chamada <Sucesso> que contem o valor True no meu entendimento significa que o lote foi recebido e não possui nenhum alerta e ou erro e na TAG <NumeroLote> temos o numero (196706063) do lote gerado pelo Web Services para o lote recebido. Você poderia considerar esse numero como sendo um numero de Recibo ou de Protocolo. Observação: no nome do arquivo aparece o numero 6 que é o numero do lote atribuído pela sua aplicação. 196706063-lista-nfse-soap.xml <== este é o retorno da consulta, note que a TAG <Sucesso> contem o valor False que no meu entendimento significa que o lote ainda não foi processado e temos a confirmação disso no grupo <Alertas> onde temos o alerta de código 203 que significa: Lote não processado ainda. Observação: no nome do arquivo aparece o numero 196706063 que é o numero do lote atribuído pelo Web Service. Concluo que o problema encontra-se no Web Services, no que diz respeito a demora em processar o lote. Se tomarmos como base o programa exemplo do ACBrNFSe temos os botões [Consultar NFSe por RPS] e [Consultar NFSe por Período], você chegou a utiliza-las para consultar os RPS enviados? Observação o botão [Consultar Lote] realiza a mesma consulta realizada automaticamente pelo Enviar. No caso do provedor IssDSF não existe o Consultar a Situação do Lote.

Bom tarde, Tem que debugar a partir do Enviar mais precisamente a unit ACBrNFeWebServices.

Claudio, Se tratando de eventos de Manifestação do Destinatário são apenas 4 e nenhum deles é de cancelamento. Na Nota Técnica 2012/002 versão 1.02 - Leia com muita atenção todos os sub itens do item 4.9.10 que trata sobre os eventos e a mudança da Manifestação do Destinatário.

Bom dia Rômulo, Desculpe, esta meio confuso: "...todas as Notas emitidas contra este CNPJ e os Eventos das notas emitidas por ele (digo a manifestação dos destinatários) estão vindo com o NSU correto". O seu cliente vamos chamar de Empresa ABC e vamos supor que ela alem de comprar vende também, logo recebe e emite NF-e. A Empresa ABC ao realizar uma consulta através do DistribuicaoDFe terá como retorno: 1. resumo da NF-e emitida contra o seu CNPJ; 2. Evento de cancelamento, carta de correção, Suframa e EPEC emita pelo emitente da NF-e (que não é a Empresa ABC); 3. Resumo de eventos CT-e e MDF-e (de Autorização / Cancelamento), emitidos pela transportadora. 4. NF-e caso a Empresa ABC venha realizar a Manifestação do Destinatário; 5. Eventos de Manifestação do Destinatário emitido pelos clientes (destinatários) da Empresa ABC; Observação o evento Suframa é emitido pela SEFAZ. Me baseie na tabela que encontra-se na Nota Técnica 2014/002 versão 1.01 - página 4. Portanto se a Empresa ABC não esta recebendo os eventos de Cancelamento, Carta de Correção, Suframa e EPEC isso significa que ou o emitente da NF-e não esta emitindo esses eventos ou a SEFAZ-Autorizadora não esta compartilhando eles para o Ambiente Nacional.

Bom dia Rodrigo, Segundo a Nota Técnica 2013/005 versão 1.22 - página 26 diz o que?

Bom dia Claudio, Sim, não tem problema, desde que a mercadoria já encontra-se no destinatário.

Bom dia Mateus, Se é a SEFAZ que esta com problemas, você deve enviar a NFC-e para a SVC- SEFAZ Virtual de Contingência que atende o Estado em questão. O componente já tem tudo implementado, basta você mudar o tipo de emissão de normal para Contingência SVC. A principio o tempo máximo para enviar uma NFC-e emitida Offline é de 24 horas, agora se esse tempo varia de Estado para Estado então é bom entrar em contato com a SEFAZ do Estado em questão e questiona-los sobre esse tempo.

Bom dia, Enviei uma proposta de alteração para o componente ACBrNFe no que diz respeito ao protocolo de autorização que algumas vezes não é adicionado ao XML já assinado. Peço que aguarde mais um pouco e debug para tentar descobrir o momento exato que ocorre o problema.

Bom dia José, O CT-e cujo numero é 379 o digito verificador é zero e você informou 4, veja: OK: C:\ACBrNFe\CTE\35150812623110000199570010000003791000003790-cte.xml CTE.AdicionarCTe("C:\ACBrNFe\CTe\35150912623110000199570010000003791000003794-cte.xml",1234)

Bom dia Fabio, Por favor, tópico novo para assunto novo. No ACBrCTe essa propriedade ainda não tem função nenhuma.

Rômulo, Segundo a NT 2014/002 se o emitente da NF-e efetuar o cancelamento da mesma o respectivo evento é enviado para a SEFAZ-Autorizadora, esta por sua vez tem que replicar no Ambiente Nacional, que por sua vez tem que gerar um NSU e disponibilizar para o destinatário, para que este ao consultar através do DistribuicaoDFe possa receber o XML do evento. O resumo da NF-e que consta como autorizada a mesma foi manifestada? Caso não tenha, realize a manifestação e depois realize novas consultas ao DistribuicaoDFe.

Você salva o XML em disco, ou apenas lê o mesmo da propriedade XML para salvar no banco de dados?

Boa tarde Marcelo, Pelo que pude ver o problema esta na demora do web service processar o RPS enviado. O envio esta ocorrendo sem nenhum problema inclusive retorna o numero de lote gerado pelo Web Service. E ao consultar o lote retorna que o mesmo ainda não foi processado. Sugiro testar as outras consultas disponíveis para saber quais é o resultado. Um outro teste é alterar o valor da propriedade Transacao de True para False e realizar um novo envio.

Boa tarde Rômulo, No meu entendimento você só informa o valor zero como terceiro parâmetro uma unica vez, dai para frente deve-se sempre informar o último NSU retornado.

Boa tarde Jose, Como lhe disse no e-mail, não utilizo o Monitor e nem faço parte do seu desenvolvimento. Mas analisando o código do mesmo me fez chegar a esse fluxo. E o seu exemplo esta em conformidade com o meu entendimento. Note que o comando CTe.CriarEnviarCTe vai criar o XML, assinar e validar baseado no INI que você esta passando como parâmetro e em seguida realiza o envio para SEFAZ. O que você deseja é o envio de um lote contendo 2 ou mais CT-e e não um a um, correto? Pois bem os 3 comandos que lhe sugeri visa atender a sua necessidade. O comando CTe.CriarCTe vai apenas criar o XML baseado no INI que você passar como paramentro, não vai enviar nada para SEFAZ. Se você deseja enviar um lote com 10 conhecimentos terá que executar o comando acima para cada um deles. Com o comando CTe.AdicionarCTe você lê o XML e o adiciona ao lote, logo você terá que executar esse comando também 10 vezes para adicionar os 10 conhecimentos segundo o exemplo acima. Por fim deve ser executado o comando CTe.EnviarLoteCTe, esse sim é o comando que vai enviar o lote contendo os 10 conhecimentos para a SEFAZ. Quanto ao retorno não sei se vem individual ou todas as informações em único arquivo INI para que a sua aplicação possa ler e atualizar o banco de dados. Mas uma coisa é certa os XMLs de cada CTe gerado pelo CriarCTe será atualizado, ou seja, receberá o procolo de autorização.

Boa tarde a todos, Aqui na empresa onde trabalho, ao comprar algo é emitido o Pedido de Compra e este é enviado via Fax ou e-mail para o fornecedor. E bem no meio do respectivo pedido consta um aviso que segundo a legislação o fornecedor é obrigado a disponibilizar o XML da NF-e e neste aviso consta o endereço de e-mail para qual deve ser enviado o XML com validade jurídica. Essa foi a forma que encontramos de deixar os nosso fornecedores cientes de suas obrigações no que se refere a emissão da NF-e. E diga-se de passagem que funcionou, ou seja, recebemos todos os XML de nossos fornecedores e das transportadoras diariamente. Portanto se cada um fazer a sua parte, não precisamos ter aplicações que obtêm os XMLs de forma não sugerida pela SEFAZ.

Boa tarde Vinicius, Segundo a Nota Técnica 2014/003 - página 9 o campo #13 RNTRC é obrigatório, e a mensagem de erro de validação é clara lhe informando que nenhum valor foi informado. Como se trata do RNTRC do proprietário do veículo, você não deve informar o RNTRC da transportadora.

Boa tarde, Caso você defina um Path em PathSalvar e atribua o valor False as propriedades que definem níveis de organização todos os XML serão salvos juntos no Path informado. Por outro lado você pode defini um Path para PathNFe e neste caso somente os XML referentes as NF-e serão salvos nesse Path os demais em outros lugares.

Boa tarde Rolemar, A propriedade no componente é a mesma que você utiliza para informar o CNPJ do destinatário. Note que ela se chama CNPJCPF.

Bom dia Fabio, O problema deve ser com a sua maquina, pois em casa estou usando o Trunk2 e esse problema não ocorre.

Bom dia Vinicius, O erro ocorre na validação antes do envio, ou se trata de uma rejeição retornada pela SEFAZ? Se é um erro de validação, por favor informe o erro para que possamos lhe ajudar.

Marcelo, Fiz algumas alterações nos fontes visando atender o provedor IssDSF. Por favor atualize os fontes e teste novamente. Configure o componente para apresentar as mensagens retornadas do provedor.

Bom dia Marcelo, Muito obrigado pelos arquivos, vou agora analisar o código do componente baseado principalmente nos retornos.