Italo Giurizzato Junior

Bom dia Solivan, Não adianta nada você gerar uma chave e atribuir ela a propriedade ID, pois o componente vai ignorar. A chave tem que ser gerada pelo componente e você lê ela através da propriedade ID para poder armazena-la no banco de dados. Lembre-se que a chave é composta por um campo chamado cNF, ou seja, código da Nota Fiscal. Alguns desenvolvedores atribuem a esse campo o mesmo numero da NF, que ao meu ver esta errado e no manual da NF-e, diz que cNF tem que ser um numero aleatório. A minha sugestão é em vez de você gerar a chave, gere o cNF (numero inteiro de 8 dígitos) através do Randomize, armazene ele no banco de dados e quando for alimentar o componente com os dados da venda pegue essa informação do banco e atribua ao campo cNF depois de todo o processo, ou seja quando o XML foi gerado e assinado, leia a propriedade ID, remova se desejar os 3 primeiros caracteres "NFe" para ficar somente com a chave e armazene-a no banco de dados. Trabalhando desta forma não tem erro.

Bom dia a todos, Dizer que da erro na consulta é muito vago. Por favor sejam mais especifico informando com exatidão a mensagem de erro retornada ao realizar a consulta de um cadastro para obter os dados de uma empresa.

Bom dia Magela, O que vem a ser esse "local de emissão"? No meu entendimento a principio o local de emissão do CT-e é o endereço da transportadora que deve aparecer ao lado do logo juntamente com os demais dados.

Graziani, Aparece somente a mensagem: "Arquivo não encontrado" ? Ou seja, não informa o nome do arquivo que não encontrou. Você esta com todos os fontes atualizados? Se sim você compilou a sua aplicação com a opção Build?

Bom dia Ermo, Se a SEFAZ retornar em xMotivo a mensagem: Falha no Schema XML não tem jeito. Uma saída é você pegar o XML que foi rejeitado, abrir ele com o bloco de notas e copiar o seu conteúdo para o validador da SEFAZ-RS, quem sabe ele aponte com mais precisão o que esta errado. Segue o link do validador: https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx

Bom dia Ariel, NF-e e NFC-e são modelos de documentos fiscais diferentes sendo assim cada um possui a sua sequencia de numeração própria. Através de um navegar abra o XML de uma NF-e, você vai notar logo no inicio uma TAG chamada <mod> cujo conteúdo é 55, ao fazer o mesmo com o XML de uma NFC-e o conteúdo da mesma TAG é 65. Isso prova que se trata de documentos fiscais diferentes. Sendo assim você pode sim ter uma NF-e e uma NFC-e do mesmo emitente com mesmo numero e serie, não existe nenhum problema quanto a isso. A SEFAZ não vai acusar duplicidade pelo simples fato de serem de modelos diferentes.

Bom dia Santos, O que o Régys quis dizer, que nos fontes baixados do repositório Trunk (não daremos mais suporte) as propriedades tem o seguinte nome: Token e idToken. Já os fontes baixados do repositório Trunk2 (fontes oficiais e atualizados) as propriedades passaram a se chamar: CSC e idCSC.

Bom dia Rafael, Eu já estou com elas em mãos, vamos estuda-la e iniciar as implementações. Esta disponível também os novos schemas por conta dessa alteração. Por favor não fiquem nervosos e ansiosos, pois os testes só poderão ser feitos a partir de 01/10/2015 no ambiente de homologação e em 03/11/2015 vai estar liberado para o ambiente de produção. Temos ai 2 meses para implementar e isso é tempo suficiente.

Bom dia Everton, Por favor atualize os fontes e compile a sua aplicação com a opção Build. Fiz a correção e acrescentei o parâmetro data na definição da function GetPathDownload.

Bom dia a todos, Pessoal, por favor não poste conteúdo de arquivos como texto da postagem, procure sempre anexa-los, a postagem fica mais curta.

Bom dia Emerson, Por favor atualize os fontes e teste novamente.

