Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    39.264
  • Registro em

  • Última visita

  • Days Won

    1.132

Tudo que Italo Giurizzato Junior postou

  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. Bom dia, Tem algo errado. Na empresa uso Windows XP e consigo imprimir a CC-e.
  6. 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.
  7. 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.
  8. Boa tarde a todos, Favor atualizar os fontes e testar novamente.
  9. Boa tarde Jadir, Já chegou a fazer algum teste com o programa exemplo, configurando-o para a cidade em questão?
  10. Boa tarde Marcio, Não é nada disso. Por favor leia a Nota Técnica.
  11. 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.
  12. Boa tarde Odlawso, O schemas que você obteve é o mesmo que encontra-se disponível na pasta: ...\Exemplos\ACBrNFSe\Delphi\Schemas\Salvador.
  13. Post como anexo.
  14. 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.
  15. Boa tarde André, Muito obrigado pela colaboração, já esta disponível.
  16. Boa tarde Fernando, Favor atualizar os fontes, pois acabo de implementar a possibilidade de imprimir o Evento de Registro do Multimodal.
  17. 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.
  18. Boa tarde André, Favor atualizar os fontes e testar novamente.
  19. Bom dia Dércio, No meu Moto G, utilizo o Rate QR Code Reader.
  20. Sim, mas este que te passei contem os fontes atuais, o outro até onde sei esta desatualizado.
  21. 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.
  22. Não esta desta forma? unit pmdfeMDFeW; interface uses SysUtils, Classes, pcnAuxiliar, pcnConversao, pcnGerador, pmdfeConversao, pmdfeMDFe; (...) Então inclua.
  23. Bom dia Cantu, Na Nota Técnica 2013/005 versão 1.03 página 94 temos a regra B25a-10 que diz que a NFC-e será rejeitada caso o indFinal seja igual a ZERO. Como não existe nada a respeito da NF-e, podemos concluir que no caso da NF-e podemos informar ZERO ou UM para indFinal dependendo da situação. Os valores que coloquei no post #2 são os mais comuns.
  24. Celso, Note que o arquivo de retorno após o envio, onde temos o numero do protocolo, consta corretamente o numero do lote. Sendo assim, pode ser algum problema no provedor, uma vez que esta retornando ZERO como numero do lote ao consultar a sua situação. Favor entrar em contato com eles.
  25. Leandro, Verifique se na unit: pmdfeMDFeW.pas consta em Uses a unit pmdfeConversao.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.