Italo Giurizzato Junior

Bom dia Warley, Essa URL consta no arquivo ACBrCTeServicos.ini que esta em conformidade com a URL informada no Portal do CT-e. https://dfe-portal.svrs.rs.gov.br/CTE/Servicos Verificar junto a SEFAZ-MG se existe alguma alteração para o caso de envio para a SEFAZ-Virtual de Contingencia de SP.

Bom dia Cleonir, O que o eFrete quer dizer que deve ser null quanto o tipo de viagem for Padrão? Não devemos gerar a tag, ou devemos gerar a tag sem nenhum valor? Veja a definição dessa tag no webservice do eFrete: <s:element name="CodigoTipoCarga" maxOccurs="1" minOccurs="1" type="s:unsignedShort" nillable="true"/> O que vem a ser o tipo unsignedShort: xsd:unsignedShort The type xsd:unsignedShort represents an integer between 0 and 65535. An xsd:unsignedShort is a sequence of digits, optionally preceded by a + sign. Leading zeros are permitted, but decimal points are not. Como podemos ver o tipo dessa tag é um numero inteiro que pode variar de 0 até 65535. Mediante a essas informações volto a perguntar, para o tipo de viagem Padrão devemos gerar essa tag? Se sim, o seu valor seria zero?

Boa noite Ronie, Muito obrigado pela colaboração, amanhã vou analisar e estando tudo OK, vou enviar para o repositório.

Boa noite Warley, Amanhã de manhã vou enviar uma correção para o repositório.

Boa noite, Você pode sim usar o ACBrCIOT para gerar o CIOT. O ACBrCIOT até onde sei esta funcionando muito bem com eFrete e este por sua vez esta com o seu sistema em conformidade com a ANTT deseja.

Boa tarde Luiz, Por favor vamos seguir as regras do fórum. Nesse tópico esta sendo discutido a obtenção do retorno de uma consulta de um MDF-e que entre outras coisas traz informações sobre os eventos que estão vinculados ao mesmo. O seu problema é outro. Sendo assim para não misturar os assuntos sugiro que você crie um tópico novo. Antes disso, abra o programa exemplo e veja o código do botão de envio do evento: Cancelamento. Vejas as linhas que estão comentadas no final da procedure.

Boa tarde ALA, Não sei porque você insiste em colocar LT_ALL para SSLType. Porque não informa LT_TLSv1_2 que é a recomendação da SEFAZ. 24/01/2020 Ambiente de homologação de DF-e: Desativação dos protocolos SSL, TLS 1.0 e TLS 1.1 A Secretaria da Fazenda do Estado do Rio Grande do Sul comunica que, no ambiente de homologação de DF-e da Sefaz-Virtual do Rio Grande do Sul (SVRS), desativou os protocolos de comunicação mais antigos (SSL, TLS versões 1.0 e 1.1), mantendo apenas o protocolo TLS versão 1.2. Essa desativação em ambiente de homologação busca possibilitar que as empresas testem seus sistemas antes deste procedimento ser realizado no ambiente de produção, o que proporciona mais segurança na comunicação entre as empresas e a SVRS. A desativação nos ambientes de produção da SVRS das versões 1.0 e 1.1 do protocolo TLS será realizada em data oportunamente comunicada.

Boa tarde Ronie, O correto não seria ter feito essa alteração na unit em vez no DFM?

Boa tarde Claudio, O XML do MDF-e com as alterações no layout conforme consta na NT 2020/001 - MDF-e Integrado passa a ser aceito em ambiente de produção a partir de hoje. No que se refere ao MDF-e o que foi prorrogado é a data de inicio de validação de algumas regras. Quanto ao CIOT você chegou a ler a resolução do dia 20/03/2020?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Luís, Veja como o componente ACBrNFSe gera o XML de envio de um lote de RPS para o provedor Ginfes. 10-env-lot-soap.xml

Luís, O conteúdo dos grupos <arg0> e <arg1> é um XML e não uma string. Quando você usa <![CDATA[ (...) ]]> o XML que esta no CDATA é convertido em uma string. E não é dessa forma que o Ginfes espera receber o cabeçalho o Lote de RPS.

É só os dados referente a Viagens que estão zerados?

Bom dia Jeihcio, Favor anexar a unit alterada para que possamos analisar.

