Migrando a MDF-e 1.00 para 3.00

A MDFeLibrary, a partir da versão 2017/01, suporta a geração do arquivo XML no layout da versão 3.00, conforme descrito no Manual de Orientação do Contribuinte, versão 3.00 digulgado em Outubro de 2016.

Esta nova versão do XML inclui diversas alterações que afetam diretamente a geração do arquivo XML. Com o objetivo de minimizar o impacto para o desenvolvedor, a MDFeLibrary foi modificada para permitir que as aplicações que a utilizam possam ser rapidamente adaptadas para atender as alterações do novo layout.

Apesar do encapsulamento feito pela MDFeLibrary da complexidade do projeto e do descritivo abaixo com as alterações necessárias para adaptação para o novo layout, é altamente recomendado que o desenvolver examine o manual de orientação e as notas técnicas para que saiba quais são as alterações que afetarão diretamente sua aplicação.

Data limite para migração

De acordo com a NT 2017.002 divulgada em Março de 2017, o dia 02/10/2017 é a data final da vigência da versão 1.00 da MDF-e. Portanto, até 01/10/2017 será possível continuar emitindo na versão 1.00.

Após atualizar a sua MDFeLibrary para a versão 2017/01, a Library passará a trabalhar automaticamente com a versão 3.00 do layout. Entretanto, se o desenvolvedor desejar, é possível continuar gerando o arquivo da versão 1.00. Para tanto, basta preencher o campo vEnvio.sVersao do parâmetro vEnvio da função MDFeRecepcao, com o valor "1.00".

Observação: fique atento à divulgação das NT’s do projeto no portal da MDF-e, pois esta data já foi prorrogada algumas vezes.

Antes de começar

Recomendamos que o desenvolvedor faça um backup completo do seu ambiente de desenvolvimento (código fonte) antes de iniciar a migração, garantindo que, por qualquer eventualidade, seja possível voltar à versão anterior.

Principais alterações introduzidas na versão 3.00

Destacaremos agora, as principais alterações introduzidas na versão 3.00 do layout do MDF-e, que o desenvolvedor precisará tratar em sua aplicação ao gerar o arquivo XML.

Alterações no grupo de identificação da MDF-e (ide)

AlteracoesMDFe300IDE

Nova tag tpTransp

A primeira novidade do grupo "ide" é a inclusão da tag opcional tpTransp, no qual pode ser informado o "Tipo do Transportador": "1" (ETC), "2" (TAC) ou "3" (CTC).

Alteração do tipo da tag dhEmi

A tag "dhEmi", agora é do tipo TDateTimeUTC. Este tipo requer a data no formato UTC completo com a informação do TimeZone. Este tipo de representação já é utilizado atualmente no projeto da NF-e.

Na versão 3.00 do layout do MDF-e, serão aceitos os horários de qualquer região do mundo (faixa de horário UTC de -11 a +12) e não apenas faixas de horário do Brasil.

Um exemplo de data neste formato: 2017-07-08T13:00:15-03:00.

Na estrutura tMDFeIde da MDFeLibrary, o campo dhEmi é do tipo DateTime.

Por isso, a forma menos impactante que encontramos para implementar esta alteração foi através da criação de um campo extra na estrutura, que chamamos de iTZD. O desenvolvedor deverá informar neste campo, o TimeZone (-2: Fernando de Noronha, -3: Brasilia, -4: Manaus, etc).

AlteracoesMDFe300IDE2

Abaixo um exemplo de preenchimento de forma fixa:

Move -3 to vMDFe.vide.iTZD

Alteração do tipo da tag dhIniViagem

A tag "dhIniViagem", também foi alterada para o tipo TDateTimeUTC.

Entretanto, diferente da tag "dhEmi", o campo criado na estrutura da MDFeLibrary para receber esta informação, é do tipo String.

Portanto, não foi feita nenhuma alteração interna nos pacotes da MDFeLibrary para receber esta alteração. O desenvolvedor precisará revisar se código fonte para passar a data no formato correto.

Alterações no grupo de informações dos documentos fiscais vinculados ao manifesto (infDoc)

AlteracoesMDFe300infDoc

Nova tag indReentrega

Uma nova tag opcional "indReentrega" foi adicionada nos grupos "infCTe", "infNFe" e "infMDFeTransp". A documentação não traz detalhes sobre a utilidade deste campo. Sabemos apenas que é opcional e numérico. Provavelmente deverá ser preenchido com "1" em uma situação de reentrega.

Se você precisar preencher esta tag em sua aplicação, basta mover o valor desejado para a tag correspondente na estrutura:

