eBook - MDF e para Desenvolvedores

1

MDF-e para Desenvolvedores .

APRESENTAÇÃO

A Tecnospeed

Especializada no desenvolvimento de tecnologia de apoio a empresas desenvolvedoras de software, a TecnoSpeed está desde 2006 no mercado e auxilia seus clientes por meio de ferramentas e componentes, que reduzem o esforço no processo de desenvolvimento de softwares de gestão.

Isto proporciona aos clientes TecnoSpeed ganho de produtividade, eficiência e competitividade.

Com sede em Maringá, na região noroeste do Paraná, a empresa se especializou no desenvolvimento de soluções componentizadas para documentos fiscais eletrônicos, uma parte importante dos ERPs, que demandaria grande esforço das software houses. A TecnoSpeed possui, hoje, clientes espalhados por todo o território nacional e se orgulha de poder fornecer tecnologia de alta qualidade a seus clientes, construindo relacionamentos lucrativos com seus parceiros, baseados na confiança e honestidade.

Desde a sua fundação, a TecnoSpeed sempre primou pela qualidade em seus produtos e serviços. Nossa missão é ‘reduzir esforços no desenvolvimento de software’, e nós fazemos isto por meio de componentes e ferramentas para desenvolvedores de software, público extremamente exigente. Sempre tivemos a consciência de que, entregar o que quer que seja, sem qualidade a esse público é assinar prematuramente o atestado de óbito da empresa.

{

Nosso Blog: tecnospeed.com.br/blog Fan Page: facebook.com/tecnospeed Twitter: twitter.com/tecnospeed TecnoTV: youtube.com/tecnospeedti

}

2

APRESENTAÇÃO

MDF-e para Desenvolvedores .

Prefácio

O cumprimento da legislação de documentos fiscais eletrônicos deve ser uma preocupação não só dos escritórios de contabilidade. A Software house, que em sua maioria desenvolve sistemas que, em algum desses momentos faz a emissão de documentos, precisa estar atenta às regras e mudanças que acontecem nesse universo. É fato que contar somente com as regras de validação dos servidores da SEFAZ não é a melhor opção para o cliente, porque há muitas regras de negócio que não são validadas pelos webservices.

Isso é uma falha do fisco? Na minha opinião não, porque por lei é uma obrigação do contribuinte enviar os documentos fiscais eletrônicos da maneira correta.

Nesse contexto, tivermos por diversas ocasiões durante o ano de 2014 clientes que chegaram até nós com dúvidas devido a problemas na logística de clientes decorrentes de documentos emitidos incorretamente, muitas vezes decorrentes de micro mudanças na legislação que passaram despercebidos e causaram dor de cabeça para todos os envolvidos no processo.

O MDFe é um documento eletrônico que entrou em obrigatoriedade recentemente (para o período de lançamento deste material), exigindo esforço de desenvolvimento de software das software houses que atendem empresas com algum tipo de logística envolvida. Em sua maioria, já possuiam os documentos fiscais CTe e NFe em seus softwares.

A Tecnospeed, cumprindo com seu papel de levar “mais software, menos esforço” e transmitir a toda sua comunidade o máximo de conhecimento possível, desenvolveu este material para que a software house passar segurança aos seus clientes e conhecer as entranhas do MDFe, evitando futuras dores de cabeça e salvando as empresas de possíveis prejuízos incalculáveis com passivos fiscais, caminhões parados em fiscalizações e até cargas que não chegam ao destinatário.

Portanto, esse material é pra você desenvolvedor que trabalha com documentos fiscais eletrônicos e seus clientes tem algum tipo de logística envolvida no processo. Qualquer dúvida que tiver enquanto faz a leitura do ebook, pode ser postada em um grupo específico de MDFe em nossa rede social, a TSDN (Tecnospeed Developer Network) que você pode acessar por meio deste link.

Uma boa leitura! por Renan Freitas - Evangelista da Tecnospeed

3

MDF-e para Desenvolvedores .

ÍNDICE

O que você encontra neste ebook?

1

O MDF-e ........................................................................................................ 05

2

As vantagens do MDF-e

2.1

Emitentes

.................................................................................................... 06

2.2

Sociedade

................................................................................................... 06

2.3

Contabilistas

2.4

Fisco

3

Qual documento o MDF-e substitui? ................................................. 07

4

A diferença entre MDF-e e MD-e ......................................................... 09

5

Quem deve emitir MDF-e ........................................................................10

6

Quais as implicações da não emissão do MDF-e .......................... 11

7

Entendendo o processo de emissão .................................................. 11

8

O XML de um MDF-e ................................................................................. 12

9

Contingência ............................................................................................... 16

............................................................................................... 07

........................................................................................................... 07

10 Eventos de um MDF-e ............................................................................................. 17

10.1 Encerramento

10.2 Cancelamento ............................................................................................. 19

10.3 Inclusão de condutor

................................................................................... 21

11 Caso de sucesso .......................................................................................... 24

4

APRESENTAÇÃO

MDF-e para Desenvolvedores .

O MDFe

Entre 2010 e 2012 a Sefaz trabalhou em um novo documento fiscal eletrônico, cuja finalidade descrita na legislação é agilizar o registro em lote de documentos fiscais em trânsito e identificar a unidade de carga utilizada e demais características do transporte.

Isso demonstra que, de tempos em tempos, a Sefaz busca automatizar os processos de fiscalização, através de documentos eletrônicos, visando aumentar a arrecadação e inibir a sonegação no país.

O modelo foi desenvolvido de forma integrada entre várias entidades em conjunto (Receita Federal, Zona Franca de Manaus, ENAT, ENCAT e representantes de empresas do setor privado).

A legislação nacional que institui a obrigação de emissão do MDFe é o Ajuste SINIEF n°021 de 10 de dezembro de 2010: “Fica instituído o Manifesto Eletrônico de Documentos Fiscais - MDF-e -, modelo 58, que deverá ser utilizado pelos contribuintes do Imposto sobre Operações Relativas à Circulação de Mercadorias e sobre a Prestação de Serviços de Transporte Interestadual e Intermunicipal e de Comunicação - ICMS, em substituição ao Manifesto de Carga, modelo 25, previsto no inciso XVIII do art. 1º do Convênio SINIEF 06/89 , de 21 de fevereiro de 1989.”