Warley, Você ainda não entendeu. Esses 2 XML que você anexou, um é o pedido (o envio) do evento e o outro é o resultado final onde temos o pedido mais o retorno da SEFAZ que acusa que o evento foi registrado e vinculado ao MDF-e. Não existe um método para consultar um evento. O que existe é o método para consulta um MDF-e. Eu pedi para você anexar o XML retornado dessa consulta, mais precisamente o XML: *-sit.xml

Bom dia Luis, Você não esta usando o componente ACBrNFSe, correto?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Warley, Se tratando de MG tudo é possível acontecer. O pessoal da SEFAZ-MG tem pata de elefante onde pisam, você já sabe o que acontece.

Warley, Como assim, "após a transmissão eu perca os dados" ? No meu entendimento esses dados devem ser salvos primeiro no banco de dados, para depois serem lidos com a finalidade de alimentar o componente. Outra coisa, para todos os eventos são gerados 3 arquivos XML: *-ped-eve.xml, *-eve.xml e *-procEventoMDFe.xml O primeiro contem os dados do evento que foram enviados para a SEFAZ. O segundo contem o retorno da SEFAZ. O terceiro nada mais é do que a composição do primeiro com o segundo. O que você esta fazendo é consultar o MDF-e, se esses campos que você esta tentando ler após a consulta estão zerados, temos as seguintes situações: 1. A SEFAZ ainda não esta retornado esse evento ao consultar o MDF-e; 2. Ou o componente não esta lendo essas informações do retorno. Você tem o XML de retorno da consulta para que possamos analisar? Se sim, favor anexar.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Filipe, Favor atualizar e faça novos testes.

Bom dia Eduardo, Você esta usando o componente ACBrNFSe? Lembre-se que as prefeituras tem a liberdade de contratar a empresa (provedor) através de licitação. Temos provedores que seguem a versão 1 do layout da ABRASF, outros seguem a versão 2 e outros tem o seu próprio layout. O provedores que seguem a versão 2 do layout da ABRASF costumam implementar o serviço GerarNFSe, os da versão 1 não tem esse serviço em seus webservice. Você não pode generalizar, ou seja, engessar a sua aplicação.

Bom dia Orlando, Se o caminhão é da transportadora e o motorista é funcionário funcionário da mesma transportadora, se vai gerar o não o CIOT tem haver com outras coisas, por exemplo: A carga inserida no caminhão é fracionada, ou seja, cada fração da carga vai para um destinatário diferente, ou a carga é lotação, ou seja, toda a carga vai para um único destinatário? Se a carga for fracionada não se deve gerar e consequentemente informar o CIOT no MDF-e.

Bom dia Warley, Não entendi o que você quer fazer. Se você enviou o evento você tem essas informações, o que você precisa pegar no retorno do envio do evento é o numero do protocolo que atesta que o evento fui autorizado e vinculado ao MDF-e em questão.

Bom dia Orlando, É muito estranho o que você esta relatando, pois no programa exemplo, mais precisamente o botão que exemplifica esse evento temos: ACBrMDFe1.Manifestos.Clear; // <--- essa linha limpa o componente antes de carregar o XML do MDF-e que vai ser encerrado ACBrMDFe1.Manifestos.LoadFromFile(OpenDialog1.FileName); ACBrMDFe1.EventoMDFe.Evento.Clear; // <--- essa linha limpa a classe evento antes de receber os dados de um evento, neste caso o de encerramento with ACBrMDFe1.EventoMDFe.Evento.New do begin infEvento.chMDFe := Copy(ACBrMDFe1.Manifestos.Items[0].MDFe.infMDFe.ID, 5, 44); infEvento.CNPJCPF := edtEmitCNPJ.Text; infEvento.dhEvento := now; infEvento.tpEvento := teEncerramento; infEvento.nSeqEvento := 1; infEvento.detEvento.nProt := ACBrMDFe1.Manifestos.Items[0].MDFe.procMDFe.nProt; infEvento.detEvento.dtEnc := Date; infEvento.detEvento.cUF := StrToInt(Copy(IntToStr(ACBrMDFe1.Manifestos.Items[0].MDFe.infDoc.infMunDescarga.Items[0].cMunDescarga),1,2)); infEvento.detEvento.cMun := ACBrMDFe1.Manifestos.Items[0].MDFe.infDoc.infMunDescarga.Items[0].cMunDescarga; end; ACBrMDFe1.EnviarEvento( 1 ); // 1 = Numero do Lote MemoResp.Lines.Text := ACBrMDFe1.WebServices.EnvEvento.RetWS; LoadXML(ACBrMDFe1.WebServices.EnvEvento.RetWS, WBResposta);