italo.giurizzato.junior

Bom dia, Verifique se essa configuração aparece em outro ponto da sua aplicação. Você pode ter corrigido em um lugar e ter esquecido de efetuar a mesma correção em outro.

Bom dia Graça, Lembre-se que o EPEC é um evento e nele contem uma duzia de informações referente a nota, todas as informações referente ao item não vai para o EPEC, nem sequer a quantidade de itens que a mesma possui. Se você enviou o EPEC com dados consistentes ele jamais será rejeitado. Quanto aos 3 comandos, lembre-se que basta executar o Valida, pois este se encarrega de executar o Assinar caso o XML não esteja assinado e consequentemente o Assinar se encarrega de executar o GerarNFe caso o XML não tenha sido gerado.

Dalpiaze, Primeiramente muito obrigado por postar os arquivos. Por favor atualize os fontes e realize novos testes provocando rejeição.

Bom dia Marcio, Para compreender essa nota técnica, primeiro é preciso ler a nota técnica que trata sobre a Manifestação do Destinatário. Entendendo o que vem a ser a Manifestação do Destinatário, você vai descobrir que a Distribuição de Documentos Fiscais é um aprimoramento. Na Manifestação do Destinatário como o próprio nome diz o Destinatário da mercadoria, primeiro realiza uma consulta para obter a lista de notas que foram emitidas contra o seu CNPJ e em seguida realiza a manifestação (por exemplo: Confirmação da Operação) com isso você esta informando a SEFAZ que realmente comprou de que emitiu a nota e a mercadoria foi entregue. O que a SEFAZ esta fazendo, criando um novo Web Service de consulta chamado NFeDistribuicaoDFe que vai substituir o NFeConsultaDest. O porque dessa troca, simples, o que existe hoje deixa claro que é para ser utilizado pelos Destinatários e esse novo não. Com o novo o Destinatário vai fazer a sua consulta e depois realizar a manifestação, portanto não muda em nada. Mas com esse novo o Emitente também vai poder consultar, mas neste caso não para se Manifestar e sim para saber se o Destinatário se manifestou. Com isso o Emitente vai ficar sabendo se a mercadoria que ele vendeu para o Destinatário XYZ e que foi transportado pela Transportadora ABC realmente foi entregue. Temos ai o que eu já tinha dito quando surgiu a Manifestação do Destinatário, o Canhoto de Entrega Eletrônico. Esta ficando mais claro agora?

Bom dia Charles, Os documentos dentro do infDoc estão condicionados ao Tipo do Emitente, ou seja ele checa o valor informado a tpEmit. Se o Tipo do Emitente for Prestador de Serviço de Transporte, você não pode informar as chaves das NF-e, uma vez que uma transportadora não emite esse tipo de documento. Você deve informar as chaves dos CT-e que a mesma emitiu.

Bom dia, Post como anexo um outro *-pro-lot.xml (envio síncrono) cuja nota foi autorizada, para que possamos comparar e efetuar as correções.

Bom dia Luciano, No meu entendimento o DANFE de uma NF-e enviada e autorizada pela SEFAZ deve conter o protocolo de autorização da mesma. Não importa se antes do envio para SEFAZ ocorreu ou não o envio do EPEC. Se não esta sendo impresso o protocolo de autorização da SEFAZ, algo esta errado. Se possível post como anexo o XML de uma NF-e que foi enviada a SEFAZ e que possui um EPEC, para que possamos analisar.

Bom dia, Tem algo errado. Na empresa uso Windows XP e consigo imprimir a CC-e.

Bom dia Fernando, Checando apenas a estrutura do grupo <evCCeCTe> que diz respeito a CC-e esta correto, inclusive os nomes dos grupos e campos que se deseja alterar. É muito estranho ocorrer a rejeição.

Bom dia JGarcia, Já foi dito em vários post que o componente possui 3 formas de envio, você testou as 3? Se o componente retorna a mensagem informando que a funcionalidade XYZ não foi disponibilizada pelo provedor ABC significa que você não pode usa-la para o respectivo provedor. No caso do Ginfes o Gerar NFSe e o Enviar Síncrono não vai funcionar, uma vez que o provedor não implementou os Web Services que atende essas funcionalidades, restando apenas o Enviar Lote RPS. Se o componente acusa que não encontrou os schemas, com certeza você esta configurando o componente de forma errada.

Boa tarde a todos, Favor atualizar os fontes e testar novamente.

Boa tarde Jadir, Já chegou a fazer algum teste com o programa exemplo, configurando-o para a cidade em questão?

Boa tarde Marcio, Não é nada disso. Por favor leia a Nota Técnica.

João, Sem levar em consideração que a NT 2013/007 versão 1.01 que trata sobre o assunto SVC foi publicado em Novembro/2013 e a última, ou seja, a versão 1.03 em agosto/2014. O ambiente de homologação foi disponibilizado em 01/12/2013 portanto fazendo as contas, foram 10 meses que a SEFAZ deu para que os desenvolvedores pudessem fazer as devidas alterações e testes em suas aplicações para atender essa nova realidade. Mas como sempre, muitos não levam as coisas a sério. Uma prova disso é que hoje: 30/09/2014, data da desativação do SCAN, existem desenvolvedores perdidos, não sabem que rumo tomar.

Boa tarde Odlawso, O schemas que você obteve é o mesmo que encontra-se disponível na pasta: ...\Exemplos\ACBrNFSe\Delphi\Schemas\Salvador.

Post como anexo.

Boa tarde Graça, A principio você não pode alterar, mas porem todavia contudo entretanto, se essa alteração não afetar nos dados já enviados através do EPEC......... Entendeu? No meu entendimento o procedimento correto é: 1. Gerar o XML da NF-e com tpEmis = 4, informar dhCont e xJust; 2. Enviar o EPEC considerando os dados usados ao gerar o XML da NF-e. 3. Assim que os problemas forem sanados, enviar o XML gerado no item 1. Na página 6 da Nota Técnica 2014/001 versão 1.00 temos a estrutura do Evento EPEC, note que temos que informar o Valor total da NF-e, Valor total do ICMS e ICMS ST. Sendo assim qualquer alteração nos itens pode provocar a alteração desses valores, fazendo com que desta forma a SEFAZ detecte que ocorreu uma alteração no XML gerado antes e depois do EPEC.

Boa tarde André, Muito obrigado pela colaboração, já esta disponível.

Boa tarde Fernando, Favor atualizar os fontes, pois acabo de implementar a possibilidade de imprimir o Evento de Registro do Multimodal.

Boa tarde Diogo, Eu não utilizo o componente ACBrNFSe, apenas ajudo no seu desenvolvimento. Por favor entre em contato com o provedor e solicite um arquivo de envio completo, não apenas a estrutura do XML do RPS ou Lote de RPS. É preciso saber a estrutura do Envelope.

Boa tarde André, Favor atualizar os fontes e testar novamente.

Bom dia Dércio, No meu Moto G, utilizo o Rate QR Code Reader.

Sim, mas este que te passei contem os fontes atuais, o outro até onde sei esta desatualizado.

Bom dia João, Você esta se referindo a TAG: indPres e neste caso você esta correto é o mesmo entendimento que tenho. A questão levantada pelo Cantu é sobre o IndFinal, onde devemos informar 0 ou 1 sendo que no caso da NFC-e essa TAG só pode conter o valor 1.

Não esta desta forma? unit pmdfeMDFeW; interface uses SysUtils, Classes, pcnAuxiliar, pcnConversao, pcnGerador, pmdfeConversao, pmdfeMDFe; (...) Então inclua.