manual_mdfe_ v 1.00 - 29.08.2012.pdf

Manifesto Eletrnico de Documentos Fiscais Manual de Orientaes do Contribuinte

Projeto Manifesto Eletrnico de Documentos Fiscais

Manual de Orientao do Contribuinte Padres Tcnicos de Comunicao do

Manifesto Eletrnico de Documentos Fiscais

Verso 1.00

Junho, 2012


2

Controle de Verses

Verso Data 1.00 30/08/2011 SP 1.00 1.00 1.00 1.00 1.00 1.00

15/12/2011 RS 17/02/2012 RS 11/04/2012 RS 07/05/2012 RS 13/06/2012 RS 31/07/2012 RS


3

Identificao e vigncia do Manual

Verso do manual 1.00 Data de divulgao do manual 31/07/2012 Pacote de liberao de Schemas XML PL_MDFe_100 Data de incio de vigncia no ambiente de homologao 01/08/2012 Data de incio de vigncia no ambiente de produo 01/10/2012

Verses de leiautes do PL_MDFe_100

Leiaute verso Schema XML

Observao MDF-e 1.00 MDFe_v1.00.xsd Leiaute do MDF-e enviMDFe 1.00 enviMDFe_ v1.00.xsd Mensagem de envio e solicitao de

autorizao do MDF-e retEnviMDFe 1.00 retEnviMDFe_v1.00.xsd Mensagem de retorno do envio de MDF-e. consReciMDFe 1.00 consReciMDFe_v1.00.xsd Mensagem de consulta processamento do

MDF-e transmitido. retConsReciMDFe 1.00 retConsReciMDFe_v1.00.xsd Mensagem de retorno da consulta de

processamento do MDFe transmitido. procMDFe 1.00 procMDFe_v1.00.xsd Leiaute de compartilhamento do MDF-e.

consSitMDFe 1.00 consSitMDFe_v1.00.xsd Mensagem de consulta da situao atual da MDF-e.

retConsSitMDFe 1.00 retConsSitMDFe_v1.00.xsd Mensagem de retorno da consulta da situao atual da MDF-e.

consStatServ 1.00 consStatServMDFe_v1.00.xsd Mensagem da consulta do status do servio de autorizao de MDF-e.

retConsStatServ 1.00 retconsStatServ_v1.00.xsd Mensagem de retorno da consulta do status do servio de autorizao de MDF-e.

aereo 1.00 MDFeModalAereo_v1.00.xsd Leiaute do modal Areo (parte Especfica) aquav 1.00 MDFeModalAquaviario_v1.00.xsd Leiaute do modal Aquavirio (parte

Especfica) ferrov 1.00 MDFeModalFerroviario_v1.00.xsd Leiaute do modal Ferrovirio (parte

Especfica) rodo 1.00 MDFeModalRodoviario_v1.00.xsd Leiaute do modal Rodovirio (parte

Especfica) eventoMDFe 1.00 eventoMDFe_ v1.00.xsd Mensagem de solicitao de registro de

evento do MDF-e retEventoMDFe 1.00 retEventoMDFe. v1.00.xsd Mensagem de retorno do resultado da

solicitao de registro de evento do MDF-e

procEventoMDFe 1.00 procEventoMDFe_v1.00.xsd Leiaute de compartilhamento de solicitao de registro de evento do MDF-e

evCancMDFe 1.00 evCancMDFe_v1.00.xsd Leiaute especfico do evento de cancelamento de MDF-e

evEncMDFe 1.00 evEncMDFe_v1.00.xsd Leiaute especfico do evento de encerramento de MDF-e


4

ndice PROJETO MANIFESTO ELETRNICO DE DOCUMENTOS FISCAIS .............................................................................. 1

IDENTIFICAO E VIGNCIA DO MANUAL .............................................................................................................. 3

VERSES DE LEIAUTES DO PL_MDFE_100 ............................................................................................................... 3

1. INTRODUO ................................................................................................................................................. 8

2. CONSIDERAES INICIAIS .............................................................................................................................. 9

2.1. CONCEITO DO MDF-E ........................................................................................................................................ 9

2.2. DESCRIO SIMPLIFICADA DO MODELO OPERACIONAL ............................................................................................. 9

3. ARQUITETURA DE COMUNICAO COM CONTRIBUINTE .............................................................................. 11

3.1. MODELO CONCEITUAL ...................................................................................................................................... 11

3.2. PADRES TCNICOS ......................................................................................................................................... 12

3.2.1. Padro de documento XML ................................................................................................................ 12

3.2.2. Padro de Comunicao .................................................................................................................... 14

3.2.3. Padro de Certificado Digital ............................................................................................................. 14

3.2.4. Padro de Assinatura Digital ............................................................................................................. 15

3.2.5. Validao de Assinatura Digital pelo Ambiente Autorizador ............................................................. 17

3.2.6. Resumo dos Padres Tcnicos ............................................................................................................ 17

3.3. MODELO OPERACIONAL .................................................................................................................................... 18

3.3.1. Servios sncronos .............................................................................................................................. 18

3.3.2. Servios assncronos ........................................................................................................................... 19

3.3.3. Filas e Mensagens .............................................................................................................................. 20

3.4. PADRO DE MENSAGENS DOS WEB SERVICES ........................................................................................................ 21

3.4.1. Informaes de controle e rea de dados das mensagens ................................................................ 21

3.4.2. Validao da estrutura XML das Mensagens dos Web Services ........................................................ 22

3.4.3. Schemas XML das Mensagens dos Web Services ............................................................................... 22

3.5. VERSO DOS SCHEMAS XML ............................................................................................................................. 23

3.5.1. Liberao das verses dos Schemas para o Manifesto Eletrnico de Documentos Fiscais MDF-e . 23

3.5.2. Pacote de Liberao Preliminar ......................................................................................................... 24

3.5.3. Pacote de Liberao de Homologao e Pacote de liberao definitivo............................................ 24

3.5.4. Correo de Pacote de Liberao ....................................................................................................... 24

3.5.5. Divulgao de novos Pacotes de Liberao ....................................................................................... 24

3.5.6. Controle de Verso ............................................................................................................................. 25

3.6. SCHEMA XML DO MDF-E ESTRUTURA GENRICA E ESTRUTURA ESPECFICA DO MODAL ............................................... 25

3.6.1. Parte Genrica ................................................................................................................................... 25

3.6.2. Parte Especfica para cada Modal ...................................................................................................... 26

3.6.3. Parte Genrica e Parte Especfica para cada Modal - Verses .......................................................... 27

3.7. SISTEMA DE REGISTRO DE EVENTOS ..................................................................................................................... 27

3.7.1. Relao dos Tipos de Evento .............................................................................................................. 28

3.8. AMBIENTE AUTORIZADOR (SEFAZ AUTORIZADORA NACIONAL)................................................................................ 28

4. WEB SERVICES............................................................................................................................................... 29

4.1. SERVIO DE RECEPO DO MDF-E ..................................................................................................................... 30

4.1.1. Web Service MDF-e Recepcao ......................................................................................................... 30

4.1.2. Leiaute Mensagem de Entrada .......................................................................................................... 30


5

4.1.3. Leiaute Mensagem de Retorno .......................................................................................................... 31

4.1.4. Validao do Certificado de Transmisso .......................................................................................... 32

4.1.5. Validao Inicial da Mensagem no Web Service ................................................................................ 32

4.1.6. Validao das informaes de controle da chamada ao Web Service ............................................... 33

4.1.7. Gerao da Resposta com o Recibo ................................................................................................... 33

4.1.8. Validao da rea de Dados .............................................................................................................. 34

4.1.9. Final do Processamento do MDF-e..................................................................................................... 37

4.2. WEB SERVICE MDFERETRECEPCAO ................................................................................................................. 39



4.2.3. Descrio do Processo de Web Service .............................................................................................. 40





4.2.8. Final do Processamento ..................................................................................................................... 43

4.3. WEB SERVICE MDFECONSULTA PROTOCOLO ..................................................................................................... 44









4.4. WEB SERVICE MDFESTATUSSERVICO ............................................................................................................... 48









4.5. SISTEMA DE REGISTRO DE EVENTOS ..................................................................................................................... 52


4.5.2. Diagrama Simplificado do Schema: eventoMDFe_v9.99.xsd ............................................................. 53


4.5.4. Diagrama Simplificado Schema de retorno: retEventoMDFe _v99.99.xsd......................................... 55






4.5.10. Processamento das validaes especficas do evento ....................................................................... 59

4.5.11. Final do Processamento do Evento .................................................................................................... 59

5. SISTEMA DE REGISTRO DE EVENTOS (PARTE ESPECFICA) ............................................................................. 60


6

5.1. EVENTO DE CANCELAMENTO .............................................................................................................................. 60

5.1.1. Leiaute Mensagem do evento de Cancelamento ............................................................................... 60

5.1.2. Diagrama Simplificado do Evento de Cancelamento ......................................................................... 60

5.1.3. Regras de Validao Especficas ........................................................................................................ 60


5.2. EVENTO DE ENCERRAMENTO .............................................................................................................................. 62

5.2.1. Leiaute Mensagem do evento de Cancelamento ............................................................................... 62

5.2.2. Diagrama Simplificado do Evento de Encerramento ......................................................................... 62

5.2.3. Regras de Validao Especficas ........................................................................................................ 63


6. WEB SERVICES INFORMAES ADICIONAIS ............................................................................................... 64

6.1. REGRAS DE VALIDAO ..................................................................................................................................... 64

6.2. TABELA DE CDIGOS DE ERROS E DESCRIES DAS MENSAGENS DE ERRO ESPECFICAS DO MDF-E .................................... 64

6.3. PADRO DE NOMES PARA OS ARQUIVOS ............................................................................................................... 67

