Jump to content

nolher

Membros
  • Content Count

    163
  • Joined

  • Last visited

Community Reputation

6 Neutral

About nolher

  • Rank
    Membro
  • Birthday November 2

Contact Methods

  • Website URL
    http://www.inovacao.inf.br
  • Skype
    nolher

Profile Information

  • Sexo
    Masculino
  • Localização
    Divinópolis
  • Interesses
    CT-e, MDF-e, NFS-e

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Muito boa tarde, Italo! Funcionou perfeitamente! Muito obrigado pela atenção.
  2. Muito boa tarde, Italo. Resolveu sim! Só gostaria de confirmar se essa é a melhor solução?
  3. Muito bom dia a todos! Após verificar outros tópicos abordando esse assunto e já estando fechados, abrimos esse tópico por os tópicos relacionados não atenderem a solução de nosso problema. O cancelamento da NFS-e para provedor govdigital não esta funcionando, ocorre erro de "Não foi possível carregar XML", verificamos que foi realizado correções para outros provedores, que essa falha foi solucionado, porém aplicando as mesma alterações não resolveu para o nosso provedor. Sendo assim venho solicitar orientações para uma solução definitiva. Acompanhamos o tópico abaixo: E realizamos a correção no arquivo INI do GovDigital o qual não havia alterações, isto é acrescentamos a linha: DocElemento=Pedido></CancelarNfseEnvio Gostaríamos de uma confirmação se esse é o procedimento correto. 18226-ped-can-soap.xml 18226-can.xml 18226-can-soap.xml 18226-ped-can.xml
  4. Bom dia a todos! Estou com uma dúvida, possivelmente é questão de interpretação, mas se puderem me auxiliar, lhes agradeço. Temos duas datas de período de desativação da versão 3.10. Prazos para alteração As alterações aplicam-se somente às NFC-es emitidas na versão 4.00 ou superior do XML. Haverá um período de concomitância entre as versões 1.00 e 2.00 do QR Code, no qual ambos os formatos poderão ser utilizados. Confira. A Sefaz publicou novos prazos para entrada do NFC-e em produção e desativação do layout 3.10 através da NT2016.002_1.41. Abaixo, segue o cronograma de migração para a NFC-e 4.0: • AMBIENTE DE HOMOLOGAÇÃO – 20/11/2017: neste período ocorre o início dos testes para homologação dos programas emissores de NF-e. É nesta fase que as empresas especializadas em softwares de emissão de notas irão iniciar os testes de homologação da nova versão; • AMBIENTE DE PRODUÇÃO – 04/12/2017: Início da emissão de NF-e pela versão 4.0. Aqui será possível emitir notas fi scais nas duas versões simultaneamente, ou seja, será opcional a migração para a nova versão; Desativação da NFC-e 3.1 • DESATIVAÇÃO DA VERSÃO ANTERIOR – 02/07/2018: Data limite para migração de versão. A partir deste dia, só será possível emitir NF-e na versão 4.0, sendo o layout 3.1 desativado. Manual de Especificações Técnicas do DANFE NFC-e e QR Code - Versao 5.0Manual de Padrões Técnicos do DANFE-NFC-e e QR Code - Versão 5.0 - Fevereiro de 2018 04/06/2018 - Início da homologação da versão 4.00 do XML para a NFC-e 02/07/2018 – Início da produção da versão 4.00 do XML para a NFC-e – início da concomitância com a versão 1.00 do QR Code (a versão 4.00 do XML da NFC-e aceitará as versões 1.00 e 2.00 do QR Code) 01/10/2018 – Desativação da versão 3.10 do XML para a NFC-e 01/10/2018 – Fim da concomitância com a versão 1.00 do QR Code (a versão 4.00 do XML da NFC-e aceitará somente a versão 2.00 do QR Code) Esse manual refere-se especificamente ao Qr Code, pois a desativação da NFC-e 3.10 prevalece a data de 02/07/2018? Foram essa a interpretações de vocês? Desde já antecipo agradecimentos, Nilton Olher
  5. A transmitir esta ocorrendo o seguinte retorno Em anexo segue arquivo de envio. Essa falha somente ocorre em uma maquina Windows 7 64bits Alguém tem alguma sugestão para realizar? Na tentativa de verifica tentei mudar o SSLib, mas sem êxito! 1006-env-lotS-soap.xml 1006-env-lotS.xml
  6. Bom dia! A título de informação a solução Gilvano solucionou o problema aqui. Aguardo novas informações se houver soluções específica de nossos Moderadores. Sem mais para o momento, atenciosamente,
  7. Bom dia novamente! A url de produção também estão erradas. Verificamos que o componente esta usando a url: https://cte.sefaz.rs.gov.br/ws/CteRecepcaoEvento/CteRecepcaoEvento.asmx E o correto deveria usar a url : https://cte.svrs.rs.gov.br/ws/cterecepcaoevento/CTeRecepcaoEvento.asmx Busquei instruções no próprio fórum e consegui recompilar o ACBrCTEServicos.rc e realizado os devidos testes. Certo de suas atenção, antecipamos nossos agradecimentos Atenciosamente,
  8. Bom dia a todos! Estamos com problema de envio em EPEC para clientes de São Paulo na versão atualizada CT-e 3.00! Verificamos que o componente esta usando a url: https://homologacao.cte.sefaz.rs.gov.br/ws/CteRecepcaoEvento/CteRecepcaoEvento.asmx E o correto deveria usar a url : https://cte-homologacao.svrs.rs.gov.br/ws/cterecepcaoevento/cterecepcaoevento.asmx Não consegui identificar onde corrigir, alterei o arquivo ACBrCTeServicos.ini e reinstalei o componente e não resolveu. Qual seria o procedimento para correção? Certo de suas atenção, antecipamos nossos agradecimentos Atenciosamente,
  9. Mas uma vez bom dia a todos. Já algum tempo tenho dificuldades em minhas atualizações dos componentes, pois em nossa aplicação trabalhamos com a nomenclatura de xml de acordo com o que esta descrito no manual, isto é, seguimos a nomenclatura definida no item 12.1 Processo de Compartilhamento: CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-procCTe.xml”. Exemplo: 143061234567890_v01.00-procCTe.xml. • Inutilização de numeração de CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-procInutCTe.xml”. Exemplo: 143061234567890_v01.00-procInutCTe.xml. • Registro de Evento de CT-e: Número do Protocolo + “_v” + [Versão do arquivo de schema com 5 posições (ex: 99.99)] + “-eventoCTe.xml”. Como já discutimos em outra oportunidade, onde até chegamos questionar o Sefaz, é questão de interpretação. Identificamos que já na atual versão já havia disponível parte de código descrito para tratar esse ponto. Sendo assim terminamos de implementar e gostaria que pudessem atualizar na versão atual as classes alteradas, assim como se segue: 1- pcteProcCTe e pcteConversaoCTe onde foi transferido o Tipo TPcnPadraoNomeProcCTe da classe pcteProcCTe para classe pcteConversaoCTe mudando o nome para TPcnPadraoNome Classe alterada pcteProcCTe.pas -> Eliminado o tipo TPcnPadraoNomeProcCTe, corrigido o método já existente ObterNomeArquivo e método PreencherTAG foi corrigido o preenchimento da propriedade "FnProt"; Classe alterada pcteConversaoCTe.pas -> Criado o tipo TPcnPadraoNome com o mesmo padrão do antigo TPcnPadraoNomeProcCTe 2- Na classe ACBrCTeConfiguracoes foi criado uma propriedade chamada PadraoNome com com o tipo TPcnPadraoNome e dendo definido como default "tpnPublico", o que permanecerá com o padrão adotado pela os moderadores ACBr. classe alterada ACBrCTeConfiguracoes.pas -> Criado a propriedade PadraoNome 3- Na classe ACBrCTeWebServices foi implementado na rotinas existente de gravação a chamada do método ObterNomeArquivo; Classe alterada ACBrCTeWebServices.pas -> Na gravação dos xml do CT-e protocolado, na gravação do xml de evento e na gravação do xml de inutilização. Todas as alterações foram identificado com o seguinte comentário: // Alterado por Nilton Olher - ??/??/20017 Certo, de que as alterações não irá impactar para os usuários que utiliza o padrão adotado pela os moderadores da equipe ACBr, solicito essa implementação que irá nos trazer mais facilidade na atualização dos componentes e assim poderemos nos dedicar mais aos testes e implementações que pudermos auxiliar a equipe, evitando o tempo que perdemos e adaptar para nós. Certo, da compreensão e aceito de nossas alterações pelos Moderadores, antecipo nossos mais sinceros agradecimentos. Estamos a disposição para maiores esclarecimentos. Atenciosamente,
  10. Bom dia, Italo! E bom dia a todos! Obrigado Italo pela atenção, enviei a dúvida para os Sefaz de Minas e de São Paulo, e estou aguardando um posicionamento. Vou deixar o tópico aberto e qualquer novidade posto aqui. Mais uma vez muito obrigado pela atenção, Atenciosamente,
  11. Bom dia, Juliomar! Muito Obrigado pela resposta. Tenha um bom dia!
  12. Bom dia! Gostaria de saber se a nova versão do componente ACBrCTe já esta preparado para utilizar o padrão de comunicação TSL? Procurei aqui no forum essa informação e não encontrei ! Sem para o momento, Antecipo agradecimentos,
  13. Bom dia, Italo! Bom, temos o entendimento que o evento de Prestação de Serviço em Desacordo é um evento emitido pelo tomador e vamos disponibilizar para nossos clientes de NF-e. Estamos implementando na versão 3.00 do CT-e já que é um serviço dos webservices de CT-e! Verifiquei que depois que transferi para a versão 3.00 a carta de correção também está me retornando a mesma rejeição. Gerei o seguinte CT-e 131170001241328_v03.00-procCTe.xml Enviei a seguinte carta de correção: 372-ped-eve.xml E tive a seguinte resposta: 372-eve.xml A proposito o envio de evento de cancelamento esta normal. Se poderem me oferecer alguma dica ficarei muito grato. Desde já antecipo agradecimento, Atenciosamente,
  14. Boa tarde|! Gostaria de saber se alguém já realizou teste do novo Evento Prestação do Serviço em Desacordo? E se sim, se tiverem a Rejeição 297: Assinatura difere do calculado? Estamos realizando o teste aqui e não consegui entender o motivo desta rejeição, estamos utilizando o componente ACBrCTe para o envio desde evento. Seque em anexos os xml que envolve o Evento: Xml gerado da NF-e no mesmo período: 333170000426982_v03.10-procNFe.xml Xml gerado do CT-e no mesmo período: 131170001241261_v03.00-procCTe.xml Xml gerado do Evento Prestação do Serviço em Desacordo: 1-ped-eve.xml1-ped-eve.xml Xml de resposta do Webservice: 1-eve.xml Se puderem oferecer alguma dica lhes agradeço. Aproveito a oportunidade para agradecer os apoio que sempre recebi aqui desde grande grupo, e também para parabenizar o excelentes trabalho de toda equipe envolvida no projeto. Sem para o momento, Antecipo agradecimentos,
  15. Bom dia, Juliomar! Você é o cara! Nossa, como não percebi isso! Me senti até envergonhado agora! Valeu mesmo! Dá pra corrigir aí pra gente? Mais uma vez obrigado por sua atenção e a do Italo! Atenciosamente,
×
×
  • Create New...