O MDFe tem as principais finalidades: • • • •

Permitir o rastreamento da circulação da carga por parte do fisco Identificar a empresa responsável pelo transporte e o condutor do veículo Consolidar as informações do transporte em um arquivo digital Consolidar todos os documentos fiscais que são referentes ao transporte que está sendo feito e agilizar o registro dos mesmos em lote • Registrar mudanças nas unidades de transporte, carga ou condutor • Registrar o início e fim de uma operação de transporte • Simplificar as obrigações acessórias do contribuinte

5

APRESENTAÇÃO

MDF-e para Desenvolvedores .

As vantagens do MDFe

O MDF-e proporciona benefícios a todos os envolvidos na prestação do serviço de transporte.

Emitentes: • Redução de custos de impressão do documento fiscal, uma vez que o documento é emitido eletronicamente. O modelo do MDF-e contempla a impressão de um documento em papel, chamado de Documento Auxiliar do Manifesto Eletrônico de Documentos Fiscais (DAMDFE), cuja função é acompanhar o transporte e consequentemente informar o trânsito dos documentos da carga. A impressão do documento auxiliar deverá ser em papel comum A4 (exceto papel jornal).

• Redução de custos de armazenagem de documentos fiscais. Essa redução não apenas abrange o espaço físico necessário para adequada guarda de documentos fiscais como também toda a logística que se faz necessária para sua recuperação. Um contribuinte que emita, hipoteticamente, 100 Manifestos por dia contará com aproximadamente 2.000 Manifestos por mês, acumulando cerca de 120.000 ao final de 5 anos. Ao emitir os documentos apenas eletronicamente a guarda do documento eletrônico continua sob responsabilidade do contribuinte, mas o custo do arquivamento digital é muito menor do que o custo do arquivamento físico; • GED - Gerenciamento Eletrônico de Documentos: O MDF-e é um documento estritamente eletrônico e não requer a digitalização do original em papel. Sendo assim, possibilita a otimização dos processos de organização, a guarda e o gerenciamento de documentos eletrônicos, facilitando a recuperação e intercâmbio das informações.

• Redução de tempo de parada de caminhões em Postos Fiscais de Fronteira: Com o MDF-e, os processos de fiscalização realizados nos postos fiscais de fiscalização de mercadorias em trânsito serão simplificados, reduzindo o tempo de parada dos veículos de cargas nestas unidades de fiscalização; • Incentivo a uso de relacionamentos eletrônicos com clientes (B2B): O B2B (business-tobusiness) é uma das formas de comércio eletrônico existente e envolve as empresas (relação empresa - à - empresa). Com o advento do MDF-e, espera-se que tal relacionamento seja efetivamente impulsionado pela utilização de padrões abertos de comunicação pela Internet e pela segurança trazida pela certificação digital.

Sociedade: • • • •

Redução do consumo de papel, com impacto positivo em termos ecológicos; Incentivo ao comércio eletrônico e ao uso de novas tecnologias; Padronização dos relacionamentos eletrônicos entre empresas; Surgimento de oportunidades de negócios e empregos na prestação de serviços ligados ao MDF-e.

6

APRESENTAÇÃO

MDF-e para Desenvolvedores

Contabilistas: • GED - Gerenciamento Eletrônico de Documentos, conforme os motivos expostos nos benefícios das empresas emitentes; • Oportunidades de serviços e consultoria ligados ao MDF-e.

Fisco: • Aumento na confiabilidade da fiscalização do transporte de cargas; • Melhoria no processo de controle fiscal, possibilitando um melhor intercâmbio e compartilhamento de informações entre os fiscos; • Redução de custos no processo de controle dos manifestos capturados pela fiscalização de mercadorias em trânsito; • GED - Gerenciamento Eletrônico de Documentos, conforme os motivos expostos nos benefícios das empresas emitentes.

Qual documento o MDFe substitui?

Quando se diz que é de existência apenas digital, você que está lendo pode pensar: “Mas não há impressão do documento?” Na verdade o documento impresso, chamado de DAMDFE é da mesma forma como o DANFE é para a NFe, somente um demonstrativo informativo de que houve a emissão, mas que é sem validade jurídica se não existir o documento digital.

O MDFe substitui o documento chamado Manifesto de Carga, modelo 25, um documento impresso responsável por acobertar o transporte de carga fracionada em cada veículo, ou seja, aquele transportador que possui mais de um conhecimento de transporte ou NFe para aquele volume.

A autorização do MDF-e implicará em eventos fiscais nos documentos a ele associados, como a NF-e e o CT-e. Um destes é impedir o cancelamento de uma NF-e que já esteja em circulação, por exemplo.

7

APRESENTAÇÃO

MDF-e para Desenvolvedores

Exemplo de um Manifesto de Carga, antigo documento utilizado pelo transportador:

Exemplo de DAMDFE, documento demonstrativo do MDFe:

8

APRESENTAÇÃO

MDF-e para Desenvolvedores

O DAMDFE é impresso pelo contribuinte após ter o retorno de autorização do fisco de que o MDFe emitido foi aceito pelo servidor. Após essa confirmação, junto com esse retorno é gerada uma chave de acesso utilizada para a impressão do documento. Lembrando que o condutor do veículo deve ter uma cópia do DAMDFE para fins de fiscalização da carga durante o transporte.

A diferença entre MDFe e MDe

Uma dúvida frequente dos desenvolvedores que estão iniciando o trabalho com MDFe é diferenciar MDFe de MDe, até pela própria semelhança de nome e abreviatura.

A diferença mais básica é que o Manifesto do Destinatário é um evento da NF-e e está relacionado à participação do destinatário no processo, já o Manifesto de Documentos Fiscais é um novo documento fiscal, assim como a NF-e e o CT-e, de existência apenas digital, vinculando à unidade de carga os documentos utilizados na operação.