6.4. TRATAMENTO DE CARACTERES ESPECIAIS NO TEXTO DE XML .................................................................................... 67

6.5. CHAVE DE ACESSO DO MDF-E ........................................................................................................................... 68

6.6. NMERO DO RECIBO ........................................................................................................................................ 69

6.7. NMERO DO PROTOCOLO.................................................................................................................................. 69

6.8. TEMPO MDIO DE RESPOSTA .............................................................................................................................. 70

7. CDIGO DE BARRA ........................................................................................................................................ 71

7.1. CLCULO DO DGITO VERIFICADOR DO CODE-128C ............................................................................................... 72

7.2. REPRESENTAO SIMBLICA DO CDIGO .............................................................................................................. 72

8. DOCUMENTO AUXILIAR DE MDF-E - DAMDFE ............................................................................................... 73

9. CONTINGNCIA ............................................................................................................................................. 74

10. AMBIENTE DE HOMOLOGAO / PRODUO .......................................................................................... 75

11. COMPARTILHAMENTO DE INFORMAES DO MDF-E ENTRE RGOS PBLICOS ..................................... 76

11.1. PROCESSO DE COMPARTILHAMENTO ................................................................................................................... 76

11.2. LEIAUTE DE COMPARTILHAMENTO: MDF-E ........................................................................................................... 76

11.3. LEIAUTE DE COMPARTILHAMENTO: REGISTRO DE EVENTO DE MDF-E ......................................................................... 76

11.4. COMPARTILHAMENTO DE DOCUMENTOS COM OUTROS RGOS PBLICOS .................................................................. 77

ANEXO I LEIAUTE DO MDF-E ............................................................................................................................... 78

MDF-E DIAGRAMA SIMPLIFICADO PARTE GENRICA ....................................................................................................... 81

MDF-E DIAGRAMA SIMPLIFICADO MODAL RODOVIRIO ................................................................................................. 82

MDF-E DIAGRAMA SIMPLIFICADO MODAL AREO ......................................................................................................... 83

MDF-E DIAGRAMA SIMPLIFICADO MODAL FERROVIRO ................................................................................................. 85

LEIAUTE MDF-E ESTRUTURA GENRICA ......................................................................................................................... 86

LEIAUTE MODAL RODOVIRIO ...................................................................................................................................... 92

LEIAUTE MODAL AREO .............................................................................................................................................. 95

LEIAUTE MODAL AQUAVIRIO ...................................................................................................................................... 96

LEIAUTE MODAL FERROVIRIO ..................................................................................................................................... 97

ANEXO II - MODELO DO DOCUMENTO AUXILIAR DE MDF-E (DAMDFE) ............................................................... 101

TABELA DE CDIGO DE UF DO IBGE ............................................................................................................................... 107


7

TABELA DE CDIGO DE MUNICPIO DO IBGE .................................................................................................................... 107

VALIDAO DO CDIGO DE MUNICPIO ........................................................................................................................... 108

EXEMPLO DE CLCULO DO DGITO DE CONTROLE DO CDIGO DE MUNICPIO ........................................................................... 108

EXCEO NO CLCULO DO DGITO DE CONTROLE DO CDIGO DE MUNICPIO ........................................................................... 109

TABELA DE CDIGO DE PAS DO BACEN .......................................................................................................................... 109

VALIDAO DO CDIGO DE PAS .................................................................................................................................... 110

EXEMPLO DE CLCULO DO DGITO DE CONTROLE DO CDIGO DE PAS .................................................................................... 110

EXCEO NO CLCULO DO DGITO DE CONTROLE DO CDIGO DE PAS .................................................................................... 110

ANEXO IV WS DISPONVEIS............................................................................................................................... 112

ANEXO V CONJUNTO DE CARACTERES CDIGO DE BARRAS CODE-128C ........................................................... 113

ANEXO VI PROJETO PILOTO DO MDF-E ............................................................................................................. 114


8

1. Introduo

Este Manual tem por objetivo a definio das especificaes e critrios tcnicos necessrios para a integrao entre os Portais das Secretarias de Fazendas das Unidades Federadas, Receita Federal do Brasil - RFB, Superintendncia da Zona Franca de Manaus SUFRAMA, e os sistemas das empresas emissoras do Manifesto Eletrnico de Documentos Fiscais MDF-e.


9

2. Consideraes Iniciais

O Manifesto Eletrnico de Documentos Fiscais (MDF-e) est sendo desenvolvido de forma integrada pelas Secretarias de Fazenda das Unidades Federadas, Receita Federal do Brasil - RFB, Superintendncia da Zona Franca de Manaus SUFRAMA e representantes das transportadoras e Agncias Reguladoras do segmento de transporte, a partir da assinatura do Protocolo ENAT, que atribuiu ao Encontro Nacional de Coordenadores e Administradores Tributrios Estaduais (ENCAT) a coordenao e a responsabilidade pelo desenvolvimento e implantao do Projeto MDF-e.

2.1. Conceito do MDF-e

Manifesto Eletrnico de Documentos Fiscais (MDF-e) o documento emitido e armazenado eletronicamente, de existncia apenas digital, para vincular os documentos fiscais utilizados na operao e/ou prestao, unidade de carga utilizada no transporte, cuja validade jurdica garantida pela assinatura digital do emitente e autorizao de uso pela administrao tributria da unidade federada do contribuinte.

O MDF-e dever ser emitido por empresas prestadoras de servio de transporte para prestaes com mais de um conhecimento de transporte ou pelas demais empresas nas operaes, cujo transporte seja realizado em veculos prprios, arrendados, ou mediante contratao de transportador autnomo de cargas, com mais de uma nota fiscal.

A finalidade do MDF-e agilizar o registro em lote de documentos fiscais em trnsito e identificar a unidade de carga utilizada e demais caractersticas do transporte.

Autorizao de uso do MDF-e implicar em registro posterior dos eventos, nos documentos fiscais eletrnicos nele relacionados.

2.2. Descrio Simplificada do Modelo Operacional

A empresa emissora do MDF-e gerar um arquivo eletrnico contendo as informaes do veculo de carga, condutor, previso de itinerrio, valor e peso da carga e documentos fiscais, o qual dever ser assinado digitalmente, de maneira a garantir a integridade dos dados e a autoria do emissor, com certificado ICP-Brasil.

O arquivo eletrnico do MDF-e, ser transmitido pela Internet, para o ambiente autorizador (1), que far uma validao do arquivo (2) e devolver uma mensagem eletrnica com o resultado da validao, podendo ser: rejeio ou autorizao de uso (3). Sendo que s poder iniciar o transporte, quando tiver a sua autorizao de uso.

Para acompanhar o transporte das mercadorias dever ser impresso, em papel, um documento auxiliar do MDF-e de acordo com leiaute definido neste manual, o Documento Auxiliar de MDF-e DAMDFE (4).

O documento auxiliar em papel poder ser substitudo por um carto com RFID no padro Brasil-ID, conforme legislao especfica.


10

A empresa emitente dever encerrar o MDF-e no final do percurso. Enquanto houver MDF-e pendente de encerramento no ser possvel autorizar novo MDF-e, para o mesmo par UF de carregamento e UF de descarregamento, para o mesmo veculo.

Se no decorrer do transporte houver qualquer alterao nas informaes do MDF-e (veculos, carga, documentao, motorista, etc.), este dever ser encerrado e ser emitido um novo MDF-e com a nova configurao.

Entende-se como encerramento do MDF-e o ato de informar ao fisco, atravs de Web Service de registro de eventos o fim de sua vigncia, que poder ocorrer pelo trmino do trajeto acobertado ou pela alterao das informaes do MDF-e atravs da emisso de um novo.

O Ambiente Autorizador ser o repositrio nacional de todos os MDF-e emitidos e disponibilizar os documentos para as Secretarias de Fazenda das Unidades Federadas, RFB e SUFRAMA (6) .

O sistema MDF-e implementa o conceito de evento, que o registro de uma ao ou situao relacionada com o manifesto, que ocorreu aps a autorizao de uso, como o registro de um cancelamento, por exemplo.

Figura 1 Representao do Modelo Operacional do MDF-e


11

3. Arquitetura de Comunicao com Contribuinte

3.1. Modelo Conceitual

O ambiente autorizador de MDF-e ir disponibilizar os seguintes servios:

a) Recepo de MDF-e; 1) Recepo; 2) Consulta Processamento;

b) Consulta da situao atual do MDF-e; c) Consulta do status do servio; d) Registro de eventos (cancelamento, encerramento, registro de passagem).

Para cada servio oferecido existir um Web Service especfico. O fluxo de comunicao sempre iniciado pelo aplicativo do contribuinte atravs do envio de uma mensagem ao Web Service com a solicitao do servio desejado.

O Web Service sempre devolve uma mensagem de resposta confirmando o recebimento da solicitao de servio ao aplicativo do contribuinte na mesma conexo.

A solicitao de servio poder ser atendida na mesma conexo ou ser armazenada em filas de processamento nos servios mais crticos para um melhor aproveitamento dos recursos de comunicao e de processamento do Ambiente Autorizador.

Os servios podem ser sncronos ou assncronos em funo da forma de processamento da solicitao de servios:

a) Servios sncronos o processamento da solicitao de servio concludo na mesma conexo, com a devoluo de uma mensagem com o resultado do processamento do servio solicitado;

b) Servios assncronos o processamento da solicitao de servio no concludo na mesma conexo, havendo a devoluo de uma mensagem de resposta com um recibo que apenas confirma o recebimento da solicitao de servio. O aplicativo do contribuinte dever realizar uma nova conexo para consultar o resultado do processamento do servio solicitado anteriormente.

