Italo Giurizzato Junior

Bom dia, Mas não devemos enviar para destinatário o XML de envio de evento (*-ped-eve.xml) e sim o XML de processamento do evento (*-procEventoNFe.xml). Você esta carregando o XML errado para o seu envio.

Bom dia Edson, O contratante que você se refere é o tomador do Serviço? Se sim, lembre-se que ele pode ser o remetente da carga ou o destinatário. Outra coisa, que não ficou clara para mim, onde você diz "uma coleta com mais de um DFe". Você que dizer que a coleta se realizou em apenas UM remetente, correto? Se sim, e levando em consideração que o contratante seja o tomador do serviço e este é o remetente da carga, temos ai duas situações: 1. a transportadora vai emitir um CT-e para cada destinatário, uma vez que são diversas NF-e e estou supondo que sejam para destinatários diferentes. 2. a transportadora vai emitir somente um CT-e caso todos os destinatários sejam a mesma pessoa, apesar de ter sido emitido mais de uma nota. Neste caso o CT-e vai relacionar todas as notas. 3. a transportadora tem a permissão de emitir um CT-e Globalizado. Você precisa definir melhor esse cenário.

Bom dia Warley, Favor atualizar os fontes e faça novos testes.

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.