Jump to content

nolher

Membros
  • Content Count

    167
  • Joined

  • Last visited

Community Reputation

7 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 Muito obrigado por sua informação Estamos entrando em contato com o cliente para que ele escolha a sua serie. Muito obrigado pela atenção. Atenciosamente, Nilton Olher Serafim Skype: nolher P.S. Este topico pode ser finalizado.
  2. Muito boa tarde, Todos! Descobri que o cliente em especifico não esta usando série! Gostaria de saber se a a série é obrigatório, correto? Certo de sua atenção, antecipo meus agradecimentos. Atenciosamente, Nilton Olher Serafim Skype: nolher
  3. Muito bom dia, a todos! Estamos finalizando as implementações referente ao provedor de vitória, ainda continuo com alguns problemas. Não conseguimos realizar o cancelamento e nem a consulta, em sua aplicação faz essas ações? Se sim, foi realizado alguma modificações em especifico? Você teria como me enviar o seu arquivo INI utilizado para comparar com o meu? E somente em Produção ocorreu o seguinte falha na transmissão: Código E160 Arquivo em desacordo com o XML Schema. System.Xml.Schema.XmlSchemaValidationException: The 'http://www.abrasf.org.br/nfse.xsd:CpfCnpj' element is not declared. Arquivos em anexo. Certo de sua atenção, antecipo meus agradecimentos. Atenciosamente, Nilton Olher Serafim Skype: nolher 1-recS.xml 1-env-lotS.xml
  4. Muito boa tarde, Italo! Funcionou perfeitamente! Muito obrigado pela atenção.
  5. Muito boa tarde, Italo. Resolveu sim! Só gostaria de confirmar se essa é a melhor solução?
  6. 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
  7. 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
  8. 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
  9. 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,
  10. 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,
  11. 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,
  12. 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,
  13. 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,
  14. Bom dia, Juliomar! Muito Obrigado pela resposta. Tenha um bom dia!
×
×
  • Create New...