Orlando Dantas

Bom dia. Li o artigo e ainda me restou algumas duvidas. Se a transportadora estiver transportando carga lotação mas o caminhão é da empresa e o motorista é funcionário via CLT, a mesma ainda tem que informar o CIOT? Quando uma empresa que não é transportadora contrata um TAC ela terá que gerar o CIOT? Por último algumas citações acima @Italo Jurisato Junior falou que tinha entendido que o MDFe geraria o CIOT automaticamente (ao ler a nota técnica também entendi o mesmo). O MDFe não vai fazer isso?

Lendo as regras de validação. Lá informa que é obrigatória a forma de pagamento quando o modal for rodoviário e Tipo Emitente for igual a transportadora ou CT-e globalizado. No caso da maioria dos meus clientes eles são do Tipo Carga Própria, mas TAC-Independente pois pagam a um transportador autônomo, nesse caso não deve ser informado a forma de pagamento? E alguém poderia me informar por que que eu não posso informa o tpTransp (TIPO DO TRANSPORTADOR) quando o emitente é carga própria, pois como já disse meus clientes emitem a nota mas quem transporta é um TAC.

A baixo os fontes modificados. Delphi.rar

No último teste que eu fiz a unica alteração foi que eu adicionei o componente ACBrMDFeDAMDFEFR e linquei ao ACBrMDFe, a outra alteração que eu disse que tinha feito foi no primeiro teste onde não tinha conseguido gerar o erro mas eu não salvei estas alterações, ou seja as mesmas não estavam no último teste. Mesmo assim se ainda preferir que eu mande os fontes com a adição do componente ACBrMDFeDAMDFEFR, anexarei agora.

Me desculpem quando eu falei acima que não tinha conseguido gerar o mesmo erro no demo eu tinha testado da seguinte forma, eu adicionei a opção ACBrMDFe1.ImprimirEvento após o enviar pois é assim que eu faço na minha aplicação. Mas testando novamente pela opção do botão (btnImprimirEvento) conseguir simular o mesmo erro da seguinte forma: Eu primeiro imprimo um XML de MDFe, após eu vou imprimir o evento, aí o mesmo erro é gerado. Lembrando que eu adicionei o componente ACBrMDFeDAMDFEFR no demo para o teste.

Farei isso. Mas só para constar e talvez com esse feedback vocês já consigam me ajudar, quando eu simplesmente abro a aplicação e encerro o MDFe que é quando ele imprime sem erro o atributo FMDFe ele é igual a (nil), já quando eu utilizo o componente para fazer uma impressão antes de encerrar o MDFe, o mesmo atributo não vem vazio ele vem com informações assim entrando no IF e gerando o erro porque a property (qrCodMDFe) vem sem informação. Como eu faço a impressão após enviar, eu utilizo os métodos: FVISUALIZAR_MDFE.MDFE.EventoMDFe.Evento.Clear; FVISUALIZAR_MDFE.MDFE.Manifestos.Clear; antes do envio.

Bom dia. Tentei simular o mesmo erro no demo, mas o mesmo não aconteceu. Vocês acham que pode está relacionado ao fast, pois aqui funcionava normal, e o erro começou a acontecer depois da atualização de alguns componentes e um deles foi o fast, mas como ele para em um arquivo do ACBr ao ser debugado, e o mesmo também, avia sido atualizado, por esse motivo imaginei que o erro estaria no componente do ACBr.

Vou tentar fazer o mesmo procedimento no demo e posto aqui o resultado.

Olá. Mais uma vez venho solicitar a ajuda de vocês. Ao encerrar o MDFe quando chamo o método ImprimirEvento ele está me dando um erro de access violation, debugando ele para na pagina ACBrMDFeDAMDFEFR na seginte procedure: procedure TACBrMDFeDAMDFEFR.frxReportBeforePrint(Sender: TfrxReportComponent); var qrCode: String; begin if Assigned(FMDFe) then begin qrCode := FMDFe.infMDFeSupl.qrCodMDFe; if Assigned(Sender) and (Trim(qrCode) <> '') and (Sender.Name = 'ImgQrCode') then PintarQRCode(qrCode, TfrxPictureView(Sender).Picture.Bitmap, qrUTF8NoBOM); end; end; O mais estranho é que o erro somente me ocorre se eu tiver tentado fazer qualquer outra impressão de danfe anteriormente, ou seja se eu abrir o sistema e for diretamente encerrar o MDFe ele faz a impressão corretamente, mas se eu imprimir o danfe e depois for tentar encerrar aí ele me retorna o erro.