O diagrama a seguir ilustra o fluxo conceitual de comunicao entre o aplicativo do contribuinte e o Ambiente Autorizador:


12

3.2. Padres Tcnicos

3.2.1. Padro de documento XML

a) Padro de Codificao

A especificao do documento XML adotada a recomendao W3C para XML 1.0, disponvel em www.w3.org/TR/REC-xml e a codificao dos caracteres ser em UTF-8, assim todos os documentos XML sero iniciados com a seguinte declarao:

OBS1: Lembrando que cada arquivo XML somente poder ter uma nica declarao .

OBS2: Cada arquivo de MDF-e ter apenas um MDF-e, dada a quantidade de documentos fiscais que um MDF-e poder conter.

b) Declarao namespace

O documento XML dever ter uma nica declarao de namespace no elemento raiz do documento com o seguinte padro:

(exemplo para o XML do MDF-e)

O uso de declarao namespace diferente do padro estabelecido para o Projeto vedado.

A declarao do namespace da assinatura digital dever ser realizada na prpria tag , conforme exemplo abaixo.

Veja exemplo a seguir:

...

Contribuinte Ambiente Autorizador

Client MDF-e ( ERP ou software especfico )

MDF-e

Aplicativo de Faturamento ( ERP ou software especfico )

HTTPS

Fluxo de Comunicao

Servios Sncronos

Aplicao MDF-e

Filas de Msgs

MDF-e

Arquitetura de Comunicao Viso Conceitual

Servios Assncronos

Web Services Transaes


13

c) Prefixo de namespace

No permitida a utilizao de prefixos de namespace. Essa restrio visa otimizar o tamanho do arquivo XML.

Assim, ao invs da declarao:

(exemplo para o XML do MDF-e com prefixo mdfe) dever ser adotada a declarao:

d) Otimizao na montagem do arquivo

Na gerao do arquivo XML do MDF-e, excetuados os campos identificados como obrigatrios no modelo (primeiro dgito da coluna de ocorrncias do leiaute iniciada com 1, ex.: 1-1, 1-2, 1-N), no devero ser includas as TAGs de campos com contedo zero (para campos tipo numrico) ou vazio (para campos tipo caractere).

Na gerao do arquivo XML do MDF-e, devero ser preenchidos no modelo apenas as TAGs de campos identificados como obrigatrios no leiaute ou os campos obrigatrios por fora da legislao pertinente. Os campos obrigatrios no leiaute so identificados pelo primeiro dgito da coluna ocorrncia (Ocorr.) que inicie com 1, ex.: 1-1, 1-2, 1-N . Os campos obrigatrios por fora da legislao pertinente devem ser informados, mesmo que no leiaute seu preenchimento seja facultativo.

A regra constante do pargrafo anterior dever estender-se para os campos onde no h indicao de obrigatoriedade e que, no entanto, seu preenchimento torna-se obrigatrio por estar condicionado legislao especfica ou ao negcio do contribuinte. Neste caso, dever constar a TAG com o valor correspondente e, para os demais campos, devero ser eliminadas as TAGs.

Para reduzir o tamanho final do arquivo XML do MDF-e alguns cuidados de programao devero ser assumidos:

no incluir "zeros no significativos" para campos numricos; no incluir "espaos" ("line-feed", "carriage return", "tab", caractere de "espao" entre as

TAGs.) no incio ou no final de campos numricos e alfanumricos; no incluir comentrios no arquivo XML; no incluir anotao e documentao no arquivo XML (TAG annotation e TAG

documentation); no incluir caracteres de formatao no arquivo XML ("line-feed", "carriage return", "tab",

caractere de "espao" entre as TAGs).

e) Validao de Schema

Para garantir minimamente a integridade das informaes prestadas e a correta formao dos arquivos XML, o contribuinte dever submeter o arquivo do MDF-e e as demais mensagens XML para validao pelo Schema do XML (XSD XML Schema Definition), disponibilizado pelo Ambiente Autorizador, antes de seu envio.


14

3.2.2. Padro de Comunicao

A comunicao entre o contribuinte e a Secretaria de Fazenda Estadual ser baseada em Web Services disponibilizados no Ambiente Autorizador.

O meio fsico de comunicao utilizado ser a Internet, com o uso do protocolo SSL verso 3.0, com autenticao mtua, que alm de garantir um duto de comunicao seguro na Internet, permite a identificao do servidor e do cliente atravs de certificados digitais, eliminando a necessidade de identificao do usurio atravs de nome ou cdigo de usurio e senha.

O modelo de comunicao segue o padro de Web Services definido pelo WS-I Basic Profile.

A troca de mensagens entre os Web Services do Ambiente Autorizador e o aplicativo do contribuinte ser realizada no padro SOAP verso 1.2, com troca de mensagens XML no padro Style/Enconding: Document/Literal.

A chamada dos diferentes Web Services do Projeto MDF-e realizada com o envio de uma mensagem XML atravs do campo mdfeDadosMsg.

A verso do leiaute da mensagem XML contida no campo mdfeDadosMsg e o cdigo da UF requisitada sero informados nos campos versaoDados e cUF, ambos do tipo string localizados no elemento mdfeCabecMsg do SOAP header.

Exemplo de uma mensagem requisio padro SOAP: string string xml

Exemplo de uma mensagem de retorno padro SOAP: string string xml

3.2.3. Padro de Certificado Digital

O certificado digital utilizado no Projeto do MDF-e ser emitido por Autoridade Certificadora credenciada pela Infra-estrutura de Chaves Pblicas Brasileira ICP-Brasil, tipo A1 ou A3, devendo


15

conter o CNPJ da pessoa jurdica titular do certificado digital no campo otherName OID =2.16.76.1.3.3.

Os certificados digitais sero exigidos em 2 (dois) momentos distintos para o projeto:

a) Assinatura de Mensagens: O certificado digital utilizado para essa funo dever conter o CNPJ de um dos estabelecimentos da empresa emissora do CT-e e/ou NF-e. Por mensagens, entenda-se: o Pedido de Autorizao de Uso (Arquivo MDF-e), o Registro de Eventos de MDF-e e demais arquivos XML que necessitem de assinatura. O certificado digital dever ter o uso da chave previsto para a funo de assinatura digital, respeitando a Poltica do Certificado.

b) Transmisso (durante a transmisso das mensagens entre o servidor do contribuinte e o Ambiente Autorizador): O certificado digital utilizado para identificao do aplicativo do contribuinte dever conter o CNPJ do responsvel pela transmisso das mensagens, mas no necessita ser o mesmo CNPJ do estabelecimento emissor do MDF-e, devendo ter a extenso Extended Key Usage com permisso de "Autenticao Cliente".

3.2.4. Padro de Assinatura Digital

As mensagens enviadas ao Ambiente Autorizador so documentos eletrnicos elaborados no padro XML e devem ser assinados digitalmente com um certificado digital que contenha o CNPJ do estabelecimento matriz ou o CNPJ do estabelecimento emissor do MDF-e objeto do pedido.

Os elementos abaixo esto presentes dentro do Certificado do contribuinte tornando desnecessria a sua representao individualizada no arquivo XML. Portanto, o arquivo XML no deve conter os elementos:

Deve-se evitar o uso das TAGs relacionadas a seguir, pois as informaes sero obtidas a partir do Certificado do emitente:

O Projeto MDF-e utiliza um subconjunto do padro de assinatura XML definido pelo http://www.w3.org/TR/xmldsig-core/, que tem o seguinte leiaute:

Schema XML: xmldsig-core-schema_v1.01.xsd

# Campo Ele Pai Tipo Ocor. Tam. Dec. Descrio/Observao XS01 Signature Raiz - - - - XS02 SignedInfo G XS01 - 1-1 Grupo da Informao da assinatura XS03 CanonicalizationMe

thod G XS02 - 1-1 Grupo do Mtodo de Canonicalizao

XS04 Algorithm A XS03 C 1-1 Atributo Algorithm de CanonicalizationMethod: http://www.w3.org/TR/2001/REC-xml-c14n-20010315


16

XS05 SignatureMethod G XS02 - 1-1 Grupo do Mtodo de Assinatura XS06 Algorithm A XS05 C 1-1 Atributo Algorithm de SignedMethod:

http://www.w3.org/2000/09/xmldsig#rsa-sha1 XS07 Reference G XS02 - 1-1 Grupo de Reference XS08 URI A XS07 C 1-1 Atributo URI da tag Reference XS10 Transforms G XS07 - 1-1 Grupo do algorithm de Transform XS11 unique_Transf_Alg RC XS10 - 1-1 Regra para o atributo Algorithm do Transform ser

nico. XS12 Transform G XS10 - 2-2 Grupo de Transform XS13 Algorithm A XS12 C 1-1 Atributos vlidos Algorithm do Transform:

http://www.w3.org/TR/2001/REC-xml-c14n-20010315 http://www.w3.org/2000/09/xmldsig#enveloped-signature

XS14 XPath E XS12 C 0-N XPath XS15 DigestMethod G XS07 - 1-1 Grupo do Mtodo de DigestMethod XS16 Algorithm A XS15 C 1-1 Atributo Algorithm de DigestMethod:

http://www.w3.org/2000/09/xmldsig#sha1 XS17 DigestValue E XS07 C 1-1 Digest Value (Hash SHA-1 Base64) XS18 SignatureValue G XS01 - 1-1 Grupo do Signature Value XS19 KeyInfo G XS01 - 1-1 Grupo do KeyInfo XS20 X509Data G XS19 - 1-1 Grupo X509 XS21 X509Certificate E XS20 C 1-1 Certificado Digital x509 em Base64

