Italo Giurizzato Junior

Bom dia a todos, Fiz as correções agora os TNFSeG.Gera_**** vai passar como parametro o Provedor. Por favor atualize os fontes e testem novamente.

Bom dia Rafa, Atualiza os fontes e tente novamente por favor.

Bom dia Gilson, Por favor atualiza os fontes e tente novamente. Após a atulização note que não tem mais a pasta DANFE_QR3 dentro de ...\Fontes\ACBrNFe2 e no logar temos o arquivo: Property_Does Not Exist .txt Que contem um passo a passa para resolver os problemas de propriedades inexistentes que ocorre com as várias versões do Quick Report.

Bom dia Ariel, Me diz uma coisa, o CIOT esta relacionado com a carga ou com o transporte da carga? Lembre-se que devemos emitir o MDF-e somente para carga fracionada ou seja, diversos remetentes e diversos destinatários, portato temos varios CT-e. Se o CIOT pode mudar para cada CT-e emitido, então esta errado o MDF-e, mas se o CIOT esta relacionado ao transporte da carga, logo todos os CT-e e bem como o MDF-e da carga em questão tem que ter o mesmo CIOT neste caso o MDF-e esta correto. Não sei se ficou claro.

Boa tarde, Favor atualizar os fontes e tentar novamente.

Boa tarde a todos, Encontra-se disponivel as alterações realizadas por mim no componente ACBrMDFe conforme a NT 2013/002. Favor atualizar os fontes do componente, bem como do programa exemplo. Peço por gentileza, de baixar também a NT 2013/002, disponibilizada no portal MDF-e. Foram implementadas as novas classes que diz respeito as informações de unidade de transporte e de carga bem como as alterações de nomenclatura, tipos e tamanhos em TAGs já existentes. Gostaria de Reforçar que dentro da pasta ...\Fontes\ACBrMDFe não existe mais a pasta DAMDFE_QR3, mas por outro lado tem um arquivo chamado: Property_Does Not Exist.txt Nesse arquivo vocês vão encontrar um passo a passo para resolver esse tipo de erro que aparece quando se utiliza versões diferentes do Quick Report.

Boa noite Gilson, Se você estiver com todos os fontes atualizados; Primeiro não existe mais a pasta DANFE_QR3 Segundo existe um texot dentro da pasta ACBRNFe2 chamdo: Property_Does Not Exist.txt Siga os passos continos desse arquivo para sanar esse problema.

Boa noite a todos, TIve um problema parecido, ao executar o aplicativo, ele era aberto e logo em seguida fechado. Solução: não fiz absolutamente nada, apenas desliguei a maquina e liguei novamente e o problema desapareceu.

Boa tarde Leandro, O que você quer dizer com: "validaram com sucesso" ?

Boa tarde a Todos, Só lembrando: Você não inutiliza uma NF-e e sim um numero ou uma faixa de numeros que não foi utilizada. Portanto não se trata de um evento relacionado a uma NF-e, logo não vai ser retornado ao consultar uma NF-e. Caso você venha perder o XML que contem a solicitação e a homologação de numeração inutilizada retornado pela SEFAZ, acredito que não tenha como reave-lo.

Boa tarde jcanjo, Sim, no manual, página 100 o elemento refCTE é do tipo numérico, cuja ocorrencia é opcional (0-1) com tamanho fixo de 44 digitos. Sendo assim a unica maneira de armazenar um numero com 44 digitos é através de string, certo?

Boa tarde Claudemir, Por favor leia esse post:

Boa tarde Armindo, O programa exemplo do ACBrCTe não gera o XML, não tive tempo de terminar, esse DMCTE é um data module da minha aplicação.

Boa tarde Gilson, Primeiramente você não informou o erro apenas onde ele ocorre. Segundo na lista de units do uses não consta o ACBrDFeUtil.

Boa tarde Geferson, Para qual CST?

Boa tarde Alessandro, Se esse XML que você esta tentando abrir é recente,favor atualizar todos os fontes de todos os componentes, recompilar a sua aplicação com build para que não gere mais XML com essa falha.

Boa tarde Daniel, Uma coisa é o status do lote de evento que foi enviado e outra coisa é o status do envento. Temos que em primeiro lugar saber o status do lote enviado depois analisar o status de cada evento retornado.

