Italo Giurizzato Junior

Boa tarde Luis, Gostaria de saber se ocorre erro de validação ou rejeição. Se erro de validação favor anexar a imagem do erro, se é rejeição favor anexar o XML de retorno que contem a rejeição.

Boa tarde, Favor anexar o XML referente a consulta ao status de serviço, você anexou o retorno.

Boa tarde Gabriel, Sim, pois os demais dados referente ao seguro são exatamente iguais, a unica coisa que muda é o campo <nAver>.

Luciano, Favor anexar os XMLs de envio e de retorno de preferencia os *-soap.xml para que eu possa analisar.

Gabriel, Lembre-se que o campo <nAver> é uma lista sendo assim você pode ADD um para cada CT-e ADD no MDF-e. Veja abaixo como ficaria no seu caso. <seg> <infResp> <respSeg>1</respSeg> <CNPJ>06155014100172</CNPJ> </infResp> <infSeg> <xSeg>LEBERTY SEGUROS</xSeg> <CNPJ>6155014100172</CNPJ> </infSeg> <nApol>3144088471</nApol> <nAver>00000000000000043310</nAver> <nAver>00000000000000043311</nAver> </seg> Isso é capaz de resolver o problema.

Bom dia Alessandra, Veja que na segunda imagem que você postou não esta aparecendo o grupo <infSeg> para o segundo <seg> dai a rejeição. Outra coisa, lembre-se que o campo <nAver> é uma lista veja este exemplo: <seg> <infResp> <respSeg>1</respSeg> <CNPJ>99999999999999</CNPJ> </infResp> <infSeg> <xSeg>xxxxxxxxxxxxxxx</xSeg> <CNPJ>9999999999999</CNPJ> </infSeg> <nApol>9999999999</nApol> <nAver>1234</nAver> <nAver>1358</nAver> </seg>

Bom dia Gabriel, O CPF do contratante é o mesmo do motorista do veículo?

Bom dia a todos, No Manual do MDF-e versão 3.00 não existe o campo CEST.

Bom dia Sérgio, Favor anexar as Units que você alterou para que possamos analisar, caso esteja tudo OK, enviaremos para o repositório.

Bom dia Graça, Para mim, a imagem não esta aparecendo.

Bom dia a todos, Ainda hoje estarei enviando para o repositório uma alteração que vai gerar a tag vINSS mesmo com o valor zero.

Bom dia a todos, A forma de envio do CT-e OS é diferente do CT-e, vocês não estão lendo o manual do CT-e versão 3.00 com atenção. O CT-e o envio é assíncrono, isso faz com que após o envio temos que realizar uma consulta para saber se foi processado com sucesso ou não. Já no CT-e OS o envio é síncrono, ou seja, o retorno do envio já é o resultado do processamento. Por favor pesquisem no fórum, pois acredito já ter respondido como obter o cStat em outro tópico.

Bom dia a todos, Ainda hoje estarei enviando para o repositório a unit alterada por bsoft.

Bom dia a todos, Ainda hoje estarei enviando para o repositório, muito obrigado pela colaboração.

