nolher

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.

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

Pelo que pude perceber esses grupos estão corretos!

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

Muito boa tarde, Italo! Funcionou perfeitamente! Muito obrigado pela atenção.

Muito boa tarde, Italo. Resolveu sim! Só gostaria de confirmar se essa é a melhor solução?

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

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

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

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,

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,

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,

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,

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,

Bom dia, Juliomar! Muito Obrigado pela resposta. Tenha um bom dia!

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,

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,

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,

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,

Bom dia, Italo! Finalmente consegui encontrar a falha: na classe ACBrNFSeWebServices a função abaixo: function TNFSeEnviarSincrono.TratarResposta: Boolean; var i: Integer; begin FPMsg := ''; FaMsg := ''; FPRetWS := ExtrairRetorno(FPConfiguracoesNFSe.Geral.ConfigGrupoMsgRet.GrupoMsg); // FNotaRetornada := (Pos(FPRetWS, 'CompNfse') > 0); // Original não consegue localizar a tag "CompNfse" simplismente sempre volta em zero. FNotaRetornada := (SeparaDados(FPRetWS, 'Comp2Nfse') <> ''); // Solução troquei a função "Pos" pela nossa conhecida "SeparaDados" Dá pra implementar daí? Desde já agradeço a atenção.

Boa tarde! Estamos finalizando a atualização dos componentes ACBr, e estamos na atualização do ACBrNFSe. Trabalhamos com provedor GovDigital, e não estamos obtendo as informações de retorno da nota, isto é os campos Numero da Nota, Código Verificação e etc. Em anexo temos o xml de retorno 476-recS.xml e o arquivo ini utilizado GovDigital.INI Abaixo rotina para obter dados com todos os campos em vermelho retornando em branco: if ACBrNFSe.EnviarSincrono(W_NrLote, false) then begin W_Status := '03'; W_Nr_Lote := StrToFloat(ACBrNFSe.WebServices.EnviarSincrono.NumeroLote); W_Dt_Protocolo := ACBrNFSe.WebServices.EnviarSincrono.DataRecebimento; W_Nr_Protocolo := ACBrNFSe.WebServices.EnviarSincrono.Protocolo; W_Msg := 'Autorizado o uso da NFS-e'; GravaResultadoLote(W_Nr_Lote, W_Dt_Protocolo, W_Nr_Protocolo, W_Msg, W_Status); for W_I := 0 to ACBrNFSe.NotasFiscais.Count-1 do begin W_Nr := StrToInt(ACBrNFSe.NotasFiscais.Items[W_I].NFSe.Numero); W_Nr_RPS := StrToFloat(ACBrNFSe.NotasFiscais.Items[W_I].NFSe.IdentificacaoRps.Numero); W_Serie := ACBrNFSe.NotasFiscais.Items[W_I].NFSe.IdentificacaoRps.Serie; W_CD_Verificacao := ACBrNFSe.NotasFiscais.Items[W_I].NFSe.CodigoVerificacao; W_ChaveAcesso := Mascarar('00',ACBrNFSe.NotasFiscais.Items[W_I].NFSe.Prestador.cUF) + FormatDateTime('YYMM',ACBrNFSe.NotasFiscais.Items[W_I].NFSe.DataEmissao) + ACBrNFSe.NotasFiscais.Items[W_I].NFSe.Prestador.Cnpj + '56'+ Mascarar('000000000',StrToInt64(ACBrNFSe.NotasFiscais.Items[W_I].NFSe.Numero)); BuscaDadosNota(W_Nr_RPS,W_NR_Pedido,W_Cliente, W_NM_Cliente); SQLDS_AuxNotaUpdate.Close; SQLDS_AuxNotaUpdate.Params[00].AsInteger := W_Nr; // NOT_NR SQLDS_AuxNotaUpdate.Params[01].AsDateTime := StrToDate(FormatDateTime('DD/MM/YYYY',ACBrNFSe.NotasFiscais.Items[W_I].NFSe.DataEmissao)); // NOT_DT_EMISSAO SQLDS_AuxNotaUpdate.Params[02].AsString := W_CD_Verificacao; // NOT_CD_VERIFICACAO_NFSE SQLDS_AuxNotaUpdate.Params[03].AsString := W_Nr_Protocolo; // NOT_NR_PROTOCOLO_AUT_NFE SQLDS_AuxNotaUpdate.Params[04].AsDateTime := W_Dt_Protocolo; // NOT_DT_HORA_PROC_NFE SQLDS_AuxNotaUpdate.Params[05].AsString := W_Status; // NOT_STATUS_NFSE SQLDS_AuxNotaUpdate.Params[06].AsString := W_Msg; // NOT_MSG_STATUS_NFE SQLDS_AuxNotaUpdate.Params[07].AsString := '100'; // NOT_STATUS_RETORNO_NFE SQLDS_AuxNotaUpdate.Params[08].AsString := '02'; // NOT_TIPO_SITUACAO SQLDS_AuxNotaUpdate.Params[09].AsFloat := W_Nr_Lote; // Numero do Lote SQLDS_AuxNotaUpdate.Params[10].AsString := W_ChaveAcesso; // Chave de Acesso SQLDS_AuxNotaUpdate.Params[11].AsDateTime := W_Dt_Transmissao; // Data da Nota SQLDS_AuxNotaUpdate.Params[12].AsFloat := StrToFloat(ACBrNFSe.NotasFiscais.Items[W_I].NFSe.IdentificacaoRps.Numero); // Nr. RPS SQLDS_AuxNotaUpdate.ExecSQL; GravaNFSeLote(W_Nr_Lote,W_Nr_RPS,W_Nr,W_NR_Pedido,W_Cliente,W_NM_Cliente, W_Serie,W_CD_Verificacao,W_Msg,W_Status); if CheckBoxGerarPDFNFSe.Checked then ACBrNFSe.DANFSE.ImprimirDANFSePDF; end; W_Flag_Transmitido := True; end Certo de vossa atenção de sempre, antecipamos agradecimentos.

Bom dia Juliomar! Muito Obrigado por sua atenção! Aqui, pra nós fizemos com a versão anterior! Mas, ficaremos no aguardo de sua solução. Mais uma vez muito obrigado! Atenciosamente,

Bom dia pessoal! Posso enviar a versão antiga modificada corrigindo o problema de impressão em mais de uma página. Não consegui corrigir na versão atual, pois a forma que esta sendo impresso não dá possibilidade de imprimir mais de uma pagina. Certo de suas atenção, antecipo agradecimentos Atenciosamente,

Bom dia pessoal! Ainda estou aguardando de um posicionamento de nossos moderadores, referente essa nossa implementação. São alterações que não traz nenhum transtorno para a plataforma atual, muito pelo contrario na minha visão traz beneficio! E como já relatei em anteriormente, irão nos oferecer um beneficio muito grande, quando realizamos a compatibilização de versão. Certo de suas atenção, agradecemos o empenho de todos e a constante colaboração, Atenciosamente,

Bom dia pessoal! Ainda estou aguardando o posicionamento dos moderadores, referente essa nossa alteração. Realizando essa alteração teremos uma maior possibilidade de manter o componente sempre atualizado. Certo de suas atenção, antecipo agradecimentos, Atenciosamente,