Italo Giurizzato Junior

Bom dia Edson, Essa empresa vende e realiza a entrega da mercadoria vendida com veiculo próprio e não "cobra" do cliente por este serviço? Se sim, no meu entendimento não existe a figura do contratante do serviço, portanto o grupo <infContratante> não deve ser preenchido. Com relação ao seguro, quem é que vai se responsabilizar por perdas ou danos? É o próprio emitente do MDF-e ou seja a empresa que vendeu a mercadoria e que esta realizando o transporte dela ou é o cliente que comprou a mercadoria? No meu entendimento o grupo <seg> deve constar no XML, por se tratar do modal Rodoviário, mas se o responsável pelo seguro é a Loja, neste caso o valor do campo <respseg> deve ser 1 - Emitente do MDF-e

Bom dia Diego, Comparando o XML de pedido de consulta, ele esta em conformidade com os Schemas. Sendo assim acredito que seja algum problema na SEFAZ. E tenho quase certeza que o problema é a palavra "NÃO" que aparece no conteúdo da tag <xServ>. A SEFAZ as vezes pisa na bola, vive recomendando que não devemos usar vogais acentuadas, cedilha, caracteres especiais, mas comete esse deslize de exigir na descrição do serviço uma palavra que cotem uma vogal com acento. A minha sugestão é que você entre em contato com a SEFAZ-RS pois é ela responsável por recepcionar todos MDF-e. Anexa os dois XML e questione eles sobre o motivo da rejeição.

Bom dia Altamiro, Primeiramente peço que procure anexar o arquivo e não colocar o seu conteúdo como parte do texto da postagem. Esse erro de validação esta ocorrendo porque você colocou no seu arquivo INI as seções: [infNFxxx] e [infNFexxx] sendo que só pode existir apenas uma delas. Em um CT-e podemos colocar "n" seções infNFe ou infNF mas não podem aparecer ambas as seções. Essas seções contem informações referente ao nota emitida pelo remetente da mercadoria. Você concorda que o remetente ou emitiu uma NF-e ou uma NF (comum de papel)? Resumindo em um arquivo INI só pode existir a sesção InfNFe ou só a infNF, ambas já mais.

Bom dia a todos, Revendo os fontes, o componente que fiz simplesmente lê o arquivo OFX e grava em um formato TXT. Acredito que seria interessante criar as classes e popular os campos ao ler o arquivo OFX, de forma semelhante que o ACBrNFe faz ao ler o XML da NF-e. Infelizmente não tenho mais nenhum arquivo OFX, se alguém puder disponibilizar um para que possa melhorar o componente e depois disponibilizar ele, ficarei agradecido.

Boa tarde Willian, Esta usando o programa exemplo do componente para realizar os testes?

Boa tarde, A um bom tempo eu fiz um, posso rever ele para compatibilizar com o Trunk2 e disponibilizar. Depois é só fazer os ajustes necessários.

Bom dia Edna, Primeiramente, peço que não post conteúdo de arquivos como texto da postagem, procure sempre anexar. Segundo, se não me falha a memória primeiramente é preciso carregar o XML para depois Enviar. Tente conforme o exemplo abaixo: eSocial.CarregarXMLEventoeSocial("C:\ACBrMonitorPLUS\Arqs\05499999000137\eSocial\10548133600000020525505015731-S-1000-0.xml") eSocial.EnviareSocial(1, 1)

Bom dia, Favor anexar o XML retornado pela consulta para que eu possa analisar.

Bom dia, Delete o seu arquivo WebISS.ini e atualize novamente os fontes, desta forma o Tortoise vai restaurar o arquivo WebISS.ini Os arquivos INI que eu utilizo são exatamente os mesmos que se encontram no repositório.

Bom dia, Qual é o provedor?

Bom dia Márcio, Favor verificar se as URLs de homologação e produção que você colocou no arquivo INI referente a cidade de Nova Xavantina estão corretas. Achei estranha pois não faz nenhuma referencia a cidade e sim ao provedor.

Bom dia Juliana, Primeiramente vamos ao Manual do CT-e versão 3.00 - páginas 225, 226. Nessas duas páginas temos uma relação de campos que não podem ser alterados através de uma CC-e - Carta de Correção. Se você emitiu um CT-e e depois emitiu uma carta de correção a SEFAZ entende que o transporte foi realizado e quem notou o erro foi o tomador do serviço. No mesmo manual - página 108, temos a regra M16 que diz: Vedado o cancelamento se possuir evento de Carta de Correção associado. Mesmo que o transporte não foi realizado, pela regra acima não tem como efetuar o cancelamento de um CT-e que possui uma Carta de Correção. E não existe nada para cancelar a carta de correção.

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

Bom dia Ricardo, No Manual do MDF-e versão 3.00 - página 114, grupo #25 <prop> deixa claro o seguinte: Proprietários do Veiculo - Só preenchido quando o veiculo não pertencer à empresa emitente do MDF-e. Idem para o grupo #46 (página 116) que se refere ao proprietário do veiculo reboque. Como você pode ver, devemos sempre ter em mãos o Manual pois ele pode nos ajudar a esclarecer se um campo ou um grupo deve ou não ser gerado e em quais condições.