Cada vez que leio a nota técnica percebo uma informação que não o tinha anteriormente. E lá tem a seguinte citação: Aprovação de legislação nacional que normatizou a obrigatoriedade de emissão do MDF-e em todas as operações de transporte, sejam elas intermunicipais ou interestaduais; Neste caso a emissão do MDFe passa a ser obrigatório mesmo que o transporte seja entre municípios do mesmo estado? Porque até onde sei aqui na Bahia, até então não era obrigatório.

Italo mais uma vez obrigado por sanar minhas duvidas. Estou pesquisando mas as respostas que encontro não estão muito claras para mim. No caso de deposito em conta corrente, não precisarei do PEF? Se for deposito ele tem que ser antecipado ou pode ser no final do trajeto? E para o CTe, por enquanto eu terei que usar o modulo do CIOT separado, ou ele também terá essas novas regras que nem o MDFe?

Obrigado pela resposta Italo. Nesse caso teremos que aguarda o ambiente de homologação, para que seja tirada a prova né? Mais uma duvida se o CIOT for gerado automaticamente pelo MDFe, como você imagina que será a integração com as PEF(Pagamento Eletrônico de Frete), Seria direta, ou estou equivocado e são casos separados?

Olá. Li o tópico e fiquei com algumas duvidas. Eu terei que gerar o CIOT antes, para que posso colocar o código identificador no MDFe, ou o terei que implementa-lo direto no MDFe?

Boa noite. Aqui na Bahia quando fazia por DistribuicaoDFePorNSU também tinha muito esse problema, mas depois que comecei a utilizar por chave não tive mais. Mas tenho um problema que é a demora para o Portal Nacional liberar o download após a manifestação, tem dias que é instantâneo mas tem dias que leva pelo menos 20 minutos para liberar.

Obrigado galera, já conseguiram me esclarecer um pouco mais. Vou tentar implementar e volto com o retorno.

Olá Também faço esse processo, mas mesmo assim acontece esse problema com meus clientes. Sei que esse é um problema grave e estou sem muita ideia de como resolver.

Olá. Já procurei por tópicos parecidos aqui no fórum, até encontrei mas não me ajudaram a resolver meu problema. Em vários clientes está dando duplicidade de NFC-e. Já percebi que ele é causado por dois motivos. Um deles é quando os web-services da Sefaz estão com instabilidade, o outro é instabilidade da internet sendo que esse tenho bastante pois a internet na nossa região é muito instável. O que me parece ocorrer é o seguinte, o sistema faz o envio dos dados a Sefaz recebe e autoriza, mas o sistema não tem o retorno e por esse motivo dá o erro 12002 perguntando ao cliente se deseja cancelar a venda ou emitir em contingência, se o cliente optar por emitir em contingência, o sistema grava a venda incrementa a numeração no banco e imprime a nota em contingência, quando ele vai enviar a mesma a Sefaz retorna o erro de duplicidade. Se o cliente optar por cancelar o sistema cancela a venda e não incrementa a numeração no BD, quando ele emite uma nova venda também retorna o erro de duplicidade pois o numero já foi autorizado. Gostaria de saber como que vocês tratam esse erro, pois estou tendo muita reclamação e ligação no suporte por causa do mesmo. O mesmo erro ocorre até mesmo nas vendas que foram colocadas em contingência por outro motivo. Por exemplo: a venda foi colocada em contingência por que está sem internet, quando o cliente vai enviar essa contingência, ocorre o erro 12002 pelos motivos já explicados acima. Desde já agradecido por toda ajuda. 145-pro-lot.xml 145-env-lot.xml