Move "1" to vMDFe.vinfDoc.vinfMunDescarga[iContador].vinfCTe[iContador2].sindReentrega

Novo grupo peri

AlteracoesMDFe300infDocPeri

Um novo grupo opcional "peri" foi adicionado nos grupos "infCTe", "infNFe" e "infMDFeTransp". Este grupo pode se repetir várias vezes, conforme schema do MDF-e, por isso na estrutura da MDFeLibrary, foi criado como um array. Abaixo um exemplo de preenchimento:

Move 1 to vMDFe.vinfDoc.vinfMunDescarga[iContador].vinfCTe[iContador2].vperi[iContador3].snONU

Inclusão de novo grupo "seg"

AlteracoesMDFe300seg

Um novo grupo opcional "seg" foi adicionado no grupo "infMDFe". Este grupo pode se repetir várias vezes, conforme schema do MDF-e, por isso na estrutura da MDFeLibrary, foi criado como um array. Abaixo um exemplo de preenchimento:

Move "TESTE" to vMDFe.vseg[iContador].vinfResp.srespSeg

Alterações no modal Rodoviário

AlteracoesMDFe300rodo

Novo grupo infANTT

Um novo grupo opcional "infANTT" foi introduzido. Neste novo grupo, foram incluídas várias novas tags, além de ter movido para dentro dele, o grupo "valePed", que antes ficava no grupo "rodo".

Novo grupo lacRodo

Um novo grupo "lacRodo" foi incluído no grupo "rodo". Este grupo pode se repetir várias vezes, conforme schema do MDF-e, por isso na estrutura da MDFeLibrary, foi criado como um array. Abaixo um exemplo de preenchimento:

Move "teste" to vMDFe.vinfModal.vrodo.vlacRodo[iContador].snLacre

Alterações no modal Aquaviário

O campo "CNPJAgeNav", que era o primeiro campo dentro do grupo "aquav", foi removido na versão 3.00. Se o desenvolvedor continuar preenchendo este campo em sua aplicação, não ocorrerá nenhum erro, mas o valor simplesmente será ignorado.

Na imagem abaixo, destacamos os novos campos e grupos introduzidos na versão 3.00:

AlteracoesMDFe300aquav

Alterações no modal Ferroviário

A tag "dhTrem" agora é do tipo TDateTimeUTC. Este tipo requer a data no formato UTC completo com a informação do TimeZone. Este tipo de representação já é utilizado atualmente no projeto da NF-e.

Na versão 3.00 do layout do MDF-e, serão aceitos os horários de qualquer região do mundo (faixa de horário UTC de -11 a +12) e não apenas faixas de horário do Brasil.

Um exemplo de data neste formato: 2017-07-08T13:00:15-03:00.

Na estrutura tMDFeTrem da MDFeLibrary, o campo dhTrem é do tipo DateTime.

Por isso, a forma menos impactante que encontramos para implementar esta alteração foi através da criação de um campo extra na estrutura, que chamamos de iTZD. O desenvolvedor deverá informar neste campo, o TimeZone (-2: Fernando de Noronha, -3: Brasilia, -4: Manaus, etc).

Exemplo:

Move -3 to vMDFe.vinfModal.vferrov.vtrem.iTZD

Na imagem abaixo, destacamos os três novos campos que foram adicionados dentro do grupo "vag":

AlteracoesMDFe300ferrov

Alterações no modal aéreo

O modal aéreo foi o único modal que não teve nenhuma alteração na versão 3.00 e continua com a mesma estrutura.

Alterações na função de encerramento

A função MDFeEncerramento também precisou ser alterada.

A exemplo dos demais campos de data do XML do MDF-e, a tag dhEvento também teve seu tipo alterado.

A tag dhEvento agora é do tipo TDateTimeUTC. Este tipo requer a data no formato UTC completo com a informação do TimeZone. Este tipo de representação já é utilizado atualmente no projeto da NF-e.

Na versão 3.00 do layout do MDF-e, serão aceitos os horários de qualquer região do mundo (faixa de horário UTC de -11 a +12) e não apenas faixas de horário do Brasil.

Um exemplo de data neste formato: 2017-07-08T13:00:15-03:00.

Na estrutura tEventoMDFe da MDFeLibrary, o campo dhEvento é do tipo DateTime.

Por isso, a forma menos impactante que encontramos para implementar esta alteração foi através da criação de um campo extra na estrutura, que chamamos de iTZD. O desenvolvedor deverá informar neste campo, o TimeZone (-2: Fernando de Noronha, -3: Brasilia, -4: Manaus, etc).

Exemplo:

Move -3 to vEventoMDFe.vinfEvento.iTZD