Antigamente a Nota Fiscal Eletrônica tinha participação apenas do emissor, que poderia registrar eventos, como a Carta de Correção Eletrônica, junto ao Fisco. Ficava a cargo do destinatário apenas a validação e armazenamento da NF-e recebida. Com a criação do Manifesto do Destinatário, o Fisco permite a participação do destinatário neste processo, inclusive confirmando se existe de fato.

Entre os eventos que o Manifesto do Destinatário permite, estão: • • • •

Confirmação da operação; Desconhecimento da operação; Operação não-realizada; Ciência da operação.

9

APRESENTAÇÃO

MDF-e para Desenvolvedores

Quem deve emitir MDFe

Atualmente, todos os estados já estão obrigados a emitir MDFe pelos seus respectivos cronogramas e decretos (como pode ser visto na página Tudo Sobre MDFe em nosso site). A obrigatoriedade do MDF-e tem âmbito nacional, porém cabe a cada estado da federação definir o cronograma de implantação e obrigatoriedades.

Um exemplo de particularidades do estado é o estado de Minas Gerais, na qual em janeiro de 2014, teve seu decreto alterado pela Secretaria de Estado de Fazenda de Minas Gerais (SEF/MG) na publicação do Decreto de N° 46.426, que obriga empresas emitirem o MDF-e mesmo em situações em que exista apenas um único CT-e ou uma NF-e. Essa obrigação aplica-se ao transporte de carga de lotação, com um único Conhecimento de Transporte e no transporte de bens e mercadorias acobertadas por uma única Nota Fiscal, em situações que não conste a data de saída na nota fiscal ou que não tenha sido feito o registro de saída da mesma. Cabe ressaltar, também, que o preenchimento das informações relativas ao transporte na nota fiscal é dispensado, desde que a mesma esteja relacionada a um MDF-e devidamente autorizado.

Este documento deve ser emitido pelos contribuintes que realizam transporte em modal rodoviário, aéreo, ferroviário, rodoviário ou aquaviário e sejam emitentes de CTe (Conhecimento de Transporte eletrônico) ou NFe, no transporte de carga fracionada - quando o transportador está levando mais de um Conhecimento de Transporte ou várias Notas Fiscais. Essa última é uma regra que pode variar de um estado para o outro, podendo o fisco exigir que seja necessário emissão do MDFe para transporte da chamada carga de lotação, quando há somente um CTe ou NFe para um veículo.

Pré requisitos exigidos pelo fisco para a emissão de um MDFe • O contribuinte deve já ser emissor de NFe e/ou CTe registrado na SEFAZ • Para ter a necessidade de emissão de um MDFe, a carga precisa ter mais de uma NFe ou mais de um CTe vinculado (chamada de carga fracionada) • Possuir um certificado digital instalado e válido vinculado ao CNPJ da empresa para realizar a assinatura digital do documento (foi publicado anteriormente no blog qual o melhor certificado para a empresa ) • Ter conexão de internet (a emissão de documentos fiscais eletrônicos suporta baixas velocidades, mas é preciso estar atento) • Ter um sistema emissor de MDFe instalado (pode ser próprio ou gratuito)

10

APRESENTAÇÃO

MDF-e para Desenvolvedores

Quais as implicações da não emissão de MDFe

Para aquelas empresas que realizam transporte de cargas, espalhadas por todo o país, é necessário estarem atentas para não sofrerem com multas e penalizações. Aquelas que já estão dentro do calendário de obrigatoriedade, mas que ainda não começaram a emitir precisam estar atentas e se adequarem. Temos conhecimendo de que a Receita começou a notificar e penalizar empresas cujas cargas não estão cobertas por um documento MDF-e, seguindo a legislação vigente no estado. Até o meio de 2014, a fiscalização era feita de forma menos frequente.

O desenvolvedor, que muitas vezes é responsável por manter seus clientes antenados nas mudanças do ambiente fiscal, precisam estar por dentro da legislação da MDF-e para não serem pegos de surpresa por problemas com seus clientes.

Segundo a Secretaria da Fazenda, a não emissão do documento MDF-e pode ocasionar punições já no ato da circulação, como a apreensão das mercadorias que estão sendo transportadas e até mesmo a retenção do veículo. Isso pode causar um prejuízo enorme para o transportador, que precisa tomar providências para liberação da carga e regularizar o processo.

Posteriormente, caso a empresa seja auditada por um fiscal da Receita, a ausência da emissão de MDF-e vinculadas a uma carga ou Nota Fiscal pode gerar passivos fiscais de acordo com a legislação vigente no estado. As medidas normalmente são notificações que podem variar de acordo com a lei e o tamanho do passivo fiscal.

Entendendo o processo de emissão

O contribuinte respeitando os pré requisitos descritos acima, já está habilitado para emitir o documento em ambiente autorizador do Fisco (chamado de ambiente de produção), tendo validade jurídica. O preenchimento do documento pode ser feito offline, dentro do sistema emissor antes de ser enviado, porém a transmissão é feita via conexão com internet. É preciso ter em mãos as Notas Fiscais ou Conhecimento de Transporte que estão na carga fracionada do transporte.

Após o preenchimento, o sistema emissor deve assinar o documento digitalmente utilizando o certificado da empresa de seu CNPJ e enviá-lo para o servidor autorizador do Fisco. Ao receber o documento, o servidor utiliza-se de um Schema XSD que faz uma verificação do arquivo XML mediante regras de validação da estrutura do arquivo e retorna uma mensagem sinalizando a autorização ou não do documento. Tudo isso é feito de forma muito rápida pelo servidor e bem semelhante ao processo de autorização da NFe, já conhecido pelo desenvolvedor de software.

Caso haja um problema no preenchimento ou no envio do documento, a mensagem retornada é de uma Rejeição apontando o erro e é preciso corrigir o documento para enviá-lo novamente (consulte rejeições utilizando a busca da TSDN, temos catalogado em nossa rede uma imensidão de mensagens de erro de todos os documentos fiscais).

11

APRESENTAÇÃO

MDF-e para Desenvolvedores

