Pesquisar na Comunidade

Boa tarde, gostaria de saber se o ACBrMonitor já está preparado para encerramendo de MDF-e por terceiro? Pois procurei em https://acbr.sourceforge.io/ACBrMonitor e não encontrei nada referente a encerramento de MDF-e por terceiro.

MDFe.xmlMDFe.xmlBoa tarde, estou migrando o webserviço para o [https://mdfe.svrs.rs.gov.br/ws/MDFeRecepcaoSinc/MDFeRecepcaoSinc.asmx] e esta me retornando esta mensagem: cStat:243 xMotivo:Rejeicao: XML Mal Formado seguem XML em anexo <enviMDFe xmlns="http://www.portalfiscal.inf.br/mdfe" versao="3.00"> <idLote>1</idLote> <MDFe> <infMDFe Id="MDFe52240610903047000119580030000000011000111795" versao="3.00"> <ide> <cUF>52</cUF> <tpAmb>2</tpAmb> <tpEmit>2</tpEmit> <mod>58</mod> <serie>3</serie> <nMDF>1</nMDF> <cMDF>00011179</cMDF> <cDV>5</cDV> <modal>1</modal> <dhEmi>2024-06-29T13:10:08-03:00</dhEmi> <tpEmis>1</tpEmis> <procEmi>0</procEmi> <verProc>BRdata</verProc> <UFIni>GO</UFIni> <UFFim>SC</UFFim> <infMunCarrega> <cMunCarrega>5201504</cMunCarrega> <xMunCarrega>Apore</xMunCarrega> </infMunCarrega> <infPercurso> <UFPer>MS</UFPer> </infPercurso> <infPercurso> <UFPer>SP</UFPer> </infPercurso> <infPercurso> <UFPer>PR</UFPer> </infPercurso> </ide> <emit> <CNPJ>10903047000119</CNPJ> <IE>104533811</IE> <xNome>ICM COMERCIO DE CEREAIS LTDA</xNome> <xFant>ICM COMERCIO DE CEREAIS LTDA</xFant> <enderEmit> <xLgr>AREA RURAL DE RIO VERDE</xLgr> <nro>SN</nro> <xBairro>AREA RURAL DE RIO VERDE</xBairro> <cMun>5218805</cMun> <xMun>RIO VERDE</xMun> <UF>GO</UF> <fone>6436238890</fone> </enderEmit> </emit> <infModal versaoModal="3.00"> <rodo> <infANTT> <RNTRC>51890300</RNTRC> </infANTT> <veicTracao> <placa>RHB7J91</placa> <tara>0</tara> <capKG>0</capKG> <capM3>0</capM3> <condutor> <xNome>VANDERLEI DE ALMEIDA</xNome> <CPF>04262224902</CPF> </condutor> <tpRod>03</tpRod> <tpCar>03</tpCar> <UF>PR</UF> </veicTracao> </rodo> </infModal> <infDoc> <infMunDescarga> <cMunDescarga>4207304</cMunDescarga> <xMunDescarga>IMBITUBA</xMunDescarga> <infNFe> <chNFe>52240210903047000119550010000265991000347062</chNFe> </infNFe> </infMunDescarga> </infDoc> <tot> <qCTe>0</qCTe> <qNFe>1</qNFe> <qMDFe>0</qMDFe> <vCarga>107199.52</vCarga> <cUnid>01</cUnid> <qCarga>54370.0000</qCarga> </tot> </infMDFe> <infMDFeSupl> <qrCodMDFe>https://dfe-portal.svrs.rs.gov.br/mdfe/qrCode?chMDFe=52240610903047000119580030000000011000111795&amp;tpAmb=2</qrCodMDFe> </infMDFeSupl> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Reference URI="#MDFe52240610903047000119580030000000011000111795"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>/T/Lefg3SF2GhWXliE7SuWiSc8I=</DigestValue> </Reference> </SignedInfo> <SignatureValue>PU9SNe23KiKsUFr1g0+x8AyRnLNP8e6pEfBEfSyYoJuc190mKJs7o+lbPmHE8NmA0WYFYCx/53+SeWRrTo8rqCfESabPqbHMuK8JIT0sUnqgp1xblFuPbZdENpklNQVpd8oIx/cTfO/hz3wzP5cvG0Foqiol2gCEUYfpWuau3ra9SpeUTHbh6gu1TjHmukPQteL4NMg+yyfEslJpq80FriY2JfDD7CctyNuXsnxLjXMltPF1mkKTJxxQJVGZyh8RInuW9sNFC2SaJvTDw+9Wzp5tBdh9Slpsu+mxfdiOfWPBZTKX2oqmgl5Lh5ImpLLwWwKfKHXzUozbxrjW25qf4g==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIH6DCCBdCgAwIBAgIIRx+5eVi+ox0wDQYJKoZIhvcNAQELBQAwdjELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxNjA0BgNVBAsTLVNlY3JldGFyaWEgZGEgUmVjZWl0YSBGZWRlcmFsIGRvIEJyYXNpbCAtIFJGQjEaMBgGA1UEAxMRQUMgU0FGRVdFQiBSRkIgdjUwHhcNMjMxMjE0MTgzMDUyWhcNMjQxMjEzMTgzMDUyWjCB/TELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxCzAJBgNVBAgTAkdPMRIwEAYDVQQHEwlSSU8gVkVSREUxNjA0BgNVBAsTLVNlY3JldGFyaWEgZGEgUmVjZWl0YSBGZWRlcmFsIGRvIEJyYXNpbCAtIFJGQjEWMBQGA1UECxMNUkZCIGUtQ05QSiBBMTEXMBUGA1UECxMOMjI2MjEzNjMwMDAxODcxGTAXBgNVBAsTEHZpZGVvY29uZmVyZW5jaWExNDAyBgNVBAMTK0lDTSBDT01FUkNJTyBERSBDRVJFQUlTIExUREE6MTA5MDMwNDcwMDAxMTkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChxs6hN+yPH93/UNngJt0rKFM5JXNlxDHmt4dM7GpaVGjzCWfmuFyka+tEfNCdb4xxvQtaqiIfBVIokKoCiwkzSVY29AreIf6VjlxOZi3q72mFVymmqiFOnfMhXLH3AMxBs3J7crcXH+5QtJA/QOqQcP65j884l2JiQdSr7FMx/BzX1YH9pRgm5BgSWJNz15kNNs0WLF0TWsoHUIuBLh/q3RbR84oCk6Ch/O1CGZjDKqRGUadbWesF/vzJAryRw4UjKfULDxoULOUfxkXw5xUQbVg24Wo7hk7/asSjUxBfA6tWi29bSBP45ukSwwB1vUmdq5iWG/tfLX6E3csxAb81AgMBAAGjggLwMIIC7DAfBgNVHSMEGDAWgBQpXkvVRky7/hanY8EdxCby3djzBTAOBgNVHQ8BAf8EBAMCBeAwaQYDVR0gBGIwYDBeBgZgTAECATMwVDBSBggrBgEFBQcCARZGaHR0cDovL3JlcG9zaXRvcmlvLmFjc2FmZXdlYi5jb20uYnIvYWMtc2FmZXdlYnJmYi9kcGMtYWNzYWZld2VicmZiLnBkZjCBrgYDVR0fBIGmMIGjME+gTaBLhklodHRwOi8vcmVwb3NpdG9yaW8uYWNzYWZld2ViLmNvbS5ici9hYy1zYWZld2VicmZiL2xjci1hYy1zYWZld2VicmZidjUuY3JsMFCgTqBMhkpodHRwOi8vcmVwb3NpdG9yaW8yLmFjc2FmZXdlYi5jb20uYnIvYWMtc2FmZXdlYnJmYi9sY3ItYWMtc2FmZXdlYnJmYnY1LmNybDCBtwYIKwYBBQUHAQEEgaowgacwUQYIKwYBBQUHMAKGRWh0dHA6Ly9yZXBvc2l0b3Jpby5hY3NhZmV3ZWIuY29tLmJyL2FjLXNhZmV3ZWJyZmIvYWMtc2FmZXdlYnJmYnY1LnA3YjBSBggrBgEFBQcwAoZGaHR0cDovL3JlcG9zaXRvcmlvMi5hY3NhZmV3ZWIuY29tLmJyL2FjLXNhZmV3ZWJyZmIvYWMtc2FmZXdlYnJmYnY1LnA3YjCBuAYDVR0RBIGwMIGtgRhJWkFCRUxCRVJUT05ASE9UTUFJTC5DT02gIwYFYEwBAwKgGhMYSVpBQkVMIENBU1NFUkxFWSBNQVJUSU5ToBkGBWBMAQMDoBATDjEwOTAzMDQ3MDAwMTE5oDgGBWBMAQMEoC8TLTIwMDUxOTc0MDAwMDM3MDM5ODMwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDB6AOEwwwMDAwMDAwMDAwMDAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwDQYJKoZIhvcNAQELBQADggIBADP8cY9EHtHC4euqE2oFSjlQzEcrI+Tg8oN3Xpq3OeZARoX9y+9tvXLD3+18XNKuHRstkUkfTWQ4eUYSvpGZk/QP4aLOCDz1OAn4HupEqv0yDTXIanO7MnaJDUrxS0eD+jdu6H7nLJdpNqjxW+zC1TjVr+KR/A7lDBbPXbRqS+mSD9VhnrgbRRzhqIjgV2UPNLaXeIiDPLGovYJu7lZs5pEn8yMM+sxn5efHR5PT4BDYThuirfhzL21i32AJV67zvJxA5mc7hi1z+XjzQG0ZPiCzjRrMWFKmxHK5uR9REnC62IoqnWygBmEeSkeH3ONMyqxYDmKCF5hHISZVVg+qyWoDfucBBGWlacRdQPzuEKXXMREpnXSSleRUYTNObMOJnmY+e9HJKFKS88dOZuzK1/kG3rS6In7APZAoVlRT9kcKo5LX5tcNeIXXLamBwocfDlnHFBFz6nqXFWudeCoABrmfrVXOmxTmF9ynYH4NcYYQm5a12jIoQ/+cJ4r4FMQdTARnGNIdzmD+Awc3InA6qkqKItDeonbTpCQG1g6FBA2tbpDaExsv2hfRwGVDBtOrEWzhTUk6kQeWlr0o+OdAX8bZ6utdZY6LXdI0RlZYk/KpGJhXUMWmJgoA58BeSIrNO++p/HkGa5xwsvXYiKllH5CuSsyIYERnggxSFGg4xfoJ</X509Certificate> </X509Data> </KeyInfo> </Signature> </MDFe> </enviMDFe>

Olá pessoal! Quando falamos de um Manifesto Eletrônico de Documentos Fiscais (MDF-e), uma dúvida recorrente que pode vir a surgir é a correta maneira de utilizar o evento de encerramento. O que diz o Manual? O Manual de Orientação do Contribuinte Visão Geral, traz a seguinte definição para o evento de encerramento: O que isso quer dizer? Na prática, isso quer dizer que quando terminado o trajeto e também toda vez que houver alteração de carga é necessário encerrar o MDF-e vigente e emitir um novo. Pode dar um exemplo? Vamos considerar como exemplo hipotético uma caminhão que saia de MT para entregar parte de sua carga em SP e o restante em MG. Neste cenário devemos: Emitir um MDF-e com carregamento em MT e descarregamento em SP (aqui toda a carga deve ser incluída) Emitir um segundo MDF-e com carregamento em MT e descarregamento em MG (só com a carga que vai para MG). Os 2 MDF-e podem ser emitidos um em seguida do outro antes mesmo de o caminhão partir de SP. Quando o motorista avisar que toda a carga referente a SP foi entregue, a empresa que esta em MT encerra o primeiro MDF-e. Quando ele avisar que o resto da carga destinada a MG foi entregue, a empresa encerra o segundo MDF-e. Vamos considerar outro exemplo em que um caminhão parte de SP ao RJ com um carga, mas no meio do trajeto, ocorre a quebra do veículo de tração ou de reboque e o mesmo precisa ser trocado. Neste exemplo, o MDF-e emitido originalmente deve ser encerrado e um novo MDF-e com a informação do novo veículo deve ser emitido. Por fim, em um cenário em que um caminhão parte de SP com destino a MG, quando chegar em seu destino e a carga for entregue o MDF-e correspondente deverá ser encerrado. Observações Importantes: Um MDF-e encerrado não pode ser cancelado. Um MDF-e só pode ser cancelado se o caminhão não saiu da empresa para realiza o transporte da carga. Todo MDF-e tem que ser encerrados (exceto os cancelados) quando a carga é descarregada ou quando ocorre alteração conforme já apresentado acima. Dica aos desenvolvedores: Ao treinar o usuário a usar a aplicação de emissão de MDF-e deixe bem claro o conceito de MDF-e Cancelado e MDF-e Encerrado.

Boa tarde !, Implementei o funcionalidade do carregamento da logo direto do meu BD, no caso da NF-e, CT-e e NFS-e funcionou corretamente. Somente não no caso da impressão da MDF-e, segui o mesmo processo dos demais documentos. Segui o exemplo do tópico abaixo:

Bom dia a todos, alguem poderia me tirar esta dúvida fazendo um favor, Na resolução diz: "3. Suspender, até ulterior Deliberação da ANTT, as obrigações e penalidades relacionadas ao cadastramento da Operação de Transporte, com a consequente geração do CIOT, para as contratações que não envolverem TAC e TAC-Equiparado." 1) Tenho Clientes que utilizam TAC, então nesse caso é obrigatório gerar o ciot pelo E-Frete? 2) Se sim, então o prazo para validar o ciot em produção será apartir de 31/07/2020 ou quando será? 3) Por enquanto somente quando tipo de transportador for ETC e CTC esta suspenso ate nova ordem? Desde já agradeço a quem puder me ajudar com essas duvidas.