A assinatura do Contribuinte no MDF-e ser feita na TAG identificada pelo atributo Id, cujo contedo dever ser um identificador nico (chave de acesso) precedido do literal MDFe para o MDF-e, conforme leiaute descrito no Anexo I. O identificador nico precedido do literal #MDFe dever ser informado no atributo URI da TAG . Para as demais mensagens a serem assinadas, o processo ser o mesmo mantendo sempre um identificador nico para o atributo Id na TAG a ser assinada. Segue um exemplo:

...

vFL68WETQ+mvj1aJAMDx+oVi928= IhXNhbdL1F9UGb2ydVc5v/gTB/y6r0KIFaf5evUi1i ... MIIFazCCBFOgAwIBAgIQaHEfNaxSeOEvZGlVDANB ...


17

Para o processo de assinatura, o contribuinte no deve fornecer a Lista de Certificados Revogados, j que a mesma ser montada e validada no Ambiente Autorizador no momento da conferncia da assinatura digital. A assinatura digital do documento eletrnico dever atender aos seguintes padres adotados:

a) Padro de assinatura: XML Digital Signature, utilizando o formato Enveloped (http://www.w3.org/TR/xmldsig-core/);

b) Certificado digital: Emitido por AC credenciada no ICP-Brasil (http://www.w3.org/2000/09/xmldsig#X509Data);

c) Cadeia de Certificao: EndCertOnly (Incluir na assinatura apenas o certificado do usurio final);