Olá Pessoal, Vejo muitos XML de CT-e que contem as informações sobre o Expedidor e o Recebedor. Quando devemos informa-los e em quais situações? Em um transporte de carga normal, ou seja, a transportadora pega a carga do Remetente e leva até o Destinatário não devemos informar o Expedidor e o Recebedor. O Expedidor e ou Recebedor só aparecem quando existe uma outra transportadora envolvida no transporte da carga e é essa transportadora que é informada como Expedidor ou como Recebedor. Vamos a um exemplo onde temos o transporte Normal, Redespacho e Redespacho Intermediário. Exemplo: Transportadoras envolvidas: A, B e C Remetente -> A -> B -> C -> Destinatário A transportadora A emite um CT-e Normal informando: Remetente: o remetente da mercadoria (quem vendeu) Destinatário: o destinatário da mercadoria (quem comprou) Recebedor: Transportadora B (o Recebedor foi informado pois a transportadora A não vai levar a carga até o Destinatário. o Expedidor não foi informado pois quem expediu a carga foi o Remetente que já esta informado) A transportadora B emite um CT-e de Redespacho Intermediário Remetente: o remetente da mercadoria (quem vendeu) - Opcional Destinatário: o destinatário da mercadoria (quem comprou) - Opcional Expedidor: Transportadora A (o Expedidor foi informado pois a carga não foi expedida pelo Remetente e sim pela Transportadora A) Recebedor: Transportadora C (o Recebedor foi informado pois a transportadora B não vai levar a carga até o Destinatário) A transportadora C emite um CT-e de Redespacho Remetente: o remetente da mercadoria (quem vendeu) Destinatário: o destinatário da mercadoria (quem comprou) Expedidor: Transportadora B (o Expedidor foi informado pois a carga não foi expedida pelo Remetente e sim pela Transportadora B. o Recebedor não foi informado pois quem vai receber a carga é o Destinatário que já esta informado) Note que a transportadora A pegou a carga do Remetente e levou até a transportadora B, esta por sua vez levou até a transportadora C, e esta por sua vez levou a carga até o destinatário.

Boa tarde, Peço que baixe o Manual do CT-e versão 3.00 que se encontra no Portal Nacional do CT-e e veja o que vem a ser cada tag (elemento) do XML. No seu arquivo INI notei que você informou o Remetente, Destinatário, Recebedor e Expedidor são todos de MG. Me responda porque você informou que o inicio da prestação do serviço (cMunIni, xMunIni e UFIni) é Exterior e o fim da prestação do serviço é Bahia? Outra coisa, se a transportadora vai pegar a carga no Remente e vai levar até o Destinatário, não devemos informar o Recebedor e o Expedidor, pois estes só aparecem quando existe outra transportadora envolvida no transporte da carga.

Boa tarde Fábio, No momento estou atarefado ajudando do desenvolvimento das DLLs que vão ajudar em muito o pessoal que desenvolve em outras linguagens que não seja o Objeto Pascal. Esse pessoal hoje se utiliza o ACBrMonitor, mas gostariam muito se existisse uma DLL para cada componente. Quem sabe algum outro membro do fórum possa arregaçar as mangas e implementar. Eu no momento não tenho condições. Vou até colocar na minha lista de afazeres mas não sei lhe informar quando isso será possível de ser feito.

Boa tarde Joffas, Muito obrigado pela colaboração, assim que possível estaremos enviando para o repositório a atualização do programa exemplo.

Boa tarde ALA, O novo provedor é NFSeBrasil que já esta implementado. Favor abrir o arquivo Cidades.ini para saber como foi feito para outras cidades atendias pelo mesmo provedor.

Boa tarde, E qual seria a URL de consulta? A mesma URL do QR-Code?

Boa tarde, Abra a unit ACBrMDFeConfiguracoes e procure por GetPathEvento.

Boa tarde Scandolara, Confirmando a resposta do Luis. No Manual do CT-e versão 3.0 - página 45, temos a regra G79 que diz: Se tomador do serviço for emitente de CT-e (verificar CNE), for contribuinte do ICMS (indIEToma=1) e diferente do CNPJ Base do Remetente ou Destinatário: - Rejeitar se o tipo de serviço informado for Normal (tpServ=0) OBS: Nas prestações de serviço que o tomador figurar como não contribuinte, indIEToma deve ser informado com 9, mesmo que exista uma Inscrição Estadual para o mesmo. Código da rejeição 746 - Tipo de Serviço inválido para o tomador informado

Boa tarde Diego, Esse erro de falha de Schema esta sendo retornado pela SEFAZ? Se sim, vamos lá. Os Schemas só são utilizados para validar o XML que vai ser enviado para SEFAZ, logo se não ocorreu erro de validação antes do envio não adianta você acessar o Portal e baixar os Schemas e atualizar. Quando é a SEFAZ que retorna esse erro, ou o problema é na SEFAZ ou alguma tag contem algum valor não aceito e a SEFAZ retorna um erro genérico como esse de erro de schema. Favor anexar o XML de pedido de consulta bem como o de retorno.

Bom dia Cordeiro, Já fiz a alteração no arquivo mencionado pelo BigWings, favor atualizar os fontes e iniciar os testes com o programa exemplo do componente. Caso ocorra problemas nos testes, favor anexar os arquivo soap de envio e de retorno para que possamos fazer os ajustes necessário, conforme o BigWings já tinha dito.

Bom dia, Ai que esta o problema, se após o envio ocorre um erro de comunicação não devemos enviar novamente, pelo simples fato de não sabermos se o erro ocorreu no envio ou no retorno. O procedimento correto é: Carregar o XML assinado do documento através do LoadFromFile, depois executar o método Consultar. Se o erro de comunicação foi no retorno com o procedimento acima o XML recebera o protocolo de autorização caso tenha sido autorizado é claro, bastando agora imprimir. Por outro lado se o erro ocorreu no envio, teremos como resposta a mensagem informando que o Documento não consta na base de dados da SEFAZ, ai sim podemos enviar novamente.