Italo Giurizzato Junior

Boa tarde Kelly, Muito obrigado pela colaboração, já fiz a alteração e enviei para o repositório. Favor atualizar os fontes e refaça os testes.

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

Boa tarde Alessandro, O pessoal do e-social fizeram uma lambança com os schemas da versão 2.5.0 removeram os namespace, logo nenhum schema funcionava. Eu tive que colocar os namespace na mão um por um. Se você comparar o schema desse evento da versão 2.4.2 com a versão 2.5 vai notar que algumas tags agora são atributos. Dai o erro que você esta tendo. Você esta gerando tags, mas nessa nova versão os caras não tem mais o que inventar, resolveram mudar em vez de elemento agora temos que colocar as informações em atributos. Veja a página 63, 64 (por exemplo) do manual, na quarta coluna que se refere ao tipo, esta aparecendo a letra A (Atributo) em vez de E (Elemento).

Boa tarde Alessandro, Peço que você envie somente as unit e ou arquivos que alterou e não todas que estão na pasta.

Boa tarde Claudio, A rejeição 519 é gerada conforme a regra G67 (página 44 do Manual do CT-e versão 3.00). Verificar o CFOP informado considerando a seguinte matriz: Para CT-e do tipo Normal, Complementar ou Substituição: Se UF de início da prestação = UF de fim de prestação (e UF fim <> EX) CFOP deve iniciar por 5 Se UF de início da prestação <> UF de fim da prestação (e UF fim <> EX) CFOP deve iniciar por 6 Se UF fim de prestação = EX CFOP deve iniciar por 7 Para CT-e de anulação de valores: Se UF de início da prestação = UF de fim de prestação (ambas <> EX) CFOP deve ser 1206 Se UF de início da prestação <> UF de fim da prestação (ambas <> EX) CFOP deve ser 2206 Se UF de início ou fim de prestação = EX CFOP deve ser 3206

Bom dia Rauber, Você poderia ver com o provedor um XML exemplo de cancelamento? Se conseguir, favor anexar aqui mesmo, muito obrigado.

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

Bom dia Tulio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Você chegou a usar as units que anexei na minha postagem anterior?

Bom dia Joveci, Seria interessante você informar qual foi a alteração que você fez para que o problema fosse resolvido, assim se algum tiver um problema parecido poderá aqui encontrar a solução.

Boa tarde Renato, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Walter, O problema é que segundo os modelos que constam no Manual do MDF-e versão 3.00, nenhum deles esta previsto a impressão dos dados da Seguradora. Ao meu ver poderíamos dividir ao meio (altura) o quadro referente ao condutor, deixando a metade de cima para o condutor e a de baixo para a Seguradora.

Boa tarde Marcio, Já estamos finalizando a implementação para deixar o ACBrNFe em conformidade com a Nota Técnica. O que esta faltando é apenas a questão do idCSRT e CSRT que serão utilizados para gerar o hashCSRT. Mas isso vai ainda depender da SEFAZ fornecer no seu site ou um serviço via webservice para que o desenvolvedor possa obter o idCSRT e CSRT. Portanto o idCSRT e hashCSRT não devem ser gerados no grupo infRespTec. Mais algumas informações:

Walter, Você tem condições anexar o XML e o PDF do DAMDFE?

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

Bom dia Walter, Seja mais claro. Os dados do seguro não aparecem no XML do MDF-e ou não são impressos no DAMDFE? Se a questão é o DAMDFE, qual é o que você utiliza (Fast ou Fortes Report)?

Bom dia Joveci, Favor configurar o componente para salvar o arquivo Soap. Configuracoes.WebServices.Salvar := True; Faça um novo teste e anexa os XMLs gerados, para que possamos analisar.

Izaque, O arquivo *-ped-rec-soap.xml é o que é enviado para a SEFAZ e portanto o outro é o retorno. Abre um chamado na SEFAZ-BA e anexa esses dois arquivos, pede para eles mostrarem no arquivo *-ped-rec-soap.xml onde esta o namespace que não se refere a NF-e ou que esteja fora do padrão.

Bom dia, Sendo assim vou fechar esse.

Bom dia, Sei que esta caminhando, mas a passos largos de tartaruga.

Bom dia Juarez, A unit que gera o XML de consulta ao webservice DistribuicaoDFe foi escrita conforme consta na Nota Técnica publicada pelo Encat e disponibilizada no Portal Nacional da NF-e, bem como a do CT-e e MDF-e. A rotina que estabelece a conexão com a SEFAZ é exatamente a mesma usada para todos os outros métodos (envio de lote, consulta, envio de eventos, ...). Me parece que a SEFAZ-RS possui um webservice particular para o DistribuicaoDFe, mas acredito que este seja apenas para os contribuintes do RS. Pode se que esses programas que você mencionou se utilizam desse webservice, tai uma coisa para se investigar. Peço que compare o XML gerado com o layout publicado na Nota Técnica, quem sabe cometemos alguma gafe. Outra coisa importante, o componente se utiliza do serviço DistribuicaoDFe disponibilizado pela SEFAZ-Virtual do Ambiente Nacional e os eventos de Manifestação do Destinatário também são enviados para a SV-AN.

Bom dia a todos, Pelos XML anexados pelo Izaque, a rejeição apontada pela SEFAZ-BA não condiz com a realidade, pois em todos os XMLs gerados pelo componente e enviados para a SEFAZ tem o mesmo NameSpace, vocês podem inclusive comparar com os XMLs retornados pela mesma. Notem que o Lote é enviado e o numero do recibo é retornado, mas ao realizar a consulta (pelo numero do recibo) é retornado a rejeição. Posso garantir que o componente esta gerando os XMLs corretamente inclusive com o NameSpace correto. O problema esta no serviço de consulta pelo recibo da SEFAZ-BA que esta com problemas. Favor abrir chamado questionando o problema, não esqueçam de anexar o XML de consulta pelo recibo (arquivo: *-ped-rec.xml), bem como o seu retorno (arquivo: *-proc-rec.xml). Pedem para eles provarem que no arquivo enviado consta o NameSpace errado. Izaque: Por favor configure o componente para salvar os arquivos soap, faça um novo teste e anexe os XMLs. Configuracoes.WebServices.Salvar := True; Teremos os arquivos: *-ped-rec-soap.xml, *-proc-rec-soap.xml, ...) anexe esses para que eu possa analisar.

Boa tarde Joceandro, Até que enfim eles viram a mercadoria que tinham feito. Esses Schemas pelo que notei são exatamente os que eu corrigi e que estão no repositório. Não há nenhuma novidade.

Boa tarde Mauricio, Muito obrigado pela colaboração, mas os seus fontes estão desatualizados. Favor atualizar todos os fontes de todas as pastas, reinstale usando o ACBrInstall_Trunk2 marcando a opção para apagar os arquivos antigos. E veja como eu fiz na unit que gera o XML para o Equiplano, não há necessidade de se criar mais uma propriedade.

Boa tarde Thiago, Segue um exemplo: if ACBrNFSe.WebServices.EnviarSincrono.RetornoNFSe.ListaNfse.MsgRetorno.Count > 0 then begin // as linhas abaixo é interessante colocar em um loop, pois pode ser retornado mais de uma rejeição sStat := ACBrNFSe.WebServices.EnviarSincrono.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Codigo; sMotivo := ACBrNFSe.WebServices.EnviarSincrono.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Mensagem; end else begin sStat := ''; sMotivo := ''; end;