Italo Giurizzato Junior

Boa tarde Jorge, É estranho pois as URLs são definidas nas units de cada provedor e no caso da cidade de Novo Hamburgo é o provedor ISSNet e na unit consta tanto a URL de homologação quanto de produção.

Boa tarde, Me responda: Porque não informar ve310 como valor de VersaoDF em vez de TpcnVersaoDF(2)? Porque você executa o GravarXML sendo que o Consultar já faz isso? E ao imprimir porque você lê o numero do protocolo e atribui a propriedade ProtocoloNFe?

Bom dia Mauro, Se você utiliza os componentes e se os fontes dos mesmos estão atualizados o seu sistema já utiliza os novos endereços desde maio/2015. Pelo simples fato de que foi eu quem alterou os endereços e enviei para o repositório no dia 01/05/2015. Por outro lado se você utiliza o Monitor te aconselho a mudar para o ACBrMonitor Plus por dois motivos: primeiro que o ACBrNFeMonitor não terá mais atualização e segundo posso lhe garantir que o ACBrMonitor Plus também se utiliza dos novos endereços.

Bom dia Bruno, Através da SEFAZ não tem como saber o último numero de NF-e emitida. Mas se a empresa em questão que vai passar a usar o seu sistema e esta já emiti NF-e é muito simples saber, basta pegar o DANFE da última NF-e emitida por ela. O DANFE contem o número da nota. Se você vai utilizar o ACBrMonitor Plus para emitir a NF-e basta você informar o numero da nota no arquivo TXT que é passado para o Monitor.

Bom dia Rodrigo, No quadro da página 26 temos uma coluna chamada Ocor., quando for 1-1 significa que o campo/grupo é obrigatório e deve aparecer uma unica vez, por outro lado se for 0-1 significa que é opcional e caso venha ser informado só deve existir apenas 1. Sendo assim o grupo <impostoDevol> é opcional, mas se há necessidade de informar o campo pDevol o grupo deverá ser criado. E nota-se também que caso o grupo <impostoDevol> venha a ser criado no XML alem do campo pDevol deverá existir o grupo <IPI> e o campo <vIPIDevol>. Conclui-se que ou você informa: pDevol e vIPIDevol para que toda essa estrutura no XML seja criada ou não informa nenhum dos dois.

Bom dia José, Não estou conseguindo abrir o seu arquivo: Log.txt

Bom dia Claudio, Isso é muito estranho, pois se a nota já esta cancelada no meu entendimento a SEFAZ deveria aceitar o evento de Ciência da Operação e não de Confirmação da Operação. Visto que, só enviamos o evento de Confirmação da Operação quando a mercadoria foi entregue, se a nota foi cancelada pressupõe que a mercadoria não enviada ao destinatário. Por outro lado o evento Ciência da Operação significa que eu comprei mas ainda não recebi a mercadoria. Se a SEFAZ aceitou o evento, concluo que a rotina de checagem deles não esta funcionando como deveria, ou existe ai uma diferença de horários que fez com que isso ocorresse.

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 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 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.