d) Tipo do certificado: A1 ou A3 (o uso de HSM recomendado); e) Tamanho da Chave Criptogrfica: Compatvel com os certificados A1 e A3 (1024 bits); f) Funo criptogrfica assimtrica: RSA (http://www.w3.org/2000/09/xmldsig#rsa-sha1); g) Funo de message digest: SHA-1 (http://www.w3.org/2000/09/xmldsig#sha1); h) Codificao: Base64 (http://www.w3.org/2000/09/xmldsig#base64); i) Transformaes exigidas: til para realizar a canonicalizao do XML enviado para

realizar a validao correta da Assinatura Digital. So elas: (1) Enveloped (http://www.w3.org/2000/09/xmldsig#enveloped-signature) (2) C14N (http://www.w3.org/TR/2001/REC-xml-c14n-20010315)

3.2.5. Validao de Assinatura Digital pelo Ambiente Autorizador

Para a validao da assinatura digital, seguem as regras que sero adotadas pelo Ambiente Autorizador:

(1) Extrair a chave pblica do certificado; (2) Verificar o prazo de validade do certificado utilizado; (3) Montar e validar a cadeia de confiana dos certificados validando tambm a LCR (Lista

de Certificados Revogados) de cada certificado da cadeia; (4) Validar o uso da chave utilizada (Assinatura Digital) de tal forma a aceitar certificados

somente do tipo A (no sero aceitos certificados do tipo S); (5) Garantir que o certificado utilizado de um usurio final e no de uma Autoridade

Certificadora; (6) Adotar as regras definidas pelo RFC 3280 para LCRs e cadeia de confiana; (7) Validar a integridade de todas as LCR utilizadas pelo sistema; (8) Prazo de validade de cada LCR utilizada (verificar data inicial e final).

A forma de conferncia da LCR pode ser feita de 2 (duas) maneiras: On-line ou Download peridico. As assinaturas digitais das mensagens sero verificadas considerando a lista de certificados revogados disponvel no momento da conferncia da assinatura.

3.2.6. Resumo dos Padres Tcnicos

A tabela a seguir resume os principais padres de tecnologia utilizados:

Caracterstica Descrio Web Services PADRO DEFINIDO PELO WS-I BASIC PROFILE 1.1

(HTTP://WWW.WS-I.ORG/PROFILES/BASICPROFILE-1.1-2004-08-24.HTML).

Meio lgico de comunicao WEB SERVICES, DISPONIBILIZADOS PELO AMBIENTE AUTORIZADOR

Meio fsico de comunicao Internet Protocolo Internet SSL verso 3.0, com autenticao mtua atravs de certificados


18

digitais. Padro de troca de mensagens SOAP verso 1.2. Padro da mensagem XML no padro Style/Encoding: Document/Literal. Padro de certificado digital X.509 verso 3, emitido por Autoridade Certificadora credenciada

pela Infra-estrutura de Chaves Pblicas Brasileira ICP-Brasil, do tipo A1 ou A3, devendo conter o CNPJ do proprietrio do certificado digital. Para assinatura de mensagens, utilizar o certificado digital de um dos estabelecimentos da empresa emissora do CT-e ou NF-e. Para transmisso, utilizar o certificado digital do responsvel pela transmisso.

Padro de assinatura digital XML Digital Signature, Enveloped, com certificado digital X.509 verso 3, com chave privada de 1024 bits, com padres de criptografia assimtrica RSA, algoritmo message digest SHA-1 e utilizao das transformaes Enveloped e C14N.

Validao de assinatura digital Ser validada alm da integridade e autoria, a cadeia de confiana com a validao das LCRs.

Padres de preenchimento XML Campos no obrigatrios do Schema que no possuam contedo tero suas tags suprimidas no arquivo XML.

Mscara de nmeros decimais e datas esto definidas no Schema XML.

Nos campos numricos inteiro, no incluir a vrgula ou ponto decimal.

Nos campos numricos com casas decimais, utilizar o ponto decimal na separao da parte inteira.

3.3. Modelo operacional

A forma de processamento das solicitaes de servios no MDF-e pode ser sncrona, caso o atendimento da solicitao de servio seja realizado na mesma conexo, ou assncrona, quando o processamento do servio solicitado no atendido na mesma conexo, nesta situao torna-se necessria a realizao de mais uma conexo para a obteno do resultado do processamento.

As solicitaes de servios que exigem processamento intenso sero executadas de forma assncrona e as demais solicitaes de servios de forma sncrona.

Assim, os servios do MDF-e sero implementados da seguinte forma:

Servio Implementao Recepo do MDF-e Assncrona Consulta Situao atual do MDF-e Sncrona Consulta do status do servio Sncrona Registro de evento Sncrona

3.3.1. Servios sncronos

As solicitaes de servios de implementao sncrona so processadas imediatamente e o resultado do processamento obtido em uma nica conexo. A seguir, o fluxo simplificado de funcionamento:

Aplicativo Cliente

Web Service Processamento de Servios (1) Solicitao de servio (2) Solicitao de servio

(4) Resultado (3) Resultado

Contribuinte Ambiente Autorizador

Servio de Implementao sncrona


19

Etapas do processo ideal:

(1) O aplicativo do contribuinte inicia a conexo enviando uma mensagem de solicitao de servio para o Web Service;

(2) O Web Service recebe a mensagem de solicitao de servio e encaminha ao aplicativo do MDF-e que ir processar o servio solicitado;

(3) O aplicativo do MDF -e recebe a mensagem de solicitao de servio e realiza o processamento, devolvendo uma mensagem de resultado do processamento ao Web Service;

(4) O Web Service recebe a mensagem de resultado do processamento e o encaminha ao aplicativo do contribuinte;

(5) O aplicativo do contribuinte recebe a mensagem de resultado do processamento e, caso no exista outra mensagem, encerra a conexo.

3.3.2. Servios assncronos

As solicitaes de servios de implementao assncrona so processadas de forma distribuda por vrios processos e o resultado do processamento somente obtido na segunda conexo.

A seguir o fluxo simplificado de funcionamento:

Envio deSolicitaode Servios

ConsultaRecibo

Web Service

Recebe Solicitaode Servios

Web Service

Consulta recibo

Processamentode Servios

(1) Solicitao de servio (2) Solicitao de servio

(8) Consulta recibo

(3) Recibo

Fila deservios

solicitados

Fila derecibos

(4)

(7)

(5)

(6)

(10) Resultado processamento(9) Resultado processamento

Fila deservios

processados

Contribuinte Secretaria de Fazenda Estadual

Servio de Implementao assncrona


20

Etapas do processo ideal: (1) O aplicativo do contribuinte inicia a conexo enviando uma mensagem de solicitao de

servio para o Web Service de recepo de solicitao de servios; (2) O Web Service de recepo de solicitao de servios recebe a mensagem de solicitao

de servio e a coloca na fila de servios solicitados, acrescentando o CNPJ do transmissor obtido do certificado digital do transmissor;

(3) O Web Service de recepo de solicitao de servios retorna o recibo da solicitao de servio e a data e hora de recebimento da mensagem no Web Service;

(4) O aplicativo do contribuinte recebe o recibo e o coloca na fila de recibos de servios solicitados e ainda no processados e, caso no exista outra mensagem, encerra a conexo;

(5) No Ambiente Autorizador a solicitao de servios retirada da fila de servios solicitados pelo aplicativo do MDF-e;

(6) O servio solicitado processado pelo aplicativo do MDF-e e o resultado do processamento colocado na fila de servios processados;

(7) O aplicativo do contribuinte retira um recibo da fila de recibos de servios solicitados; (8) O aplicativo do contribuinte envia uma consulta de recibo, iniciando uma conexo com o

Web Service Consulta Recibo (MDFeRetRecepcao); (9) O Web Service Consulta Recibo recebe a mensagem de consulta recibo e localiza o

resultado de processamento da solicitao de servio; (10) O Web Service Consulta Recibo (MDFeRetRecepcao) devolve o resultado do

processamento ao aplicativo contribuinte; (11) O aplicativo do contribuinte recebe a mensagem de resultado do processamento e, caso

no exista outra mensagem, encerra a conexo.

3.3.3. Filas e Mensagens

As filas de mensagens de solicitao de servios so necessrias para a implementao do processamento assncrono das solicitaes de servios. As mensagens de solicitaes de servios no processamento assncrono so armazenadas em uma fila de entrada. Para ilustrar como as filas armazenam as informaes, observe o diagrama a seguir:

A estrutura de um item composta pela rea de controle (identificador) e pela rea de detalhe que contem a mensagem XML. As seguintes informaes so adotadas como atributos de controle:

CNPJ do transmissor: CNPJ da empresa que enviou a mensagem que no necessita estar vinculado ao CNPJ do estabelecimento emissor do MDF-e. Somente o transmissor da mensagem ter acesso ao resultado do processamento das mensagens de solicitao de servios;

Recibo de entrega: Nmero seqencial nico atribudo para a mensagem pelo Ambiente Autorizador. Este atributo identifica a mensagem de solicitao de servios na fila de mensagem;

Data e hora de recebimento da mensagem: Data e hora local do instante de recebimento da mensagem atribuda pelo Ambiente Autorizador. Este atributo importante como

Estrutura de um item da fila:

CNPJ do Transmissor

Nmero do Recibo

data e hora recebimento

cUF XML de Dados

rea de controle rea de mensagem

VersoDados


21

parmetro de desempenho do sistema, eliminao de mensagens, adoo do regime de contingncia, etc. O tempo mdio de resposta calculado com base neste atributo;

cUF: Cdigo da UF (na codificao utilizada pelo IBGE) de origem do emissor do MDF-e informada no campo cUF do elemento mdfeCabecMsg do SOAP Header. O atributo importante para a identificao da UF de origem da mensagem;

versaoDados: Verso do leiaute da mensagem existente na rea de dados. O atributo utilizado para validao de schema XML do XML de dados e verificar a vigncia da verso informada.

Para processar as mensagens de solicitaes de servios, a aplicao do MDF-e ir retirar a mensagem da fila de entrada de acordo com a ordem de chegada, devendo armazenar o resultado do processamento da solicitao de servio em uma fila de sada.

A fila de sada ter a mesma estrutura da fila de entrada, a nica diferena ser no contedo do detalhe da mensagem que contm o resultado do processamento da solicitao de servio em formato XML.

O tempo mdio de resposta que mede a performance do servio de processamento do arquivo calculado com base no tempo decorrido entre o momento de recebimento da mensagem e o momento de armazenamento do resultado do processamento da solicitao de servio na fila de sada. Nota: O termo fila utilizado apenas para designar um repositrio de recibos emitidos. A implementao da fila poder ser feita atravs de Banco de Dados ou qualquer outra forma, sendo transparente ao contribuinte que realizar a consulta do processamento efetuado (processos assncronos).

3.4. Padro de mensagens dos Web Services

As chamadas dos Web Services disponibilizados pelo Ambiente Autorizador e os respectivos resultados do processamento so realizadas atravs das mensagens com o seguinte padro:

cUF cdigo da UF de origem da mensagem. versaoDados - verso do leiaute da estrutura XML informado na rea de dados. rea de Dados estrutura XML varivel definida na documentao do Web Service

acessado.

3.4.1. Informaes de controle e rea de dados das mensagens

As informaes de controle das chamadas dos Web Services so armazenadas no elemento mdfeCabecMsg do SOAP Header e servem para identificar a UF de origem do emissor e a verso do leiaute da estrutura XML armazenada na rea de dados da mensagem:

string string

cUF Estrutura XML definida na documentao do Web Service

Padro de Mensagem de chamada/retorno de Web Service

Elemento mdfeCabecMsg (SOAP Header) rea de dados (SOAP Body)

versaoDados


22

A informao armazenada na rea de dados um documento XML que deve atender o leiaute definido na documentao do Web Service acessado:

xml

3.4.2. Validao da estrutura XML das Mensagens dos Web Services

As informaes so enviadas ou recebidas dos Web Services atravs de mensagens no padro XML definido na documentao de cada Web Service.

As alteraes de leiaute e da estrutura de dados XML realizadas nas mensagens so controladas atravs da atribuio de um nmero de verso para a mensagem.

Um Schema XML uma linguagem que define o contedo do documento XML, descrevendo os seus elementos e a sua organizao, alm de estabelecer regras de preenchimento de contedo e de obrigatoriedade de cada elemento ou grupo de informao.

A validao da estrutura XML da mensagem realizada por um analisador sinttico (parser) que verifica se a mensagem atende as definies e regras de seu Schema XML.

Qualquer divergncia da estrutura XML da mensagem em relao ao seu Schema XML provoca um erro de validao do Schema XML.

A primeira condio para que a mensagem seja validada com sucesso que ela seja submetida ao Schema XML correto.

Assim, o aplicativo do contribuinte deve estar preparado para gerar as mensagens no leiaute em vigor, devendo ainda informar a verso do leiaute da estrutura XML da mensagem no campo versaoDados do elemento mdfeCabecMsg do SOAP Header.

35 1.00

3.4.3. Schemas XML das Mensagens dos Web Services

Toda mudana de leiaute das mensagens dos Web Services implica na atualizao do seu respectivo Schema XML.

A identificao da verso dos Schemas ser realizada com o acrscimo do nmero da verso no nome do arquivo precedida da literal _v, como segue:

mdfe_v1.00.xsd (Schema XML do MDF-e, verso 1.00); tiposGeral_v10.15.xsd (Schema XML dos tipos do MDF-e, verso 10.15).


23

A maioria dos Schemas XML do MDF-e utilizam as definies de tipos bsicos ou tipos complexos que esto definidos em outros Schemas XML (ex.: tiposGeral_v1.00.xsd, etc.), nestes casos, a modificao de verso do Schema bsico ser repercutida no Schema principal.

Por exemplo, o tipo numrico de 15 posies com 2 decimais definido no Schema tiposGeral_v1.01.xsd, caso ocorra alguma modificao na definio deste tipo, todos os Schemas que utilizam este tipo bsico devem ter a sua verso atualizada e as declaraes import ou include devem ser atualizadas com o nome do Schema bsico atualizado.

Exemplo de Schema XML Manifesto Eletrnico de Documentos Fiscais

As modificaes de leiaute das mensagens dos Web Services podem ser causadas por necessidades tcnicas ou em razo da modificao de alguma legislao. As modificaes decorrentes de alterao da legislao devero ser implementadas nos prazos previstos na norma que introduziu a alterao. As modificaes de ordem tcnica sero divulgadas pela Coordenao Tcnica do ENCAT e podero ocorrer sempre que se fizerem necessrias.

3.5. Verso dos Schemas XML

3.5.1. Liberao das verses dos Schemas para o Manifesto Eletrnico de Documentos Fiscais MDF-e

Os schemas vlidos para o MDF-e sero disponibilizados no sitio nacional do Projeto (www.mdfe.fazenda.gov.br), e sero liberados aps autorizao da equipe de Gesto do Projeto formada pelos Lderes dos Projetos nos Estados e representante das Empresas.

A cada nova liberao de schema ser disponibilizado um arquivo compactado contendo o conjunto de schemas a serem utilizados pelas empresas para a gerao dos arquivos XML. Este arquivo ser denominado Pacote de Liberao e ter a mesma numerao da verso do Manual de Orientaes que lhe compatvel. Os pacotes de liberao sero identificados pelas letras PL_MDFe, seguida do nmero da verso do Manual de Orientaes correspondente. Exemplificando: O pacote PL_MDFe_1.00.zip representa o Pacote de Liberao de schemas do MDF-e compatveis com o Manual de Orientaes do Contribuinte verso 1.00.

Os schemas XML das mensagens XML so identificados pelo seu nome, seguido da verso do respectivo schema.

Assim, para o schema XML de enviMDF-e, corresponder um arquivo com a extenso .xsd, que ter o nome de enviMDFe_v9.99.xsd, onde v9.99, corresponde a verso do respectivo schema.

Para identificar quais os schemas que sofreram alterao em um determinado pacote liberado, deve-se comparar o nmero da verso do schema deste pacote com o do pacote anterior.


24

Exemplificando: PACOTE PL_ MDFe_ 1.00.ZIP PL_MDFe_ 1.01.ZIP DATA LIBERAO 01/08/2011 01/11/2011 SCHEMAS enviMDFe_v1.00.xsd enviMDFe _v1.30.xsd

eventoMDFe_v1.00.xsd eventoMDFe_v1.00.xsd tiposGeral_v1.00.xsd tiposGeral _v1.01.xsd

3.5.2. Pacote de Liberao Preliminar

Aps a divulgao de uma nova verso do Manual de Orientaes do Contribuinte, ser divulgado um pacote de liberao preliminar com vigncia limitada at o incio da fase de disponibilizao do ambiente de homologao.

Durante este perodo, os novos Schemas XML sero avaliados e testados para a identificao de eventuais falhas de implementao das alteraes realizadas no Manual de Orientaes do Contribuinte.

O PL preliminar ser identificado com o acrscimo da literal pre na identificao do pacote, como por exemplo: PL_MDFe_1.00pre.zip.

3.5.3. Pacote de Liberao de Homologao e Pacote de liberao definitivo

Para o ambiente de homologao ser divulgado um pacote de liberao de homologao que ser identificado com o acrscimo da literal hom na identificao do pacote, como por exemplo: PL_MDFe_100hom.zip.

A principal caracterstica do pacote de liberao de homologao seu uso estar restrito ao ambiente de homologao por aceitar somente mensagens XML com tpAmb=2-homologao.

O pacote de liberao definitivo ser divulgado na vspera da data de incio da vigncia do ambiente de produo.

3.5.4. Correo de Pacote de Liberao

Em alguma situao pode surgir a necessidade de correo de um Schema XML por um erro de implementao de regra de validao, obrigatoriedade de campo, nome de tag divergente do definido no leiaute da mensagem, que no modifica a estrutura do Schema XML e nem exige a alterao dos aplicativos da SEFAZ ou dos contribuintes. Nesta situao, divulgaremos um novo pacote de liberao com o Schema XML corrigido, sem modificar o nmero da verso do PL para manter a compatibilidade com o Manual de Orientaes do Contribuinte vigente. A identificao dos pacotes mais recentes se dar com o acrscimo de letras minscula do alfabeto, como por exemplo: MDFe_PL_1.00a.ZIP, indicando que se trata da primeira verso corrigida do MDFe_PL_1.00.ZIP

3.5.5. Divulgao de novos Pacotes de Liberao

A divulgao de novos pacotes de liberao ou atualizaes de pacote de liberao ser realizada atravs da publicao de Notas Tcnicas no Portal Nacional do MDF-e (www.mdfe.fazenda.gov.br) com as informaes necessrias para a implementao dos novos pacotes de liberao.


25

3.5.6. Controle de Verso

O controle de verso de cada um dos schemas vlidos do MDF-e compreende uma definio nacional sobre:

Qual a verso vigente (verso mais atualizada)? Quais so as verses anteriores ainda suportadas por todas as SEFAZ? Quais so as verses da parte especfica de cada modal suportadas pela parte genrica?

Este controle de verso permite a adaptao dos sistemas de informtica das empresas participantes do Projeto em diferentes datas. Ou seja, algumas empresas podero estar com uma verso de leiaute mais atualizada, enquanto outras empresas podero ainda estar operando com mensagens em um leiaute anterior.

No esto previstas mudanas freqentes de leiaute de mensagens e as empresas devero ter um prazo razovel para implementar as mudanas necessrias, conforme acordo operacional a ser estabelecido.

Mensagens recebidas com uma verso de leiaute no suportada sero rejeitadas com uma mensagem de erro especfica na verso do leiaute de resposta mais recente em uso.

3.6. Schema XML do MDF-e estrutura genrica e estrutura especfica do modal

A estrutura do Schema XML do MDF-e foi criada como sendo composta de uma parte genrica do schema e uma parte especfica para cada modal, com o objetivo de criar uma maior independncia entre os modais, onde uma alterao no leiaute especfico para um modal no repercuta nos demais.

3.6.1. Parte Genrica

A estrutura genrica a parte que possui os campos (tags) de uso comum a serem utilizados por todos os modais.

Para alcanar este objetivo foi criada no schema XML do MDF-e uma estrutura genrica com um elemento do tipo any que permite a insero do XML especfico do modal, conforme demonstrado na figura a seguir:


26

A verso do schema XML a ser utilizada na parte especfica do modal ser identificada com um atributo de verso prprio (tag versaoModal), conforme figura a seguir:

3.6.2. Parte Especfica para cada Modal

A estrutura especfica a parte que possui os campos (tags) exclusivos do modal.

A parte especfica do schema XML para cada modal ser distribuda no mesmo pacote de liberao em arquivo separado para cada um deles.

A identificao do modal se dar no nome do arquivo, como segue: mdfeModalXXXXXXXXXXXX_v9.99.xsd Onde XXXXXXXXXXXX a identificao do modal, e v9.99 a identificao da verso.

Segue exemplo de nomes de arquivos de schema XML da parte especfica de cada modal:

mdfeModalRodoviario_v1.00.xsd (modal rodovirio, verso 1.00); mdfeModalAereo_v1.00.xsd (modal areo, verso 1.00); mdfeModalFerroviario_v1.00.xsd (modal ferrovirio, verso 1.00); mdfeModalAquaviario_v1.00.xsd (modal aquaviario, verso 1.00).


27

3.6.3. Parte Genrica e Parte Especfica para cada Modal - Verses

Uma verso da parte genrica dever suportar mais de uma verso da parte especfica de cada modal. Normalmente esta relao deve ser de uma para uma (1:1). Apenas em momentos de transio poderemos ter empresas de um modal utilizando uma verso mais atualizada, enquanto outras empresas podero ainda estar operando com um leiaute anterior da parte especfica.

O Ambiente autorizador dever manter na sua aplicao o controle de qual(is) verso(es) da parte especfica (so) suportada(s) pela parte genrica.

3.7. Sistema de Registro de Eventos

O Sistema de Registro de Eventos do MDF-e SRE o modelo genrico que permite o registro de evento de interesse do MDF-e originado a partir do prprio contribuinte ou da administrao tributria.

Um evento o registro de um fato que ocorreu com o documento aps sua autorizao de uso, esse evento pode ou no modificar a situao do documento (por exemplo: cancelamento e encerramento) ou simplesmente dar cincia sobre o trnsito deste documento (por exemplo: registro de passagem).

O servio para registro de eventos ser disponibilizado pelo Ambiente Autorizador atravs de WebService de processamento sncrono e ser propagado para os demais rgos interessados pelo mecanismo de compartilhamento de documentos fiscais eletrnicos. As mensagens de evento utilizaro o padro XML j definido para o projeto MDF-e contendo a assinatura digital do emissor do evento (seja ele contribuinte ou fisco).

O registro do evento requer a existncia do MDF-e vinculado no Ambiente Autorizador, contudo alguns eventos do trnsito podero ser registrados sem que exista o MDF-e na base de dados do autorizador em conformidade com as regras de negcio estabelecidas para este tipo de evento.

O modelo de mensagem do evento dever ter um conjunto mnimo de informaes comuns, a saber: identificao do autor da mensagem; identificao do evento; identificao do MDF-e vinculado; informaes especficas do evento; assinatura digital da mensagem;

O WebService ser nico com a funcionalidade de tratar eventos de forma genrica para facilitar a criao de novos eventos sem a necessidade de criao de novos servios e com poucas alteraes na aplicao de Registro de Eventos do Ambiente Autorizador.

O leiaute da mensagem de Registro de Evento seguir o modelo adotado para o documento MDF-e, contendo uma parte genrica (comum a todos os tipos de evento) e uma parte especfica onde ser inserido o XML correspondente a cada tipo de evento em uma tag do tipo any.

As regras de validao referentes parte genrica dos eventos estaro descritas no item 4.4 deste manual.

As validaes especficas de cada tipo de evento estaro descritas no item 5 deste Manual, originando um novo subitem para cada tipo de evento especificado.

O Pacote de Liberao de schemas do MDF-e dever conter o leiaute da parte genrica do Registro de Eventos e um schema para cada leiaute especfico dos eventos definidos neste manual.


28

3.7.1. Relao dos Tipos de Evento

Os eventos identificados abaixo sero construdos gradativamente pelo ambiente autorizador, assim como novos eventos podero ser identificados e acrescentados nesta tabela em futuras verses deste MOC.

Tipo de Evento Descrio Evento

Tipo de Autor do Evento

Tipo de Meio Informao

MDF-e deve existir?

*** Evento: Empresa Emitente 110111 Cancelamento 1-Empresa Emitente 1=via WS Evento Sim 110112 Encerramento 1-Empresa Emitente 1=via WS Evento Sim

*** Evento: Fisco (implementao futura) 310620 Registro de Passagem 3-Fisco 1=via WS Evento No

Legenda:

Tipo de Autor do Evento: 1 Empresa Emitente; 2 Fisco do Emitente; 3 Fisco; 4 RFB; 5 Outros rgos / Agncia Reguladora; Tipo de Meio de Informao: 1 via WS de Evento; 2 via Extranet MDF-e; 3 via Portal MDF-e; 4 Via integrao sistemas;

3.8. Ambiente Autorizador (SEFAZ Autorizadora Nacional)

Os servios de autorizao sero providos pelo Ambiente Autorizador, que prestar o servio para todos os Estados, mediante Protocolo de Cooperao assinado entre as SEFAZ e/ou entre a SEFAZ e a RFB.

Os servios deste ambiente compreendem os Web Services descritos no Modelo Conceitual da Arquitetura de Comunicao, conforme consta no item 3.1 deste manual.

A responsabilidade sobre o credenciamento e sobre a autorizao para o contribuinte usar os servios do Ambiente Autorizador da SEFAZ de circunscrio do contribuinte atravs do Cadastro Nacional de Emitentes do Ambiente Nacional (CNE).


29

4. Web Services

Os Web Services disponibilizam os servios que sero utilizados pelos aplicativos dos contribuintes. O mecanismo de utilizao dos Web Services segue as seguintes premissas:

a) Ser disponibilizado um Web Service por servio, existindo um mtodo para cada tipo de servio;

b) Para os servios assncronos, o mtodo de envio retorna uma mensagem de confirmao de recebimento da solicitao de servio com o recibo e a data e hora local de recebimento da solicitao ou retorna uma mensagem de erro.

O Ambiente Autorizador se compromete a processar os manifestos recebidos em at 3 minutos em no mnimo 95% do total do volume recebido no perodo de 24 horas. Este indicador de performance ser constantemente avaliado e aperfeioado pelo Comit Gestor e os contribuintes emissores de MDF-e.

A qualquer momento as empresas podero verificar a performance do servio de processamento dos MDF-e, verificando o tempo mdio de resposta do servio nos ltimos 5 minutos.

Em caso de problema tcnico, quando a empresa no conseguir autorizar o MDF-e, ela poder optar por entrar em contingncia, emitindo o DAMDFE, em formulrio comum, para acompanhar o trnsito da mercadoria e autorizar o MDF-e, em at 24 horas, contados da sua impresso.

No recibo de recepo do MDF-e, tambm ser informado o tempo mdio de resposta do servio nos ltimos 5 minutos.

Para os servios sncronos, o envio da solicitao e a obteno do retorno sero realizados na mesma conexo atravs de um nico mtodo.

c) As URLs dos Web Services encontram-se no Anexo IV deste manual e no Ambiente Autorizador (www.mdfe.sefaz.rs.gov.br). Acessando a URL pode ser obtido o WSDL (Web Services Description Language) de cada Web Service.