Se autorizado, o contribuinte está quase liberado para iniciar o transporte das mercadorias.

Com a mensagem de autorização, o emissor também terá a chave de acesso para impressão do DAMDFE (Documento Auxiliar do MDFe), que é o documento em papel que comprova que o MDFe foi enviado e autorizado pelo Fisco estando de acordo com a legislação. Ele deve obrigatoriamente acompanhar a mercadoria jutno ao condutor durante todo o transporte para que as autoridades fiscalizadoras, quando necessário, tenham conhecimento de que a carga está autorizada a ser transportada e de quais são os documentos que se referem às mercadorias em transporte.

Com o DAMDFE em mãos, o emitente pode liberar a carga para o transporte. Depois de autorizado o documento e feita a liberação da carga, existe a possibilidade também, caso a empresa tenha a necessidade, de substituição de condutor. Esse procedimento é realizado por meio de um evento de inclusão de condutor.

O XML de um MDFe

O desenvolvedor, que precisa enfrentar diariamente muitos desafios no desenvolvimento de soluções, ao se deparar com o MDFe precisa entender quais são as particularidades do seu XML, para poder desenvolver um bom sistema e sem retrabalhos para a empresa.

Para auxiliar nessa tarefa e ir além do manual do MDFe (que pode ser baixado no Portal do MDFe no site da SEFAZ), pegamos um XML deste documento e destrinchamos os detalhes de como funciona o preenchimento do arquivo para realizar a emissão.

Para tornar a explicação mais sintonizada com a prática, ao invés de explicar campo por campo em uma tabela, como faz o manual, nós utilizamos o próprio conteúdo do arquivo inserindo como comentários em formato XML destacados. Assim, se o desenvolvedor quiser, copiar o mesmo conteúdo e colar em seu editor de código para visualizar melhor toda a estrutura.

O arquivo que foi utilizado nesse exemplo é um XML de autorização de MDFe, ou seja, que traz o retorno da SEFAZ com a mensagem de autorizado (vide o final do arquivo). Isso porque ele contém todas as informações e grupos para poder visualizar uma estrutura completa e assim o desenvolvedor pode identificar as diferenças. Nos comentários estão descritas as mudanças para o XML de envio que deve ser montado pelo sistema para emissão no servidor do Fisco.

12

APRESENTAÇÃO

MDF-e para Desenvolvedores

Segue o arquivo com seus respectivos comentários:

<mdfeProc versao=”1.00” xmlns=” http://www.portalfiscal.inf.br/mdfe “> <!-- No caso de um MDFe que seja de envio, aqui no lugar de mdfeProc é utilizado enviMDFe --> <MDFe xmlns=”http://www.portalfiscal.inf.br/mdfe”><infMDFe versao=”1.00” Id=”MDFe4114080818716800016000369341000000018”>

<ide> <!-- campo de identificação -->

<cUF>41</cUF>

<tpAmb>2</tpAmb> <!-- Identificação do ambiente em que foi emitido o documento e que irá identificá-lo no servidor do fisco. Nesse caso, a emissão foi feita em ambiente de Homologação, como segue: 1 Produção; 2 - Homologação -->

<tpEmit>1</tpEmit>

<mod>58</mod>

<serie>1</serie>

<nMDF>364</nMDF>

<cMDF>000001</cMDF>

<cDV>8</cDV>

<modal>1</modal> <!-- Identificação do modal do XML: ferroviário, hidroviário, aquaviário, aéreo ou rodoviário -->

<dhEmi>2014-08-12T18:07:14</dhEmi>

<tpEmis>1</tpEmis>

<procEmi>0</procEmi>

<verProc>1.0</verProc>

<UFIni>PR</UFIni> <!-- O campo UFIni deve ser usado para identificação do estado onde o transporte irá começar. Lembrando, como é descrito em outros comentários, que essa UF não é identificada no campo infPercurso -->

<UFFim>PB</UFFim> <!-- O campo UFFim deve ser usado para identificação do estado onde o transporte irá terminar. Lembrando, como é descrito em outros comentários, que essa UF não é identificada no campo infPercurso -->

<infMunCarrega> <!-- Município onde o carregamento da carga é feito a partir do endereço de onde o transporte está saindo para transporte (origem) -->

<cMunCarrega>4115200</cMunCarrega>

<xMunCarrega>Maringa</xMunCarrega>

</infMunCarrega>

