ANEXO 20 de la Primera Resolución de Modificaciones a la Resolución Miscelánea Fiscal para 2010, publicada el 14 de septiembre de 2010. |
Jueves 23 de septiembre de 2010 |
Al margen un sello con el Escudo Nacional, que dice: Estados Unidos Mexicanos.- Secretaría de Hacienda y Crédito Público.
Modificación al Anexo 20 de la Resolución Miscelánea Fiscal para 2010
Contenido Medios
electrónicos I. Del Comprobante Fiscal Digital: A. Características
técnicas del archivo que contenga el informe mensual de comprobantes fiscales
digitales emitidos B. Estándar
de comprobante fiscal digital C. Generación
de sellos digitales para comprobantes fiscales digitales II. Del Comprobante Fiscal Digital por
Internet: A. Estándar
de comprobante fiscal digital por internet B. Generación
de sellos digitales para comprobantes fiscales digitales por internet C. Estándar
y uso del complemento obligatorio: Timbre Fiscal Digital del SAT D. Estándar
del servicio de cancelación E. Especificación
técnica del código de barras bidimensional III. De los distintos medios de comprobación
digital: A. Estándares
y especificaciones técnicas que deberán cumplir las aplicaciones informáticas
para la generación de claves de criptografía asimétrica a utilizar para Firma
Electrónica Avanzada B. Uso
de la facilidad de nodos opcionales <Complemento> y
<ComplementoConcepto> C. Uso
de la facilidad de ensobretado <Addenda> |
I. Del
Comprobante Fiscal Digital:
A. Características
técnicas del archivo que contenga el informe mensual de comprobantes fiscales
digitales emitidos.
Informe Mensual de Comprobantes Emitidos: Al optar por el esquema de comprobantes fiscales
digitales, el contribuyente está obligado a enviar un informe mensual por los
comprobantes fiscales emitidos, siguiendo para ello las reglas y la secuencia
aquí especificada: Reglas
Generales: 1. El
archivo del informe mensual deberá ser creado con formato de texto simple,
con extensión TXT y contener un registro por reglón. 2. Ninguno
de los atributos que conforman el informe mensual deberá contener el carácter
| (“pipe”) debido a que este será utilizado como carácter de control en la
formación del informe mensual. 3. El
inicio de cada registro dentro del informe mensual se marcará mediante un
carácter | (“pipe” sencillo). 4. Cada
campo individual se encontrará separado de su dato subsiguiente, mediante un
carácter | (“pipe” sencillo). 5. Se
expresará únicamente la información del dato sin expresar el atributo al que
hace referencia. Esto es, si la serie del comprobante es “A” solo se
expresará |A| y nunca |Serie A|. 6. En
el caso de datos con valor Nulo serán expresados en el informe mensual
mediante una cadena de caracteres || (“pipe” doble). 7. El
final de cada registro dentro del informe mensual se marcará mediante un
carácter | (“pipe” sencillo). 8. Para
aquellos contribuyentes que cumplan con lo dispuesto en la regla I.2.5.3. de
la presente Resolución Miscelánea Fiscal, y emitan comprobantes para efectos
fiscales en distintos esquemas al mismo tiempo, deberán generar un archivo de
informe mensual por cada tipo de esquema de comprobación que utilicen. 9. El
nombre del archivo del informe mensual se compone de: a. número
del esquema: ■ 1
para Comprobantes Fiscales Digitales. ■ 2
para Comprobantes solicitados por medio de un establecimiento autorizado. b. RFC
del emisor. ■ XXXX010101000 c. Mes
y Año a ser reportado. ■ mmyyyy Ejemplos
de los nombres de archivo a ser enviados por el esquema que utilice para el
informe mensual, Comprobantes
Fiscales Digitales: 1 +
RFC + MES + AÑO 1XXXX010101000012006.txt Comprobantes solicitados por medio de un
establecimiento autorizado: 2 +
RFC + MES + AÑO 2XXXX010101000012006.txt Ejemplos de registros dentro de un informe
mensual por esquema de comprobación fiscal, Comprobantes
Fiscales Digitales: 1. |PLW750114XP1|PPP|47|200401|24/02/2004
16:16:52|26314.00|0.00|1|
T|00133234881430,00112107659200|24/02/2003,21/09/2002|VERACRUZ,MEXICO
PANTACO| 2. |SWP7501140P1|PPP|48|200460|25/02/2004
16:16:55|00.00||1|E| 12118123499430,13129107634240|24/02/2008,21/09/2009|VERACRUZ,NUEVO
LAREDO| 3. |LOPQ750114X10|PPP|49|200460|24/02/2004
16:16:59|1150.00|150.00|1|I|
00128132456430,00438987651140|24/05/2008,18/09/2008|VERACRUZ,LA PAZ| 4. |ONC750114OG3|ABCDEFGHIÑ|53|200453|29/02/2004
16:20:52|1100.00|100.00|1|E|00988456783430,00459876543020|13/06/2008,21/01/2009| 5. |ONC750114XP1|ABCDEFGHIÑ|530|1202053|29/02/2004
00:00:00|115.00|15.00|0|T|00433675437430,00235876543200|24/02/2003,21/09/2005| 6. |XAXX010101000|ABCDEFGH|53|21453|29/02/2004
00:00:00|2300.00|300.00|1|E|
00545123873430,00345843912200|24/02/2005,21/09/2005|VERACRUZ,MEXICO PANTACO| 7. |XEXX010101000|ACDEGHIÑ|53|22453|29/02/2004
00:00:00|1150.00|150.00|1|T| ||| Comprobantes
solicitados por medio de un establecimiento autorizado: 1. |SWP750114XP1|BBBB|480|2830647|25/02/2004
00:00:00|0.00|0.00|1|E|
00338123451110,00568987651650|14/03/2008,11/04/2008|ENSENADA,TOLUCA| 2. |LOQ750114XP1|BBBB|490|2830647|24/02/2004
00:00:00|582192.00||1|T| 00128654321430,00768876543200,00128765439670|24/06/2008,29/09/2008,
29/07/2008 |VERACRUZ,MEXICO PANTACO,CHIHUAHUA| 3. |DNWS750114XP1|BBBB|1150|2830647|26/02/2004
00:00:00|1150.00|150.00|1|I|00128100234530,01119357123390,14217567123530|24/06/2008, 4. |ONC750114XP1|ABCDEFGHIÑ|530|1202053|29/02/2004
00:00:00|1100.00|100.00|1|T|00323123456430,03312100345784380|24/02/2003,21/09/2002| 5. |ONC750114XP1|ABCDEFGHIÑ|530|1202053|29/02/2004
00:00:00|110.00|10.00|0|I|01247123456430,00128111347510|27/01/2007,15/04/2008|VERACRUZ,LAZARO
CARDENAS| 6. |XAXX010101000|ABCDEFGH|53|21453|29/02/2004
00:00:00|1150.00|150.00|1|I|00128345673430,00328230045200,00458230093670|24/06/2008, 7. |XEXX010101000|ACDEGHIÑ|53|22453|29/02/2004
00:00:00|110.00|10.00|1| E|
00433123984430,00322453212200|24/02/2003,21/09/2002|VERACRUZ,MEXICO PANTACO| Descripción
de los registros: Registros
1: IVA a tasa cero. Registros
2: Exento de IVA. Registros
3: IVA trasladado. Registros
4: Serie hasta 10 caracteres. Registros
5: Para cancelar un Comprobante Fiscal Digital deberá existir un registro
reportado con anterioridad como emitido. Registros
6: Reporte global diario de operaciones con el público en general (aplica
únicamente para efectos del reporte mensual.) Registros
7: Comprobantes para extranjeros que no cuentan con RFC (aplica únicamente
para efectos del informe mensual.) |
Campos del detalle:
No. |
Campo |
Descripción |
Tamaño |
Obligatorio |
1 |
RFC
del cliente |
Clave
del RFC del contribuyente receptor del Comprobante Fiscal. |
12
– 13 caracteres |
SI |
2 |
Serie |
Caracteres
alfabéticos en mayúsculas (incluye la Ñ). Se permite el valor nulo. |
0 – 10 caracteres alfabéticos |
SI |
3 |
Folio del Comprobante Fiscal |
Número
del folio del Comprobante Fiscal. |
Valores
permitidos: del
1 al 2147483647 |
SI |
4 |
Número de Aprobación |
Número
de aprobación otorgado por el Sistema Integral de Comprobantes Fiscales
derivado de la solicitud de rangos o asignación de folios de comprobantes
fiscales. -
Para Comprobantes Fiscales Digitales el formato es yyyy + número del 1 al
2147483647. -
Para Comprobantes Fiscales impresos, número entre 1 y 2147483647 |
14
Máximo para comprobantes fiscales digitales. 10
Máximo para comprobantes impresos. |
SI |
5 |
Fecha
y hora de expedición |
-
Para Comprobantes Fiscales Digitales el formato es: dd/mm/yyyy hh:mm:ss -
En el caso de los comprobantes impresos dd/mm/yyyy 00:00:00 |
19
caracteres de fecha |
SI |
6 |
Monto
de la operación |
Monto
total de la transacción que ampara el comprobante. Valor
numérico igual o mayor a cero. En
caso de que sea mayor a cero debe ser menor o igual a 9999999999.99 |
13
caracteres sin formato. 10 números, un punto decimal y 2 números a la derecha
que indican la fracción. |
SI |
7 |
Monto
del Impuesto |
Monto
del Impuesto al Valor Agregado trasladado. Puede
ser NULO, CERO o un número menor o igual a 9999999999.99 Debe
ser menor que el Monto de la operación (campo 6) |
13
caracteres sin formato. 10 números, un punto decimal y 2 números a la derecha
que indican la fracción. |
SI |
8 |
Estado del comprobante |
0.-
cancelado 1.- vigente |
1
carácter |
SI |
9 |
Efecto de Comprobante |
Utilización
de una letra en Mayúscula. conforme al tipo de comprobante: I para Ingreso E para Egreso T para Traslado |
1
carácter |
SI |
10 |
Pedimento |
Número
de pedimento aduanal. En
caso de contemplarse mas de un pedimento, estos deberán separarse con una
coma (,) dentro del mismo campo. Se
pueden incorporar n pedimentos. 15
posiciones numéricas por cada pedimento. |
De
0 a 300 caracteres |
SI |
11 |
Fecha de Pedimento |
Fecha
de pedimento aduanero, formato dd/mm/aaaa. En
caso de contemplarse mas de un pedimento, se deberá incorporar la fecha de
cada uno de ellos, separándose por una coma (,) dentro del mismo campo. Se
pueden incorporar n fechas de
pedimento, que deberán corresponder cada una a su pedimento. |
De
0 a 350 caracteres. |
SI |
12 |
Aduana |
Nombre
de la Aduana. Si
se incluye más de un pedimento, se deberá contemplar la aduana que
corresponda al pedimento, delimitadas de igual manera por una coma (,) dentro
del mismo campo. |
De
0 a 600 caracteres |
SI |
Nota: Cada campo estará delimitado con un
carácter (pipe) | Ejemplo del
contenido de archivo actual |PLW750114XP1|PPP|47|200401|24/02/2004
16:16:52|26314.00|0.00|1| |SWP7501140P1|PPP|48|200460|25/02/2004
16:16:55|671425.00||1| |LOPQ750114X10|PPP|49|200460|24/02/2004
16:16:59|582192.00|12050.00|1| |ONC750114OG3|ABCDEFGHIÑ|53|200453|29/02/2004
16:20:52|887551.00|88755.00|0| Ejemplo del
contenido con los datos requeridos |PLW750114XP1|PPP|47|200401|24/02/2004
16:16:52|26314.00|0.00|1|I|11233467891430|24/02/2003|VERACRUZ| |SWP7501140P1|PPP|48|200460|25/02/2004
16:16:55|671425.00||1|E|||| |LOPQ750114X10|PPP|49|200460|24/02/2004
16:16:59|1150.00|150.00|1|T|11233234554430,11431234111160|24/02/2003,26/04/2003|VERACRUZ, |ONC750114OG3|ABCDEFGHIÑ|53|200453|29/02/2004
16:20:52|1100.00|110.00|0|I|11233456781430,001221235435130|24/02/2003,21/09/2002|VERACRUZ, |
B. Estándar
de comprobante fiscal digital.
Formato
electrónico único El contribuyente
que opte por emitir comprobantes fiscales digitales deberá generarlos bajo el
siguiente estándar XSD base y los XSD complementarios que requiera, validando
su forma y sintaxis en un archivo con extensión XML, siendo este el único
formato para poder representar y almacenar comprobantes de manera electrónica
o digital. Para poder ser
validado, el comprobante fiscal digital deberá estar referenciado al
namespace del comprobante fiscal digital y referenciar la validación del
mismo a la ruta publicada por el SAT <Comprobante xmlns="http://www.sat.gob.mx/cfd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.sat.gob.mx/cfd http://www.sat.gob.mx/sitio_internet/cfd/2/cfdv2.xsd" …………….. </Comprobante> Adicionalmente a
las reglas de estructura planteadas dentro del presente estándar, el
contribuyente que opte por este mecanismo de generación de comprobantes
deberá sujetarse tanto a las disposiciones fiscales vigentes, como a los
lineamientos técnicos de forma y sintaxis para la generación de archivos XML
especificados por el consorcio w3, establecidos en www.w3.org. En particular se
deberá tener cuidado de que aquellos casos especiales que se presenten en los
valores especificados dentro de los atributos del archivo XML como aquellos
que usan el carácter &, el carácter “, el carácter ‘, el carácter < y
el carácter > que requieren del uso de secuencias de escape. ■ En el caso del & se deberá usar la
secuencia & ■ En el caso del “ se deberá usar la
secuencia " ■ En el caso del < se deberá usar la
secuencia < ■ En el caso del > se deberá usar la
secuencia > ■ En el caso del ‘ se deberá usar la
secuencia ' Ejemplos: Para representar
nombre=“Juan & José & “Niño”” se usará nombre=”Juan & José
& "Niño"” Cabe mencionar
que la especificación XML permite el uso de secuencias de escape para el
manejo de caracteres acentuados y el carácter ñ, sin embargo, dichas
secuencias de escape no son necesarias al expresar el documento XML bajo el
estándar de codificación UTF-8 si fue creado correctamente. |
Estándar Base del XSD Estructura |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Elementos |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Tipos Complejos |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TIPOS SIMPLES
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
C. Generación
de sellos digitales para comprobantes fiscales digitales.
Elementos
utilizados en la generación de Sellos Digitales: ·
Cadena
Original, el elemento a sellar, en este caso de un comprobante fiscal
digital. ·
Certificado
de Sello Digital y su correspondiente clave privada. ·
Algoritmos
de criptografía de clave pública para firma electrónica avanzada. ·
Especificaciones
de conversión de la firma electrónica avanzada a Base 64. Para la generación de sellos digitales se
utiliza criptografía de clave pública aplicada a una cadena original. Criptografía de la Clave Pública La criptografía de Clave Pública se basa
en la generación de una pareja de números muy grandes relacionados
íntimamente entre sí, de tal manera que una operación de encripción sobre un
mensaje tomando como clave de encripción a uno de los dos números, produce
una mensaje alterado en su significado que solo puede ser devuelto a su
estado original mediante la operación de desencripción correspondiente
tomando como clave de desencripción al otro número de la pareja. Uno de estos dos números, expresado en una
estructura de datos que contiene un módulo y un exponente, se conserva
secreta y se le denomina "clave privada", mientras que el otro número
llamado "clave pública", en formato binario y acompañado de
información de identificación del emisor, además de una calificación de
validez por parte de un tercero confiable, se incorpora a un archivo
denominado "certificado de firma electrónica avanzada o certificado para
sellos digitales". El Certificado puede distribuirse
libremente para efectos de intercambio seguro de información y para ofrecer
pruebas de autoría de archivos electrónicos o acuerdo con su contenido
mediante el proceso denominado "firma electrónica avanzada ", que
consiste en una característica observable de un mensaje, verificable por
cualquiera con acceso al certificado digital del emisor, que sirve para
implementar servicios de seguridad para garantizar: La integridad (facilidad
para detectar si un mensaje firmado ha sido alterado), autenticidad,
certidumbre de origen (facilidad para determinar qué persona es el autor de
la firma y valida el contenido del mensaje) y no repudiación del mensaje
firmado (capacidad de impedir que el autor de la firma niegue haber firmado
el mensaje). Estos servicios de seguridad proporcionan
las siguientes características a un mensaje con firma electrónica avanzada: ·
Es
infalsificable. ·
La
firma electrónica avanzada no es reciclable (es única por mensaje). ·
Un
mensaje con firma electrónica avanzada alterado, es detectable. ·
Un
mensaje con firma electrónica avanzada, no puede ser repudiado. Los certificados de sello digital se
generan de manera idéntica a la firma electrónica avanzada y al igual que las
firmas electrónicas avanzadas el propósito del sello digital es emitir
comprobantes fiscales con autenticidad, integridad, verificables y no
repudiables por el emisor. Para ello bastará tener acceso al mensaje original
o cadena original, al sello digital y al certificado de sello digital del
emisor. Al ser el certificado de sello digital
idéntico en su generación a una firma electrónica avanzada, proporciona los
mismos servicios de seguridad y hereda las características de las firmas
digitales. Por consecuencia un comprobante fiscal
digital sellado digitalmente por el contribuyente tiene las siguientes
características: ·
Es
infalsificable. ·
El
sello digital de un comprobante fiscal digital no es reciclable (es único por
documento). ·
Una
cadena original de un comprobante fiscal digital sellada digitalmente, que
hubiese sido alterada es detectable. ·
Una
cadena original de un comprobante fiscal digital sellada digitalmente no
puede ser repudiada. Los algoritmos utilizados en la generación
de un sello digital son los siguientes: SHA-1, que es una función hash (digestión,
picadillo o resumen) de un solo sentido tal que para cualquier entrada
produce una salida compleja de 160 bits (20 bytes) denominada
"digestión". RSAPrivateEncrypt, que utiliza la clave privada
del emisor para encriptar la digestión del mensaje. RSAPublicDecrypt, que utiliza la clave pública
del emisor para desencriptar la digestión del mensaje. A manera de referencia y para obtener
información adicional, se recomienda consultar el sitio de comprobantes
fiscales digitales que se encuentra dentro del portal del SAT: www.sat.gob.mx Cadena Original Se entiende como cadena
original, a la secuencia de datos formada con la información contenida dentro
del comprobante fiscal digital, establecida en el Rubro C “Estándar de
comprobante fiscal digital extensible” de este anexo. Siguiendo para ello las
reglas y la secuencia aquí especificadas: Reglas Generales: 1. Ninguno de los atributos que conforman al comprobante fiscal
digital deberá contener el carácter | (“pipe”) debido a que este será
utilizado como carácter de control en la formación de la cadena original. 2. El inicio de la cadena original se encuentra marcado mediante
una secuencia de caracteres || (doble “pipe”). 3. Se expresará únicamente la información del dato sin expresar
el atributo al que hace referencia. Esto es, si la serie del comprobante es
la “A” solo se expresará |A| y nunca |Serie A|. 4. Cada dato individual se encontrará separado de su dato
subsiguiente, en caso de existir, mediante un carácter | (“pipe” sencillo). 5. Los espacios en blanco que se presenten dentro de la cadena
original serán tratados de la siguiente manera: a. Se deberán remplazar todos los tabuladores, retornos de carro
y saltos de línea por espacios en blanco. b. Acto seguido se elimina cualquier carácter en blanco al
principio y al final de cada separador | (“pipe” sencillo). c. Finalmente, toda secuencia de caracteres en blanco
intermedias se sustituyen por un único carácter en blanco. 6. Los datos opcionales no expresados, no aparecerán en la
cadena original y no tendrán delimitador alguno. 7. El final de la cadena original será expresado mediante una
cadena de caracteres || (doble “pipe”). 8. Toda la cadena de original se expresará en el formato de
codificación UTF-8. 9. El nodo o nodos adicionales <ComplementoConcepto> se
integraran a la cadena original como se indica en la secuencia de formación
en su numeral 10, respetando la secuencia de formación y número de orden del
ComplemetoConcepto. 10. El nodo o nodos adicionales <Complemento> se integraran
al final de la cadena original respetando la secuencia de formación para cada
complemento y número de orden del Complemento. Secuencia
de Formación: La
secuencia de formación será siempre en el orden que se expresa a
continuación, tomando en cuenta las reglas generales expresadas en el párrafo
anterior. 1. Información del nodo Comprobante a. version b. serie c. folio d. fecha e. noAprobacion f. anoAprobacion g. tipoDeComprobante h. formaDePago i. condicionesDePago j. subTotal k. descuento l. total 2. Información del nodo Emisor a. rfc b. nombre 3. Información del nodo DomicilioFiscal a. calle b. noExterior c. noInterior d. colonia e. localidad f. referencia g. municipio h. estado i. pais j. codigoPostal 4. Información del nodo ExpedidoEn a. calle b. noExterior c. noInterior d. colonia e. localidad f. referencia g. municipio h. estado i. pais j. codigoPostal 5. Información del nodo Receptor a. rfc b. nombre 6. Información del nodo Domicilio a. calle b. noExterior c. noInterior d. colonia e. localidad f. referencia g. municipio h. estado i. pais j. codigoPostal 7. Información de cada nodo Concepto nota: esta secuencia
deberá ser repetida por cada nodo Concepto relacionado a. cantidad b. unidad c. noIdentificacion d. descripcion e. valorUnitario f. importe g. InformacionAduanera i. numero ii. fecha iii. aduana h. Información del nodo CuentaPredial i. numero 8. Información del nodo ComplementoConcepto
de acuerdo con lo expresado en el Rubro III.B. 9. Información de cada nodo Retencion nota: esta secuencia a,
b, deberá ser repetida por cada nodo Retención relacionado, el total de
impuestos retenidos no se repite. a. impuesto b. importe c. totalImpuestosRetenidos 10. Información de cada nodo Traslado nota: esta secuencia a,
b, deberá ser repetida por cada nodo Traslado relacionado, el total de
impuestos trasladados no se repite. a. Impuesto b. tasa c. importe d. totalImpuestosTrasladados 11. Información del nodo Complemento de
acuerdo con lo expresado en el Rubro III.B. Generación del Sello Digital Para toda cadena original a ser sellada
digitalmente, la secuencia de algoritmos a aplicar es la siguiente: I.- Aplicar el método de digestión SHA-1
cadena original a sellar incluyendo los nodos Complementarios. Este
procedimiento genera una salida de 160 bits (20 bytes) para todo mensaje. La
posibilidad de encontrar dos mensajes distintos que produzcan una misma
salida es de 1 en 2160, y por lo tanto en esta posibilidad se basa
la inalterabilidad del sello, así como su no reutilización. Es de hecho una
medida de la integridad del mensaje sellado, pues toda alteración del mismo
provocará una digestión totalmente diferente, por lo que no se podrá
autentificar el mensaje. SHA-1 no requiere semilla alguna. El
algoritmo cambia su estado de bloque en bloque de acuerdo a la entrada
previa. II.- Con la clave privada correspondiente
al certificado digital del emisor del mensaje y del sello digital, encriptar
la digestión del mensaje obtenida en el paso I utilizando para ello el
algoritmo de encripción RSA. Nota: La mayor parte del software
comercial puede generar los pasos I y II invocando una sola función y
especificando la constante simbólica "RSAwithSHA1Encryption". En el
SAT este procedimiento se hace en pasos separados, lo cual es totalmente
equivalente. Es importante resaltar que prácticamente todo el software
criptográfico comercial incluye APIs o expone métodos en sus productos que
permiten implementar la secuencia de algoritmos aquí descrita. La clave
privada solo debe mantenerse en memoria durante la llamada a la función de
encripción; inmediatamente después de su uso debe ser eliminada de su
registro de memoria mediante la sobre escritura de secuencias binarias
alternadas de "unos" y "ceros". III.- El resultado será una cadena binaria
que no necesariamente consta de caracteres imprimibles, por lo que deberá
traducirse a una cadena que sí conste solamente de tales caracteres. Para
ello se utilizará el modo de expresión de secuencias de bytes denominado
"Base 64", que consiste en la asociación de cada 6 bits de la
secuencia a un elemento de un "alfabeto" que consta de 64
caracteres imprimibles. Puesto que con 6 bits se pueden expresar los números
del 0 al 63, si a cada uno de estos valores se le asocia un elemento del
alfabeto se garantiza que todo byte de la secuencia original puede ser
mapeado a un elemento del alfabeto Base 64, y los dos bits restantes formarán
parte del siguiente elemento a mapear. Este mecanismo de expresión de cadenas
binarias produce un incremento de 25% en el tamaño de las cadenas imprimibles
respecto de la original. La codificación en base 64, así como su
decodificación, se hará tomando los bloques a procesar en el sentido de su
lectura, es decir, de izquierda a derecha. El alfabeto a utilizar se expresa en el
siguiente catálogo:
Por tanto, los caracteres utilizados en el
alfabeto de Base 64 son: A, B, C, D, E, F, G, H, I, J, K, L, M, N,
O, P, Q, R, S, T, U, V, W, X, Y, Z, a, b, c, d, e, f, g, h, i, j, k, l, m, n,
o, p, q, r, s, t, u, v, w, x, y, z, 0, 1, 2, 3,4, 5, 6, 7, 8, 9, +, / Y en el orden descrito les corresponden
los índices del 0 al 63 en un arreglo de 64 elementos. Para traducir de
binario a Base 64, se examina la secuencia binaria evaluando 6 bits a la vez;
si el valor de los primeros 6 bits es 0, entonces se imprime la letra A; si
es 1, entonces se imprime la letra B y así sucesivamente hasta completar la
evaluación de todos los bits de la secuencia binaria evaluados La función inversa consiste en reconstruir
la secuencia binaria original a partir de la cadena imprimible que consta de
los elementos del alfabeto de Base 64. Para ello se toman 4 caracteres a la
vez de la cadena imprimible y sus valores son convertidos en los de los tres
caracteres binarios correspondientes Ejemplo de Sello digital: GqDiRrea6+E2wQhqOCVzwME4866yVEME/8PD1S1g6AV48D8VrLhKUDq0Sjqnp9IwfMAbX0ggwUCLRKa+Hg5q8aYhya63If2HVqH1sA08poer080P1J6Z+BwTrQkhcb5Jw8jENXoErkFE8qdOcIdFFAuZPVT+9mkTb0Xn5Emu5U8= |
II. Del Comprobante Fiscal Digital por
Internet:
A. Estándar
de Comprobante Fiscal Digital por Internet.
Formato electrónico único El contribuyente que opte
por emitir comprobantes fiscales digitales por Internet deberá generarlos
bajo el siguiente estándar XSD base y los XSD complementarios que requiera,
validando su forma y sintaxis en un archivo con extensión XML, siendo este el
único formato para poder representar y almacenar comprobantes de manera
electrónica o digital. Para poder ser validado, el
comprobante fiscal digital por Internet deberá estar referenciado al
namespace del comprobante fiscal digital por Internet y referenciar la
validación del mismo a la ruta publicada por el SAT en donde se encuentra el
esquema XSD objeto de la presente sección
(http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv3.xsd) de la siguiente
manera: <cfdi:Comprobante Xmlns:cfdi="http://www.sat.gob.mx/cfd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.sat.gob.mx/cfd http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv3.xsd" …………….. </cfdi:Comprobante> Adicionalmente a las reglas
de estructura planteadas dentro del presente estándar, el contribuyente que
opte por este mecanismo de generación de comprobantes deberá sujetarse tanto
a las disposiciones fiscales vigentes, como a los lineamientos técnicos de
forma y sintaxis para la generación de archivos XML especificados por el
consorcio w3, establecidos en www.w3.org. En particular se deberá
tener cuidado de que aquellos casos especiales que se presenten en los
valores especificados dentro de los atributos del archivo XML como aquellos
que usan el carácter &, el carácter ■ En el caso del & se deberá usar la
secuencia & ■ En el caso del “ se deberá usar la
secuencia " ■ En el caso del < se deberá usar la
secuencia < ■ En el caso del > se deberá usar la
secuencia > ■ En el caso del ‘ se deberá usar la
secuencia ' Ejemplos: Para representar
nombre=“Juan & José & “Niño”” se usará nombre=”Juan & José
& "Niño"” Cabe mencionar que la
especificación XML permite el uso de secuencias de escape para el manejo de
caracteres acentuados y el carácter ñ, sin embargo, dichas secuencias de
escape no son necesarias al expresar el documento XML bajo el estándar de
codificación UTF-8 si fue creado correctamente. |
Estandar base del
XSD
|
B. Generación
de sellos digitales para Comprobantes Fiscales Digitalespor Internet.
Elementos
utilizados en la generación de Sellos Digitales: ·
Cadena
Original, el elemento a sellar, en este caso de un comprobante fiscal digital
por Internet. ·
Certificado
de Sello Digital y su correspondiente clave privada. ·
Algoritmos
de criptografía de clave pública para firma electrónica avanzada. ·
Especificaciones
de conversión de la firma electrónica avanzada a Base 64. Para la generación de sellos digitales se
utiliza criptografía de clave pública aplicada a una cadena original. Criptografía de la Clave Pública La criptografía de Clave Pública se basa
en la generación de una pareja de números muy grandes relacionados
íntimamente entre sí, de tal manera que una operación de encripción sobre un
mensaje tomando como clave de encripción a uno de los dos números, produce un
mensaje alterado en su significado que solo puede ser devuelto a su estado
original mediante la operación de desencripción correspondiente tomando como
clave de desencripción al otro número de la pareja. Uno de estos dos números, expresado en una
estructura de datos que contiene un módulo y un exponente, se conserva
secreta y se le denomina "clave privada", mientras que el otro
número llamado "clave pública", en formato binario y acompañado de
información de identificación del emisor, además de una calificación de
validez por parte de un tercero confiable, se incorpora a un archivo denominado
"certificado de firma electrónica avanzada o certificado para sellos
digitales". El
Certificado puede distribuirse libremente para efectos de intercambio seguro
de información y para ofrecer pruebas de autoría de archivos electrónicos o
acuerdo con su contenido mediante el proceso denominado "firma
electrónica avanzada ", que consiste en una característica observable de
un mensaje, verificable por cualquiera con acceso al certificado digital del
emisor, que sirve para implementar servicios de seguridad para garantizar: La
integridad (facilidad para detectar si un mensaje firmado ha sido alterado),
autenticidad, certidumbre de origen (facilidad para determinar qué persona es
el autor de la firma y valida el contenido del mensaje) y no repudiación del
mensaje firmado (capacidad de impedir que el autor de la firma niegue haber
firmado el mensaje). Estos servicios de seguridad proporcionan
las siguientes características a un mensaje con firma electrónica avanzada: ·
Es
infalsificable. ·
La
firma electrónica avanzada no es reciclable (es única por mensaje). ·
Un
mensaje con firma electrónica avanzada alterado, es detectable. ·
Un
mensaje con firma electrónica avanzada, no puede ser repudiado. Los certificados de sello digital se
generan de manera idéntica a la firma electrónica avanzada y al igual que las
firmas electrónicas avanzadas el propósito del sello digital es emitir
comprobantes fiscales con autenticidad, integridad, verificables y no
repudiables por el emisor. Para ello bastará tener acceso al mensaje original
o cadena original, al sello digital y al certificado de sello digital del
emisor. Al ser el certificado de sello digital
idéntico en su generación a una firma electrónica avanzada, proporciona los
mismos servicios de seguridad y hereda las características de las firmas
digitales. Por consecuencia un comprobante fiscal
digital sellado digitalmente por el contribuyente tiene las siguientes
características: ·
Es
infalsificable. ·
El
sello digital de un comprobante fiscal digital no es reciclable (es único por
documento). ·
Una
cadena original de un comprobante fiscal digital sellada digitalmente, que
hubiese sido alterada es detectable. ·
Una
cadena original de un comprobante fiscal digital sellada digitalmente no
puede ser repudiada. Los algoritmos utilizados en la generación
de un sello digital son los siguientes: SHA-1, que es una función hash (digestión,
picadillo o resumen) de un solo sentido tal que para cualquier entrada
produce una salida compleja de 160 bits (20 bytes) denominada
"digestión". RSAPrivateEncrypt, que utiliza la clave privada
del emisor para encriptar la digestión del mensaje. RSAPublicDecrypt, que utiliza la clave pública
del emisor para desencriptar la digestión del mensaje. A manera de referencia y para obtener información adicional, se
recomienda consultar el sitio de comprobantes fiscales digitales que se
encuentra dentro del portal del SAT: www.sat.gob.mx Cadena Original Se entiende como cadena original, a la
secuencia de datos formada con la información contenida dentro del
comprobante fiscal digital por internet, establecida en el Rubro II.A
“Estándar de comprobante fiscal digital por internet” de este anexo.
Siguiendo para ello las reglas y la secuencia aquí especificadas: Reglas Generales: 1. Ninguno
de los atributos que conforman al comprobante fiscal digital deberá contener
el carácter | (“pipe”) debido a que este será utilizado como carácter de
control en la formación de la cadena original. 2. El
inicio de la cadena original se encuentra marcado mediante una secuencia de
caracteres || (doble “pipe”). 3. Se
expresará únicamente la información del dato sin expresar el atributo al que
hace referencia. Esto es, si la serie del comprobante es la “A” solo se
expresará |A| y nunca |Serie A|. 4. Cada
dato individual se encontrará separado de su dato subsiguiente, en caso de
existir, mediante un carácter | (“pipe” sencillo). 5. Los
espacios en blanco que se presenten dentro de la cadena original serán
tratados de la siguiente manera: a. Se
deberán remplazar todos los tabuladores, retornos de carro y saltos de línea
por espacios en blanco. b. Acto
seguido se elimina cualquier carácter en blanco al principio y al final de
cada separador | (“pipe” sencillo). c. Finalmente,
toda secuencia de caracteres en blanco intermedias se sustituyen por un único
carácter en blanco. 6. Los datos opcionales no
expresados, no aparecerán en la cadena original y no tendrán delimitador
alguno. 7. El final de la cadena
original será expresado mediante una cadena de caracteres || (doble “pipe”). 8. Toda la cadena de
original se expresará en el formato de codificación UTF-8. 9. El nodo o nodos
adicionales <ComplementoConcepto> se integrarán a la cadena original
como se indica en la secuencia de formación en su numeral 10, respetando la
secuencia de formación y número de orden del ComplemetoConcepto. 10. El nodo o nodos
adicionales <Complemento> se integraran al final de la cadena original
respetando la secuencia de formación para cada complemento y número de orden
del Complemento. 11. El nodo Timbre Fiscal
Digital del SAT será integrado posterior a la validación realizada por un
proveedor autorizado por el SAT que forma parte de la Certificación Digital
del SAT. Dicho nodo no se integrará a la formación de la cadena original del
CFDI, las reglas de conformación de la cadena original del nodo se describen
en el rubro II.C del presente anexo. Secuencia de Formación: La secuencia de formación será siempre en
el orden que se expresa a continuación, tomando en cuenta las reglas
generales expresadas en el párrafo anterior. 1. Información del nodo Comprobante a. version b. fecha c. tipoDeComprobante d. formaDePago e. condicionesDePago f. subTotal g. descuento h. TipoCambio i. Moneda j. total 2. Información del nodo Emisor a. rfc b. nombre 3. Información del nodo DomicilioFiscal a. calle b. noExterior c. noInterior d. colonia e. localidad f. referencia g. municipio h. estado i. pais j. codigoPostal 4. Información del nodo ExpedidoEn a. calle b. noExterior c. noInterior d. colonia e. localidad f. referencia g. municipio h. estado i. pais j. codigoPostal 5. Información del nodo Receptor a. rfc b. nombre 6. Información del nodo Domicilio a. calle b. noExterior c. noInterior d. colonia e. localidad f. referencia g. municipio h. estado i. pais j. codigoPostal 7. Información de cada nodo Concepto nota: esta secuencia deberá ser
repetida por cada nodo Concepto relacionado a. cantidad b. unidad c. noIdentificacion d. descripcion e. valorUnitario f. importe g. InformacionAduanera i. numero ii. fecha iii. aduana h. Información del nodo CuentaPredial i. numero 8. Información del nodo ComplementoConcepto
de acuerdo con lo expresado en el Rubro III.B. 9. Información de cada nodo Retencion nota: esta secuencia a, b, deberá
ser repetida por cada nodo Retención relacionado, el total de impuestos
retenidos no se repite. a. impuesto b. importe c. totalImpuestosRetenidos 10. Información de cada nodo Traslado nota: esta secuencia a, b, deberá
ser repetida por cada nodo Traslado relacionado, el total de impuestos
trasladados no se repite. a. Impuesto b. tasa c. importe d. totalImpuestosTrasladados 11. Información del nodo Complemento de
acuerdo con lo expresado en el Rubro III.B. Generación del Sello Digital Para toda cadena original a
ser sellada digitalmente, la secuencia de algoritmos a aplicar es la
siguiente: I.- Aplicar el método de
digestión SHA-1 a la cadena original a sellar incluyendo los nodos
Complementarios. Este procedimiento genera una salida de 160 bits (20 bytes)
para todo mensaje. La posibilidad de encontrar dos mensajes distintos que
produzcan una misma salida es de 1 en 2160, y por lo tanto en esta posibilidad se basa la inalterabilidad del
sello, así como su no reutilización. Es de hecho una medida de la integridad
del mensaje sellado, pues toda alteración del mismo provocará una digestión
totalmente diferente, por lo que no se podrá autentificar el mensaje. SHA-1 no requiere semilla
alguna. El algoritmo cambia su estado de bloque en bloque de acuerdo a la
entrada previa. II.- Con la clave privada correspondiente
al certificado digital del emisor del mensaje y del sello digital, encriptar
la digestión del mensaje obtenida en el paso I utilizando para ello el
algoritmo de encripción RSA. Nota: La mayor parte del software
comercial podría generar los pasos I y II invocando una sola función y
especificando una constante simbólica. En el SAT este procedimiento se hace
en pasos separados, lo cual es totalmente equivalente. Es importante resaltar
que prácticamente todo el software criptográfico comercial incluye APIs o
expone métodos en sus productos que permiten implementar la secuencia de
algoritmos aquí descrita. La clave privada solo debe mantenerse en memoria
durante la llamada a la función de encripción; inmediatamente después de su
uso debe ser eliminada de su registro de memoria mediante la sobre escritura
de secuencias binarias alternadas de "unos" y "ceros". III.- El resultado será una cadena binaria
que no necesariamente consta de caracteres imprimibles, por lo que deberá
traducirse a una cadena que sí conste solamente de tales caracteres. Para
ello se utilizará el modo de expresión de secuencias de bytes denominado
"Base 64", que consiste en la asociación de cada 6 bits de la
secuencia a un elemento de un "alfabeto" que consta de 64
caracteres imprimibles. Puesto que con 6 bits se pueden expresar los números
del 0 al 63, si a cada uno de estos valores se le asocia un elemento del
alfabeto se garantiza que todo byte de la secuencia original puede ser
mapeado a un elemento del alfabeto Base 64, y los dos bits restantes formarán
parte del siguiente elemento a mapear. Este mecanismo de expresión de cadenas
binarias produce un incremento de 25% en el tamaño de las cadenas imprimibles
respecto de la original. La codificación en base 64, así como su
decodificación, se hará tomando los bloques a procesar en el sentido de su
lectura, es decir, de izquierda a derecha. El alfabeto a utilizar se expresa en el siguiente catálogo:
Por tanto, los caracteres utilizados en el
alfabeto de Base 64 son: A, B, C, D, E, F, G, H, I, J, K, L, M, N,
O, P, Q, R, S, T, U, V, W, X, Y, Z, a, b, c, d, e, f, g, h, i, j, k, l, m, n,
o, p, q, r, s, t, u, v, w, x, y, z, 0, 1, 2, 3,4, 5, 6, 7, 8, 9, +, / Y en el orden descrito les corresponden
los índices del 0 al 63 en un arreglo de 64 elementos. Para traducir de
binario a Base 64, se examina la secuencia binaria evaluando 6 bits a la vez;
si el valor de los primeros 6 bits es 0, entonces se imprime la letra A; si
es 1, entonces se imprime la letra B y así sucesivamente hasta completar la
evaluación de todos los bits de la secuencia binaria evaluados La función inversa consiste en reconstruir
la secuencia binaria original a partir de la cadena imprimible que consta de
los elementos del alfabeto de Base 64. Para ello se toman 4 caracteres a la
vez de la cadena imprimible y sus valores son convertidos en los de los tres
caracteres binarios correspondientes Ejemplo de Sello digital: GqDiRrea6+E2wQhqOCVzwME4866yVEME/8PD1S1g6AV48D8VrLhKUDq0Sjqnp9IwfMAbX0ggwUCLRKa+Hg5q8aYhya63If2HVqH1sA08poer080P1J6Z+BwTrQkhcb5Jw8jENXoErkFE8qdOcIdFFAuZPVT+9mkTb0Xn5Emu5U8= |
C. Estándar
y uso del complemento obligatorio Timbre Fiscal Digital del SAT
Estructura |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Elementos |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Codigo
Fuente |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<?xml
version="1.0" encoding="UTF-8"?> <xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tfd="http://www.sat.gob.mx/TimbreFiscalDigital"
targetNamespace="http://www.sat.gob.mx/TimbreFiscalDigital"
elementFormDefault="qualified"
attributeFormDefault="unqualified"> <xs:element
name="TimbreFiscalDigital"> <xs:annotation> <xs:documentation>Complemento requerido
para el Timbrado Fiscal Digital que da validez a un Comprobante Fiscal
Digital.</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute
name="version" use="required" fixed="1.0"> <xs:annotation> <xs:documentation>Atributo requerido para la expresión de la
versión del estándar del Timbre Fiscal Digital</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute
name="UUID" use="required" id="UUID"> <xs:annotation> <xs:documentation>Atributo requerido para expresar los 36
caracteres del UUID de la transacción de timbrado</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction
base="xs:string"> <xs:whiteSpace
value="collapse"/> <xs:length
value="36"/> <xs:pattern
value="[a-f0-9A-F]{8}-[a-f0-9A-F]{4}-[a-f0-9A-F]{4}-[a-f0-9A-F]{4}-[a-f0-9A-F]{12}"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute
name="FechaTimbrado" use="required"> <xs:annotation> <xs:documentation>Atributo requerido para expresar el número de
serie del certificado del SAT usado para el Timbre </xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction
base="xs:dateTime"> <xs:whiteSpace
value="collapse"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute
name="selloCFD" use="required"> <xs:annotation> <xs:documentation>Atributo requerido para contener el sello
digital del comprobante fiscal, que será timbrado. El sello deberá ser
expresado cómo una cadena de texto en formato Base
64.</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction
base="xs:string"> <xs:whiteSpace
value="collapse"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute
name="noCertificadoSAT" use="required"> <xs:annotation> <xs:documentation>Atributo requerido para expresar el número de
serie del certificado del SAT usado para el Timbre</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction
base="xs:string"> <xs:whiteSpace
value="collapse"/> <xs:length
value="20"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute
name="selloSAT" use="required"> <xs:annotation> <xs:documentation>Atributo requerido para contener el sello
digital del Timbre Fiscal Digital, al que hacen referencia las reglas de
resolución miscelánea aplicable. El sello deberá ser expresado cómo una
cadena de texto en formato </xs:annotation> <xs:simpleType> <xs:restriction
base="xs:string"> <xs:whiteSpace
value="collapse"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> </xs:schema> |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Secuencia de
Elementos a Integrar en la Cadena Original del Timbre Fiscal Digital del SAT. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Cadena
Original Se
entiende como cadena original, a la secuencia de datos formada con la
información contenida dentro del Timbre fiscal digital del SAT. Siguiendo
para ello las reglas y la secuencia aquí especificadas: Reglas
Generales: 1.
Ninguno
de los atributos que conforman al comprobante fiscal digital deberá contener
el carácter | (“pipe”) debido a que este será utilizado como carácter de
control en la formación de la cadena original. 2.
La
cadena original resultante del complemento será integrada a la cadena original
del comprobante de acuerdo con lo especificado en el anexo 20 de la
Resolución Miscelánea Fiscal para 2010. 3.
Se
expresará únicamente la información del dato sin expresar el atributo al que
hace referencia. Esto es, si el atributo tipoOperación tiene el valor
“monedero” solo se expresará |monedero| y nunca |tipoOperacion monedero|. 4.
Cada
dato individual se encontrará separado de su dato anterior, en caso de
existir, mediante un carácter | (“pipe” sencillo). 5.
Los
espacios en blanco que se presenten dentro de la cadena original serán
tratados de la siguiente manera: a.
Se
deberán remplazar todos los tabuladores, retornos de carro y saltos de línea
por espacios en blanco. b.
Acto
seguido se elimina cualquier carácter en blanco al principio y al final de
cada separador | (“pipe” sencillo). c.
Finalmente,
toda secuencia de caracteres en blanco intermedias se sustituyen por un único
carácter en blanco. 6.
Los
datos opcionales, cuando no existan, no aparecerán expresados en la cadena
original y no tendrán delimitador alguno. 7.
Toda
la cadena de original se expresará en el formato de codificación UTF-8. Secuencia
de Formación La
secuencia de formación será siempre en el orden que se expresa a
continuación, tomando en cuenta las reglas generales expresadas en el párrafo
anterior. a.
Atributos
del elemento raíz TimbreFiscalDigital 1.
version 2.
UUID 3.
FechaTimbrado 4.
selloCFD 5.
noCertificadoSAT Ejemplo
de cadena original de un timbre: ||1.0|ad662d33-6934-459c-a128-bdf0393e0f44|2001-12-17T09:30:47Z|iYyIk1MtEPzTxY3h57kYJnEXNae9lvLMgAq3jGMePsDtEOF6XLWbrV2GL/2TX00vP2+YsPN+5UmyRdzMLZGEfESiNQF9fotNbtA487dWnCf5pUu0ikVpgHvpY7YoA4lB1D/JWc+zntkgW+Ig49WnlKyXi0LOlBOVuxckDb7EAx4=|12345678901234
567890|| Nota:
El atributo selloCFD será el sello previo del Comprobante Fiscal Digital, el
sello del timbre será guardado dentro del atributo selloSAT. Esta cadena
original será sellada utilizando el algoritmo de digestión SHA-1. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Uso del Complemento
obligatorio Timbre Fiscal Digital |
|
El resultado de la validación de un CFDI, asignación de
un folio fiscal e incorporación del sello digital del SAT se entenderá como
el Timbrado Fiscal Digital. El folio fiscal digital será referido como el
UUID. Para integrar el complemento TimbreFiscalDigital a un comprobante
fiscal digital por Internet, la estructura resultante deberá integrarse como
un nodo hijo del nodo Comprobante/Complemento/TimbreFiscalDigital. Adicional a su inclusión, se deberá definir el
namespace correspondiente dentro del nodo Comprobante, así como referenciar
la ubicación pública del esquema xsd correspondiente. Por ejemplo, asumiendo que el contribuyente requiere
integrar el namespace correspondiente al presente estándar, se deberá incluir
la referencia al namespace aplicable
(http://www.sat.gob.mx/TimbreFiscalDigital) el cual se define mediante el
esquema público definido en http://www.sat.gob.mx/sitio_internet/cfd/TimbreFiscalDigital/TimbreFiscalDigital.xsd
y se vincularía de la siguiente forma: <cfdi:Comprobante …
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:cfdi=”http://www.sat.gob.mx/cfd/3” xsi:schemaLocation=" http://www.sat.gob.mx/cfd/3
http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv3.xsd .... < cfdi:Complemento> <tfd:TimbreFiscalDigital/> xsi:schemaLocation="http://www.sat.gob.mx/TimbreFiscalDigital TimbreFiscalDigital.xsd" xmlns:tfd="http://www.sat.gob.mx/TimbreFiscalDigital" < cfdi:Complemento> …. </cfdi:Comprobante> La línea que especifica
xml:xsi=”http://www.w3.org/2001/XMLSchema-instance” indica que se está usando
validación mediante el estándar de esquema XSD. La línea que especifica
xmlns:cfdi:=”http://www.sat.gob.mx/cfd/3” hace referencia al namespace de
comprobantes. La línea que especifica
xmlns:tfd=”http://www.sat.gob.mx/TimbreFiscalDigital/” hace referencia al
namespace adicional del complemento aplicable para la expresión de Timbre
Fiscal Digital. Finalmente la línea que especifica xsi:schemaLocation
hace referencia a los dos namespaces usados, marcando adicionalmente la
ubicación de los esquemas xsd que definen las especificaciones de cada
namespace. En caso de que se requiriera agregar otros namespaces
adicionales, el mecanismo sería agregar una línea tipo xmlns definiendo el
namespace y expresando nuevamente el namespace y ubicación de su definición
dentro del atributo xsi:schemaLocation Cabe aclarar que los nodos básicos del comprobante
deberán llevar encabezado del namespace publicado por el SAT. Por ejemplo el
siguiente: <cfdi:Comprobante> <cfdi:Emisor/> </cfd:Comprobante> Respecto de los nodos propios del estándar aplicable para
el complemento obligatorio de Timbre Fiscal Digital del SAT, éstos deberán
utilizar el encabezado “tfd”, por ejemplo: <cfdi:Complemento> <tfd:TimbreFiscalDigital/> < cfdi:Complemento> |
D. Estándar
y uso del servicio de cancelación de CFDI
Para realizar la cancelación de un CFDI se cuenta con
un Servicio Web autenticado al cual se debe conectar el usuario para hacer el
envío por lotes de los comprobantes (desde 1 hasta 500) por transacción. El
cual será expuesto en la siguiente URL: http://tramitesdigitales.sat.gob.mx/cancelacfdi Este servicio puede ser accedido mediante el portal del
SAT, o conectarse de manera síncrona (bajo las mismas condiciones de
seguridad) para realizar cancelaciones de manera automatizada. El usuario deberá enviar peticiones firmadas utilizando
el Certificado de Sello Digital del emisor de los CFDI, bajo el estándar XML
Digital Signature establecido por el W3C (http://www.w3.org/TR/xmldsig-core)
identificando cada uno de los CFDI a cancelar por medio del identificador único incluido en el Timbre
Fiscal Digital.
|
E. Especificación
técnica del código de barras bidimensional
Las impresiones de los comprobantes fiscales digitales
por Internet deben incluir un código de barras bidimensional conforme al
formato de QR Code (Quick Response Code) descrito en el estándar
ISO/IEC18004, con base a los siguientes lineamientos de representación
gráfica. a)
Código de barras bidimensional QR, con base
al estándar ISO/IEC 18004:2000, conteniendo los siguientes datos en el
siguiente formato: 1.
RFC del emisor 2.
RFC del receptor 3.
Total (a 6 decimales fijos) 4.
Identificador único del timbre (UUID)
asignado Donde se manejarán
95 caracteres conformados de la siguiente manera:
De esta manera se
generan los datos válidos para realizar una consulta de un CFDI por medio de
su expresión impresa. Ejemplo: ?re=XAXX010101000&rr=XAXX010101000&tt=1234567890.123456&id=ad662d33-6934-459c-a128-BDf0393f0f44 El código de barras
bidimensional deberá ser impreso en un área no menor a 2.75 centímetros
cuadrados, ejemplo: _______ 2.75 cm______ |
III. De los distintos medios de comprobación
digital:
A. Estándares
y especificaciones técnicas que deberán cumplir las aplicaciones informáticas
para la generación de claves de criptografía asimétrica a utilizar para Firma
Electrónica Avanzada.
Las
aplicaciones informáticas de las que el contribuyente se auxilie para la
generación de su par de claves (clave pública y clave privada) deberán
cumplir con las especificaciones y estándares siguientes: 1. Las
claves a generar deberán ser de tipo RSA de 1024 ó 2048 bits conforme al
certificado de sello otorgado al emisor por parte del SAT. 2. Los
requerimientos digitales contendrán la clave pública y se regirán por el
estándar PKCS10 en formato DER. Mientras que la clave privada se almacenará
en un archivo configurado de acuerdo al estándar PKCS8 en formato DER. Los
campos requeridos para el procesamiento adecuado del requerimiento digital son
los que a continuación se enlistan: a. Registro
Federal de Contribuyente a 12 posiciones para personas morales y a 13
posiciones para personas físicas. En
el caso de que el requerimiento pertenezca a una persona moral o que la
persona física cuente con Representante Legal, por carecer de capacidad de
ejercicio o tenga restricciones de la misma, se debe agregar la clave del RFC
del representante legal, separada de la del contribuyente con un carácter
(/). Ejemplo:
RFC del contribuyente / RFC del Representante Legal. Este
dato debe registrarse en el campo denominado “UniqueIdentifier” de los
“Nombres Distinguidos”, considerando el estándar X.509. b. Correo
Electrónico, almacenado en el campo denominado “emailAddress” de los “Nombres
Distinguidos”, considerando el estándar PKCS – 9. c. Clave
de Revocación, registrado en el atributo extendido “ChallengePassword”. El
valor de este campo, definido para el SAT, se obtiene de la siguiente forma: ■ Unir
el RFC del Contribuyente en mayúsculas con la clave de revocación
proporcionada por el contribuyente. ■ A
este valor se le aplica el algoritmo de digestión SHA1, y se expresa en Base
64. El
estándar que define las características dentro del requerimiento de este
atributo es el PKCS-9. Adicionalmente
deberá incluir la clave CURP en el campo denominado “SerialNumber” de los
“Nombres Distinguidos”. Si
el requerimiento pertenece a una persona moral, se debe agregar la clave CURP
del representante legal, anteponiendo un carácter (/) como se muestra a
continuación: ■ Persona
Moral: / CURP del RL. En
caso de las personas físicas, aplican los siguientes escenarios: ■ Persona
Física: CURP del
contribuyente ■ Persona
física con Representante Legal: CURP del contribuyente / CURP del RL El
Servicio de Administración Tributaria pone a disposición del Contribuyente la
aplicación “SOLCEDI” (Solicitud de Certificado Digital), a fin de facilitar
la generación de claves. NOTA:
Es responsabilidad del Contribuyente el utilizar un equipo de cómputo de su
confianza para la generación de su par de claves y guardar en lugar seguro la
Clave Privada generada y sus contraseñas. |
B. Uso de la facilidad de
nodos opcionales <Complemento> y <ComplementoConcepto>
El estándar del comprobante fiscal digital
incluye dos elementos definidos como de tipo abierto que servirán para
integrar nodos adicionales, definidos por el Servicio de Administración
Tributaria al cuerpo del comprobante. A diferencia del nodo Addenda, estos nodos
si son de uso fiscal por lo que su contenido será reglamentado por la
autoridad para ser utilizados por los contribuyentes que cuenten con alguna
facilidad particular dispuesta en la Resolución Miscelánea Fiscal vigente,
incluyendo los datos complementarios solicitados en dichos nodos de acuerdo
al sector o actividad específica. Las reglas de uso de aquellos complementos
disponibles estarán publicados en el sitio de Comprobantes Fiscales Digitales
dentro del portal del SAT “http://www.sat.gob.mx” Reglas generales de uso: 1. Dentro de estos nodos de complemento se integrarán al
comprobante los elementos adicionales necesarios de acuerdo con el formato
definido por el SAT como requerido por la actividad específica del
contribuyente. 2. La integración de estos elementos adicionales se hará siguiendo
los siguientes lineamientos: a. Se integrarán idénticos los nodos complementarios requeridos
dentro del nodo designado, según sea el caso requerido en la regla de la
Resolución Miscelánea Fiscal aplicable. b. El Contribuyente deberá sujetarse a la estructura de estos
nodos complementarios, teniendo cuidado de especificar las referencias
necesarias al “namespace” del complemento que se utilice, de acuerdo a los
estándares definidos y publicados por el SAT. c. Esto implica que si el contribuyente requiere utilizar esta
funcionalidad complementaria deberá definir el namespace correspondiente
dentro del nodo Comprobante, así como referenciar la ubicación pública del
esquema xsd correspondiente. Por ejemplo, asumiendo que el contribuyente
requiere integrar el namespace http://www.sat.gob.mx/cfd/ecc el cual se
define mediante el esquema público definido en
http://www.sat.gob.mx/schemas/cfd/ecc/ecc.xsd se vincularía de la siguiente
forma: < cfdi:Comprobante … xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:cfdi=”http://www.sat.gob.mx/cfd/3” http://www.sat.gob.mx/cfd/3 …. Nota: El
ejemplo mostrado es para un CFDI, en el caso de un CFD no se incluirá el
encabezado del namespace “cfdi” en el cuerpo del comprobante. Cada complemento tendrá definida su propia regla para
inclusión en la cadena original, la cual, en caso de existir, se integrará en
el lugar correspondiente de acuerdo a lo expresado en los rubros I.C y II.B
del presente anexo. |
C. Uso de la facilidad de
ensobretado <Addenda>
La facilidad de ensobretado consiste en ofrecer
un mecanismo a aquellos contribuyentes que desean utilizar otros formatos
electrónicos de forma adicional y no substituta al establecido dentro del
Anexo 20 Rubro I.B y II.A. Su objeto es permitir que el envío de dichos
formatos adicionales se integre dentro del cuerpo del estándar de comprobante
fiscal digital definido por el SAT, facilitando el transporte de los formatos
e información adicional, evitando con ello envíos paralelos. Su mecánica de uso es el siguiente: 1. Se genera la información adicional en el
formato particular del contribuyente. 2. Se genera el comprobante fiscal digital
en el estándar definido por el SAT y se agregará el nodo o elemento de <
cfdi:Addenda>posterior a que el servicio de certificación de los
proveedores autorizados sea exitoso, como información adicional. 3. Dentro del nodo de <cfdi:Addenda>
se expresa el formato particular del contribuyente siguiendo los siguientes
lineamientos: a. Si
el formato es XML se transcriben idénticos los nodos adicionales requeridos
dentro del nodo < cfdi:Addenda>. Si el contribuyente desea sujetar
estos nodos adicionales a un diccionario o estándar específico, podrá hacerlo
teniendo cuidado de especificar las referencias necesarias al “namespace” del
formato utilizado, de acuerdo a los estándares definidos por el consorcio W3.
Esto implica que si el contribuyente desea utilizar esta funcionalidad
adicional deberá definir su nuevo namespace dentro del propio nodo de la Addenda
publicando la ruta del esquema XSD para validación, por ejemplo: xmlns:otro="http://www.misitio.mx/miNS" xsi:schemaLocation=" La
línea que especifica xml:xsi=”http://www.w3.org/2001/XMLSchema-instance”
indica que se está usando validación mediante el estándar de esquema XSD. b. Si
el formato es texto plano, se expresa idéntico dentro del nodo “Addenda”
teniendo cuidado de no usar caracteres reservados según la especificación de
XML según los planteamientos del consorcio W3. Si el formato es binario, se deberá expresar como
una cadena de caracteres codificados en formato |
Atentamente.
México, D.F., a 27 de
julio de 2010.- El Jefe del Servicio de Administración Tributaria, Alfredo Gutiérrez Ortiz Mena.- Rúbrica.