d) O processo de utilizao dos Web Services sempre iniciado pelo contribuinte enviando uma mensagem nos padres XML e SOAP, atravs do protocolo SSL com autenticao mtua.

e) A ocorrncia de qualquer erro na validao dos dados recebidos interrompe o processo com a disponibilizao de uma mensagem contendo o cdigo e a descrio do erro.


30

4.1. Servio de Recepo do MDF-e

O Servio de Recepo do MDF-e o servio oferecido pelo WS do Ambiente Autorizador para atualizao do repositrio dos MDF-e emitidos por usurios autorizados a emitir CT-e ou NF-e.

A forma de processamento do servio de recepo de MDF-e assncrona. O contribuinte deve transmitir o MDF-e atravs do Web Service de recepo de MDF-e e buscar o resultado do processamento do MDF-e no Web Service de consulta resultado de processamento.

4.1.1. Web Service MDF-e Recepcao

Funo: servio destinado recepo de mensagens de envio de MDF-e.

Processo: assncrono.

Mtodo: mdfeRecepcaoLote

4.1.2. Leiaute Mensagem de Entrada

Entrada: Estrutura XML com o MDF-e

Schema XML: enviMDFe_v9.99.xsd

# Campo Ele Pai Tipo Ocorr Tam. Dec. Descrio/Observao AP01 enviMDFe Raiz - - - - TAG raiz