Boa tarde pessoal. Ainda não sei o campo correto onde criar tópicos para isto, peço desculpas. Minha dúvida é a seguinte, surgiu um de meus clientes que utilizam o ERP para emissão de NF-e, NFC-e e manifestos... Realizando o MDF-e, cliente me informou que utiliza nosso sistema para emitir os manifestos do mesmo veiculo/placa realizando diversas coletas e criando novos MDF-e mesmo sem mudar a placa do veiculo. Exemplo, (DEVOLUÇÃO EMITIDA PELO FORNECEDOR) irei buscar com meu (CAMINHÃO). Porém nesta busca vou passar por algumas UF's onde também vou buscar mercadorias e realizei manifestos diferentes e no segundo houve esta rejeição. 286->611-Rejeição: Existe MDF-e não encerrado para esta placa, tipo de emitente e UF descarregamento. (Porém visualizei que meu cliente já emitiu MDF-e com os mesmos estados, acrescentando apenas um a mais e autorizou). Algo mudou na legislação? O que devo proceder?

Olá, quando as novas regras estiverem funcionando em julho como devo proceder com relação ao CIOT integrado ao MDF-e. Eu devo digitar algum número para o CIOT ou deixar vazio. Se devo digitar um número serão quantos caracteres? Pois lembro que não aceitava a quantidade de caracteres de um CIOT já aprovado. Estou com dúvida nesse tópico.