Bom dia Luiz, Os XMLs alem da versão ser diferente a SEFAZ-Autorizadora também é, dessa forma não da para fazer comparações. Outra coisa importante, em nenhum Manual ou Nota Técnica ou na Legislação consta que ao cancelar um CT-e o protocolo de autorização deve ser substituído pelo de cancelamento. Infelizmente a SEFAZ-MT no Web Services da versão 2.00 do CT-e (espero que consertem na versão 3.00) ao realizar uma consulta se o CT-e estiver cancelado é retornado o protocolo de cancelamento, sendo que o correto seria retornar o protocolo de autorização e o evento de cancelamento vinculado ao CT-e em questão. O componente por sua vez acaba pegando o protocolo de cancelamento uma vez que o de autorização não é retornado. Na unit ACBrCTeWebServices temos o seguinte fragmento de código que comprova o que foi dito acima. Atualiza := (NaoEstaVazio(CTeRetorno.XMLprotCTe)); if Atualiza and TACBrCTe(FPDFeOwner).cStatCancelado(CTeRetorno.CStat) then Atualiza := False; if (CTeRetorno.cUF = 51) and (CTeRetorno.CStat = 101) then Atualiza := True; Inicialmente a variável Atualizar recebe o valor True caso temos um retorno que contenha o grupo <protCTe>. Depois essa variável poderá se tornar False caso o status do CT-e seja cancelado. Em seguida poderá receber o valor True caso a UF seja 51 (MT) e o status seja 101 (cancelado). A variável Atualiza sendo True faz com que o XML caso esteja com o protocolo de autorizado, faz com que seja atualizado, ou seja, o protocolo de autorização seja substituído pelo de cancelamento. Como dito anteriormente isso esta errado, mas infelizmente a SEFAZ-MT ao consultar um CT-e cancelado não retorna o protocolo de autorizado mais o evento de cancelamento. Se removermos o IF em negrito (acima) um XML que esteja somente assinado, ao realizar essa consulta, corre o risco de ficar sem o protocolo, principalmente se este foi cancelado. Não sei se ficou claro. Mas procure fazer testes na SEFAZ-MT e na de MG com a versão 3.00 para ver o comportamento de de ambas. Faça o seguinte teste. Emita um CT-e na versão 3.00 na SEFAZ-MT, o XML é para ficar com o protocolo de autorizado. Depois remova o protocolo de autorização, carregue o XML e realize uma consulta, é para repor o protocolo de autorizado. O próximo passo é realizar o cancelamento desse CT-e. Remova novamente o protocolo de autorizado, carregue o XML e realize a consulta, verifique se o XML recebeu o protocolo de autorizado (correto) ou o de cancelamento. Depois fação o teste acima com a SEFAZ-MG e compare o resultado de ambas.

Boa noite Luciano, Isso ocorreu porque os seus fontes estão desatualizados, pois essa propriedade esta com o valor default igual a tiNao.

Boa noite, Muito obrigado pela colaboração, já foi enviado para o repositório.

Boa noite, O ACBrCTe possui um método chamado DistribuicaoDFe. Acesse o Portal Nacional do CT-e, baixe a Nota Técnica 2015/002 versão 1.00a e leia atentamente.

Boa tarde Rodrigo, Você esta com todos os fontes de todas as pastas atualizados? Não fez nenhuma alteração em nenhum fonte do MDF-e?

Bom dia Marcio, A mensagem de erro não significa que os arquivos XSD estejam incompletos ou errados. A mensagem é clara, você esta tentando validar um XML que não esta assinado. Você deve primeiro executar o método Assinar e depois o Validar só assim o erro vai ser sanado. Se o XML não esta sendo gerado é porque você esta alimentando o componente e depois esta executando o método validar, este não salva XML nenhum no disco, apenas o valida. Quem salva o XML em disco é o Assinar, que alem de assinar o XML o salva em disco caso o componente esteja configurado para tal.

Boa noite André, Sem os XML de envio e de retorno não tem como nós lhe ajudar.

Boa noite Luiz, Não temos o Recibo, pelo simples fato de que o envio do CT-e OS ser síncrono, ou seja, o retorno que temos ao enviar já é o resultado do processamento. Logo você vai ter o retorno da seguinte forma: Protocolo := ACBrCTe.Conhecimentos.Items[ 0 ].CTe.procCTe.nProt; Os demais dados você consegue mudando o nProt pelas demais propriedades disponíveis.

Boa noite Luiz, Muito obrigado pela colaboração, já enviei para o repositório.

Boa noite, A mensagem é clara: Nenhum valor informado no campo NroRegEstadual, esse campo é composto por 25 dígitos.

Rodrigo, Se a empresa é uma transportadora e emite CT-e você não pode dizer que o emitente é transportador de carga própria, pelo simples fato de que a carga não é do emitente e sim de um terceiro (remente). Não tem jeito, essa transportadora vai ter que fazer o seguro da carga que ele vai transportar.