Italo Giurizzato Junior

Boa noite John, Você esta tentando carregar o XML errado. Esse XML não é a nota e sim o retorno do web services DonwloadNFe note que a primeira tag é retDownloadNFe que deixa claro que se trata de um retorno do web services mencionado. Você esta cometendo um erro comum, pega o retorno do web service e salva no banco de dados. O XML da NF-e propriamente dita esta dentro da tag: procNFe. Você deve estar lendo a propriedade ....XML, correto? Pois bem em vez ler a propriedade ....XML, mude para ....retNFe.Items[ x ].procNFe Desta forma você terá o XML propriamente dito da NF-e, ou seja, o conteúdo da tag: procNFe. Outra coisa, o motivo pelo qual esta aparecendo a data 30/12/1899, simples, ao tentar carregar o XML do retorno do Donwload note que a versão desse web service é 1.00, o componente acredita que é essa a versão da NF-e, como não existe a versão 1.00 assume a versão 2.00 e nesta versão não existe a tag dhEmi e sim dEmi, isso faz com que o componente atribua a data base 30/12/1899 a propriedade dEmi. Espero ter ajudado.

Boa noite John, Exitem alguns erros na sua aplicação. Note que algumas TAG é necessário informar a data e hora (por exemplo: dhEmi e a sua aplicação esta informando somente a data ficando a hora toda zerada. Para esses campos você deve usar a função Now em vez de Date, pois a primeira retorna a data e hora do computador e a segunda somente a hora. As TAGs: dhCont e xJust são informadas pela sua aplicação é por isso que no XML consta: As TAGs: dhCont e xJust são informadas pela sua aplicação é por isso que no XML consta: <dhCont>2016-09-29T00:00:00-03:00</dhCont> <xJust>SEFAZ-MG AUTORIZOU O USO INDERTEMINADAMENTE</xJust> Reveja a sua aplicação mais precisamente a rotina que alimenta o componente e veja o que esta sendo passado para o campo xJust. No campo dhCont devemos informar a data e hora de inicio de contingência, a primeira nota emitida poderá ter a mesma data e hora informada no campo dhEmi, mas as demais o valor dhCont deve permanecer igual a da primeira, logo o valor de dhEmi das demais notas serão superior ao dhCont.+ Já o campo xJust você deve informar o motivo pelo qual o Emitente optou por emitir a nota em contingência. Espero ter ajudado.

Boa noite Allan, Por favor lei com mais atenção a minha postagem anterior. Da forma que estava antes esta errado. A alteração ou melhor a correção foi feita com base no exposto do item 10.4 - Leiaute de Distribuição: Evento de NF-e - página 169 da versão 6.0 do Manual da NF-e. Onde deixa bem claro que o XML (*-procEventoNFe.xml) deve conter os dados do evento enviado a SEFAZ mais os dados da homologação deste evento. Sendo assim, se o evento foi rejeitado ele não foi homologado, logo não devemos gerar o XML acima mencionado.

Boa tarde Leo, A cidade em questão se utiliza do provedor Betha ou Bethav2? Até onde sei você precisa usar um certificado e-CNPJ para assinar. A não ser que esse certificado da Betha seja para realizar testes.

Boa tarde Aline, "Aba Remetente", você esta se referindo ao programa gratuito do governo? Se sim, desculpe, aqui é tratado sobre o componente ACBrCTe.

Boa noite André, Pelo que entendi o componente compara o valor de rootNode com infElement. O infElement é passado para a rotina como sendo "ns3:LoteRps" mas o valor de rootNote retornado pela função xmlDocGetRootElement é "LoteRps". Sendo que no XML existe o prefixo ns3: na tag LoteRps. O problema é que somente uns 2 ou 3 provedores existem o prefixo, um deles é o Ginfes. Talvez a solução seria: (...) if Pos(':', infElement) > 0 then infElement := Copy(infElement, Pos(':', infElement) +1, Length(infElement)); { Se tem InfElement, procura pelo mesmo. Isso permitirá acharmos o nó de assinatura, relacionado a ele (mesmo pai) } if (InfElement <> '') then begin (...) Com isso removemos o prefixo do infElement caso ele exista. Tente essa solução.

Bom dia, Para separar o vTotTrib de produto e serviço a sua aplicação pode muito bem fazer isso, através de 2 variáveis. vTotTribProd e vTotTribServ a propriedade vTotTrib recebera o valor de uma ou de outra dependendo se for um produto ou serviço.

Sérgio, Os testes que você fez foram somente com o Fortes Report, correto? Não realizou nenhum teste usando o Fast Report?

André, Por favor atualize todos os fontes de todas as notas reinstale todos os componentes, pois foi enviado algumas correções e melhorias no que se refere ao OpenSSL.

Sergio, Inutilização não é evento. Você não inutiliza um CT-e e sim um numero ou uma faixa de números. Cancelamento é um evento pelo simples fato do CT-e existir. A inutilização não é evento, como dito, você esta informando a SEFAZ que o numero ou uma faixa de números não se referem a nenhum CT-e, pois ocorreu uma falha no sistema e não existe nenhum CT-e com o numero informado ou pertencente a faixa informada. Temos os seguintes métodos de impressão: Para o CT-e temos Imprimir e ImprimirPDF; Para Eventos temos ImprimirEvento e ImprimirEventoPDF; Para Inutilização temos ImprmirInutilizacao e ImprimirInutilizacaoPDF.

Bom dia Werner, Se uma NFC-e for rejeitada, segundo o seu exemplo, o procedimento é: 1. Corrigir o dado que esta errado no banco de dados, para que mais nenhuma nota se utilize da informação errada. 2. Gerar novamente o XML da nota que foi rejeitada, sendo que agora o dado que estava errado tem que estar correto. 3. Assinar, validar e Enviar. Você não pode alterar um XML assinado, mas pode gera-lo novamente com o mesmo numero e código de nota ( temos que garantir que o valor de nNF e cNF sejam exatamente iguais os da nota que foi rejeitada ) só que agora com os dados corretos.

Bom dia Marcio, Muito obrigado pela colaboração, já esta no repositório.

Bom dia André, Só para deixar claro, quando você diz "transmitir a NF" esta se referindo a NFS-e, correto?

Bom dia Sérgio, No meu entendimento devemos sempre carregar o XML do CT-e e depois do evento e por fim imprimir ou gerar o seu PDF. Caso contrario teremos somente os dados do evento e desta forma não saberemos qual CT-e o evento esta vinculado.

Bom dia Rogério, Sendo assim, o Remente por ser uma Pessoa Física, deve emitir uma Carta Remessa de Mercadoria e anexar a Nota Fiscal de compra da mercadoria. A transportadora por sua vez deve informar como documento originário a CRM emitida pelo Remetente para poder emitir o CT-e. Não se deve informar a chave da NF-e de compra da mercadoria, pois o CT-e será rejeitado uma vez que o CNPJ/CPF do remente não condiz com o CNPJ que consta na chave. E tem um outro detalhe se o Remente é uma pessoa física, ele não pode ter emitido a NF-e uma vez que não esta credenciado junto a SEFAZ para tal emissão. Por outro lado se o Remente é uma pessoa jurídica e obrigada a emitir NF-e, não podemos informar os dados da nota como sendo uma nota fiscal comum de papel ou informar como sendo outro tipo de documento. Se assim fizermos o CT-e também será rejeitado, pelo simples fato que se o Remente é obrigado a emitir NF-e, então devemos informar a chave da NF-e como sendo o documento originário. Espero ter sido claro.

Boa noite Márcio, Você fez as alterações nos arquivos Cidades.ini e Fiorilli.ini ? Se sim, funcionou? Se sim, por favor anexe os INI alterados.

Boa noite Sérgio, O correto é carregar o XML do CT-e e depois o XML do Evento, por fim executar o método Imprimir ou ImprimirPDF.

Boa noite Allan, Se tratando de evento o componente gera 3 XML que se forem salvos em disco temos: *-ped-eve.xml (Pedido de Evento, trata-se do XML de envio para a SEFAZ) *-eve.xml (Evento, trata-se do XML de retorno da SEFAZ) *-procEventoNFe.xml (Processamento do Evento da NF-e, trata-se de um XML que contem o conteúdo do XML de envio e do retorno) Este último devemos guardar e disponibilizar ao Destinatário. A alteração que fiz foi baseado no seguinte argumento: Se o evento não foi processado significa que ele foi rejeitado, sendo assim não faz sentido gerar o XML (*-procEventoNFe.xml). Para pegar o XML retorno da SEFAZ tente da seguinte forma: xRetorno := ACBrNFe1.WebServices.EnvEvento.RetWS; Para ler diretamente os dados do retorno, tente da seguinte forma: aStatus := ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[ x ].RetInfEvento.cStat; aProtocolo := ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[ x ].RetInfEvento.nProt; Espero ter ajudado.

Bom dia Rogério, O refrigerador se encontra de posse do Remetente ou da Loja? Quem vai pagar o Frete, Remetente (pessoa física) ou o destinatário? Se é o Remetente que vai pagar pelo frete, este tem que emitir uma carta remessa de mercadoria que pode ser de próprio punho e anexar a NF para comprovar que a mercadoria não é fruto de roubo (por exemplo). Mas no CT-e o que deve ser informado como sendo documento originário é a carta remessa de mercadoria.

Bom dia Sandro, Favor visitar diariamente o Portal Nacional da NF-e. Quando o ENCAT regulamentar a inclusão de uma TAG para o Troco, será publicado uma Nota Técnica e esta será disponibilizada pela SEFAZ no Portal Nacional da NF-e. Desta forma você vai descobrir sem tem algo de novo ou não.

Bom dia, Não entendi o motivo pelo qual você incluiu a propriedade vTotTrib ao grupo ISSQNTot, pois segundo o Manual da NF-e não existe o vTotTrib no grupo ISSQNTot.

Boa tarde Gabriel, Muito obrigado pela colaboração, já esta no repositório.

Boa tarde Rogério, No meu entendimento o Remetente sempre é o emissor do documento originário a ser informado no CT-e. Se o Remente é uma pessoa física, o documento emitido por ela será algo do tipo "Carta Remessa de Mercadoria" ou "Declaração".

Boa tarde Leonardo, Se o emitente do MDF-e for uma transportadora o documento a ser informado é o CT-e e não a NF-e. O componente só vai incluir as chaves das NF-e caso o emitente não seja uma transportadora.

Bom dia a todos, Paulo, se tratando de NFS-e não existe nada e nem vai ter uma vez que a emissão da NFS-e é a nível municipal, você como destinatário terá que solicitar o XML da NFS-e ao emitente. Douglas, infelizmente não tenho nenhuma informação privilegiada com relação ao CT-e, mas acredito sim que vamos ter algo nesse sentido, veja os motivos: 1. Foi criado o Web Services MDFeDistribuicaoDFe para o MDF-e, sendo que não vejo necessidade, uma vez que não se trata de um Documento Fiscal que deva ser compartilhado, ele serve para agilizar a fiscalização da carga transportada em um posto fiscal de fronteira entre Estados. 2. Se você acessar o Portal Nacional do CT-e e for em Notas Técnicas, vai notar que esta faltando a NT 2015/002. Qual será o conteúdo dessa NT, uma minuta da versão 3.00 do CT-e ou o CTeDistribuicaoDFe? 3. Se para a NF-e e MDF-e já temos um Web Services de DistribuicaoDFe, porque não ter um também para o CT-e? Visto que o Tomador do Serviço também tem o direito de saber se alguém esta emitindo um CT-e contra o seu CNPJ/CPF e com base nessa informação se manifestar (semelhante a NF-e) e após essa manifestação obter o XML completo do CT-e bem como os Eventos: como carta de correção, cancelamento, etc.