Bom dia Desingenrba, Por favor quanto for postar preste muito atenção em qual fórum vai postar, pois este o ACBrMDFe se trata do componente para emissão do MDF-e Manifesto Eletrônico de Documentos Fiscais, não tem nada haver com a Manifestação do Destinatário e muito menos com o Download de NF-e. Outra dica, leia a nota técnica que trata sobre: DistribuicaoDFe - Distribuição de Documentos Fiscais Eletrônicos.

Bom dia Ademar, Favor atualizar os fontes e testar novamente.

Bom dia Graziani, Segundo a sua configuração do PathSchemas me diz que dentro da pasta onde encontra-se a sua aplicação existe uma pasta chamada Schemas e dentro desta existe os arquivos XSD? Se sim, remova a barra no final do nome da pasta, ou seja, '\Schemas'. Ou existe uma outra pasta dentro da pasta Schemas, por exemplo ve310? Se sim você deve incluir ela: '\Schemas\ve310'

Bom dia Ale, Uma empresa ficar sem a internet por falha na rede é algo que até da para conversar com a SEFAZ, agora ficar sem internet por falta de pagamento da fatura, acho melhor fechar as portas.

Bom dia Ale, Primeiro, voltamos a frisar que não poste conteúdo de arquivos como texto na postagem, pois deixa ela muito longa, procure sempre anexar, no seu caso o XML referente a nota. Segundo, no caso da NFC-e pressupõe que o consumidor já vai levar a mercadoria, logo não existe a cobrança de frete e nem sequer devemos informar a empresa que vai transportar a mercadoria. No meu entendimento se vai ocorrer a cobrança do frete devemos emitir uma NF-e e não uma NFC-e.

Bom dia Ale, Tanto da NF-e (venda ao consumidor final) quanto na NFC-e devemos informar o valor aproximado dos tributos. Em uma cartilha do próprio IBPT sugere que seja impresso o valor, o porcentual e a fonte, no caso o IBPT. Quanto a endereço, telefone e site do Procon para mim é novidade não vi isso em nenhum DANFE. Para imprimir as mensagens abaixo você pode colocar em observações: Valor Aprox. dos Tributos Federais R$ xx,xx (yy,yy%) - Fonte: IBPT Valor Aprox. dos Tributos Estaduais R$ xx,xx (yy,yy%) - Fonte: IBPT

Tiago, Não entendi: "Esse webservice não tem lógica". Você leu a Nota Técnica que trata sobre esse Web Service? O NFeConsDest só serve para o Destinatário, por outro lado o NFeDistribuicaoDFe pode ser usado tanto pelo destinatário quanto pelo emitente da nota. Se o destinatário se manifestar sobre uma nota, o emitente da mesma quando realizar uma consulta usando esse web service terá como retorno a manifestação feita pelo destinatário. Se a manifestação for do tipo Operação concluída, isso significa que o destinatário já recebeu a mercadoria. Temos ai o Canhoto eletrônico. Desculpe, mas quem diz que esse web service não tem lógica, realmente não conhece nada sobre ele.

Boa tarde a todos, Tiago, Cantu esta coberto de razão, não se deve automatizar isso. Desta forma você esta informando a SEFAZ que comprou da empresa XYZ sendo que na verdade essa empresa esta dando um golpe. Melhor você repensar sobre o assunto.

Boa tarde Daniel, Você deve estar invertendo as coisas: O idToken é um numero sequencial e o Token é a chave Hexadecimal. Lembrando que agora devemos usar a sigla CSC em vez de Token para não confundir com o certificado digital em formato Token (pen-drive). Portanto idCSC e CSC.

Boa tarde Alex, Toda vez que o status for 999 o problema é na SEFAZ, o jeito é aguardar e tentar mais tarde.

Boa tarde Carlos, Favor pesquisar, no fórum existem varias dicas sobre isso.

Boa tarde, Já tentou? ACBrNFe1.DANFE.TipoDANFE := tiNFCeA4;

Boa tarde Emerson, Por favor atualize novamente os arquivos abaixo e tente novamente. ACBrMDFeWebServices.pas ACBrMDFe.pas

Bom dia Tiago, Sim o NFeConsDest vai ser desativado, e sempre peço para utilizarem o DistribuicaoDFe. Lembre-se se trata de uma minuta não é a versão final do manual e com certeza contem erros ou algo que não deveria ser mais colocado, pois não existe mais.