<infPercurso> <!-- No campo infPercurso, informar quais UF o transporte irá passar sem que tenha carregamento, ou seja, são os intermediários entre o início e fim (o início e fim há campos específicos, portando não são inseridos no campo infPercurso. Necessariamente deve estar na ordem em que o veículo irá seguir -->

<UFPer>SP</UFPer>

</infPercurso>

<infPercurso>

<UFPer>MG</UFPer>

</infPercurso>

<infPercurso>

<UFPer>BA</UFPer>

</infPercurso>

<infPercurso>

<UFPer>SE</UFPer>

</infPercurso>

<infPercurso>

<UFPer>AL</UFPer>

</infPercurso>

<infPercurso>

<UFPer>PE</UFPer>

</infPercurso>

13

APRESENTAÇÃO

MDF-e para Desenvolvedores

<infPercurso>

<UFPer>CE</UFPer>

</infPercurso>

</ide>

<emit> <!-- Não tem segredo, aqui são as informações do emitente do MDFe, assim como nos outros documentos eletrônicos -->

<CNPJ>081867677100160</CNPJ>

<IE>90446866788</IE>

<xNome>TECNOSPEED</xNome>

<xFant>TECNOSPEED</xFant>

<enderEmit>

<xLgr>RUA DUQUE DE CAXIAS</xLgr>

<nro>882</nro>

<xBairro>CENTRO</xBairro>

<cMun>4115200</cMun>

<xMun>Maringa</xMun>

<CEP>87060025</CEP>

<UF>PR</UF>

<fone>4430283749</fone>

</enderEmit>

</emit>

<infModal versaoModal=”1.00”>

<rodo>

<RNTRC>12345678</RNTRC> <!-- Código do transportador no Registro Nacional de Transportadores Rodoviários de carga, verificar link:http://www.antt.gov.br/index.php/content/view/4929/ RNTRC___Registro_Nacional_de_Transportadores_Rodoviarios_de_Cargas.html-->

<veicTracao> <!--Identificação do veículo que está conduzindo a carga -->

<placa>ABC5677</placa>

<tara>5000</tara>

<capKG>4500</capKG>

<capM3>400</capM3>

<prop> <!-- Descrição do proprietário do veículo descrito acima. Só preenchido quando o veículo não pertencer à empresa emitente do MDF-e -->

<CPF>09841019755</CPF>

<RNTRC>87784321</RNTRC>

<xNome>Lucas</xNome>

<IE/>

<UF>PR</UF>

<tpProp>2</tpProp>

</prop>

<condutor> <!-- Descrição do condutor do veículo. Em um MDFe podem ser inseridos até 10 condutores em um mesmo XML -->

<xNome>JOAO</xNome>

<CPF>12345678912</CPF>

</condutor>

<tpRod>01</tpRod>

<tpCar>00</tpCar>

<UF>PR</UF>

</veicTracao>

</rodo>

</infModal>

<infDoc>

<infMunDescarga> <!-- Nesse campo é preciso descrever o último município onde haverá descarga, lembrando que não é preciso que o UF de descarregamento esteja no campo infPercurso. O descarregamento utilizando esse modelo de MDFe que estamos utilizando de exemplo pode ser feito em vários municípios desde

14

APRESENTAÇÃO

MDF-e para Desenvolvedores

que na mesma UF, que nesse caso é na Paraíba. Se houver a necessidade de descarregar em duas UFs diferentes, é necessário que haja 2 MDFe. -->

<cMunDescarga>2507507</cMunDescarga>

<xMunDescarga>João Pessoa</xMunDescarga>

<infCTe> <!-- Nesse campo, são inseridos os documentos de CTe que estão vinculados nessa carga. Nesse caso não há nenhuma NFe vinculada, mas se houvesse, o grupo seria denomidado infNFe com o campo chNFe para inserção da chave do XML -->

<chCTe>4213010579382723245343571010000010021000000011</chCTe>

<infUnidTransp> <!--Informações das Unidades de Transporte (Carreta/Reboque/ Vagão). Os Tipos aceitos são 1 – Rodoviário Tração 2 – Rodoviário Reboque 3 – Navio 4 – Balsa 5 – Aeronave 6 – Vagão 7 - Outros. -->

<tpUnidTransp>1</tpUnidTransp>

<idUnidTransp>A</idUnidTransp>

</infUnidTransp>

</infCTe>

<infCTe>

<chCTe>43130994814834000150576450000001078001234892</chCTe>

</infCTe>

</infMunDescarga>

</infDoc>

<tot> <!-- Grupo totalizador de informações do MDFe de acordo com os CTe vinculados. A SEFAZ não faz nenhum tipo de validação automática com os CTe que estão no MDFe, por isso esse campo é informado manualmente pelo emitente. Esse valor pode, por exemplo, ser inserido pelo software do emitente -->

<qCTe>2</qCTe> <!-- Quantidade total de CTe que estão vinculadas no XML do MDFe -->

<vCarga>55.00</vCarga> <!-- Valor total da carga do MDFe informado pelo emitente -->

<cUnid>02</cUnid> <!-- Unidade de carga que é utilizada no campo qCarga, de acordo com tabela do manual -->

<qCarga>50.0000</qCarga> <!-- Peso bruto da carga informado pelo emitente -->

</tot>

<autXML>

<CNPJ>34548370000189</CNPJ> <!-- CNPJ de empresa autorizada a fazer o download do XML posteriormente -->

</autXML> </infMDFe> <Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”> <!-- Grupo referente a assinatura do XML pelo certificado digital da empresa -->

<SignedInfo>

<CanonicalizationMethod Algorithm=”http://www.w3.org/TR/2001/REC-xml-c14n-20010315”/>

<SignatureMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#rsa-sha1& quot;/>

<Reference URI=”#MDFe41140808187345000160580010000369341000000018& quot;>

<Transforms>

<Transform Algorithm=”http://www.w3.org/2000/09/xmldsig#envelopedsignature& quot;/>

<Transform Algorithm=”http://www.w3.org/TR/2001/REC-xml-c14n-20010315”/>

</Transforms>

<DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1& quot;/>

<DigestValue>VlyxjWBWkliHPz4EV7Hs9y4r/q4=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>MiZqRH9VBIrkDFjl9g2K2OGa/VSCzmvvVNOFGnv4QF (...) </SignatureValue>

<KeyInfo>

<X509Data>

<X509Certificate>MIIIAzCCBeugAwIBAgIIWPTrb74GwM8wDQYJKoZIhvcNAQELBQAwd (...)

</X509Certificate>

15

APRESENTAÇÃO

MDF-e para Desenvolvedores

</X509Data>

</KeyInfo> </Signature> </MDFe> <protMDFe versao=”1.00”> <!-- Protocolo de autorização e retorno da SEFAZ sobre a situação do documento, daqui em diante são informações referentes ao XML de autorização e não devem constar no arquivo de envio --> <infProt Id=”MDFe941143400049672”>

<tpAmb>2</tpAmb> <!-- Identificação do ambiente em que foi autorizado o documento. Nesse caso, a autorização foi feita em ambiente de Homologação, como segue: 1 - Produção; 2 - Homologação -->

<verAplic>RS20140801111734

</verAplic>

<chMDFe>3423808187168000160580010000369341000000018 <!-- Chave de autorização do MDFe, que é utilizado para impressão do DAMDFE -->

</chMDFe>

<dhRecbto>2014-08-12T18:07:27</dhRecbto>

<nProt>941140000049672</nProt>

<digVal>VlyxjWBWkliHPz4EV7Hs9y4r/q4=</digVal>

<cStat>100

</cStat>

<xMotivo>Autorizado o uso do MDF-e

</xMotivo> </infProt> </protMDFe> </mdfeProc>

Contingência

No momento da autorização, além da possibilidade de Rejeição, podem ocorrer também problemas técnicos de oscilações nos serviços web do fisco bem como na internet do contribuinte, impedindo a autorização online do documento para liberação da carga. Quando não é possível transmitir o MDFe, o contribuinte pode operar em contingência, realizando alguns procedimentos da seguinte forma: 1. Alterar a forma de emissão do MDFe de “Normal” para “Contingência” 2. Imprimir o DAMDFE obrigatoriamente com a informação no papel que o documento foi emtido em contingência 3. Após a cessação dos problemas, transmitir o documento via internet para o servidor do fisco respeitando o prazo máximo em lei de 168 horas* contatos a partir da emissão do documento *A não emissão do documento em até 168 horas pode ocasionar passivos fiscais para a empresa.

16

APRESENTAÇÃO

MDF-e para Desenvolvedores

Eventos de um MDFe (Encerramento, Cancelamento e alteração de condutor)

Nos documentos vinculados ao SPED, há algumas ações com o MDFe que são feitas por meio de eventos e no caso do MDFe específico há três: Cancelamento, Encerramento e Inclusão de condutor.

Encerrando um MDFe

Se você já é cliente Tecnospeed, pode consultar o artigo sobre encerramento de MDFe no Manager eDoc ou encerramento de MDFe no Componente MDFe. O evento de Encerramento de MDFe está no Manual MDFe v1.00 no índice “Sistema de Registro de Eventos (Parte específica).

O que você precisa saber sobre o Encerramento de MDFe

Encerrar o MDFe trata-se de uma prática necessária para avisar o fisco de que o fato gerador do documento foi finalizado, ou seja, as mercadorias e o veículo chegaram ao ponto final da rota daquele documento. Isso consolida todo o processo de um MDFe.

Caso o transporte não tenha terminado, mas haja a necessidade de mudanças nas informações do MDFe que está acobertando uma carga, é preciso também realizar o encerramento do mesmo para que em seguida uma nova emissão seja feita para o trecho do restante do percurso.

Enquanto um MDFe está aberto e não encerrado, o veículo que está realizando o transporte não pode fazer a emissão de um novo documento. Portanto, caso haja documentos pendentes que referenciam um veículo é preciso registrar seu cancelamento ou encerramento para que assim seja possível emitir um novo MDFe.

Em uma situação por exemplo, em que o descarregamento da carga é feita em dois UF diferentes, onde há necessidade de emissão de um novo MDFe durante o percurso, para a emissão deste segundo é necessário que seja feito o encerramento do primeiro.

O leiaute do XML de encerramento deve ter as seguintes informações: • Campo tpEvento: Contem a identificação do tipo de evento, no caso de inclusão de condutor deve ser 110112 • Campo chMDFe: Contém a idenficiação de qual MDFe está sendo encerrado • Campo descEvento: Descrição do evento que está sendo feito, no caso “Encerramento” • Campo condutor: Deve conter os campos dtEnc, cUF e cMun referente aos dados do município onde o XML está sendo encerrado.

O XML deve ser assinado digitalmente antes do envio para o servidor.

17

APRESENTAÇÃO

MDF-e para Desenvolvedores

Abaixo um exemplo, utilizando um arquivo XML comentado para detalhamento de como deve ser a estrutura do arquivo: <eventoMDFe xmlns=”http://www.portalfiscal.inf.br/mdfe” versao=”1.00”> <!-- eventoMDFe indica que o XML é de um evento --> <infEvento Id=”ID1101124114080818716800016058001000036934100000001801”> <!-- Identificador de assinatura opcional -->

<cOrgao>41</cOrgao>

<tpAmb>2</tpAmb> <!-- Tipo de ambiente que foi emitido o documento: 1 - Produção; 2 - Homologação -->

<CNPJ>08187168000160</CNPJ>

<chMDFe>41140808187168000160580010000369341000000018</chMDFe> <!-- Chave de acesso ao MDFe vinculado que está sendo encerrado -->

<dhEvento>2015-01-27T17:21:18</dhEvento> <!-- Data e hora do evento -->

<tpEvento>110112</tpEvento> <!-- Tipo de evento: 110111 - Cancelamento; 110112 - Encerramento e 110114 - Inclusão de condutor -->

<nSeqEvento>1</nSeqEvento> <!-- Campo opcional -->

<detEvento versaoEvento=”1.00”>

<evEncMDFe>

<descEvento>Encerramento</descEvento>

<nProt>941140000049672</nProt> <!-- Número do protocolo de registro (opcional também) -->

<dtEnc>2015-01-27</dtEnc>

<cUF>41</cUF>

<cMun>4115200</cMun>

</evEncMDFe>

</detEvento> </infEvento> <Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”> <!-- Daqui para baixo, o XML é referente a assinatura digital do arquivo -->

<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=”#ID1101124114080818716800016058001000036934100000001801”>

<Transforms>

<Transform Algorithm=”http://www.w3.org/2000/09/xmldsig#envelopedsignature”/>

<Transform Algorithm=”http://www.w3.org/TR/2001/REC-xml-c14n-20010315”/>

</Transforms>

<DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1”/>

<DigestValue>E/P1wkx35bwcdkKDGRFokhFzduk=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>H0Q8z8jx24lHoqp7NVgb0AAvd7o9SZ2CWTj+6zcFLmM7V038Fqt7RfsS(...) </ SignatureValue>

<KeyInfo>

<X509Data> <X509Certificate>MIIIAjCCBeqgAwIBAgIIRTHxfzgL9tgwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCQlIxEzARB(...) </X509Certificate>

</X509Data>

</KeyInfo> </Signature> </eventoMDFe>

18

APRESENTAÇÃO

MDF-e para Desenvolvedores

Rejeições específicas que podem retornar para este evento: • • • • • • •

Rejeição (249): UF da Chave de Acesso difere da UF do WebService Rejeição (636): Verificar se o nSeqEvento é maior do que o valor permitido (=99) Rejeição (613): Código Município de encerramento inválido Rejeição (614): Município de encerramento diverge da UF Rejeição (203): Verificar emitente não autorizado a emitir MDFe Rejeição (218): Verificar se MDFe já está cancelado Rejeição (615): Verificar se a data de encerramento é anterior à data de emissão do manifesto • Rejeição (222): Verificar se o número Protocolo informado difere do número Protocolo do MDFe • Rejeição (609): Verificar se houve encerramento do manifesto

Se o evento de encerramento for homologado, a situação do MDF-e para efeito de consulta situação passará para “132 – Encerramento homologado”.

Cancelamento de um MDFe

O “Evento de Cancelamento” consta no Manual do MDFe na parte de “Sistema de Registro de Eventos”. Caso já seja usuário de Componente, em um post anterior da Base do Conhecimento já foi explicado como fazer o cancelamento utilizando o Componente MDFe . Ou se você é usuário de Manager eDoc , pode consultar como fazer o cancelamento de MDFe utilizando Manager Edoc.

Atenção aos aspectos legais do cancelamento:

Antes de realizar o evento, é preciso saber que não é permitido realizar o cancelamento do documento em algumas situações previstas na lei: • Após o MDFe que se deseja cancelar tenha sido encerrado • Após ter sido vinculado ao MDFe que deseja cancelar um registro de passagem • Ter ocorrido o fato gerador que exige o documento fiscal, ou seja, o transporte já ter sido realizado ou mesmo iniciado

Caso nenhuma dessas três situações tenham acontecido, o evento pode ser realizado utilizando o código de Tipo de Evento 110111 .

O autor do evento é o próprio emissor do MDFe que deseja cancelar . A mensagem do XML deve ser assinada com seu respectivo certificado digital vinculado ao CNPJ da empresa emitente.

19

APRESENTAÇÃO

MDF-e para Desenvolvedores

O leiaute de cancelamento deve conter as seguintes informações: • Campo evCancMDFe: Schema XML de validação do evento do cancelamento 110111 , sendo o Schema XML: evCancMDFe_v9.99.xsd • Campo descEvento : Descrição do Evento “Cancelamento” • Campo nProt : Informar o número do Protocolo de Autorização do MDFe a ser cancelado • Campo xJust : Informar a justificativa do cancelamento do MDFe • Campo chMDFe : Informar a chave de acesso do MDFe que está sendo cancelado Para visualizar melhor o leiaute, segue um exemplo de XML comentado de um evento de cancelamento: <eventoMDFe xmlns=”http://www.portalfiscal.inf.br/mdfe” versao=”1.00”> <!-- eventoMDFe indica que o XML é de um evento --> <infEvento Id=”ID1101114114080818716800016058001000036934100000001801”> <!-- Identificador de assinatura opcional -->

<cOrgao>41</cOrgao>

<tpAmb>2</tpAmb> <!-- Tipo de ambiente que foi emitido o documento: 1 - Produção; 2 - Homologação

<CNPJ>08187168000160</CNPJ>

<chMDFe>41140808187168000160580010000369341000000018</chMDFe> <!-- Chave de acesso ao MDFe vinculado que está sendo encerrado -->

<dhEvento>2015-01-27T17:21:57</dhEvento>

<tpEvento>110111</tpEvento> <!-- Tipo de evento: 110111 - Cancelamento; 110112 - Encerramento e 110114 - Inclusão de condutor -->

<nSeqEvento>1</nSeqEvento>

<detEvento versaoEvento=”1.00”>

<evCancMDFe>

<descEvento>Cancelamento</descEvento>

<nProt>941140000049672</nProt>

<xJust>teste de justificativa de cancelamento</xJust>

</evCancMDFe>

</detEvento> </infEvento> <!-- Daqui para baixo, o XML é referente a assinatura digital do arquivo --> <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& quot;/>

<Reference URI=”#ID1101114114080818716800016058001000036934100000001801& quot;>

<Transforms>

<Transform Algorithm=”http://www.w3.org/2000/09/xmldsig#enveloped-signature& quot;/>

<Transform Algorithm=”http://www.w3.org/TR/2001/REC-xml-c14n-20010315”/>

</Transforms>

<DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1& quot;/>

<DigestValue>wD9zFU9xPlmfYJJdftdy7rplyIw=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>NnL1KIRD7codqNzf51he9bnI/yl (...) <SignatureValue>

<KeyInfo>

<X509Data> <X509Certificate>MIIIAjCCBeqgAwIBAgIIRTHxfzgL9tgwDQYJKoZIhvcNAQELBQAwdTEL(...) </X509Certificate>

</X509Data>

</KeyInfo> </Signature> </eventoMDFe>

20

APRESENTAÇÃO

MDF-e para Desenvolvedores

Para o evento há algumas regras de validação específicas e que podem retornar as seguintes rejeições: • • • •

Rejeição 249: UF da Chave de Acesso difere da UF do WebService Rejeição 636: Verificar se o nSeqEvento é maior que o valor permitido (=1) Rejeição 203: Verificar emitente não autorizado a emitir MDFe Rejeição 218: Verificar se MDFe já está cancelado Rejeição 220: Verificar MDFe autorizado há mais de 24 horas • Rejeição 222: Verificar se o número do protocolo informado difere do número do Protocolo do MDFe • Rejeição 609: Verificar se houve encerramento do manifesto • Rejeição 219: Verificar se houve registro de circulação do MDFe

Caso o evento tenha sido homologado com sucesso, o servidor retorna o código 135 . Se feita consulta sobre a situação do documento posteriormente, é emitida a seguinte mensagem pelo servidor do Fisco: “101 - Cancelamento homologado”. Ao fim do processo, o MDFe está cancelado.

Inclusão de condutor

Este não é um evento obrigatório e deve ser feito somente quando houver alterações necessárias no condutor do veículo, após a sua autorização. Se você já é cliente Tecnospeed, pode consultar na Base de conhecimento como fazer inclusão de condutor no Manager edoc ou como fazer inclusão de condutor no Componente MDFe.

O evento chamado “Inclusão de condutor” não consta no Manual do MDFe versão 1.00 e foi incluido no documento MDFe por meio da Nota Tecnica 2013/0041 .

Condições para emissão do evento Este evento de inclusão de condutor deve serguir as regras: • O documento MDFe já deve ter sido emitido e autorizado • Ainda não tenha sido encerrado ou cancelado • Esse evento é exclusivamente para transporte via modal Rodoviário.

O leiaute de Inclusão de condutor deve ter as seguintes informações • Campo tpEvento : Contem a identificação do tipo de evento, no caso de inclusão de condutor deve ser 110114 • Campo chMDFe : referente a chave do MDFe na qual o evento está referenciando • Campo descEvento : Descrição do evento que está sendo feito, no caso “Inclusao Condutor” • Campo condutor : Deve conter os campos xNome e CPF referente aos dados do condutor O XML deve ser assinado digitalmente antes do envio para o servidor.

21

APRESENTAÇÃO

MDF-e para Desenvolvedores

Abaixo um exemplo, utilizando um arquivo XML comentado para detalhamento de como deve ser a estrutura do arquivo: <eventoMDFe xmlns=”http://www.portalfiscal.inf.br/mdfe” versao=”1.00”> <!-- eventoMDFe indica que o XML é de um evento --> <infEvento Id=”ID1101144114080818716800016058001000036934100000001801”> <!-- Identificador de assinatura opcional --> <cOrgao>41</cOrgao> <tpAmb>2</tpAmb> <!-- Tipo de ambiente que foi emitido o documento: 1 - Produção; 2 - Homologação --> <CNPJ>08187168000160</CNPJ> <chMDFe>41140808187168000160580010000369341000000018</chMDFe> <!-- Chave de acesso ao MDFe vinculado que está sendo encerrado --> <dhEvento>2014-08-12T18:07:27</dhEvento> <!-- Data e hora do evento --> <tpEvento>110114</tpEvento> <!-- Tipo de evento: 110111 - Cancelamento; 110112 - Encerramento e 110114 Inclusão de condutor --> <nSeqEvento>1</nSeqEvento> <!-- Campo opcional --> <detEvento versaoEvento=”1.00”>

<evIncCondutorMDFe>

<descEvento>Inclusao Condutor</descEvento>

<condutor> <!-- Descrição do condutor que está sendo inserido no MDFe -->

<xNome>Lucas</xNome>

<CPF>082213019955</CPF>

</condutor>

</evIncCondutorMDFe> </detEvento> </infEvento> <Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”> <!-- Daqui para baixo, o XML é referente a assinatura digital do arquivo --> <SignedInfo>

<CanonicalizationMethod Algorithm=”http://www.w3.org/TR/2001/REC-xml-c14n-20010315”/>

<SignatureMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#rsa-sha1& quot;/>

<Reference URI=”#ID1101144114080818716800016058001000036934100000001801& quot;>

<Transforms>

<Transform Algorithm=”http://www.w3.org/2000/09/xmldsig#enveloped-signature& quot;/>

<Transform Algorithm=”http://www.w3.org/TR/2001/REC-xml-c14n-20010315”/>

</Transforms>

<DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1& quot;/>

<DigestValue>Zp/V4LB9ocvyEeyefTfPlenDSOo=</DigestValue>

</Reference> </SignedInfo> <SignatureValue>Qvsoz8WLi2U+kqcIwlNAo4LpL75xbKheDKP6+Sg(...) </SignatureValue> <KeyInfo>

<X509Data>

<X509Certificate>MIIIAjCCBeqgAwIBAgIIRTHxfzgL9tgwDQYJKoZIhvcNAQE(...) </X509Certificate>

</X509Data> </KeyInfo> </Signature> </eventoMDFe>

22

APRESENTAÇÃO

MDF-e para Desenvolvedores

Rejeições que podem retornar específicas para este evento: • Rejeição (249): UF da Chave de Acesso difere da UF do WebService • Rejeição (636): Verificar se o nSeqEvento é maior do que o valor permitido (=99) • Rejeição (203): Verificar emitente não autorizado a emitir MDFe • Rejeição (218): Verificar se MDFe já está cancelado • Rejeição (609): Verificar se MDFe já está encerrado • Rejeição (644): Verificar se MDFe é do modal rodoviário • Rejeição (645): CPF Condutor: CPF Inválido (dígito de controle, zeros) • Se o evento de inclusão de condutor for homologado, o status de retorno será “ 135 - Evento vinculado a MDF-e ”.

23

APRESENTAÇÃO

MDF-e para Desenvolvedores

Um caso de sucesso de aplicação de MDFe para redução de tempo de transporte

Projeto do estado da Paraíba, o Fronteira Livre permitire as empresas de transporte de carga detentoras de regimes especiais e que utilizam o documento fiscal eletrônico, Manifesto Eletrônico de Documentos Fiscais (MDF-e), a economia de tempo nas viagens de carga. O sistema consiste em permitir que essas empresas não tenham a necessidade de parada em postos fiscais paraibanos.

A economia de tempo com essa medida, segundo o presidente do Sindicato das Empresas de Transporte de Cargas da Paraíba (Setce-PB), Arlan Rodrigues, em entrevista à Secretaria de Comunicação do Estado do Paraíba, é de 5 a 8 horas para cada viagem. Não existe economia forte com logística fraca e como vendemos o serviço de entrega, o fator prazo é fundamental. Com o rompimento das barreiras fiscais, teremos um impacto positivo no tempo de entrega de forma significativa em nossas operações , esclarece.

Para participar, a empresa deve fazer a opção pelo regime especial junto à Receita Estadual.. Outras empresas também podem aderir ao regime especial, desde que estejam aptas à emissão de MDF-e.

O Fronteira Livre teve seu lançamento com antecedência de 45 dias de antecedência para que as empresas tenham tempo de se adequarem ao novo sistema. Segundo depoimento de Arlan Rodrigues: “Confesso que só encontrei vantagens no projeto Fronteira Livre da Receita Estadual para o setor e não tenho dúvida que haverá uma adesão rápida da maioria das transportadoras, por uma questão até de competitividade”, explicou na época do lançamento do projeto.

24

25