Boa tarde Claudemir, Já fiz a alteração conforme o seu post e já encontra-se disponivel, favor atualizar os fontes e testar. Muito obrigado pela colaboração.

Boa tarde a Todos, Abinoan, vou analisar as suas alterações, assim que possível dou um retorno. Estou disponibilizando algumas alterações e simplificações no código fonte do componente. Essas alterações podem trazer alguns problemas para alguns provedores, por favor reportem os erros que por ventura surgirem. Fui obrigado a fazer essas alterações pois o código estava ficando muito grande e com varios trechos repetidos. Recebi o código fonte do componente alterado para atender o padrão DSF. Precisamos agora decidir se vamos ter 2 componentes um para o padrão ABRASF e outro para o DSF ou vamos ter um só, onde o desenvolvedor possa selecionar o padrão através de uma propriedade. Se for unir os dois em um só vai demorar, pois não vai ser fácil encontrar uma forma de fazer essa união. Só lembrando, eu alterei o componente ACBrNFe para gerar dois tipos de modelos de documentos fiscais, ou seja NF-e e NFC-e, mas a estrutura do XML é 99 % igual, a forma de assinar é igual, os envelopes de envio e retorno são iguais e isso faz a diferença. Já na NFS-e a coisa muda completamente de figura, a estrutura do XML é totalmente diferente, a forma de assinar é diferente. Precisamos pensar muito bem, antes de colocar a mão na massa.

Boa tarde a todos, Foi publicado no Portal Nacional do Conhecimento Eletrônico a NT 2013/006 juntamente com o Pacote de Liberação 2.00, no final de Maio. Ela se refere a versão 2.00 do CT-e cujas datas de liberação são: Ambiente de Homologação: até 01/09/2013; Ambiente de Produção: 01/11/2013. Note que existe a palavra "até" antes da data, portanto o ambiente de homologação pode ser liberado antes. O MOC - Manual contido na NT é preliminar, portanto pode sofrer alterações. Mas, não vamos deixar para última hora ou vamos? Eu não vou, já estou trabalhando na implementação dessa nova versão. Criei uma diretiva de compilação chamada PL_200 para tornar o componente compativel. Esta faltando implementar as classes que vão conter os grupos de informações de unidade de transporte e unidade de carga ligados aos documentos originários. Até o momento o DACTE continua o mesmo, somente o XML que teve a sua estrutura reformulada. Por conta disso não foi possível manter um nivel alto de compatibilidade, vamos a um exemplo: Nas versões 1.03 e 1.04 os documentos originários ficam dentro do grupo remetente, na versão 2.00 eles passam a ter um grupo próprio e fora do remetente. Este mês começo a fazer os primeiros testes, gerar, assinar e validar o XML e é claro finalizar a implementação. A minha previsão é que até o final de Julho já esteja tudo disponivel para todos da comunidade ACBr.

Boa tarde Gilson, Deleta o fonte em questão e baixe ele novamente. Você deve ter alterado alguma coisa nele que esta impedindo do Tortoise realizar a atualização, você esta com o fonte desatualizado.

Gilson, O seu fonte esta desatualizado. Favor alterar o nome da função de NotaUtil para DFeUtil.

Bom dia Gilson, Esse erro: "Ancestor for 'TfqrDanfeQR' not found" é do Delphi e não do componente. Esse erro aparece porque o Delphi encontrou um erro no fonte ACBrNFeDANFEQRRetrato e o abriu para apresetar a linha com o erro. Mas para abrir o fonte citado acima devemos primeiramente abrir o ACBrNFeDANFEQR e o Delphi não faz isso automaticamente, dai o erro. Precisamos saber qual é o erro que o Delphi esta encontrando no ACBrNFeDANFEQRRetrato para que possamos corrigir.

Boa tarde kzarlopes, Abra o arquivo texto chamado AlimentarComponente, que acompanha o programa exemplo, procure por infcarga.infq.add você vai ver que no meu exemplo eu adiciono duas unidades, por Kg e por unidade.

Boa tarde a todos, Se a NF-e foi enviada para o ambiente de homologação e a consulta esta sendo feita no ambiente de produção da SEFAZ não vai aparecer mesmo.