AP02 versao A AP01 N 1-1 1-4 2 Verso do leiaute

AP03 idLote E AP01 N 1-1 1-15

Identificador de controle do envio do lote. Nmero sequencial autoincremental, de controle correspondente ao identificador nico do lote enviado. A responsabilidade de gerar e controlar esse nmero exclusiva do contribuinte. OBS: Embora no primeiro momento ocorra apenas um MDF-e por lote, esta especificao prev futuras alteraes nessa composio

AP04 MDFe G AP01 Xml 1-1 - MDF-e transmitido (no primeiro momento apenas um MDF-e) seguindo definio do Anexo I Leiaute do MDF-e. O tamanho mximo do arquivo no dever ultrapassar 500k.


31

Schema XML: MDFe_v9.99.xsd

# Campo Ele Pai Tipo Ocorr Tam. Dec. Descrio/Observao

AP01 MDFe Raiz - xml 1-1 - UM MDF-e transmitido seguindo a definio do Anexo I Leiaute do MDF-e.O tamanho mximo do arquivo de 500Kb

AP02 Signature E AP01 xml 1-1 - Assinatura XML do grupo identificado pelo atributo "id"

4.1.3. Leiaute Mensagem de Retorno

Retorno: Estrutura XML com a mensagem do resultado do envio do MDF-e.

Schema XML: retEnviMDFe_v9.99.xsd

# Campo Ele Pai Tipo Ocorr Tam. Dec. Descrio/Observao AR01 retEnviMDFe Raiz - - - - - TAG Raiz da resposta AR02 versao A AR01 N 1-1 1-4 2 Verso do leiaute AR03 tpAmb E AR03 N 1-1 1 Identificao do ambiente:

1- Produo; 2 - Homologao. AR04 cUF E AR03 N 1-1 2 Cdigo da UF que atendeu a solicitao AR06 verAplic E AR03 C 1-1 1-20 Verso do aplicativo que recebeu o lote. AR05 cStat E AR03 N 1-1 3 Cdigo do status da resposta. AR06 xMotivo E AR03 C 1-1 1-255 Descrio literal do status da resposta AR07 infRec G AR01 - 0-1 - Dados do Recibo (S gerado se o arquivo

for aceito) AR08 nRec E AR07 N 1-1 15 Nmero do Recibo gerado pelo Ambiente

Autorizador, composto por duas posies com o Cdigo da UF (codificao do IBGE) onde foi entregue o Arquivo, uma posio para o Tipo de Autorizador e doze posies numricas seqenciais (vide item 6.5)

AR09 dhRecbto E AR07 D 1-1 - Data e Hora do Recebimento Formato = AAAA-MM-DDTHH:MM:SS. Preenchido com data e hora do recebimento do arquivo.

AR10 tMed E AR07 N 1-1 N 1-4 Tempo mdio de resposta do servio (em segundos) dos ltimos 5 minutos (vide item 6.7).Nota: Caso o tempo mdio de resposta fique abaixo de 1 (um) segundo, o tempo ser informado como 1 segundo. Arredondar as fraes de segundos para cima.

As mensagens recebidas com erro geram uma mensagem de erro. Nas demais hipteses ser retornado um recibo com nmero, data, hora local de recebimento e tempo mdio de resposta do servio nos ltimos 5 minutos.

O nmero do recibo gerado pelo servio do Ambiente Autorizador ser a chave de acesso do servio de consulta ao resultado do processamento.


32

4.1.4. Validao do Certificado de Transmisso Validao do Certificado Digital do Transmissor (protocolo SSL)

# Regra de Validao Crtica Msg Efeito

A01

Certificado de Transmissor Invlido: - Certificado de Transmissor inexistente na mensagem - Verso difere 3 - Basic Constraint = true (no pode ser Certificado de AC) - KeyUsage no define Autenticao Cliente

Obrig. 280 Rej.

A02 Validade do Certificado (data incio e data fim) Obrig. 281 Rej.

A03 Verifica a Cadeia de Certificao: - Certificado da AC emissora no cadastrado na SEFAZ - Certificado de AC revogado - Certificado no assinado pela AC emissora do Certificado

Obrig. 283 Rej.

A04 LCR do Certificado de Transmissor - Falta o endereo da LCR (CRL DistributionPoint) - LCR indisponvel - LCR invlida

Obrig. 286 Rej.

A05 Certificado do Transmissor revogado Obrig. 284 Rej. A06 Certificado Raiz difere da ICP-Brasil Obrig. 285 Rej. A07 Falta a extenso de CNPJ no Certificado (OtherName OID=2.16.76.1.3.3) Obrig. 282 Rej.

As validaes de A01, A02, A03, A04 e A05 so realizadas pelo protocolo SSL e no precisam ser implementadas. A validao A06 tambm pode ser realizada pelo protocolo SSL, mas pode falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que no sejam ICP-Brasil no repositrio de certificados digitais do servidor de Web Service da SEFAZ.

4.1.5. Validao Inicial da Mensagem no Web Service Validao Inicial da Mensagem no Web Service

# Regra de Validao Crtica Msg Efeito B01 Tamanho do XML de Dados superior a 500 Kbytes Obrig. 214 Rej. B02 XML de Dados Mal Formado Facult. 243 Rej. B03 Verifica se o Servio de processamento est Paralisado Momentaneamente Obrig. 108 Rej.

B04 Verifica se o Servio de processamento est Paralisado sem Previso Obrig. 109 Rej.

A mensagem ser descartada se o tamanho exceder o limite previsto (500 KB) A aplicao do contribuinte no poder permitir a gerao de mensagem com tamanho superior a 500 KB. Caso isto ocorra, a conexo poder ser interrompida sem mensagem de erro se o controle do tamanho da mensagem for implementado por configuraes do ambiente de rede da SEFAZ (ex.: controle no firewall). No caso do controle de tamanho ser implementado por aplicativo teremos a devoluo da mensagem de erro 214.

O Ambiente Autorizador que mantm o Web Service disponvel, mesmo quando o servio estiver paralisado, dever implementar as verificaes 108 e 109. Estas validaes podero ser dispensadas se o Web Service no ficar disponvel quando o servio estiver paralisado.


33

4.1.6. Validao das informaes de controle da chamada ao Web Service Validao das informaes de controle da chamada ao Web Service

# Regra de Validao Crtica Msg Efeito C01 Elemento mdfeCabecMsg inexistente no SOAP Header Facult. 242 Rej. C02 Campo cUF inexistente no elemento mdfeCabecMsg do SOAP Header Obrig. 409 Rej.

C03 Verificar se a UF informada no cUF atendida pelo WebService Obrig. 410 Rej.

C04 Campo versaoDados inexistente no elemento mdfeCabecMsg do SOAP Header Obrig. 411 Rej.

C05 Verso dos Dados informada superior verso vigente Facult. 238 Rej. C06 Verso dos Dados no suportada Obrig. 239 Rej.

A informao da verso do leiaute do MDF-e e a UF de origem do emissor de MDF-e so informadas no elemento mdfeCabecMsg do SOAP Header (para maiores detalhes vide item 3.4.1).

A aplicao dever validar os campos cUF e versaoDados, rejeitando o arquivo recebido em caso de informaes inexistentes ou invlidas.

O campo versaoDados contm a verso do Schema XML da mensagem contida na rea de dados que deve ser utilizado pelo Servidor de Processamento do MDF-e na validao do Schema XML do arquivo.

4.1.7. Gerao da Resposta com o Recibo

No existindo qualquer problema nas validaes, o aplicativo dever gerar um nmero de recibo (vide item 6.5) e gravar a mensagem juntamente com o CNPJ do transmissor, verso da mensagem e o cdigo da UF de origem.

Aps a gravao da mensagem na fila de entrada, ser retornada uma mensagem de confirmao de recebimento para o transmissor, com as seguintes informaes:

identificao do ambiente; verso do aplicativo; o cdigo 103 e o literal Arquivo recebido com Sucesso; o cdigo da UF que atendeu a solicitao; o nmero do recibo (vide item 6.5), com data, hora e local de recebimento da mensagem; tempo mdio de resposta do servio de processamento dos arquivos nos ltimos 5 minutos

(vide detalhamento da forma de clculo no item 6.7).

Caso ocorra algum problema de validao, o aplicativo dever retornar uma mensagem com as seguintes informaes:

a identificao do ambiente; a verso do aplicativo; o cdigo e a respectiva mensagem de erro (vide a tabela do item 6.1.1); o cdigo da UF que atendeu a solicitao;