boa tarde pessoal, tudo bem? Ao tentar gerar o evento evPagtoOperMDFe do MDF-e está ocorrendo uma rejeição: 630 - Rejeição: Falha no Schema XML específico para o evento. Em anexo está o xml incMDFe42190901724075000188580050000016901006518830.xml Saberiam me dizer o que tem de errado?

Bom dia grupo. Gostaria de saber se alguém esta conseguindo enviar para SEFAZ-RS em ambiente de homologação um MDF-e que tenha o produto predominante. Toda vez que tento enviar direto pra SEFAZ-RS retorna falha de schema. Obrigada pela ajuda.

Alguém esta conseguindo validar um MDF-e com o grupo prodPred? Estou tendo o problema abaixo ao passar o arquivo no validador do site dfe (https://dfe-portal.svrs.rs.gov.br/Mdfe/ValidadorXML The element 'infMDFe' in namespace 'http://www.portalfiscal.inf.br/mdfe' has invalid child element 'prodPred' in namespace 'http://www.portalfiscal.inf.br/mdfe'. List of possible elements expected: 'seg, tot' in namespace 'http://www.portalfiscal.inf.br/mdfe'. Em anexo o xml gerado. 33200303282458000179580750000005011692612317-mdfe.xml

Como todos sabem o emissor gratuito de MDF-e parou de ser atualizado e também seu suporte encerrou. Por isso estou disponibilizando a venda de um emissor pronto onde você já pode disponibilizar a seus clientes. usando o mais simples do Delphi e o FrameWork ACBr com banco Firebird. 100% funcional Como faz para adquirir? Basta clicar no link abaixo e efetuar a compra. após o pagamento ser processado você irá receber no seu e-mail o acesso aos fontes . COMPRAR http://juliomarmarchetti.com.br/blog/2018/10/03/mdf-e-fontes-para-venda/

Boa tarde pessoal. Preciso de ajuda, urgente! Hoje meu cliente foi enviar um MDF-e que retornou a seguinte rejeição: 'Data de emissao MDF-e posterior a data de recebimento'. Notei que o ACBR está montando o XML com o ano de 2020, mesmo a data estando correta no MDF-e, exemplo: 51201213461776000150580010000000011000000051 Se eu mudo a data de emissão para 28/12/2019, ele monta a chave de acesso corretamente no ano de 2019, exemplo: 51191213461776000150580010000000011000000050. Alguém sabe como pode ser resolvido? Testei em várias versões até na 1.3.0.171, e todas acontecem o mesmo.

Boa tarde pessoal. Preciso de ajuda, urgente! Hoje meu cliente foi enviar um MDF-e que retornou a seguinte rejeição: 'Data de emissao MDF-e posterior a data de recebimento'. Notei que o ACBR está montando o XML com o ano de 2020, mesmo a data estando correta no MDF-e, exemplo: 51201213461776000150580010000000011000000051 Se eu mudo a data de emissão para 28/12/2019, ele monta a chave de acesso corretamente no ano de 2019, exemplo: 51191213461776000150580010000000011000000050. Alguém sabe como pode ser resolvido? Testei em várias versões até na 1.3.0.171, e todas acontecem o mesmo.

boa tarde, estava fazendo o mdf-e usando gerar txt e a versao 1...4 e agora baixei a versao 1..62 acrescentei os campos q foram pedidos mas ta dando erro no qr cod, como faco pra informar ao monitor essa opcao? grato e aguardo jerry

Boa tarde, estou tentando emitir o evento de Inclusão de Condutor do MDF-e, porem não esta sendo possível pois estou recebendo uma rejeição referente ao tamanho máximo da tag descEvento, que segundo o manual é de 12 caracteres, porem no próprio manual é dito que a descrição a ser enviada é ‘Inclusão Condutor’, porem a mesma possui 17 caracteres impossibilitando o envio do evento. Dentro do evento TEventoMDFe.GerarXML: Boolean; realizei a seguinte alteração: Gerador.wCampo(tcStr, 'EP02', 'descEvento', 05, 12, 1, Evento.Items[0].InfEvento.DescEvento); Por Gerador.wCampo(tcStr, 'EP02', 'descEvento', 05, 17, 1, Evento.Items[0].InfEvento.DescEvento); Troquei o tamanho máximo de 12 para 17 dessa forma consegui emitir o evento, gostaria de saber se existe algum problema em fazer isso ou se existe uma outra forma de corrigir o problema.

Boa dia. Hoje ao emitir um MDF-e em homologação ocorreu uma rejeição no ACBrMonitor: [Retorno] CStat=480 CUF=43 ChMDFe= MotivoMDFe= Msg=Manifesto(s) não confirmado(s): 51->480-Rejeição: O QR Code do MDF-e deve ser informado NProt= NRec=439000007000516 TpAmb=2 VerAplic=RS20190715104004 Versao=RS20190715104004 XMotivo=Rejeição: O QR Code do MDF-e deve ser informado Minha versão está atualizada é a 1.2.0.69. O que precisaria ser feito? Alguma configuração no Monitor?

"Rejeição: CNPJ / CPF do proprietário do veículo reboque inválido:" Esta programado para entrar hoje a validação abaixo: Se modal Rodoviário e informado grupo do proprietário do veículo reboque (grupo:veicReboque/prop):Rejeitar se o CPF ou CNPJ informado para o proprietário estiver inválido (dígito de controle, zeros) observação: Verificar em todos os reboques informados* Porém verifiquei o CNPJ e esta tudo certo. CNPJ, RNTRC e PLACA tudo de acordo. Alguém mais esta sofrendo com isso?

Olá Estou implementando a consulta do MDF-e através da chaveMDF-e, no entanto percebi um inconsistência nos dados retornado quando o MDF-e está cancelado, caso o MDF-e esteja autorizado ou encerrado o retorno esta correto, mas quando esta cancelado está havendo inconsistência, segue abaixo exemplificação do problema: Estou pegado os dados da seguinte forma: // DADOS DE AUTORIZAÇÃO DE ENVIO DO MDFE // Aqui é que está o problema, pois quando a consulta é de um MDF-e autorizado ou encerrado, os dados retornando é da Autorização, porem se a consulta é de uma MDF-e cancelado o retorno é do evento de cancelamento e não da autorização de envio Protocolo := ACBrMDFe.WebServices.Consulta.Protocolo; DtAutorizacao := ACBrMDFe.WebServices.Consulta.DhRecbto; // DADOS DE AUTORIZAÇÃO DO EVENTO DO MDFE QUE PODE SER DE ENCERRAMENTO OU CANCELAMENTO DEPENDO DO STATUS // Aqui retorna perfeitamente tanto para MDF-e encerrado quanto para cancelado ProtocoloEvento := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[0].RetEventoMDFe.retEvento.Items[0].RetInfEvento.nProt; DtAutorizacaoEvento := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[0].RetEventoMDFe.retEvento.Items[0].RetInfEvento.dhRegEvento;Cancelado) Justificativa := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[0].RetEventoMDFe.InfEvento.DetEvento.xJust; // Acredito que ficaria mais legível se as propriedades básicas do retorno do evento fossem encapsulados diretamente na consulta, por exemplo "ACBrMDFe.WebServices.Consulta.RetEvento.nProt", caso seja necessário pegar outras informações do evento poderia ser feito por "ACBrMDFe.WebServices.Consulta.DetEvento", porem é só uma sugestão

Boa ! Estou tendo problemas com o aceite da MDF-e. Quando dou a ciência de emissão, somente após, aproximadamente, 5 minutos, consigo realizar o download da nota. Esse tempo de espera, tem alguma norma técnica sobre ? Valeu!

Olá! A situação é a seguinte: Indústria do RS sai com carga própria para venda pronta entrega em vários estados (SC, PR, MS, MT) emite NF-e de remessa venda externa colocando destinatário a própria empresa e sai vendendo. Em relação ao MDF-e... como nas NF-e o destinatário é a própria empresa temos que colocar UF Início=RS e UF Fim=RS Porém se colocarmos desta forma a empresa vai ser multada, pois não especifica que está indo para fora do estado. Se colocarmos UF Fim: MT não valida devido as NF-e terem destino cidade do RS Para colocarmos UF Fim: MT teriamos que ter uma NF-e com destinatário de uma cidade do MT, porém como é venda pronta entrega não se sabe para quem vai vender a mercadoria na hora da saída da carga. Alguém já teve esta situação? Qual seria o procedimento correto nesse caso?

Boa tarde Estou tentando emitir um MDF-e no estado do Maranhão, e esta retornado o seguinte erro: Element '{http://www.portalfiscal.inf.br/mdfe}infDoc' cannot be empty according to the DTD/Schema. Estou utilizando a ultima versão do acbr plus.

Boa tarde! Após atualizar o ACBr hoje passou a ocorrer o erro "RLMDFe: Erro durante a preparação do relatório EArgumentOutOfRangeException(Argument out of range)" quando tento imprimir a DAMDFE usando o Fortes Report. O evento imprime normalmente. Gostaria de saber se alguém já enfrentou este problema. Desde já, grato pelo auxílio. Leandro

Bom dia. Utilizando o ACBRmonitorPlus ocorreu um erro ao tentar inutilizar numeração do MDF-e. O retorno foi esse: "ERRO: Método: MDFe.InutilizarMDFe não implementado." (ACBrMonitorPlus 1.2.0.19)

Boa Tarde... Vendo o post e, concordando plenamente com as palavras do Italo, fiz uma alteração no fonte, especificamente no arquivo ACBrMDFeDAMDFEFR.pas... Alterei o seguinte: Linha 1553: De: FieldByName('placa').AsString := FormatarPlaca(veicTracao.placa); Para: FieldByName('placa').AsString := FormatarPlaca(veicTracao.placa) + ' / ' + veicTracao.UF; Linha 1568: De: FieldByName('placa').AsString := FieldByName('placa').AsString + #13#10 + FormatarPlaca(FMDFe.rodo.veicReboque.Items.placa); Para: FieldByName('placa').AsString := FieldByName('placa').AsString + #13#10 + FormatarPlaca(FMDFe.rodo.veicReboque.Items.placa) + ' / ' +FMDFe.rodo.veicReboque.Items.UF; Testei e ficou como desejado (vejam figura em anexo. Caso considerem relevante a alteração, segue em anexo o arquivo ACBrMDFeDAMDFEFR.pas modificado para atualização do repositório. (Utilizei o arquivo da Revision 16217) ACBrMDFeDAMDFEFR.pas

Bom dia Pessoal, sou novo aqui no fórum e não sei se já existe algum tópico sobre o caso (pelo menos não localizei algo do gênero), mas gostaria de saber se hoje existe alguma forma, web service de consulta junto a ANTT ou a algum órgão ligado a Agência que possamos consultar a situação do RNTRC do transportador. Atualmente tenho como conhecimento apenas o site de consulta(Consulta RNTRC)Mas gostaria de implementar esta consulta. Desde já agradeço!