CIRCULAR EXTERNA 17 DE 2012
(julio 27)
Diario Oficial No. 48.507 de 30 de julio de 2012
DIRECCIÓN DE IMPUESTOS Y ADUANAS NACIONALES
| Para: | Representantes de las entidades autorizadas para recaudar |
| De: | Subdirector de gestión de recaudo y cobranzas (a) |
| Asunto: | Instrucciones para la recepción, entrega de información y conciliación de los formularios que contienen dos códigos de barras |
De acuerdo con lo dispuesto en los artículos 800 y 801 del Estatuto Tributario, y de acuerdo con el “Proyecto Recaudo en Caja” Fase I y Fase II, se establecen algunos aspectos de procedimiento, con el propósito de lograr mayor eficiencia y celeridad en la entrega de la información física, magnética y del archivo diario de conciliación que deben realizar las Entidades Autorizadas para Recaudar, con las declaraciones y/o recibos oficiales de pago diligenciados vía web que contienen dos códigos de barras.
1. PROCESO DE RECEPCIÓN EN CAJA EN LAS OFICINAS, AGENCIAS O SUCURSALES:
1.1. Para la presentación de la declaración y/o recibo de pago diligenciados vía web que contienen dos códigos de barras, no se requiere de la presentación del RUT, y el contribuyente deberá llevar dos (2) hojas impresas del mismo modelo en papel no reutilizado, tamaño carta, color blanco, bond y/o biodegradable.
1.2. El cajero verificará que el número de formulario de la casilla 4 y el valor de la casilla 980 Pago Total, sea igual en los dos ejemplares, para garantizar la coincidencia en la información.
1.3. El valor a pagar no puede ser diferente al registrado en la casilla 980 del documento a recepcionar.
1.4. El cajero verificará que las declaraciones contengan al menos una firma en la casilla determinada para tal fin. Es obligatorio para las declaraciones del Gravamen a los Movimientos Financieros que contenga además la firma de contador o revisor fiscal. Las firmas deben ser autógrafas. Los recibos oficiales de pago pueden venir o no firmados.
1.5. Las declaraciones y/o recibos oficiales de pago no deben tener tachaduras o enmendaduras.
1.6. Las declaraciones y/o recibos oficiales de pago se recibirán en horario normal y/o extendido
1.7. El cajero realizará la lectura óptica de los dos códigos de barras. En caso de no poder realizarse la lectura óptica, deberá digitar los números asociados los códigos.
1.8. La fecha de presentación y/o pago no puede ser superior a la fecha límite asignada por el sistema.
1.9. Cuando el sistema valide la información de los códigos de barras, el cajero recepcionará el documento colocando en el espacio establecido, el sello de recibido con o sin pago en horario normal y/o extendido. El cajero por ningún motivo deberá colocar adhesivos a las declaraciones y/o recibos oficiales de pago diligenciados vía web que contienen dos códigos de barras, ni firmar o colocar anotaciones adicionales.
1.10. Una vez recepcionada la declaración y/o recibo oficial de pago, el cajero entregará al contribuyente un ejemplar de la declaración y/o recibo oficial de pago y conservará el otro ejemplar para ser enviado físicamente al Centro Nacional de Administración Documental - CNAD y/o Grupos de gestión documental, o quien haga sus veces de las Direcciones Seccionales.
Son factores de rechazo cuando no se cumpla con uno o más de los numerales relacionados anteriormente.
Para subsanar los errores que generaron el rechazo, el contribuyente deberá:
-- Diligenciar vía web un nuevo formulario y presentarlo ante el Banco (declaración y/o recibo de pago), o.
-- Presentar ante el Banco el formulario diligenciado en formato litográfico.
2. ARCHIVO DE CONCILIACIÓN PAGO EN CAJA:
Para el reporte del archivo de conciliación pago en caja se debe tener en cuenta:
2.1. El archivo de conciliación pago en caja debe consolidar toda la información de las declaraciones y recibos de pago recepcionadas a nivel nacional el día hábil anterior incluyendo lo correspondiente a horarios adicionales o extendidos.
2.2. El “archivo de Conciliación pago en Caja” debe enviarse diariamente en un archivo XML, de acuerdo con la especificación técnica del Anexo 01.
2.3. El consecutivo del envío del archivo de conciliación es manejado automáticamente por los sistemas informáticos electrónicos de la DIAN.
2.4. La información deberá enviarse a la DIAN, a más tardar a las 10:00 a.m., del día hábil siguiente a la fecha de la transacción, en el formato de conciliación pago en caja, modelo 1740, cumpliendo la especificación técnica del Anexo 01.
2.5. Para los recaudos recepcionados los días sábados, domingo y/o festivo se deberá enviar un archivo por cada día de recaudo el día hábil siguiente.
2.6. En el archivo XML se incluye un código que permite diferenciar los recaudos de horario normal y los de horario extendido o adicional.
2.7. Los campos que corresponden a fechas siempre deben diligenciarse en Formato AAAAMMDD.
2.8. En caso de inconsistencia en el archivo de “Conciliación pago en Caja”, está corrección, se realizará como se tiene establecido para el archivo de conciliación de Pagos Electrónicos y en ningún evento se anula una transacción enviada.
2.9. Los registros por archivo XML son máximo 5.000 y se pueden enviar varios archivos XML para una misma fecha de recaudo hasta incluir la totalidad de las transacciones. (Anexo 01).
2.10. Las declaraciones y/o recibos oficiales de pago que contienen los dos códigos de barras no deben incluirse en la grabación y envío FTP. En el evento que se haya duplicado la información enviada a la DIAN en el archivo de “conciliación pago en caja” y en el archivo FTP, el banco responderá por el valor pago total de la casilla 980.
3. FORMATOS DE REPORTE DE RECAUDO Y CONSIGNACIONES MODELOS 050 Y 1188.
La información correspondiente a las declaraciones y/o recibos oficiales de pago que contienen los dos códigos de barras, se deberán incorporar en el formato 1188 “Reporte de Recaudos y Consignaciones”. El valor recaudado con las declaraciones y/o recibos oficiales de pago que contienen los dos códigos de barras, para su traslado a la Dirección General de Crédito Público y Tesoro Nacional, se deberá incluir en el formato 050 “Consignación de las Entidades Autorizadas para Recaudar a la Dirección General de Crédito Público y del Tesoro Nacional”, de acuerdo con lo señalado en los artículo 1o y 2o de la Resolución 03083 del 16 de marzo de 2007.
Para efectos del procedimiento a seguir en casos de contingencia, se aplicará lo dispuesto en el artículo 4o de la Resolución 03083 de 2007.
4. SANCIONES
El incumplimiento de las obligaciones señaladas en la presente Circular acarreará las sanciones previstas en el Estatuto Tributario.
Publíquese y cúmplase.
Dada en Bogotá, D. C., 27 de julio de 2012.
El Subdirector de Gestión Recaudo y Cobranzas (A) de la Unidad Administrativa Especial de Dirección de Impuestos y Aduanas Nacionales,
MANUEL ALBERTO PEREA URIBE.
ARCHIVOS DE CONCILIACIÓN PAGO EN CAJA.
Especificaciones Técnicas
Formato 1740 - Versión 1
OBJETIVO
Definir las características y contenido de los archivos para los Archivos de Conciliación Pago en Caja.
ESPECIFICACIÓN TÉCNICA
El formato “Archivos de Conciliación Pago en Caja” debe enviarse en un archivo XML que cumpla las siguientes especificaciones:
1. Estándar del Nombre de los Archivos
El nombre de cada uno de los archivos, debe especificarse mediante la siguiente secuencia de caracteres:
Dmuisca_ccmmmmmvvaaaacccccccc.xml
| cc | : Concepto (Inserción = 01 Reemplazo = 02) |
| mmmmm | : Formato (Archivos de Conciliación Pago en Caja = 01740) |
| vv | : Versión del formato (Versión = 01). |
| aaaa | : Año de envío. |
| cccccccc | : Consecutivo de envío por año. |
2. Formato del Archivo
El formato “Archivos de Conciliación Pago en Caja”, contiene un documento XML, que está compuesto por dos elementos complejos: Encabezado y Contenido, las cuales se deben enviar en el orden enunciado.
Encabezado
Contenido Información 1
Contenido Información 2
...
Contenido Información N
1. El documento XML debe cumplir con la especificación 1.0 Tercera edición.
2. El conjunto de caracteres utilizado en el documento XML debe ser el alfabeto latino número 1: “ISO-8859-1”.
3. El archivo debe contener un documento XML bien formado y válido de acuerdo al esquema XSD que incluye en esta especificación técnica.
4. El archivo debe contener un elemento único elemento raíz llamado “mas”, que a su vez contendrá toda la información del archivo, tanto el encabezado como los registros.
2.1. Formato del Encabezado
El encabezado del archivo viene en el elemento “Cab” y contiene los siguientes datos, todos de carácter obligatorio:
| ETIQUETA | DENOMINACIÓN CASILLA | TIPO | LONGITUD CAMPO | VALIDACIONES | OBSERVACIONES |
| Ano | Año de envío | Int | 4 | Formato AAAA | |
| CodCpt | Concepto | Int | 2 | 1 = Inserción 2 = Reemplazo | |
| Formato | Código del formato | Int | 5 | Archivos de Conciliación Pago en Caja = 1740 | |
| Versión | Versión del formato | Int | 2 | Versión = 7 | |
| NumEnvio | Número de envío | Int | 8 | Debe ser un número consecutivo por año para el formato 1740 | Consecutivo de envío por año. |
| FecEnvio | Fecha de envío | DateTime | 19 | Debe ser la fecha calendario. | Formato AAAA-MM-DDTHH:MM:SS |
| FecInicial | Fecha Inicial | Date | 10 | Debe ser la fecha calendario. | Los registros corresponden mínimo esta fecha inicial. Formato AAAA-MM-DD |
| FecFinal | Fecha Final | Date | 10 | Debe ser la fecha calendario. | Los registros corresponden máximo a esta fecha inicial. Formato AAAA-MM-DD |
| ValorTotal | Valor Total | double | 20 | Corresponde a la sumatoria de la casilla “nop” (Número de Operación o autorización) de los registros reportados. | |
| CantReg | Cantidad de registros | Int | 4 | Se enviarán archivos con máximo 5000 registros; si se deben reportar más de 5000 registros se fraccionará la información en archivos de 5000 registros o menos. La cantidad de registros esta medida por el número de elementos “caja” que contenga el archivo. | Cantidad de registros reportados en el contenido. |
2.3. Formato del Contenido
En el contenido del archivo se deben incluir tantos registros como se informó en la cabecera en el campo “Cantidad de registros”.
Cada registro reportado debe mantener la misma estructura previamente explicada y usada para la cabecera.
El contenido del archivo viene en el elemento “caja” y debe incluir los siguientes datos:
| ATRIBUTO | CASILLA | DENOMINACIÓN CASILLA | TIPO | LONGITUD | CRITERIOS |
| Dec | 24 | Número de la declaración o recibo de pago | long | 16 | Siempre debe diligenciarse. Se lee del primer código de barras. |
| Hash | 25 | Hash | string | 6 | Siempre debe diligenciarse. Se lee del segundo código de barras. |
| Nit | 26 | NIT | double | 14 | Siempre debe diligenciarse. Se lee del segundo código de barras. |
| Fpag | 27 | Forma de pago | int | 2 | Siempre debe diligenciarse. Se lee del segundo código de barras. Debe estar de acuerdo a la Tabla 2 |
| Cpt | 28 | Concepto | int | 2 | Siempre debe diligenciarse. Se lee del segundo código de barras. Debe estar de acuerdo a la Tabla 1. El formato en esa tabla corresponde a los tres primeros caracteres del número de la declaración o recibo de pago |
| Val | 29 | Valor Recaudado | decimal | 20.2 | Siempre debe diligenciarse. Se lee del segundo código de barras. |
| Fec | 30 | Fecha limite pago | long | 8 | Siempre debe diligenciarse. Se lee del segundo código de barras. Formato AAAAMMDD |
| fecpag | 31 | Fecha y hora del pago | dateTime | 19 | Siempre debe diligenciarse Formato AAAA-MM-DDTHH:MM:SS |
| Cban | 32 | Código del banco | int | 2 | Siempre debe diligenciarse |
| Csuc | 33 | Código de la sucursal | int | 3 | Siempre debe diligenciarse |
| Ccaj | 34 | Código del cajero | int | 2 | Siempre debe diligenciarse |
| Nop | 35 | Número de Operación o autorización | string | 10 | Siempre debe diligenciarse |
| Hor | 36 | Horario | int | 1 | Siempre debe diligenciarse 1 – Normal 2 - Extendido |
Tabla 1 – Conceptos
| FORMATO | CONCEPTO | NOMBRE |
| 490 | 4 | RENTA |
| 490 | 5 | VENTAS |
| 490 | 7 | SANCIONES |
| 490 | 8 | VTA ACTIVO FIJO |
| 490 | 10 | SEGURIDAD DEMOCRÁTICA |
| 490 | 54 | IMPUESTO AL PATRIMONIO |
| 490 | 55 | SANCIÓN DECLARACIÓN INDIVIDUAL PRECIOS DE TRANSFERENCIA |
| 490 | 56 | SANCIÓN DECLARACIÓN CONSOLIDADA PRECIOS DE TRANSFERENCIA |
| 490 | 61 | RETENCIÓN A TÍTULO DE RENTA |
| 490 | 62 | RETENCIÓN A TÍTULO DE VENTAS |
| 490 | 63 | RETENCIÓN A TÍTULO DE TIMBRE |
| 490 | 88 | APORTE A LAS NOTARÍAS |
| 490 | 99 | GRAVAMEN A LOS MOVIMIENTOS FINANCIEROS |
| 495 | 1 | DERECHOS DE EXPLOTACIÓN Y ADM. JUEGOS DE SUERTE Y AZAR |
| 690 | 1 | DECLARACIÓN IMPORTACIÓN |
| 690 | 2 | LIQUIDACIÓN OFICIAL |
| 690 | 3 | SANCIONES ADUANERAS |
| 690 | 4 | SANCIONES CAMBIARIAS |
| 690 | 5 | VIAJEROS |
| 690 | 6 | PAGOS CONSOLIDADOS UPAS |
| 690 | 7 | PAGOS DECLARACIÓN CONSOLIDADA |
| 690 | 8 | FINALIZACIÓN PLAN VALLEJO |
| 690 | 9 | IMPORTACIÓN TEMPORAL |
| 690 | 10 | RESCATE |
| 690 | 11 | SANCIONES ADUANERAS VOLUNTARIAS |
| 690 | 12 | PAGO GRAVAMEN 6% |
| 110 | 4 | RENTA |
| 210 | 4 | RENTA |
| 300 | 5 | VENTAS |
| 350 | 4 | RETENCIÓN |
| 420 | 54 | IMPUESTO AL PATRIMONIO |
| 120 | 55 | SANCIÓN DECLARACIÓN INDIVIDUAL PRECIOS DE TRANSFERENCIA |
| 130 | 56 | SANCIÓN DECLARACIÓN CONSOLIDADA PRECIOS DE TRANSFERENCIA |
| 410 | 99 | GRAVAMEN A LOS MOVIMIENTOS FINANCIEROS |
Tabla 1 – Conceptos
| FORMATO | CONCEPTO | NOMBRE |
| 320 | 1 | DERECHOS DE EXPLOTACIÓN Y ADM. JUEGOS DE SUERTE Y AZAR |
| 500 | 1 | DECLARACIÓN IMPORTACIÓN |
| 510 | 1 | DECLARACIÓN IMPORTACIÓN SIMPLIFICADA |
| 520 | 8 | FINALIZACIÓN PLAN VALLEJO |
| 540 | 7 | PAGOS DECLARACIÓN CONSOLIDADA |
| 550 | 1 | DECLARACIÓN IMPORTACIÓN / FACTURA DE NACIONALIZACIÓN |
Tabla 2 – Forma de pago
| 0 | Recaudos en Efectivo |
| 10 | Recaudos en Bonos para la Seguridad |
| 20 | Recaudos en Bonos Agrarios |
| 30 | Recaudos en CD TUR |
| 40 | Recaudos en SERTE |
| 50 | Recaudos en RIDIS |
| 60 | Recaudos en Bonos Financiamiento Especial |
| 70 | Recaudos en Bonos Financiamiento Presupuestal |
NOTA: Los datos de los campos cban, csuc y ccaj deben corresponder a los códigos que se utilizan para la impresión de los autoadhesivos, que se eliminan para el proceso de recaudo en caja con lectura de dos códigos de barras.
3. Validaciones
3.1. Validaciones Generales
1. El archivo debe contener todos los campos definidos para el encabezado y estos campos deben estar correctamente diligenciados.
2. La información del contenido del archivo debe corresponder al esquema XSD entregado.
3. Los atributos que registran valores numéricos, se reportan con valores numéricos positivos, sin signos ni puntuaciones, según lo reportado por el informante o en su defecto con cero (0).
4. Los campos que corresponden a fechas, deben contener fechas válidas en cuando a año, mes, y día.
3.2. Validaciones del Encabezado
1. Los campos concepto, formato y versión, deben venir diligenciados con los valores estipulados en las especificaciones técnicas,
2. Año de envío, debe ser el año calendario.
3. Número de envío, debe ser un número consecutivo por año para todos los formatos que el remitente envíe a la DIAN.
4. Fecha de envío, debe ser la fecha calendario, en formato AAAA-MM-DDTHH:MM:SS.
5. Cantidad de registros, debe ser igual a la cantidad de registros reportados en el contenido, que como máximo puede ser 5.000 registros.
6. Valor total, corresponde a la sumatoria de la casilla “nop” de los registros reportados en el elemento “caja”.
4. Esquema XSD
A continuación se incluye el esquema XSD para esta especificación técnica.
<?xml version=»1.0» encoding=»ISO-8859-1»?>
<xs:schema xmlns:xs=»http://www.w3.org/2001/XMLSchema» elementFormDefault=»qualified» attributeFormDefault=»unqualified»>
<xs:element name=»caja»>
<xs:annotation>
<xs:documentation>Archivos de Conciliación Pago en Caja</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name=»dec» use=»required»>
<xs:annotation>
<xs:documentation>Número de la declaración</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:double”>
<xs:minInclusive value=»0»/>
<xs:maxInclusive value=»9999999999999999»/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»hash» use=»required»>
<xs:annotation>
<xs:documentation>Hash</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=»xs:string»>
<xs:minLength value=»1»/>
<xs:maxLength value=»6»/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»nit» use=»required»>
<xs:annotation>
<xs:documentation>NIT</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:double”>
<xs:minInclusive value=”0”/>
<xs:maxInclusive value=”99999999999999”/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»fpag» use=»required»>
<xs:annotation>
<xs:documentation>Forma de pago</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:int”>
<xs:totalDigits value=”2”/>
<xs:minInclusive value=”0”/>
<xs:maxInclusive value=”99”/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»cpt» use=»required»>
<xs:annotation>
<xs:documentation>Concepto</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:int”>
<xs:totalDigits value=”2”/>
<xs:minInclusive value=”0”/>
<xs:maxInclusive value=”99”/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»val» use=»required»>
<xs:annotation>
<xs:documentation>Valor Recaudado</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:double”>
<xs:minInclusive value=”0”/>
<xs:maxInclusive value=”99999999999999999999.99”/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»fec» type=»xs:date» use=»required»>
<xs:annotation>
<xs:documentation>Fecha limite pago</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name=»fecpag» type=»xs:dateTime» use=»required»>
<xs:annotation>
<xs:documentation>Fecha y hora del pago</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name=»cban» use=»required»>
<xs:annotation>
<xs:documentation>Codigo del banco</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:int”>
<xs:totalDigits value=»2»/>
<xs:minInclusive value=»0»/>
<xs:maxInclusive value=»99»/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»csuc» use=»required»>
<xs:annotation>
<xs:documentation>Codigo de la sucursal</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:int”>
<xs:totalDigits value=”3”/>
<xs:minInclusive value=”0”/>
<xs:maxInclusive value=”999”/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»ccaj» use=»required»>
<xs:annotation>
<xs:documentation>Codigo del cajero</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:int”>
<xs:totalDigits value=»2»/>
<xs:minInclusive value=»0»/>
<xs:maxInclusive value=»99»/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»nop» use=»required»>
<xs:annotation>
<xs:documentation>Número de identificación</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=»xs:string»>
<xs:minLength value=»1»/>
<xs:maxLength value=»6»/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=»hor» use=»required»>
<xs:annotation>
<xs:documentation>Concepto</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:int”>
<xs:totalDigits value=”1”/>
<xs:minInclusive value=”0”/>
<xs:maxInclusive value=”9”/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name=»mas»>
<xs:annotation>
<xs:documentation>Elemento raiz del xml de carga masiva</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name=”Cab” type=”CabType”/>
<xs:element ref=»caja» maxOccurs=»unbounded»/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name=»CabType»>
<xs:sequence>
<xs:element name=»Ano» type=»xs:gYear» nillable=»false»>
<xs:annotation>
<xs:documentation>Año de envio</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name=”CodCpt” nillable=”false”>
<xs:annotation>
<xs:documentation>Concepto</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:int”>
<xs:minInclusive value=”0”/>
<xs:maxInclusive value=”99”/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name=»Formato» fixed=»1740»>
<xs:simpleType>
<xs:restriction base=”xs:positiveInteger”>
<xs:totalDigits value=»4»/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name=”Version” type=”xs:positiveInteger” fixed=”1”/>
<xs:element name=”NumEnvio”>
<xs:annotation>
<xs:documentation>Numero de envio</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:positiveInteger”>
<xs:totalDigits value=”8”/>
<xs:maxInclusive value=”99999999”/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name=»FecEnvio» type=»xs:dateTime»>
<xs:annotation>
<xs:documentation>Fecha de envio</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name=”FecInicial” type=”xs:date”>
<xs:annotation>
<xs:documentation>Fecha inicial</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name=”FecFinal” type=”xs:date”>
<xs:annotation>
<xs:documentation>Fecha Final</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name=”ValorTotal” type=”xs:double”>
<xs:annotation>
<xs:documentation>Valor Total</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name=”CantReg”>
<xs:annotation>
<xs:documentation>Cantidad de registros</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base=”xs:positiveInteger”>
<xs:totalDigits value=”4”/>
<xs:maxInclusive value=”9999”/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