34

4.1.8. Validao da rea de Dados

a) Validao de forma da rea de dados

A validao de forma da rea de dados da mensagem realizada com a seguinte regra: Validao da rea de dados da mensagem

# Regra de Validao Crtica Msg Efeito D01 Verifica Schema XML da rea de Dados (parte genrica) Obrig. 215 Rej.

D02 Verifica a existncia de qualquer namespace diverso do namespace padro do MDF-e (http://www.portalfiscal.inf.br/mdfe)

Facult. 598 Rej.

D03 Verifica a existncia de caracteres de edio no incio ou fim da mensagem ou entre as tags Facult. 599 Rej. D04 Verifica o uso de prefixo no namespace Obrig. 404 Rej. D05 XML utiliza codificao diferente de UTF-8 Obrig. 402 Rej.

A existncia de qualquer erro na validao de forma da rea de dados (item 4.1.8 a) implica na rejeio do arquivo.

A validao do schema XML do MDF-e pelo Ambiente Autorizador dever ser feita em duas etapas:

- A primeira etapa deve validar a estrutura genrica do arquivo, submetendo a mensagem contra o schema XML definido para o mesmo. Em caso de erro, retornar o cdigo 225;

- A segunda etapa (realizada mais adiante) deve validar a estrutura especfica do modal. Em caso de erro, retornar o cdigo 580.

b) Validao do Certificado Digital de Assinatura

A seguir ser validada a assinatura digital do MDF-e: Validao do Certificado Digital utilizado na Assinatura Digital


E01

Certificado de Assinatura Invlido: - Certificado de Assinatura inexistente na mensagem - Verso difere 3 - Basic Constraint = true (no pode ser Certificado de AC) - KeyUsage no define Autenticao Cliente

Obrig. 290 Rej.

E02 Validade do Certificado (data incio e data fim) Obrig. 291 Rej. E03 Falta a extenso de CNPJ no Certificado (OtherName OID=2.16.76.1.3.3) Obrig. 292 Rej.

E04 Verifica a Cadeia de Certificao: - Certificado da AC emissora no cadastrado na SEFAZ - Certificado de AC revogado - Certificado no assinado pela AC emissora do Certificado

Obrig. 293 Rej.

E05 LCR do Certificado de Assinatura - Falta o endereo da LCR (CRL DistributionPoint) - Erro no acesso LCR

Obrig. 296 Rej.

E06 Certificado de Assinatura revogado Obrig. 294 Rej. E07 Certificado Raiz difere da ICP-Brasil Obrig. 295 Rej.


35

c) Validao da Assinatura Digital Validao da Assinatura Digital


F01

Assinatura difere do padro do Projeto: - No assinado o atributo ID (falta Reference URI na assinatura) (*validado tambm pelo Schema) - Faltam os Transform Algorithm previstos na assinatura (C14N e Enveloped) Estas validaes so implementadas pelo Schema XML da Signature

Obrig. 298 Rej.

F02 Valor da assinatura (SignatureValue) difere do valor calculado Obrig. 297 Rej.

F03 CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital Obrig. 213 Rej.

d) Validao das regras de negcios do MDF-e Validao das Regras de Negcio de Autorizao do MDF-e


G001 Tipo do ambiente do MDF-e difere do ambiente do Web Service Obrig. 252 Rej.

G002 Cdigo da UF do Emitente difere da UF do Web Service Obrig. 226 Rej.

G003 Sigla da UF do Emitente difere da UF do Web Service Obrig. 247 Rej.

G004 Processo de emisso informado invlido (diferente de 0 ou 3) Obrig. 494 Rej.

G005 Campo "ID" invlido: - Falta literal "MDFe" - Chave de acesso do campo ID difere da concatenao dos campos correspondentes

Obrig. 227 Rej.

G006 Dgito Verificador invlido da Chave de acesso resultante da concatenao dos campos correspondentes Obrig. 253 Rej.

G007 Verificar se a Verso do Modal suportada Obrig 579 Rej

G008 Verifica Schema XML conforme o modal (parte especfica do modal)

Obrig. 580 Rej.

G009 Cdigo Municpio de Carregamento do MDF-e invlido (dgito de controle), vide item 2.1 do Anexo III.

Facult. 455 Rej.

G010 Municpio de Carregamento do MDF-e diverge da UF (verificar se as 2 posies da esquerda do cdigo de municpio que identifica o cdigo da UF esto de acordo com a sigla da UF informada)

Obrig. 456 Rej.

G011 Cdigo Municpio de decarregamento do MDF-e invlido (dgito de controle), vide item 2.1 do Anexo III. Retornar o cdigo do municpio de descarga invlido.

Facult. 611 Rej.

G012

Municpio de descarregamento diverge da UF de descarregamento (verificar se as 2 posies da esquerda do cdigo de municpio de descarregamento que identifica o cdigo da UF de descarga esto de acordo com a sigla da UF informada) Retornar o cdigo do municpio de descarga invlido.

Obrig. 612 Rej.


36

G013 Pelo menos um dos grupos de documentos dever ser informado (CT-e, CT, NF-e e/ou NF)

Obrig. 616 Rej.

G014 Se informado grupo CTe Chave de acesso de um dos CT-e invlida (dgito de controle, zeros ou nulo) Observao: Retornar a chave invlida

Obrig. 601 Rej.

G015 Se informado grupo CTe: - Chave de acesso de CT-e invlida (Ano < 2009 ou Ano maior que Ano corrente) Observao: Retornar a chave invlida

Obrig. 617 Rej.

G016 Se informado grupo CTe: - Chave de acesso de CT-e invlida (Ms = 0 ou Ms > 12) Observao: Retornar a chave invlida

Obrig. 618 Rej.

G017 Se informado grupo CTe: - Chave de acesso de CT-e invlida (CNPJ zerado ou digito invlido) Observao: Retornar a chave invlida

Obrig. 619 Rej.

G018 Se informado grupo CTe: - Chave de acesso de CT-e invlida (modelo diferente de 57) Observao: Retornar a chave invlida

Obrig. 620 Rej.

G019 Se informado grupo CTe: - Chave de acesso de CT-e invlida (numero CT = 0) Observao: Retornar a chave invlida

Obrig. 621 Rej.

G020 Se o tipo de emisso do CT-e informado for diferente de 1 o campo SegCodBarra ter de ser informado Observao: Retornar a chave do CT-e em contingncia

Obrig. 602 Rej.

G021 Se o tipo de emisso do CT-e informado for igual a 1 o campo SegCodBarra no dever ser informado Observao: Retornar a chave do CT-e em contingncia

Obrig. 603 Rej.

G022 Se informado grupo NFe Chave de acesso de uma das NF-e invlida (dgito de controle, zeros ou nulo) Observao: Retornar a chave invlida

Obrig. 604 Rej.

G023 Se informado grupo NFe: - Chave de acesso de NF-e invlida (Ano < 2005 ou Ano maior que Ano corrente) Observao: Retornar a chave invlida

Obrig. 622 Rej.

G024 Se informado grupo NFe: - Chave de acesso de NF-e invlida (Ms = 0 ou Ms > 12) Observao: Retornar a chave invlida

Obrig. 623 Rej.

G025 Se informado grupo NFe: - Chave de acesso de NF-e invlida (CNPJ zerado ou digito invlido) Observao: Retornar a chave invlida

Obrig. 624 Rej.

G026 Se informado grupo NFe: - Chave de acesso de NF-e invlida (modelo diferente de 55) Observao: Retornar a chave invlida

Obrig. 625 Rej.

G027 Se informado grupo NFe: - Chave de acesso de NF-e invlida (numero NF = 0) Observao: Retornar a chave invlida

Obrig. 626 Rej.

G028 Se informado o grupo NF-e, as notas relacionadas devem ter sido emitidas pela mesma empresa emissora do manifesto (CNPJ base).

Obrig. 605 Rej.

G029 Se o tipo de emisso da NF-e informada for diferente de 1 o campo SegCodBarra ter de ser informado Observao: Retornar a chave da NF-e em contingncia

Obrig. 606 Rej.


37

G030 Se o tipo de emisso da NF-e informada for igual a 1 o campo SegCodBarra no dever ser informado Observao: Retornar a chave da NF-e em contingncia

Obrig. 607 Rej.

G031 Se informado o grupo NF, as notas relacionadas devem ter sido emitido pela mesma empresa emissora do manifesto (CNPJ base).

Obrig. 608 Rej.

G032 CNPJ Emitente invlido (dgito controle, zeros ou nulo) Obrig. 207 Rej. G033 IE Emitente no informada (zeros ou nulo) Obrig. 229 Rej.

G034

IE Emitente invlida (erro no dgito de controle) Obs.: Antes da validao, a IE dever ser normalizada, na aplicao da SEFAZ, com o acrscimo de zeros no significativos previstos na definio do formato da IE se necessrio. Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve ser padronizada para 00130000019, com o acrscimo dos zeros no significativos necessrios para a validao do dgito verificador.

Obrig. 209 Rej.

G035 Acessar Cadastro Contribuinte para o Emitente - CNPJ emitente no cadastrado Obrig. 245 Rej.

G036 Emitente no credenciado no CT-e e/ou NF-e Obrig. 203 Rej. G037 IE Emitente no vinculada ao CNPJ Obrig. 231 Rej. G038 Data/Hora de Emisso posterior a Data/Hora de Recebimento (o

Ambiente Autorizador deve considerar a hora local do emissor para a validao).A SEFAZ deve tolerar uma diferena mxima de 5 minutos quando a data/hora de emisso for maior que a data de recebi

manual_mdfe_ v 1.00 - 29.08.2012.pdf

Documents