• Author / Uploaded
• Raul Eduardo Correa Vergara

• Categories
• Factura
• Correo electrónico
• Internet
• Red mundial
• Tecnología

Citation preview

MODELO FACTURA ELECTRÓNICA. Actualizaciones: 2003 08 18

I.

Se Agrega punto que describe el proceso de Postulación y Certificación para obtener Resolución SII que autoriza a operar con Factura Electrónica.

Introducción.

La importancia de implementar un sistema que permita operar con factura electrónica nace de la innegable necesidad de otorgar validez legal al ejemplar electrónico de los documento tributarios de compra y venta tales como facturas, notas de crédito, notas de débito, guías de despacho, ya que con ello se optimiza la operación de las empresas y del Servicio de Impuestos Internos (SII). Actualmente, el Servicio de Impuestos Internos exige a los contribuyentes que sus documentos tributarios en papel, sean registrados y autorizados antes de utilizarlos. Esta autorización del SII se materializa a través de un timbre de cuño que el contribuyente está obligado a aplicar sobre sus documentos en papel, previo a utilizarlos. Para aplicar este timbre de cuño, que autoriza que un papel sea utilizado como documento tributario, el contribuyente debe concurrir periódicamente a la Unidad del SII que le corresponde, llevando los documentos que desea timbrar foliados en forma previa. Tanto para el Servicio como para los contribuyentes, especialmente para los que requieren timbrar un gran volumen de documentos, este es un procedimiento molesto y costoso. Adicionalmente el utilizar estos formularios para imprimir sus documentos tributarios provoca molestias en el procesamiento masivo al obligar a respetar la foliación en la impresión y al no poder utilizar tecnología de impresión láser, como es el deseo de muchos contribuyentes. En relación con el almacenamiento de las facturas y otros documentos tributarios, el contribuyente está obligado a guardar los papeles que los sustentan durante 6 años para su posterior posible revisión. Esta obligación deviene, especialmente para los generadores de grandes volúmenes de documentos, una exigencia costosa en administración y bodegas. Como una respuesta a estas necesidades, y en concordancia con la política adoptada de modernizar su gestión y utilizar la red Internet como elemento de comunicación con los contribuyentes, el Servicio de Impuestos Internos ha impulsado, con la colaboración de un grupo de empresas piloto, un modelo de operación con Factura Electrónica que actualmente se encuentra en su etapa de Marcha Blanca y que próximamente estará abierto a todos los contribuyentes. En dicho modelo, los contribuyentes pueden generar, transmitir, y almacenar en forma electrónica sus documentos tributarios, autenticados con firma electrónica, además deben enviar un ejemplar electrónico del documento tributario al SII, antes de que sea recibido por su receptor o utilizado para el transporte físico de bienes. La autorización de los folios que se usan en estos documentos se obtiene en el sitio Web del SII, como alternativa al timbre físico con cuño. En este modelo se incorpora la facilidad de la firma electrónica de los documentos como un medio de asegurar la autenticidad de sus emisores, y cautelar la integridad de los documentos a transmitir.

Servicio de Impuestos Internos

II.

Descripción del Sistema .

Cuando se inicie la masificación del sistema de Factura Electrónica el SII habilitará una opción en su sitio Web. En dicha opción, todos los contribuyentes interesados en ser emisores de documentos tributarios electrónicos y que tengan desarrollado el sistema para la generación de dichos documentos, podrán registrar sus antecedentes y postular para obtener la certificación del SII y la correspondiente autorización de emisor de documentos tributarios electrónicos. Para operar con la factura electrónica los contribuyentes deben estar autorizados por SII como emisores de documentos electrónicos. Esto no los obliga a generar todos sus documentos en forma electrónica pero sí a recibir documentos electrónicos de otros emisores. Los contribuyentes enrolados en el sistema, una vez que han obtenido la autorización del SII, puede conseguir la autorización de sus folios a través del Web del SII, y, utilizando esos folios, emitir, transmitir y almacenar sus documentos tributarios en forma electrónica. Los contribuyentes enrolados en el sistema requieren almacenar los documentos tributarios electrónicos emitidos y recibidos sólo en forma electrónica y están eximidos de la obligación de almacenar dichos documentos en papel para una posible revisión del SII. El contribuyente debe enviar el documento al SII, vía Internet, antes de que sea recibido por su destinatario o utilizado para el transporte físico de bienes. El contribuyente emisor debe enviar el documento al receptor, ya sea manual o electrónico. Al receptor manual, no enrolado en el sistema, le debe enviar la representación en papel del documento, la que este último sí está obligado a almacenar. Cada documento debe ser generado en el estándar definido por las especificaciones del SII. Debe incorporar una firma electrónica digital de la totalidad del documento, la que permite asegurar la identidad del emisor y cautelar la integridad del documento. Como resguardo adicional, se exige incorporar un “timbre electrónico”, el que se imprime en código de barras en la representación impresa de los documentos. Este timbre electrónico, obtenido según un algoritmo de seguridad especificado por el SII, permite a los fiscalizadores verificar fuera de línea, en los controles móviles, la validez de los documentos impresos que acompañan mercaderías. El Servicio de Impuestos Internos habilitó una verificación de documentos en su sitio Web, lo que permite a los contribuyentes receptores y a los fiscalizadores del SII, cerciorarse de la validez de un documento. Próximamente, esta verificación también estará disponible a través del teléfono. En la figuras 1 y 2 se pueden apreciar cuadros comparativo entre la situación actual y el sistema de facturación electrónica propuesto. FUNCION SISTEMA ACTUAL Foliación de documentos Pre-impreso en los documentos Timbrado de documentos En oficinas del Servicio Timbre De cuño Almacenamiento Del papel. Contribuyente, durante 6 años Verificación de Validez Impresión del documento

SISTEMA PROPUESTO Autorizado a través del Web del SII Por el contribuyente Electrónico Electrónico. SII ejemplar tributario. Contribuyente para sus propósitos y para eventuales solicitudes del SII Sólo de autorización en Web SII. Autorización, recepción y validez. En el Web SII. Papel autocopiativo, formulario continuo, Papel normal, hoja suelta, impresora láser. prefoliado, impresora de impacto

Figura 1

SII-Modelo Factura-Electrónica

18 Agosto 2003 Pág. 2 de 9

Servicio de Impuestos Internos SISTEMA ACTUAL

SII Autorización de Folios

SII

SII Revisión

Revisión Compradores

Vendedores

EMISOR

Resguardo Papeles sin utilizar ( Valorados)

CORREO

RECEPTOR

Almacenamiento

Almacenamiento

IMPRENTA

SISTEMA Con FACTURA ELECTRÓNICA

Autorización de folios

Envío de documento

Revisión

EMISOR

SII En vío de do cu me nto

RECEPTOR

Figura 2

III.

Modelo de Operación.

El contribuyente debe obtener la autorización del SII para operar como Emisor de Documentos Tributarios Electrónicos. El contribuyente podrá solicitar autorización sólo para emitir factura electrónica, lo cual significa que estará autorizado también para notas de crédito y de débito, o podrá solicitar en forma adicional autorización para guías de despacho, facturas de compra o boletas. Las boletas sólo se le autorizarán en el caso que sea un proveedor de servicios periódicos. Una vez autorizado para operar con documentos tributarios electrónicos el contribuyente tiene la obligación de almacenar en forma electrónica, información de los libros de ventas y compras, de acuerdo al formato establecido por el SII. Esta información deberá incluir la totalidad de los documentos emitidos y recibidos, tanto electrónicos como manuales y deberá ser enviada al SII en forma mensual de acuerdo con los procedimientos establecidos para ello por el SII. Excepcionalmente podrá ser solicitada en forma especial (de acuerdo con alguna selección o clasificación específica) si ello es requerido por necesidades de fiscalización.

SII-Modelo Factura-Electrónica

18 Agosto 2003 Pág. 3 de 9

Servicio de Impuestos Internos

En el sitio Web del SII, se encuentra disponible un registro público de los contribuyentes enrolados en el sistema, en el que se indica el tipo de documentos (facturas, notas de débito y crédito, guías, facturas de compra, etc), que están autorizados a generar en forma electrónica. Todo contribuyente registrado en el SII como generador de un tipo de documento electrónico, está obligado a recibir documentos tributarios electrónicos. Al estar autorizado para generar cierto tipo de documento en forma electrónica, no está obligado a generar todos sus documentos de ese tipo en forma electrónica, ya que estará permitido que maneje en forma paralela un stock de documentos tributarios manuales para ser usados eventualmente, los cuales timbrará en el SII con el procedimiento habitual del timbre de cuño y estarán sujetos a las normas establecidas para dichos documentos. Los contribuyentes enrolados deben mantener actualizada en el sitio Web del SII la información acerca de los Rut de las personas autorizadas al interior de su empresa a interactuar con el SII en el sistema de factura electrónica. Deben identificar él o los Rut de los titulares de los certificados digitale s habilitados en su empresa para firmar documentos y, designar en forma especial, quién o quienes están autorizados para la solicitud de folios. Previo a la generación de un documento tributario electrónico es preciso que el contribuyente obtenga, desde el sitio Web del SII, un rango de números o folios autorizados para un tipo de documento que generará en forma electrónica. El SII entrega junto a cada rango autorizado un “código de autorización” asociado a ese rango de folios, que debe ser utilizado para la obtención del timbre electrónico cuya representación en código de barras 2D se incluye en los documentos impresos. Para autenticar y evitar la alteración del rango de folios autorizados se incluirá en el código de autorización una firma del Servicio. Se considera que los documentos electrónicos son tipos de documentos distintos de los manuales, por lo que el SII se entrega para ellos un rango diferente a los folios de los documentos manuales. La estructura de contenido de los documentos, está defin ida por el SII, bajo el formato estándar XML; la obligatoriedad de los campos depende de tipo de documento. El contribuyente debe convertir sus documentos al formato XML definido por el SII. Los documentos deben incluir un “timbre electrónico”, como parte del documento electrónico y su representación gráfica, a través de un código de barras bidimensional (PDF417), en las impresiones de los documentos tributarios electrónicos. El timbre es una firma digital de los datos relevantes de un documento, inclu ido el “Código de autorización de Folios” que el Servicio entregó al contribuyente junto con el rango de folios autorizados. El Servicio de Impuestos Internos verifica la validez del timbre electrónico de los documentos, tanto en la presencia fiscalizadora y en la fiscalización móvil que se realiza en carreteras, como en la recepción masiva de ellos. Una vez generado el documento en el formato establecido, incluyendo el timbre electrónico, debe ser firmado, en su contenido completo, por un emisor autorizado. Es importante que el contribuyente resguarde adecuadamente tanto sus código de folios autorizados como sus certificados digitales. Los mecanismos de seguridad que el contribuyente implemente para asegurar el acceso a los folios autorizados, y a sus llaves privadas, son de su responsabilidad. Todo documento electrónico debe ser transmitido al SII en el momento de ser generado. En el caso de traslado de mercaderías, debe ser enviado al SII antes de que el ejemplar impreso sea utilizado para realizar el transporte. En los procesos de facturación masiva, se deben transmitir tan pronto se complete el proceso correspondiente. En el caso de no existir transporte de productos asociado al documento electrónico, este podrá ser transmitido en un plazo no mayor a 12 horas desde su generación. El

SII-Modelo Factura-Electrónica

18 Agosto 2003 Pág. 4 de 9

Servicio de Impuestos Internos

mecanismo de envío de estos documentos será vía Internet y permite el envío de documentos en forma unitaria o en lotes, según procedimientos determinados por el SII. El Servicio de Impuestos Internos almacena el ejempla r tributario del documento pero no se hace cargo de almacenar ejemplares para el contribuyente. Si el contribuyente desea acceder a los ejemplares de sus documentos debe almacenar, bajo su responsabilidad, sus documentos tributarios para sus fines particulares Es necesaria la impresión de un documento para enviarlo a un receptor manual, así como para acompañar los bienes físicos a entregar, mediante factura o guía de despacho, a un receptor, electrónico o manual. La impresión debe cumplir las normas establecidas por el SII. Los productos siempre deben ir acompañados de una impresión del documento (factura o guía), en dos ejemplares. La impresión de los documentos está acotada a un máximo de una sola hoja de tamaño oficio, según reglamentación del SII. El emisor podrá eximirse de hacer la impresión para un receptor manual cuando el documento no acompaña bienes, siempre que cuente con la autorización expresa del receptor, de acuerdo con lo que establece la Resolución Exenta N° 11 del 14 de Febrero de 2003. En este caso, la imagen que se ponga a disposición del receptor deberá cumplir con las especificaciones del SII en cuanto a que sea en un formato que permita la correcta verificación posterior del timbre electrónico. En ese caso el receptor manual se obliga, a través de esa misma autorización, a imprimir en la calidad y forma establecida por el SII. La modalidad tecnológica de transmisión del documento electrónico, desde el emisor al receptor electrónico, debe ser acordada entre ambos e incluir la firma de l emisor e información del certificado digital del firmante y respetar el estándar mínimo establecido por el SII. Los contribuyentes deben intercambiar documentos tributarios electrónicos en el mismo formato XML en que dichos documentos se envían al SII, y se obligan a responder la recepción. Adicionalmente se ha definido un formato XML para la respuesta de recepción o rechazo del envío y la obligación de definir una casilla de correo electrónico para recibir la información relacionada con factura electrónica que le envíen otros emisores electrónicos, en el caso que no convengan un medio alternativo. Desde el punto de vista de un receptor, si el documento recibido da cuenta de una transacción que se ha realizado, existe la obligación de registrar el documento en la contabilidad, debiendo solicitar que se realicen los ajustes vía Nota de Crédito o de Débito, si corresponde. Si la transacción no se ha realizado, o hay error en el Rut del receptor, puede rechazar los documentos como lo hace con los documentos no electrónicos, sin registrarlo y constituye obligación del emisor generar y enviar al SII la nota de crédito electrónica que anule el documento. Los documentos tributarios electrónicos recibidos por un Receptor Electrónico al ser almacenados electrónicamente debe adjuntárseles la firma y el Certificado que permite verificar la firma. Los registros de un documento electrónico, hechos en la contabilidad, tendrán como respaldo válido sólo los documentos archivados electrónicamente; no se podrá utilizar como respaldo un documento impreso, aún cuando éste cumpla con las normas de impresión. Se considera que un documento electrónico está válidamente emitido si cumple con las especificaciones del formato electrónico (“schema” XML) y por lo tanto es aceptado en la recepción por parte del SII. Toda factura que no cumpla con estas condiciones, aún cuando hubiera tenido una representación en papel, se considerará como no emitida y en consecuencia el SII podrá rechazar el crédito fiscal. En este caso el receptor deberá acreditar a satisfacción del Servicio que se han cumplido las exigencias establecidas en el artículo 23° N° 5 de la Ley del IVA.

SII-Modelo Factura-Electrónica

18 Agosto 2003 Pág. 5 de 9

Servicio de Impuestos Internos

Toda corrección de una factura válidamente emitida debe ser realizada vía Notas de Crédito o de Débito electrónicas. Se habilitó para receptores, o contribuyentes en general, una verificación vía Internet de documentos (próximamente también disponible por vía telefónica), en la que el contribuyente debe indicar el Rut del emisor, el tipo de documento y el N de Folio, a lo que el SII responde si el documento ha sido recibido por el SII, y si no lo ha sido, si el folio está autorizado, no autorizado o anulado. Opcionalmente, si el documento se reconoce recibido, en la consulta el contribuyente puede indicar otros valores del DTE (Rut del receptor y monto, por ejemplo) y el SII indicará si esos valores coinciden con los del DTE existente en su Base de Datos.

IV. Postulación al Sistema y Certificación de Emisores Electrónicos En el sitio Web del SII está publicada toda la información, incluyendo antecedentes generales y técnicos, que le permiten al contribuyente planificar e iniciar las actividades necesarias para generar documentos tributarios electrónicos. En la página Web del SII habrá una opción de Postulación a la emisión, que describe los requisitos y condiciones de la postulación. En esta opción, si la empresa cumple con lo estipulado en estos requisitos y desea postular a emitir documentos tributarios electrónicos bajo las condiciones estipuladas por el SII, el representante legal de la empresa, autenticado con Certificado digital, deberá ingresar los datos requeridos en la postulación. El Certificado de Rut Digital debe ser obtenido con una de las Entidades Proveedoras de Certificados Digitales acreditadas ante el SII o ante la Subsecretaría de Economía. (Ver sitios de Interés en www.sii.cl). Se debe ingresar la identificación del Usuario-Administrador y las direcciones de correo electrónico exigidas para la comunicación con el SII y con otras empresas emisoras de factura Electrónica. El Usuario -Administrador es la persona nominada por el contribuyente, a través de su representante legal, para efectuar las pruebas de certificación, mantener actualizada la información en el sitio Web del SII, nombrar otros usuarios autorizados del contribuyente y en general efectuar operaciones relacionadas con la Factura Electrónica ante el SII. Antes de aceptar la postulación el sistema verificará en línea que la persona que ingresa la postulación sea un Representante Legal de la empresa postulante, y que no existen impedimentos para otorgar la autorización. Una vez aceptada la postulación, la empresa postulante quedará registrada en el ambiente de Certificación del SII y podrá iniciar las pruebas. El SII pondrá a su disposición un archivo con un Set de Pruebas y la documentación que le permitirá iniciar dichas pruebas en el ambiente de Certificación del SII. El Set de Pruebas le indicará un conjunto de datos con los que debe construir un envío de documentos al SII, el que debe ser recibido sin rechazos ni reparos. Como documentación adicional, en el ambiente de Certificación estarán disponibles, para las empresas autorizadas, los Manuales de Operación y de Servicios de operación automática. Si la postulación no fuese aceptada por el SII, se debe aclarar ante el Servicio la situación objetada antes de postular nuevamente. SII-Modelo Factura-Electrónica

18 Agosto 2003 Pág. 6 de 9

Servicio de Impuestos Internos

A través de una opción el contribuyente podrá notificar que completó cada hito exigido en la Certificación, y los antecedentes que permitan al SII verificar su cumplimiento. El proceso de Certificación contempla las siguientes actividades: 1. Envío al SII de los documentos preparados con el Set de Pruebas entregado por el SII, recibido sin rechazos ni reparos. 2. Simulación, que contempla la generación de entre 10 y 100 documentos, con datos representativos de la operación del contribuyente que desea certificarse. 3. Envío de documentos impresos que incluyan el timbre electrónico en representación PDF417. 4. Pruebas de envío de la Información Electrónica de Ventas. 5. Pruebas de envío de la Información Electrónica de Compras. 6. Otras pruebas de envío de otros documentos que debe tener a disposición del SII como registros de guías de despacho, libro de boletas, etc. Si todas las pruebas de certificación se completan exitosamente, el SII emitirá una Resolución que autoriza al contribuyente a operar con la Factura Electrónica y lo registrará en su ambiente de Producción para que comience a generar documentos tributarios electrónicos tributaria y legalmente válidos. El contribuyente podrá comenzar a generar documentos tributarios a partir del período tributario indicado en la Resolución correspondiente.

V.

Boletas de Servicios Electrónicas.

Las boletas electrónicas, se restringirán a las boletas de servicios periódicos, las que se emiten para receptores conocidos y en forma masiva. Con respecto a las boletas de Servicios Periódicos su tratamiento es similar al resto de los documentos con la diferencia de que no se exige firmar cada boleta indiv idual, sino que se firma un resumen, el que será trasladado al libro de ventas.

VI. Resumen de las actividades a efectuar por los contribuyentes para la generación de Documentos Tributarios Electrónicos. Todos los contribuyentes deberán acreditarse ante el SII, efectuando pruebas en un ambiente de certificación que el SII habilitará para ese efecto. A continuación se detalla las principales actividades que el SII recomienda efectuar para ser autorizado a emitir Documentos Tributarios Electrónicos. En la página Web del SII se encuentra la información general y técnica que permite planificar y realizar las actividades indicadas. 1.

Definir los usuarios autorizados por la empresa para solicitar folios autorizados, firmar con sus certificados digitales los docume ntos tributarios electrónicos de su empresa y enviarlos al SII.

2.

Obtener Certificados digitales para los usuarios autorizados por su empresa, definidos en el punto anterior. Estos certificado digitales deben obtenerse de las entidades certificadoras acreditadas ante el SII o ante la Subsecretaría de Economía, para proveer certificados digitales con fines tributarios.

SII-Modelo Factura-Electrónica

18 Agosto 2003 Pág. 7 de 9

Servicio de Impuestos Internos

3.

Diseñar el procedimiento que le permita obtener un rango de folios autorizados desde el SII, vía Internet y alimentar con dicha información su software de facturación o emisión de documentos tributarios electrónicos y cautelar adecuadamente su seguridad.

4.

Adecuar su sistema computacional de facturación para incorporar la generación de los documentos tributarios electrónicos, en el formato estándar definido por el SII, y generar el timbre electrónico de acuerdo con el algoritmo especificado por el SII.

5.

Diseñar un procedimiento que le permita firmar, con llave privada del signatario autorizado, el DTE completo.

6.

Contar con software de manejo de códigos de barra bidimensionales (PDF417) que le permita generar e imprimir un código de barra bidimensional que contenga la información especificada por el SII (el timbre electrónico y la información requerida para verificarlo).

7.

Adecuar sus procedimie ntos y formularios de impresión, para la correcta impresión del documento, según la norma del SII, incluyendo el timbre electrónico en representación gráfica PDF417.

8.

Diseñar la generación computacional de la información de los libros de compra y de venta, en el formato estándar definido por el SII.

9.

Diseñar la generación computacional de la información que el SII podría requerir en forma electrónica para la fiscalización.

10.

Diseñar el mecanismo para enviar los documentos e información de los libros al SII, vía Internet, y al receptor electrónico (contribuyentes incorporados al sistema) los documentos, por el medio que acuerden mutuamente, respetando el estándar mínimo establecido por el SII.

11.

Definir un procedimiento de respaldo y recuperación de DTEs, ya que el ejemplar enviado al SII se conservará sólo para uso tributario.

12.

Contar con lo necesario para realizar la recepción de documentos tributarios electrónicos que le enviarán otros contribuyentes autorizados y que está obligado a recibir. La recepción debe contemplar la emisión del comprobante de recepción y de rechazo, de acuerdo al estándar mínimo establecido por el SII. A este punto se le debe poner mucha atención ya que en el momento de ingresar al sistema empezará a recibir documentos desde otros emisores electrónicos y debe tener muy bien definido cual será el flujo que éstos tomarán al interior de su empresa.

13.

Proveer las opciones de consulta e impresión de información que eventualmente serán utilizadas por los fiscalizadores del SII, en el cumplim iento de su labor.

14.

Postular en www.sii.cl a la emisión de documentos tributarios electrónicos. Esta postulación debe ser hecha por un representante de la empresa, con certificado digital, ingresando los datos requeridos de la empresa.

15.

Obtener Set de pruebas y documentación para certificación. Aprobada la postulación el contribuyente tendrá acceso al ambiente de certificación de SII, a documentación para operar en él y a un set de pruebas que indicará un conjunto de datos con los que debe construir un envío de documentos al SII, el que debe ser recibido sin rechazos ni reparos.

16.

Informar al SII del avance en las pruebas, notificando a través de la página web el éxito de cada hito de la certificación.

SII-Modelo Factura-Electrónica

18 Agosto 2003 Pág. 8 de 9

Servicio de Impuestos Internos

17.

Obtener la Resolución que lo autoriza como Emisor de Documentos Tributarios Electrónicos. Si las pruebas de certificación se completan exitosamente, el SII emitirá una Resolución que autoriza al contribuyente a operar con la Factura Electrónica a partir del período tributario correspondiente.

SII-Modelo Factura-Electrónica

18 Agosto 2003 Pág. 9 de 9

MANUAL PARA EMPRESAS USUARIAS

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA

Fecha Documento: 2 Febrero 2009

2009 Servicio de Impuestos Internos SII – Chile

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

REGISTRO DE CAMBIOS: 26 de Noviembre 2003. Se incorpora paso de Intercambio de documentos en certificación de contribuyentes. 2 de Febrero 2009. Corrección en descripción etapa de Documentos Impresos Actualización del orden de las etapas de Intercambio y Documentos Impresos.

TABLA DE CONTENIDOS

1. DATOS DE LA EMPRESA .............................................................................................. 4 1.1 USUARIOS AUTORIZADOS................................................................................... 5 2. AMBIENTE DE CERTIFICACIÓN................................................................................ 5 2.1 AGREGAR USUARIOS ............................................................................................ 6 2.1 AGREGAR USUARIOS ............................................................................................ 7 2.2 SOLICITUD DE TIMBRAJE ELECTRONICO .................................................... 9 2.3 ENVÍO DE DOCUMENTOS .................................................................................. 12 2.4 CONSULTA DE ENVÍOS ....................................................................................... 14 2.5 OTRAS OPCIONES ................................................................................................ 15 3. DOCUMENTOS TRIBUTARIOS ELECTRONICOS (DTE) ....................................... 17 3.1 Estructura de un DTE.............................................................................................. 17 3.2 Proceso de Validación .............................................................................................. 18 VALIDAR SCHEMA .................................................................................................. 19 VALIDAR FIRMA DIGITAL ..................................................................................... 19 VALIDAR TIMBRE ELECTRONICO SII ................................................................. 19 4. AUTOMATIZACIÓN DE PROCESOS.......................................................................... 20 5. ANEXOS .......................................................................................................................... 21 5.1 DTE DE EJEMPLO ................................................................................................. 21 6. CERTIFICACION........................................................................................................... 26

2 de Febrero de 2009

Pág. 2 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

2009 Servicio de Impuestos Internos SII – Chile

2 de Febrero de 2009

Pág. 3 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

1. DATOS DE LA EMPRESA Su empresa operará en el ambiente de certificación de Documentos Tributarios Electrónicos (DTE en adelante), con los siguientes datos: Rut Emisor, Fecha Resolución, Numero Resolución Documentos Autorizados (TipoDTE) Factura Electrónica (33) Nota de Crédito Electrónica (61) Nota de Débito Electrónica (56) Guía de Despacho Electrónica (52) Confirme estos datos para Su Empresa en la opción “Consultar Empresas Autorizadas”

Usuario Administrador(*) Nombre: RUT: (*) Previamente debe obtener un Certificado Digital (Rut Digital) emitido por alguna de las Empresas acreditadas ante el SII (Ver Proveedores de Certificados Digitales) e-mail Contacto SII: (*) (*) A este correo electrónico se enviarán las respuestas del resultado de los envíos de documentos al SII. Se recomienda utilizar un e-mail genérico destinado exclusivamente a estos fines (ejemplo [email protected] ).

2 de Febrero de 2009

Pág. 4 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

1.1 USUARIOS AUTORIZADOS Inicialmente existe 1 único usuario autorizado, denominado Usuario Administrador, quien a su vez es el único encargado de ingresar otros usuarios al sistema. Los Usuarios Autorizados deben cumplir con: Estar autenticados ante el sitio web del SII, es decir debe poseer Rut-Clave en el SII Visite el web SII, bajo la Opción “Clave Secreta y Certificado Digital” (Fig.1)

Poseer un Certificado Digital extendido para su RUT personal, por alguna de las empresas Certificadoras autorizadas por el SII (Acepta.com, E-CertChile, Once). Modificar su modalidad de autenticación ante el SII para que acepte su Certificado Digital. Recomendamos dejar habilitada la autenticación con ambas opciones (Rut clave y Certificado Digital) (Fig. Fig.1

Fig.2

2. AMBIENTE DE CERTIFICACIÓN El SII ofrece un ambiente de pruebas para los contribuyentes que desean ingresar al sistema, a través de un ambiente de certificación que es idéntico al ambiente que utilizan las empresas que ya están operando con el sistema de facturación electrónica. Ingrese a la siguiente dirección web: https://maullin.sii.cl/cvc/dte/certificacion_dte.html (*) Se recomienda utilizar Internet Explorer versión 5.5 o superior.

2 de Febrero de 2009

Pág. 5 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

(*) Previamente debe tener instalado su Certificado Digital para acceder a las opciones para contribuyentes autorizados y estar dentro de la lista de usuarios autorizados de la empresa (Capítulo 1. Usuarios Autorizados). En adelante nos referiremos a las opciones indicadas bajo el título de “Opciones para contribuyentes autorizados (*)

2 de Febrero de 2009

Pág. 6 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

2.1 AGREGAR USUARIOS Esta opción es realizada solamente por el Usuario Administrador. Puede agregar cuantos usuarios quiera y darle las atribuciones o perfiles que se indican: El Usuario Administrador debe ingresar a la Opción “Mantención de Usuarios Autorizados”, y digitar el Rut de la empresa.

en donde inicialmente se muestra la lista de usuarios y el perfil o atributo que tiene: Actualmente hay 5 atributos asociados a un Usuario Autorizado: 1. Usuario Administrador: Tiene el atributo de poder hacer Mantención de Usuarios, Agregar, Eliminar, o Modificar perfiles. 2. Solicitar Folio: Persona autorizada a solicitar Rango de Folios. 3. Anular Folio: Persona autorizada para anular Folios 4. Firmar Doctos: Persona autorizada a Firmar Documentos Electrónicos 5. Enviar Doctos: Persona autorizada a hacer los Envios de documentos al SII y a firmar el envio de DTE.

2 de Febrero de 2009

Pág. 7 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

Al ingresar un nuevo usuario debe ingresar el RUT y el (los) perfil (es) correspondiente a la función que ejecutará (Fig.3)

Fig. 3

Estos perfiles son independientes entre sí y un Usuario puede tener uno o varios atributos. A modo de ejemplo, el Usuario Administrador inicialmente tiene solamente el atributo de Usuario Administrador, es decir no puede Solicitar Folios o Enviar documentos. Para realizar esas tareas debe habilitar para sí mismo los respectivos atributos.

2 de Febrero de 2009

Pág. 8 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

2.2 SOLICITUD DE TIMBRAJE ELECTRONICO Ingrese a la opción “Solicitud de Timbraje Electrónico de Documentos”. Luego de identificarse con su Certificado Digital, ingrese el RUT de la Empresa, seleccione el Tipo de Documento y digite la cantidad de folios solicitados. (Fig.5) (*) El usuario que ingresa a esta opción debe tener perfil para “Solicitar Folios”

Fig.5

Luego se le pide confirmar la solicitud, para lo cual debe pinchar el botón “Obtener Folios”. Entonces aparece un Comprobante de Solicitud de Folios, que se recomienda imprimir para sus registros internos. (Fig.6)

2 de Febrero de 2009

Pág. 9 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

Fig.6

2 de Febrero de 2009

Pág. 10 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

Desde esta pantalla puede bajar el archivo xml que contiene el Código de Autorización de Folios (CAF).

Fig.7 CAF

2 de Febrero de 2009

Pág. 11 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

2.3 ENVÍO DE DOCUMENTOS Ir a la opción “Envío de Documentos Tributarios Electrónicos” del menú de contribuyentes autorizados. (Fig.8) (*) El usuario que ingresa a esta opción debe tener perfil para “Enviar Documentos”

Fig.8 Ingrese el Rut de la Empresa y Seleccione el archivo a enviar (debe tener extensión *.xml).

2 de Febrero de 2009

Pág. 12 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

El Sistema le entregará una respuesta en donde se indica los datos del envío (fecha, hora, Rut Empresa, Rut Enviador) y en la esquina superior derecha un Identificador de envío, con el cual podrá posteriormente consultar el resultado de la validación (Documentos Aceptados, Rechazados). (Fig.9)

Fig.9

2 de Febrero de 2009

Pág. 13 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

2.4 CONSULTA DE ENVÍOS Ir a la opción “Consulta Estado de un Envío”, ingrese el Rut de la Empresa y el “Identificador de Envío” que fue entregado al momento de realizar el envío. (Fig.10)

Fig.10

En forma posterior a la revisión del envío también se genera un e-mail con la respuesta de la validación del envío, en donde se indican fecha, hora, Ruts, e identificador del envío.

2 de Febrero de 2009

Pág. 14 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

Existe la opción “Historia de Envíos” que entrega un resumen de los últimos envíos realizado por la Empresa (Fig.11)

Fig.11

2.5 OTRAS OPCIONES Para las empresas autorizadas también existen las siguientes opciones: Anulación de Folios : Para inutilizar o anular 1 o más folios. Reobtención de Folios: Para obtener un nuevo archivo CAF de un Rango que había sido autorizado anteriormente. Si por algún motivo necesita una copia del archivo de autorización que realizó anteriormente. Información de Timbrajes Históricos: Resumen de todas las Solicitudes de Folio autorizadas por el SII, fecha, rango y quién lo solicitó. Consulta de Folios Anulados: Resumen de todas las Solicitudes de Folio autorizadas por el SII, fecha, rango y quién lo solicitó. Consulta entre Contribuyentes Autorizados: Permite a una empresa conocer datos de otras empresas autorizadas como los documentos que tiene autorizado emitir y la dirección del correo electrónico que tiene destinada al intercambio de documentos electrónicos con otras empresas. Documentación para empresas autorizadas: Documentación técnica que incluye la documentación necesaria para operar en el sistema, las instrucciones para construir el set de prueba de certificación y la documentación de los servicios automáticos.

2 de Febrero de 2009

Pág. 15 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

Actualización de Datos de la Empresa: Opción habilitada para Representantes Legales de las empresas, en que pueden cambiar el Usuario Administrador y los datos de correos y otros que se ingresaron en la postulación. Para todos los contribuyentes que ingresan al sitio web del SII se encuentran disponibles las opciones de consulta de: -

Empresas Autorizadas. Es un listado de las empresas autorizadas por el SII a emitir documentos electrónicos.

-

Verificación del contenido de un documento electrónico. Previo ingreso de los datos relevantes de un documentos (Ruts, fecha, montos) el SII responde acerca de si ese documento ha sido recibido y si los datos ingresados coinciden.

2 de Febrero de 2009

Pág. 16 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

3. DOCUMENTOS TRIBUTARIOS ELECTRONICOS (DTE) 3.1 Estructura de un DTE Los DTE tienen estructura de un archivo xml en donde se distinguen las siguientes secciones: -

SetDTE, sección del documento que contiene toda la data del envío, esto es la Carátula y 1 o más DTE, y su respectiva firma electrónica Carátula, sección que contiene los datos principales de quien hace el envío, a quién va dirigido, y el tipo y cantidad de documentos que contiene el envío. DTE, sección que contiene la data de un único Documento y su respectiva firma electrónica. Documento, sección que contiene la información en detalle del dte, emisor, receptor, ítems de detalle, etc Signature, sección que contiene la firma electrónica y los parámetros con los cuales fue generada, de acuerdo al estándar XML Digital Signature.

Fig. Estructura de un DTE El detalle completo del formato de un DTE se encuentra en la especificación del schema. -> Ver archivo: EnvioDTE_v10.xsd

2 de Febrero de 2009

Pág. 17 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

3.2 Proceso de Validación Los DTE recibidos por el SII pasan por un proceso de validación cuyo resultado puede ser uno de los siguientes: -

Envío Procesado: El envío completo fue validado de acuerdo al schema y su firma electrónica. Sin embargo en su interior pueden haber documentos Aceptados o Rechazados, a nivel individual. Se individualizan los documentos que presentan algún Reparo o que han sido Rechazados.

-

Envío Rechazado. El envío completo es rechazado, ningún documento contenido dentro del envío fue aceptado. Generalmente esto es debido a errores de Schema, error en la firma del envío, o usuario no autorizado. Estos documentos deben ser reenviados por la empresa una vez corregido los errores.

El siguiente diagrama muestra las validaciones generales por las que pasa un envío.

Para el envío de documentos tributarios electrónicos (DTE) válidos recomendamos seguir los siguientes pasos: 1- Validar Schema 2- Validar Firma Digital 3- Validar Timbre Electrónico SII 2 de Febrero de 2009

Pág. 18 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

VALIDAR SCHEMA Los DTE deben ser validados contra el schema EnvioDTE_v10.xsd (disponible en sitio web SII). Como primer paso es imprescindible ajustar el formato de los documentos a esta especificación. Existen software para verificar un xml contra un schema, lo cual facilita la validación sin tener que enviar al SII y esperar la respuesta. (Ej. XMLSpy.com) Otra alternativa es utilizar herramientas de validación en internet, por ejemplo visite la web: http://apps.gotdotnet.com/xmltools/xsdvalidator/

VALIDAR FIRMA DIGITAL Una vez aprobada la validación de schema se procede a verificar la firma digital. Esta firma digital debe ajustarse al estándar “XML Digital Signature” visitar link http://www.w3c.org/Signature/ En esa misma dirección se informan sobre librerías para el desarrollo en diferentes plataformas (Java, C, .Net, etc). Algunas de estas librerías son gratuitas y otras comerciales para el desarrollo de aplicaciones para este tipo de firma.

VALIDAR TIMBRE ELECTRONICO SII Como un tercer paso sugerimos dedicarse a generar un Timbre Electrónico SII válido, de acuerdo a las especificaciones indicadas en la documentación técnica disponible en el sitio web del SII. La firma del Timbre Electrónico es una firma RSA Standard (PKCS#1), en donde el método de hashing es SHA-1, la llave privada (Private Key) es la que entrega el SII dentro del Código de Autorización de Folios (CAF), y el Mensaje a firmar es un string formado de acuerdo a lo indicado en la documentación técnica.

2 de Febrero de 2009

Pág. 19 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

4. AUTOMATIZACIÓN DE PROCESOS En forma opcional las empresas pueden implementar la automatización de los procesos de envío de documentos al SII y de consulta de los mismos. Para ello el SII ha implementado estas funcionalidades a través de webservices. Existe documentación para los siguientes webservices: -

Autenticación con Certificado Digital Upload automático (*) Consulta Estado de un Envío Verificación Detalle de un DTE

(*) El upload automático no es un webservice sino una emulación de la conexión https, pero su documentación está asociada a las especificaciones del webservice de autenticación.

2 de Febrero de 2009

Pág. 20 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

5. ANEXOS 5.1 DTE DE EJEMPLO Se adjunta el siguiente documento de ejemplo de acuerdo a los siguientes datos de una Empresa ficticia: Rut Emisor: Rut Envia: Fecha Resolución: Numero Resolución: Tipo DTE: Folio: NroDTE:

97975000-5 (Rut Empresa) 7880442-4 (Rut Usuario autorizado a Enviar) 2002-10-20 (Variable particular para cada Empresa) 0 (Valor fijo en Ambiente de Certificación) 33 (Factura Electrónica) 1582 1 (Cantidad Total de DTE incluidos en este envio)

Este es un archivo DTE válido en el ambiente de Certificación.



97975000-5 7880442-4 60803000-K 2003-09-02 0 2003-09-08T12:31:59

33 1



33 27 2003-09-08

97975000-5 RUT DE PRUEBA Insumos de Computacion 31341 1234 Teatinos 120, Piso 4 Santiago Santiago

8414240-9 JORGE GONZALEZ LTDA COMPUTACION SAN DIEGO 2222

2 de Febrero de 2009

Pág. 21 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII LA FLORIDA SANTIAGO

426226 18 76720 502946

1

INT1 011

Cajon AFECTO

139 1807 251173

2

INT1 022

Relleno AFECTO

59 2967 175053

1 SET 1 2003-08-01 1 Caso 4256-1

97975000-5 33 27 2003-09-08 8414240-9 JORGE GONZALEZ LTDA 502946 Cajon AFECTO

97975000-5 RUT DE PRUEBA 33

1 200

2003-09-04

0a4O6Kbx8Qj3K4iWSP4w7KneZYeJ+g/prihYtIEolKt3cykSxl1zO8vSXu397QhTmsX7SBEudTUx++2zDXBhZw == Aw==

100

g1AQX0sy8NJugX52k2hTJEZAE9Cuul6pqYBdFxj1N17umW7zG/hAavCALKByHzdYAfZ3LhGT XCai5zNxOo4lDQ==

2 de Febrero de 2009

Pág. 22 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

2003-09-08T12:28:31

pqjXHHQLJmyFPMRvxScN7tYHvIsty0pqL2LLYaG43jMmnfiZfllLA0wb32lP+HBJ /tf8nziSeorvjlx410ZImw==

2003-09-08T12:28:31







C9T6trZSt8zZUQK2+YUkYuIw5pE=

kAxNuhGppcs1mTd6sXYGwy+etbKBlOqboMvnO2qyARJYmibHEGb3NOsunmPQS8D+ZHZH/QENE47m wVSKb/HgqjfIU1zsQcxEnTLQgbG9H6JYmSVXNh5DfVYXFmIDv/1kQOoeu8w8zPLeGLSQzVZ2fK9M9zzcUGWRWvZ6aNP p59o=



tNEknkb1kHiD1OOAWlLKkcH/UP5UGa6V6MYso++JB+vYMg2OXFROAF7G8BNFFPQx iuS/7y1azZljN2xq+bW3bAou1bW2ij7fxSXWTJYFZMAyndbLyGHM1e3nVmwpgEpx BHhZzPvwLb55st1wceuKjs2Ontb13J33sUb7bbJMWh0=

AQAB



MIIEPjCCA6mgAwIBAgIDAgGKMAsGCSqGSIb3DQEBBDCBsTEdMBsGA1UECBQUUmVn aW9uIE1ldHJvcG9saXRhbmExETAPBgNVBAcUCFNhbnRpYWdvMSIwIAYDVQQDFBlF LUNlcnRjaGlsZSBDQSBJbnRlcm1lZGlhMTYwNAYDVQQLFC1FbXByZXNhIE5hY2lv bmFsIGRlIENlcnRpZmljYWNpb24gRWxlY3Ryb25pY2ExFDASBgNVBAoUC0UtQ0VS VENISUxFMQswCQYDVQQGEwJDTDAeFw0wMjEwMDIxOTExNTlaFw0wMzEwMDIwMDAw MDBaMIHXMR0wGwYDVQQIFBRSZWdpb24gTWV0cm9wb2xpdGFuYTEnMCUGA1UECxQe U2VydmljaW8gZGUgSW1wdWVzdG9zIEludGVybm9zMScwJQYDVQQKFB5TZXJ2aWNp byBkZSBJbXB1ZXN0b3MgSW50ZXJub3MxETAPBgNVBAcUCFNhbnRpYWdvMR8wHQYJ KoZIhvcNAQkBFhB3Z29uemFsZXpAc2lpLmNsMSMwIQYDVQQDFBpXaWxpYmFsZG8g R29uemFsZXogQ2FicmVyYTELMAkGA1UEBhMCQ0wwXDANBgkqhkiG9w0BAQEFAANL ADBIAkEAvNQyaLPd3cQlBr0fQWooAKXSFan/WbaFtD5P7QDzcE1pBIvKY2Uv6uid ur/mGVB9IS4Fq/1xRIXy13FFmxLwTQIDAQABo4IBgjCCAX4wIwYDVR0RBBwwGqAY BggrBgEEAcNSAaAMFgowNzg4MDQ0Mi00MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6 Ly9jcmwuZS1jZXJ0Y2hpbGUuY2wvRWNlcnRjaGlsZUNBSS5jcmwwIwYDVR0SBBww GqAYBggrBgEEAcEBAqAMFgo5NjkyODE4MC01MIHmBgNVHSAEgd4wgdswgdgGCCsG AQQBw1IAMIHLMDYGCCsGAQUFBwIBFipodHRwOi8vd3d3LmUtY2VydGNoaWxlLmNs L3BvbGl0aWNhL2Nwcy5odG0wgZAGCCsGAQUFBwICMIGDGoGARWwgdGl0dWxhciBo YSBzaWRvIHZhbGlkYWRvIGVuIGZvcm1hIHByZXNlbmNpYWwsIHF1ZWRhbmRvIGhh YmlsaXRhZG8gZWwgQ2VydGlmaWNhZG8gcGFyYSB1c28gdHJpYnV0YXJpbywgcGFn b3MsIGNvbWVyY2lvIHUgb3Ryb3MwCwYDVR0PBAQDAgTwMAsGCSqGSIb3DQEBBAOB gQB2V4cTj7jo1RawmsRQUSnnvJjMCrZstcHY+Ss3IghVPO9eGoYzu5Q63vzt0Pi8 CS91SBc7xo+LDoljaUyjOzj7zvU7TpWoFndiTQF3aCOtTkV+vjCMWW3sVHes4UCM DkF3VYK+rDTAadiaeDArTwsx4eNEpxFuA/TJwcXpLQRCDg==









2 de Febrero de 2009

Pág. 23 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII z4vLb55G61Q3156xX9/PiUR0d5A=

FD0hdAwcAk/UkpPZHZfKRDdgN2x0MtLgcXBgkyloo2Q5Ufd7KQrbIwqydNtS3KKWcoAVjQ9C7UeWN1xM R8KD1p07Lt/Yq1Fr1rbq4/naTFEN4AlMlx3R8Z3oZcjB7Jq+Buazeff4iadPWdw0osz6/eQlfyUe/TSRV9mnz8Azok8=



tNEknkb1kHiD1OOAWlLKkcH/UP5UGa6V6MYso++JB+vYMg2OXFROAF7G8BNFFPQx iuS/7y1azZljN2xq+bW3bAou1bW2ij7fxSXWTJYFZMAyndbLyGHM1e3nVmwpgEpx BHhZzPvwLb55st1wceuKjs2Ontb13J33sUb7bbJMWh0=

AQAB



MIIEPjCCA6mgAwIBAgIDAgGKMAsGCSqGSIb3DQEBBDCBsTEdMBsGA1UECBQUUmVn aW9uIE1ldHJvcG9saXRhbmExETAPBgNVBAcUCFNhbnRpYWdvMSIwIAYDVQQDFBlF LUNlcnRjaGlsZSBDQSBJbnRlcm1lZGlhMTYwNAYDVQQLFC1FbXByZXNhIE5hY2lv bmFsIGRlIENlcnRpZmljYWNpb24gRWxlY3Ryb25pY2ExFDASBgNVBAoUC0UtQ0VS VENISUxFMQswCQYDVQQGEwJDTDAeFw0wMjEwMDIxOTExNTlaFw0wMzEwMDIwMDAw MDBaMIHXMR0wGwYDVQQIFBRSZWdpb24gTWV0cm9wb2xpdGFuYTEnMCUGA1UECxQe U2VydmljaW8gZGUgSW1wdWVzdG9zIEludGVybm9zMScwJQYDVQQKFB5TZXJ2aWNp byBkZSBJbXB1ZXN0b3MgSW50ZXJub3MxETAPBgNVBAcUCFNhbnRpYWdvMR8wHQYJ KoZIhvcNAQkBFhB3Z29uemFsZXpAc2lpLmNsMSMwIQYDVQQDFBpXaWxpYmFsZG8g R29uemFsZXogQ2FicmVyYTELMAkGA1UEBhMCQ0wwXDANBgkqhkiG9w0BAQEFAANL ADBIAkEAvNQyaLPd3cQlBr0fQWooAKXSFan/WbaFtD5P7QDzcE1pBIvKY2Uv6uid ur/mGVB9IS4Fq/1xRIXy13FFmxLwTQIDAQABo4IBgjCCAX4wIwYDVR0RBBwwGqAY BggrBgEEAcNSAaAMFgowNzg4MDQ0Mi00MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6 Ly9jcmwuZS1jZXJ0Y2hpbGUuY2wvRWNlcnRjaGlsZUNBSS5jcmwwIwYDVR0SBBww GqAYBggrBgEEAcEBAqAMFgo5NjkyODE4MC01MIHmBgNVHSAEgd4wgdswgdgGCCsG AQQBw1IAMIHLMDYGCCsGAQUFBwIBFipodHRwOi8vd3d3LmUtY2VydGNoaWxlLmNs L3BvbGl0aWNhL2Nwcy5odG0wgZAGCCsGAQUFBwICMIGDGoGARWwgdGl0dWxhciBo YSBzaWRvIHZhbGlkYWRvIGVuIGZvcm1hIHByZXNlbmNpYWwsIHF1ZWRhbmRvIGhh YmlsaXRhZG8gZWwgQ2VydGlmaWNhZG8gcGFyYSB1c28gdHJpYnV0YXJpbywgcGFn b3MsIGNvbWVyY2lvIHUgb3Ryb3MwCwYDVR0PBAQDAgTwMAsGCSqGSIb3DQEBBAOB gQB2V4cTj7jo1RawmsRQUSnnvJjMCrZstcHY+Ss3IghVPO9eGoYzu5Q63vzt0Pi8 CS91SBc7xo+LDoljaUyjOzj7zvU7TpWoFndiTQF3aCOtTkV+vjCMWW3sVHes4UCM DkF3VYK+rDTAadiaeDArTwsx4eNEpxFuA/TJwcXpLQRCDg==



2 de Febrero de 2009

Pág. 24 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

5.2 TIMBRE ELECTRONICO DE EJEMPLO Para el ejemplo anterior (5.1) el timbre fue generado como sigue: 1) Del xml indicado se arma el string que será firmado (Mensaje) Mensaje= 97975000-533272003-09-08 8414240-9JORGE GONZALEZ LTDA502946Cajon AFECTO979750005RUT DE PRUEBA331200 2003-09-040a4O6Kbx8Qj3K4iWSP4w7KneZYe J+g/prihYtIEolKt3cykSxl1zO8vSXu397QhTmsX7SBEudTUx++2zDXBhZw==< /M>Aw==100g1AQX0sy8NJugX52k2hTJEZAE9Cuul6pqYBdFxj1N17umW7zG/hAa vCALKByHzdYAfZ3LhGTXCai5zNxOo4lDQ==2003-09 -08T12:28:31

2) Desde el Código de Autorización de Folios (CAF) el SII entrega la llave privada en formato PEM con la cual se firmará el Mensaje. -----BEGIN RSA PRIVATE KEY----MIIBOwIBAAJBANGuDuim8fEI9yuIlkj+MOyp3mWHifoP6a4oWLSBKJSrd3MpEsZd czvL0l7t/e0IU5rF+0gRLnU1Mfvtsw1wYWcCAQMCQQCLyV9FxKFLW09yWw7bVCCd xpRDr7FRX/EexZB4VhsNxm/vtJfDZyYle0Lfy42LlcsXxPm1w6Q6NnjuW+AeBy67 AiEA7iMi5q5xjswqq+49RP55o//jqdZL/pC9rdnUKxsNRMMCIQDhaHdIctErN2hC IP9knS3+9zra4R+5jSXOvI+3xVhWjQIhAJ7CF0R0S7SIHHKe04NUURf/7RvkMqm1 08k74sdnXi3XAiEAlkWk2vc2HM+a1sCqQxNz/098ketqe7NuidMKeoOQObMCIQCk FAMS9IcPcMjk7zI2r/4EEW63PSXyN7MFAX7TYe25mw== -----END RSA PRIVATE KEY-----

3) El resultado obtenido de la firma RSA-SHA1, utilizado la llave privada 2) sobre el mensaje 1) es: pqjXHHQLJmyFPMRvxScN7tYHvIsty0pqL2LLYaG43jMmnfiZfllLA0wb32lP+HBJ /tf8nziSeorvjlx410ZImw==

2 de Febrero de 2009

Pág. 25 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

6. CERTIFICACION La Certificación es un proceso compuesto por varios pasos en cada uno de los cuales los postulantes van completando las pruebas solicitadas y declarando su avance al SII. Una vez terminadas las pruebas, el postulante debe efectuar una declaración en donde señala que además de haber completado exitosamente las pruebas requeridas, cuenta en su instalación con los procedimientos y condiciones solicitados por el SII para generar y recibir adecuadamente documentos tributarios electrónicos. El proceso de certificación contempla los siguientes pasos: 1. Set de Prueba asignado por el SII. 2. Simulación. 3. Intercambio de Información 4. Envío de Muestras de Impresión. 5. Declaración de Cumplimiento de Requisitos. 6. Autorización del Contribuyente. Si todas las pruebas de certificación se completan exitosamente, el Postulante será autorizado por el SII para operar con la Factura Electrónica A continuación se describen en detalle los pasos de la certificación 1. Set de Prueba asignado por el SII. Este paso consiste en la recepción en el SII, sin rechazos ni reparos, de un envío de documentos que el postulante construye en base a un archivo con datos de prueba que el SII genera en forma única para cada Postulante, en función de su giro y de los documentos que desea certificar. Además de documentos tributarios electrónicos, en este paso los Postulantes deben enviar también al SII, como parte de las pruebas, la Información Electrónica de Ventas y la Información Electrónica de Compras. Se recomienda realizar el Set de Pruebas, una vez que Ud. haya realizado pruebas de envíos exitosos al SII (Aceptados sin Reparos). En cualquier momento, además, tiene la opción de obtener un nuevo Set de Pruebas (Fig. “Generación Nuevo Set de Pruebas”). Recuerde que los envíos correspondientes al Set de Prueba serán evaluados respecto al último Set de Pruebas que haya bajado. Para la construcción de los Documentos Tributarios Electrónicos, así como la Información Electrónica de Ventas y Información Electrónica de Compras, con los datos del Set de Pruebas entregado por el SII, se deben seguir las indicaciones del documento “Instrucciones para la Construcción del Set de Prueba”, disponible en la opción “Documentación para Empresas Autorizadas”. Los envíos con los documentos generados a partir de los datos del set de prueba deben ser enviados al SII dentro del plazo de 2 meses contados a partir del momento de obtener el set de prueba. Los envíos que excedan ese plazo serán rechazados y el postulante deberá Generar un Nuevo Set de pruebas para realizar las pruebas. El postulante puede iterar 2 de Febrero de 2009

Pág. 26 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

cuanto desee enviando archivos correspondientes al set de prueba. Cuando el resultado de la validación de dichos envíos resulte sin rechazos ni reparos el usuario administrador puede declararlos para la revisión del SII. Esta revisión consistirá en comprobar que el envío haya sido realizado con los datos del set de prueba entregado al postulante. Usando la opción Declarar Avance de la Postulación, el Postulante puede informar al SII que completó exitosamente el Set de Pruebas, señalando la fecha y número de cada envío para permitir al SII verificar su validez. Una vez que el SII haya verificado que el postulante completó satisfactoriamente el set de prueba, el SII le permitirá avanzar al siguiente paso, la Simulación.

2. Simulación. La simulación es una etapa que contempla la generación de un envío, recibido en el SII sin rechazos ni reparos, con los documentos tributarios electrónicos correspondientes a su facturación de los últimos 2 meses, con un máximo de 100 documentos, con datos representativos, paralelos de la operación real del contribuyente que desea certificarse. En el caso de los contribuyentes con gran volumen de facturación, los 100 documentos pueden corresponder a un sólo mes y en el caso de las empresas con bajo volumen de facturación, los documentos pueden abarcar un período de más de 2 meses, con un mínimo de 10 documentos, si no tiene facturación suficiente. El Servicio chequeará el número de documentos enviados en la Simulación con el volumen histórico de timbraje de papeles. Usando la opción Declarar Avance de la Postulación, el Postulante puede informar al SII que completó exitosamente la simulación, señalando la fecha y número de envío para permitir al SII verificar su validez Una vez que el SII haya verificado que el postulante completó satisfactoriamente la simulación, se le permitirá avanzar al siguiente paso, las pruebas de impresión

3. Intercambio de Información En esta etapa el SII envía documentos tributarios electrónicos al contribuyente postulante para comprobar que éste entrega un acuse de recibo del envío y la aceptación o rechazo de los documentos enviados, de acuerdo a las definiciones que el SII ha establecido para el intercambio de información entre contribuyentes autorizados. El SII hará envío de DTEs, a la casilla de correo electrónico que el postulante tiene registrada en el SII como Mail de Contacto Empresas. El postulante deberá enviar un acuse de recibo del envío y la aceptación o rechazo de los documentos de acuerdo al schema XML establecido por el SII para el intercambio de información entre contribuyentes autorizados a la siguiente casilla: [email protected]

2 de Febrero de 2009

Pág. 27 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

Una vez que el SII haya revisado y verificado la consistencia de las respuestas enviadas, se considera que la empresa ha superado la prueba de Intercambio de Información y la empresa pasará a la siguiente etapa del proceso de certificación.

4. Pruebas de Impresión de DTEs. Esta etapa considera la entrega al SII de la imagen de un conjunto de documentos impresos de acuerdo a la normativa y que incluyan el timbre electrónico en representación PDF417. Estas imágenes se deben entregar en un archivo de tipo PDF adjunto a un correo electrónico enviado a la siguiente casilla: [email protected]. El archivo enviado al SII debe contener la imagen de la impresión de todos los documentos del set de pruebas además de 10 documentos de la etapa de simulación, representativos de todos los tipos de documentos con que el postulante operará. Una vez que el SII haya revisado y aprobado las imágenes de impresión enviadas, se considera que la empresa ha superado las pruebas de certificación y que está preparada para que el Representante Legal haga en el web, en la opción correspondiente, la declaración de cumplimiento de requisitos

5. Declaración de Cumplimiento de Requisitos Una vez realizadas correctamente todas las pruebas de Certificación el contribuyente deberá declarar en el web del SII, a través de su representante legal, que se obliga a cumplir con las resoluciones del SII que norman el sistema de Facturación Electrónica y cuenta con la implementación de procedimientos formales y establecidos, que podrán ser auditados por el SII, que realicen adecuadamente las siguientes funciones, estimadas críticas: a) Gestión de Códigos de Autorización de Folios (almacenamiento y control de acceso). b) Foliación controlada (asignación única de cada folio autorizado por el SII). c) Respaldo de los documentos e información generada. d) Envío de documentos al SII. e) Intercambio (envío y recepción) de documentos con otros contribuyentes f) Cuadratura de envíos aceptados, rechazados y aceptados con reparos por el SII g) Administración de contingencias.

2 de Febrero de 2009

Pág. 28 de 29

AMBIENTE DE CERTIFICACIÓN FACTURA ELECTRONICA - SII

Adicionalmente el representante legal del contribuyente declarará conocer las obligaciones que emanan de la resolución que lo autorizará a operar en el sistema de documentos tributarios electrónicos.

6. Autorización del Contribuyente Si todas las pruebas de certificación se completan exitosamente, y el Postulante, a través de su Representante Legal, efectúa la declaración de cumplimiento de Requisitos, el SII emitirá una Resolución que autoriza al contribuyente a operar con Documentos Tributarios Electrónicos y lo registrará en su ambiente de Producción para que comience a generar documentos tributarios electrónicos legalmente válidos a partir del período tributario indicado en dicha Resolución.

2 de Febrero de 2009

Pág. 29 de 29

INSTRUCCIONES PARA LA CONSTRUCCIÓN DE DOCUMENTOS ELECTRÓNICOS CON LOS DATOS DEL SET DE PRUEBAS.

TRIBUTARIOS

INTRODUCCIÓN Este es el primer paso del proceso de certificación para convertirse en emisor, autorizado por el SII, de Factura Electrónica. Varias de las actividades que debe efectuar el Usuario Administrador para completar esta etapa se realizan a través de las opciones del ambiente de Certificación (también conocido como ambiente de pruebas), por lo que recomendamos obtener el Manual de Operación desde el submenú “Documentación para Empresas Autorizadas”. En dicho Manual se describen las opciones disponibles en el ambiente de Certificación que el SII ha habilitado para que las empresas postulantes efectúen las pruebas. En esta primera etapa del proceso de certificación el Usuario Administrador debe enviar al SII documentos tributarios electrónicos preparados con los datos entregados por el SII en el Set de Pruebas y generados de acuerdo al formato XML establecido por el SII. I.- RESPECTO A LA CONFECCIÓN DE CADA DOCUMENTO 1. 2. 3. 4.

Ud. ha recibido un conjunto de datos que debe utilizar para confeccionar los documentos de prueba. Previo a emitir los documentos debe solicitar folios por tipo de documento. Debe generar un documento DTE para cada caso incluido en el SET. Para generar cada documento del SET: a. Asigne un folio autorizado. b. Agregue un Rut receptor de un cliente existente. Utilice RUT distintos para las distintas facturas. c. Agregue fecha del día. d. En la glosa del ítem debe anotar exactamente lo indicado en el caso; debe incluir acentos, ñ u otros que se indiquen. No debe agregar líneas adicionales de ítems. e. Debe registrar los valores de cantidad y precio unitario que se indiquen en cada caso. - En el Caso de las Notas de Crédito por devolución de mercaderías, el precio unitario debe corresponder al precio de la Factura original. - En el caso de Notas de Crédito por diferencia de precio, la diferencia se debe aplicar a todas las unidades del ítem respectivo f. Las líneas de detalle deben ir en el orden especificado. g. Utilice la tasa del IVA que corresponda a la fecha de emisión del DTE.

5.

En el sector encabezado: Calcule los valores de Monto Neto, Exento y otros, que correspondan según el caso. Asegúrese de incorporar todos los datos que son obligatorios, según el tipo de documento y el caso.

6.

En el sector de referencias: En la primera línea de referencia de cada DTE del set de prueba debe indicar: -

El texto “SET“ como “Tipo de Documento de Referencia” y El texto “CASO xxxxx-x” en el campo “Razón referencia”

Como ejemplo, si ha confeccionado un DTE del Set de prueba, cuyo N° de caso es 1062-1,

Ud. debe agregar en el campo correspondiente a “tipo de documento de referencia” la palabra SET y en el campo “Razón referencia” el texto CASO 1062-1 Las otras referencias que sea preciso agregar dado el tipo de documento correspondiente a la prueba, deben ir a partir de la línea 2. II.- RESPECTO AL ENVIO DEL SET DE PRUEBAS Mientras realice las pruebas, puede enviar los documentos en tantos envíos como desee, pero en el envío de los Set reportados para la Revisión del SII, debe incluir todos los documentos de los Sets de pruebas y en el mismo orden en que le fueron entregados. En la carátula de cada envío debe indicar: Rut del Contribuyente Rut del firmante autorizado (quien envía) Rut del Receptor. Indicar Rut 60803000-K, que corresponde al RUT del SII Número y Fecha de Resolución: Indique el número y fecha que está publicado en los datos de su empresa en el ambiente de certificación Tipos de documentos enviados y cantidad de cada uno Si envía un documento del Set de prueba y éste es aceptado con reparos, deberá usar un folio distinto para enviar el documento nuevamente, ya que en caso contrario el documento será rechazado por folio duplicado. III.- RESPECTO A LA CONFECCIÓN DEL ARCHIVO INFORMACIÓN ELECTRONICA DE VENTAS (IEV) Debe confeccionar este Libro, incorporando sólo la información de los documentos que son parte de sus SET de prueba y que han sido reportados para revisión. En el Archivo IEV, se deben incluir Facturas, Notas de Crédito y Notas de Débito electrónicas. 1.

2. 3.

Zona Carátula: Debe indicar la siguiente información: Rut del Contribuyente Rut del firmante autorizado Período Tributario: Los documentos del SET de prueba deben ser emitidos de forma que sean todos del mismo período tributario. En la carátula deberá indicarse ese período tributario. Número y Fecha de Resolución: Indique el número y fecha que está publicado en los datos de su empresa en el ambiente de certificación Tipo de Operación. Venta Tipo de Libro: ESPECIAL Tipo de envío: TOTAL Folio Notificación: Registrar 1 Zona Resumen período: Debe entregar totalizados los campos por tipo de documento Zona Detalle: Debe registrar para cada documento del SET de Prueba Los datos contenidos del documento

Agregar datos obligatorios en caso que se requiera. Verificar el documento “Formato Información Electrónica de Compras y Ventas” . IV.- RESPECTO A LA CONFECCIÓN DEL ARCHIVO INFORMACIÓN ELECTRONICA DE COMPRAS Ud. debe confeccionar este Libro, incorporando sólo la información de los documentos que se le han entregado en el SET de prueba de Libro de Compras. 1.

Zona Carátula: Debe indicar la siguiente información: Rut del Contribuyente Rut del firmante autorizado Período Tributario: Se asume que el período tributario es el mismo del Libro de Ventas. Número y Fecha de Resolución: Indique el número y fecha que está publicado en los datos de su empresa en el ambiente de certificación Tipo de Operación. Compra Tipo de Libro: ESPECIAL Tipo de envío: TOTAL Folio Notificación: Registrar 2

2.

Zona Resumen período: Debe entregar totalizados los campos por tipo de documento

3.

Zona Detalle: Debe registrar la información que se le ha entregado en el Set respectivo Considerar los datos informados en el Set de prueba de Compras. Calcular los datos que se requieran para completar la información necesaria de un documento de compra; se deberá completar, según sea el caso, el Monto Neto, Exento, tasa de IVA, IVA, Monto Total. Agregar datos del emisor del documento para lo cual se deberán usar Rut válidos. Agregar otros datos obligatorios que se requieran según el documento y sus características. Verificar el documento “Formato Información Electrónica de Compras y Ventas”

Manual de Desarrollador Externo Solicitud Reenvío de Correo Validación DTE

Oficina Factura Electrónica Subdirección Informática Servicio Impuestos Internos Fecha:11/05/2007

WS para Reenvío de Correos con Diagnóstico de Validación DTE Versión 1.0 – 10/01/2006

INDICE INTRODUCCIÓN .................................................................................................................................3 CAPITULO 1........................................................................................................................................4 OBJETIVOS Y CARACTERISTICAS ..................................................................................................4 1.1 OBJETIVOS DE LA APLICACIÓN .......................................................................................................4 1.2 CARACTERÍSTICA DE LA APLICACIÓN ..............................................................................................4 CAPITULO 2........................................................................................................................................5 WSDL DE WSDTECORREO .................................................................................................................5 2.1 GRAMÁTICA DEL WSDL...............................................................................................................5 2.1.1 WSDL de wsDTECorreo ...................................................................................................5 CAPITULO 3........................................................................................................................................6 DETALLE DE PARÁMETROS DEL SERVICIO ...................................................................................6 3.1 PARÁMETROS DE E NTRADA ..........................................................................................................6 3.1.1 Ejemplo Real Parámetros de Entrada Formato WSDL ........................................................6 3.2 PARÁMETROS DE SALIDA .............................................................................................................7 3.2.1 Ejemplos de Salida Formato WSDL ...................................................................................7 3.3 VALORES DE SALIDA ...................................................................................................................8 3.4 VALORES DE ESTADO PARA SALIDAS CON ERROR ..........................................................................8 3.4.1 Errores de Datos: .............................................................................................................8 3.4.2 Errores por Autenticación: .................................................................................................8 3.4.3 Otros Errores: ..................................................................................................................8 CAPITULO 4........................................................................................................................................9 GUIA PARA REALIZAR PRUEBAS................................ ................................ ................................ ....9 4.1 PRUEBA DEL S ERVICIO ................................................................................................................9 REFERENCIAS ................................................................................................................................. 10

Página 2 de 10

WS para Reenvío de Correos con Diagnóstico de Validación DTE Versión 1.0 – 10/01/2006

INTRODUCCIÓN

El servicio wsDTECorreo, forma parte del proyecto Documentos Tributarios Electrónicos (DTE), y corresponde a un servicio que permite a las empresas (contribuyentes) solicitar en forma automática al SII el reenvío de los correos con diagnostico de validación DTE para trackids específicos. Este documento está dirigido a quienes tengan la misión de utilizar y probar este servicio. La forma de acceder a este servicio es a través de WSDL (Web Services Definition Language ). Este es un lenguaje descriptor, basado en XML, que permite conocer en forma abstracta, la gramática de los componentes de un webservice (ubicación, formato, tipos de datos, servicios, funciones, parámetros de entrada, salida, etc). El WSDL que se detalla en este documento apunta al ambiente de certificación del SII, sin embargo este ambiente es una copia fiel del ambiente de producción. La ubicación del WSDL de wsDTECorreo es: Certificación : https://maullin.sii.cl/DTEWS/services/wsDTECorreo?wsdl Producción

: https://palena.sii.cl/DTEWS/services/wsDTECorreo?wsdl

Una vez que el cliente conoce el WSDL del webservice, debe construir un Request en formato SOAP (Simple Object Access Protocolo), para luego enviarlo hacia el proveedor de servicio (SII), previa Autenticación. Respecto a la Autenticación, para poder realizar consultas hacia cualquier webservice entregado por el SII, los clientes deben estar previamente autenticados a través de la AUTENTICACIÓN AUTOMATICA.

Requisitos de uso. Para poder utilizar este manual, es necesario tener previo conocimiento de XML, Web Services y Certificado Digital.

Recomendaciones. Se recomienda el uso de la herramienta XMLSPY5 de la Altova ( http://www.altova.com ).

Página 3 de 10

WS para Reenvío de Correos con Diagnóstico de Validación DTE Versión 1.0 – 10/01/2006

CAPITULO 1 OBJETIVOS Y CARACTERISTICAS

1.1 Objetivos de la aplicación El servicio wsDTECorreo, forma parte del proyecto Documentos Tributarios Electrónicos (DTE), y corresponde a un servicio que permite a las empresas (contribuyentes) solicitar en forma automática al SII el reenvío de los correos con diagnostico de validación DTE para trackids específicos.

1.2 Característica de la aplicación El servicio wsDTECorreo es de tipo “Consulta-Respuesta” Es una aplicación B2B. Esta aplicación puede ser utilizada por aquellos usuarios habilitados para su uso. Para solicitar un reenvío de correo el contribuyente autenticado, debe tener representación sobre la empresa emisora de los documentos.

Página 4 de 10

WS para Reenvío de Correos con Diagnóstico de Validación DTE Versión 1.0 – 10/01/2006

CAPITULO 2 WSDL de wsDTECorreo

2.1 Gramática del WSDL El siguiente cuadro muestra el WSDL del webservice wsDTECorreo.

2.1.1

WSDL de wsDTECorreo

- -



+ -



+

+ + + + +

Figura 2-1

Página 5 de 10

WS para Reenvío de Correos con Diagnóstico de Validación DTE Versión 1.0 – 10/01/2006

CAPITULO 3 DETALLE DE PARÁMETROS DEL SERVICIO

3.1 Parámetros de Entrada Los parámetros de entrada requeridos por el servicio, se detallan en el siguiente ejemplo:

3.1.1

Ejemplo Real Parámetros de Entrada Formato WSDL



String String String String



Figura 3-1 Donde: Campo Token

Tipo String Alfanumérico

Largo 1-40

RutEmpresa DvEmpresa TrackId

String numérico String Alfanumérico String numérico

1-8 1-1 1-10

Detalle El Token es un identificador único que identifica a un contribuyente , el cual es almacenado y enviado al cliente en el Header del Response de la Autenticación Automática con Certificado Digital (CD), y permite la búsqueda de toda la información relacionada a una sesión del cliente. El contribuyente autenticado debe tener representación sobre la empresa emisora. Rut de la Empresa emisora del envio Dv del Emisor. Trackid al que se le solicita el reenvío. Tabla 3-1

Página 6 de 10

Obligatorio S

S S S

WS para Reenvío de Correos con Diagnóstico de Validación DTE Versión 1.0 – 10/01/2006

3.2 Parámetros de Salida La salida del servicio corresponden a un “string” XML codificado, por lo tanto, es necesario que el programa cliente sea capaz de decodificar el “string” y llevarlo a formato original, los campos de retorno son: ESTADO y GLOSA, ERR_CODE, GLOSA_ERR, NUM_ATENCIÓN.

3.2.1

Ejemplos de Salida Formato WSDL



0



Figura 3-2 Respuesta Correcta



105 TRACKID NO EXISTE



Figura 3-3 Respuesta con error



114 ENVIO NO HA CONCLUIDO VALIDACION



Figura 3-4 Respuesta con error, no existe correo para reenvio Donde: Campo ESTADO

String

Tipo

GLOSA

String Alfanumérico

Largo 1-3 1-40

Detalle Código Estado de la operación En caso de Error indica una glosa descriptiva del error.

Tabla 3-2

Página 7 de 10

Obligatorio s S S

WS para Reenvío de Correos con Diagnóstico de Validación DTE Versión 1.0 – 10/01/2006

3.3 Valores de Salida El resultado del requerimiento puede arrojar uno de los siguientes valores: Estado 0 0

Tipo String String

Largo 1-3 1-3

Glosa Requerimiento recibido OK. Ha ocurrido un error.

Tabla 3-3

3.4 Valores de estado para salidas con ERROR

3.4.1

Errores de Datos:

El resultado de la consulta puede arrojar uno de los siguientes Estados de Error: Estado 101

String

Tipo

Largo 1-3

102 105 106

String String String

1-3 1-3 1-3

114

String

1-3

Glosa Error en dígito verificador del Rut de la empresa. Faltan datos de entrada Error TrackId no existe Usuario autenticado no tiene permisos sobre Empresa. Envío solicitado no ha concluido su validación, por lo tanto no existe correo.

Tabla 3-4

3.4.2

Errores por Autenticación:

Estado 104

Tipo String numérico

Largo 1-3

Glosa Token Inactivo o No Existe

Tabla 3-5

3.4.3

Otros Errores:

Estado 103 107 108 110 111 112 113

Tipo String String String String String String String

La rgo 1-3 1-3 1-3 1-3 1-3 1-3 1-3

Glosa Error Error Error Error Error Error Error

Tabla 3-6

Página 8 de 10

Interno. Interno Interno Interno Interno Interno Interno

WS para Reenvío de Correos con Diagnóstico de Validación DTE Versión 1.0 – 10/01/2006

CAPITULO 4 GUIA PARA REALIZAR PRUEBAS

4.1 Prueba del Servicio Para probar el servicio, se deben seguir los siguientes pasos: 1.- Autenticarse mediante Autenticación Automática con Certificado Digital (CD). Nota:

El proceso de la Autenticación Automática con CD, permitirá obtener un Token, el cuál es requerido como parámetro de entrada por el webservice wsDTECorreo. Para la implementación de la autenticación, se recomienda ver “Manual del Desarrollador Autenticación Automática”.

2.- Una vez obtenido el Token, se debe invocar al sitio donde se encuentra el webservice wsDTECorreo, ejemplo: Certificación : https://maullin.sii.cl/DTEWS/services/wsDTECorreo?wsdl Producción

: https://palena.sii.cl/DTEWS/services/wsDTECorreo?wsdl

3.- Luego, para realizar las pruebas, al WS invocado, se le deben pasar los parámetros de entrada requeridos por la función reenvioCorreo, estos son: Token, RutEmpresa, DvEmpresa, TrackId. 4.- Como respuesta del WS se obtiene un XML con los siguientes tags: ESTADO GLOSA (solo en caso de error)

Página 9 de 10

WS para Reenvío de Correos con Diagnóstico de Validación DTE Versión 1.0 – 10/01/2006

REFERENCIAS Para mayor información sobre temas tratados en este manual, se recomienda visitar:

Documentación WSDL: http://www.w3.org/TR/wsdl Herramienta XMLSPY : http://www.xmlspy.com/features_wsdl.html Manual del Desarrollador Autenticación Automática : http://www.sii.cl/factura_electronica/autenticacion.pdf

Página 10 de 10

Manual de Desarrollador Externo Consulta Avanzada Estado de DTE

Oficina Informática Factura Electrónica Subdirección Informática Servicio Impuestos Internos Versión : 1.0 Fecha : 03/05/2007

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

INDICE CONTROL DE VERSIONES .................................................................................................................2 INTRODUCCIÓN .................................................................................................................................3 CAPITULO 1........................................................................................................................................4 OBJETIVOS Y CARACTERISTICAS ..................................................................................................4 1.1 OBJETIVOS DE LA APLICACIÓN .......................................................................................................4 1.2 CARACTERÍSTICA DE LA APLICACIÓN ..............................................................................................4 CAPITULO 2........................................................................................................................................5 WSDL DE Q UERY ESTD TEA V ...............................................................................................................5 2.1 GRAMÁTICA DEL WSDL...............................................................................................................5 CAPITULO 3........................................................................................................................................6 DETALLE DE PARÁMETROS DE LA FUNCION GET E ST DTE AV .............................................................6 3.1 PARÁMETROS DE E NTRADA ..........................................................................................................6 3.2 PARÁMETROS DE SALIDA .............................................................................................................7 3.2.1 Sección RESP_HDR...........................................................................................................7 3.2.2 Sección RESP_BODY.........................................................................................................7 3.3 VALORES DE SALIDA ...................................................................................................................8 3.3.1 RESP_HDR/ESTADO......................................................................................................8 3.3.2 RESP_BODY/RECIBIDO ...............................................................................................8 3.3.3 RESP_BODY/ESTADO ...................................................................................................8 3.4 EJEMPLOS DE S ALIDA ................................................................................................................9 3.4.1 Documento Recibido y Datos Coinciden ................................ ................................ ............9 3.4.2 Documento Recibido y Datos No Coinciden .......................................................................9 3.4.3 Error de Autenticación ......................................................................................................9 3.4.4 Error en Parámetros de Entrada...................................................................................... 10 CAPITULO 4......................................................................................................................................11 GUIA PARA REALIZAR PRUEBAS................................ ................................ ................................ .. 11 4.1 PRUEBA DEL S ERVICIO .............................................................................................................. 11 REFERENCIAS ................................................................................................................................. 12

Subdirección de Informática – Oficina Factura Electrónica Página : 1 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

CONTROL DE VERSIONES Versión

Fecha

1.0

24-07-2006

Motivo Versión Inicial.

Subdirección de Informática – Oficina Factura Electrónica Página : 2 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

INTRODUCCIÓN

El servicio QueryEstDteAv, forma parte del proyecto Documentos Tributarios Electrónicos (DTE), y corresponde a un servicio que permite a las empresas (contribuyentes) consultar en forma automática por el estado en que se encuentra un DTE enviado al SII, además de corroborar los datos asociados al documento. La forma de acceder a este servicio es a través de WSDL 1 (Web Services Definition Language). El WSDL que se detalla en este documento apunta al ambiente de certificación del SII, sin embargo este ambiente es una copia fiel del ambiente de producción. La ubicación del WSDL de QueryEstDteAv es: Certificación : https://maullin.sii.cl/DTEWS/services/QueryEstDteAv?wsdl Producción

: https://palena.sii.cl/DTEWS/services/QueryEstDteAv?wsdl

Una vez que el cliente conoce el WSDL del webservice, debe construir un Request en formato SOAP (Simple Object Access Protocolo), para luego enviarlo hacia el proveedor de servicio (SII), previa Autenticación. Respecto a la Autenticación, para poder realizar consultas hacia cualquier webservice entregado por el SII, los clientes deben estar previamente autenticados a través de la AUTENTICACIÓN AUTOMATICA. Este documento está dirigido a quienes tengan la misión de utilizar y probar este servicio.

Requisitos de uso. Para poder utilizar este manual, es necesario tener previo conocimiento de XML, Web Services y Certificado Digital.

Recomendaciones. Se recomienda el uso de la herramienta XMLSPY5 de la Altova ( http://www.altova.com ).

1

WSDL: Lenguaje descriptor, basado en XML, que permite conocer en forma abstracta, la gramática de los componentes de un web service (ubicación, formato, tipos de datos, servicios, funciones, parámetros de entrada, salida, etc). Subdirección de Informática – Oficina Factura Electrónica Página : 3 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

CAPITULO 1 OBJETIVOS Y CARACTERISTICAS 1.1 Objetivos de la aplicación El objetivo de este servicio es entregar una herramienta que permita consultar por el estado de un DTE y corroborar los datos asociados a dicho DTE.

1.2 Característica de la aplicación El servicio QueryEstDteAv, es de tipo “Consulta-Respuesta”. Es una aplicación B2B. Esta aplicación puede ser utilizada por aquellos usuarios habilitados para su uso. Para realizar una consulta el contribuyente autenticado, debe tener representación sobre la empresa emisora del documento.

Subdirección de Informática – Oficina Factura Electrónica Página : 4 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

CAPITULO 2 WSDL de QueryEstDteAv 2.1 Gramática del WSDL El siguiente cuadro muestra el WSDL del web service QueryEstDteAv.

- + + + -







-



+

+ + +

Como se muestra en los recuadros del WSDL, el servicio QueryEstDteAv, tiene la función getEstDteAv, la que permite realizar la consulta. A continuación se detallan los parámetros de entrada y la salida de esta función.

Subdirección de Informática – Oficina Factura Electrónica Página : 5 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

CAPITULO 3 DETALLE DE PARÁMETROS DE LA FUNCION getEstDteAv 3.1 Parámetros de Entrada Los parámetros de entrada requeridos por el servicio, se detallan en el siguiente cuadro:

String String String String String String String String String String



Donde: Campo RutEmpresa DvEmpresa RutReceptor DvReceptor TipoDte FolioDte FechaEmisionDte

Tipo String numérico String Alfanumérico String numérico String Alfanumérico String numérico String numérico String Date

Largo 1-8 1-1 1-8 1-1 1-3 1-10 1-10

MontoDte FirmaDte

String numérico String Alfanumérico

1-15 1-500

Token

String Alfanumérico

1-40

Detalle Obligatorio Rut del Emisor. S Dv del Emisor. S Rut del Receptor. S Dv del receptor. S Tipo del DTE. S Folio del DTE. S Fecha de Emisión del DTE, en formato S DD-MM-AAAA. Monto Total del DTE. S S Firma del DTE. Corresponde al tag: del DTE/Signature/SignatureValue xml asociado al documento. Identificador único de autenticación que S identifica a un contribuyente. Se obtiene como respuesta de servicio de Autenticación Automática con Certificado Digital (CD).

Subdirección de Informática – Oficina Factura Electrónica Página : 6 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

3.2 Parámetros de Salida La salida del servicio corresponde a un “string” XML codificado. La respuesta esta organizada en dos secciones: RESP_HDR RESP_BODY

3.2.1

Sección RESP_HDR

Esta sección entrega el resultado de la operación a través de los campos : Campo ESTADO GLOSA

3.2.2

Tipo Numérico String

Largo 1-2 1-238

Detalle Indica el resultado de la operación En caso de error, breve descripción del error

Obligatorio S N

Sección RESP_BODY

Esta sección entrega el detalle del estado del documento consultado a través de los campos: Campo RECIBIDO

Tipo String

Largo 1-2

ESTADO GLOSA TRACKID NUMATENCION

String String Numérico String

1-3 1-238 1-20 1-40

Detalle Indica si el documento fue recibido por el SII Estado en que se encuentra Descripción del estado Trackid asociado al documento Numero de Atención asociado a la consulta

Subdirección de Informática – Oficina Factura Electrónica Página : 7 de 13

Obligatorio S S S N S

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

3.3 Valores de Salida Algunos de los campos tienen asociado valores codificados, los que se detallan a continuación:

3.3.1

RESP_HDR/ESTADO ESTADO 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

3.3.2

Descripción Consulta procesada OK. Token inactivo (expirado) Token no existe Error Interno (ver glosa) Error Interno Error parámetros de entrada (ver glosa) Error Interno Error Interno Error Interno Usuario no autorizado en empresa Error Interno Error Interno Error Interno Error Interno Error Interno

RESP_BODY/RECIBIDO RECIBIDO Descripción SI Documento fue recibido por el SII NO Documento no ha sido recibido por el SII

3.3.3

RESP_BODY/ESTADO ESTADO EMP TMD TMC MMD MMC AND ANC DOK DNK FNA FAN FAU

Descripción Empresa No Autorizada a Emitir Documentos Tributarios Electrónicos Existe Nota de Débito que Modifica Textos Documento Existe Nota de Crédito que Modifica Textos Documento Existe Nota de Débito que Modifica Montos Documento Existe Nota de Crédito que Modifica Montos Documento Existe Nota de Débito que Anula Documento Existe Nota de Crédito que Anula Documento Documento Recibido por el SII. Datos Coinciden con los Registrados Documento Recibido por el SII pero Datos NO Coinciden con los registrados Documento No Autorizado Documento Anulado Documento No Recibido por el SII

Subdirección de Informática – Oficina Factura Electrónica Página : 8 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

3.4 Ejemplos de Salida A continuación se muestran algunos ejemplos de salidas.

3.4.1

Documento Recibido y Datos Coinciden



0

SI DOK Documento Recibido por el SII. Datos Coinciden con los Registrados 36440 137416 [25/07/2006 12:08:20]

3.4.2

Documento Recibido y Datos No Coinciden



0

SI DNK Documento Recibido por el SII pero Datos NO Coinciden con los registrados 137417 [25/07/2006 12:11:03]

3.4.3

Error de Autenticación



2 Token no existe



Subdirección de Informática – Oficina Factura Electrónica Página : 9 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

3.4.4

Error Autenticación Expirada



1 Token Inactivo



3.4.5

Error en Parámetros de Entrada



5 DV Rut Empresa no correspo nde.



3.4.6

Error de Permisos



9 Usuario no tiene permiso en empresa



Subdirección de Informática – Oficina Factura Electrónica Página : 10 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

CAPITULO 4 GUIA PARA REALIZAR PRUEBAS 4.1 Prueba del Servicio Para probar el servicio, se deben seguir los siguientes pasos: 1.- Autenticarse mediante Autenticación Automática con Certificado Digital (CD). Nota:

El proceso de la Autenticación Automática con CD, permitirá obtener un Token, el cuál es requerido como parámetro de entrada por el web service QueryEstDteAv. Para la implementación de la autenticación, se recomienda ver “Manual del Desarrollador Autenticación Automática”.

2.- Una vez obtenido el Token, se debe invocar al sitio donde se encuentra el web service QueryEstDteAv, ejemplo: Certificación : https://maullin.sii.cl/DTEWS/services/QueryEstDteAv?wsdl Producción

: https://palena.sii.cl/DTEWS/services/QueryEstDteAv?wsdl

3.- Luego, para realizar las pruebas, al WS invocado, se le deben pasar los parámetros de entrada requeridos por la función getEstDteAv, estos son: RutEmpresa, DvEmpresa, RutReceptor, DvReceptor, TipoDte, FolioDte, FechaEmisionDte, MontoDte, FirmaDte, Token . 4.- Como respuesta del WS se obtiene un XML.

Subdirección de Informática – Oficina Factura Electrónica Página : 11 de 13

WS de Consulta Avanzada del Estado de un DTE Versión 1.0 – 03/05/2007

REFERENCIAS Para mayor información sobre temas tratados en este manual, se recomienda visitar:

Documentación WSDL: http://www.w3.org/TR/wsdl Herramienta XMLSPY : http://www.xmlspy.com/features_wsdl.html Manual del Desarrollador Autenticación Automática : http://www.sii.cl/factura_electronica/autenticacion.pdf

Subdirección de Informática – Oficina Factura Electrónica Página : 12 de 13

Manual de Desarrollador Autenticación Automática OI2007_AUTAUTOM_MDE_1.9

Subdirección Informática Servicio Impuestos Internos Fecha:18/11/2007

SII WS de Autenticación con Certificado Digital

INTRODUCCIÓN ................................................................................................................................................ 5 CAPÍTULO 1....................................................................................................................................................... 6 ANÁLISIS DEL SISTEMA................................................................................................................................ 6 1.2 OBJETIVOS DE LA APLICACIÓN. ...................................................................................................................... 7 1. 3 CARACTERÍSTICA DE LA APLICACIÓN .............................................................................................................. 7 CAPÍTULO 2....................................................................................................................................................... 8 VISIÓN GENERAL DEL SISTEMA.................................................................................................................. 8 CAPITULO 3..................................................................................................................................................... 11 WSDL DE AUTENTICION AUTOMATICA..................................................................................................... 11 3.1.1 WSDL DE CRSEED.JWS ................................................................................................................... 11 3.1.2 WSDL DE GETTOKENFROMSEED.JWS ............................................................................................... 12 CAPÍTULO 4..................................................................................................................................................... 14 PARÁMETROS DE ENTRADA ..................................................................................................................... 14 4.1.1 PARÁMETROS DE ENTRADA PARA CRSEED.JWS ......................................................................................... 14 4.1.2 EJEMPLO REAL PARÁMETROS DE ENTRADA FORMATO WSDL..................................................................... 14 4.1.3 PARÁMETROS DE ENTRADA PARA GETTOKENFROMSEED.JWS ..................................................................... 14 4.1.4 EJEMPLO REAL PARÁMETROS DE ENTRADA FORMATO WSDL..................................................................... 14 4.1.5 EJEMPLO FORMATO XML DE ENTRADA ..................................................................................................... 16 CAPÍTULO 5..................................................................................................................................................... 17 CAPÍTULO 5..................................................................................................................................................... 17 PARÁMETROS DE SALIDA.......................................................................................................................... 17 5.1.1 PARÁMETROS DE SALIDA ......................................................................................................................... 17 5.2.1 ESTADOS DE SALIDA ............................................................................................................................... 17 5.2.2 ESTADOS DE SALIDA DE CRSEED SON:..................................................................................................... 17 5.2.3 EJEMPLOS DE SALIDA ............................................................................................................................ 19 5.2.3.1 EJEMPLO PARÁMETROS DE SALIDA WSDL CODIFICADO CRSEED.JWS ..................................................... 19 FORMATO DECODIFICADO DE LOS PARÁMETROS DE SALIDA CRSEED.JWS ............................................................. 19 5.2.3.2 EJEMPLO PARÁMETROS DE SALIDA WSDL CODIFICADO GETTOKENFROMSEED.JWS ................................. 20 CAPÍTULO 6..................................................................................................................................................... 21 EJEMPLOS XML DE RESPUESTA.............................................................................................................. 21 6.1 EJEMPLO SALIDA GENERA SEMILLA:............................................................................................................. 21 6.1.1 EJEMPLO DE SALIDA, ESTADO 00 (GENERA SEMILLA)................................................................................ 21 6.1.2 EJEMPLO DE SALIDA, ESTADO -1 (ERROR NO GENERA SEMILLA) .............................................................. 21 6.1.3 EJEMPLO DE SALIDA, ESTADO -2 (ERROR : BD) ....................................................................................... 21 6.2 EJEMPLO SALIDA GENERA TOKEN ................................................................................................................ 22 6.2.1 EJEMPLO DE SALIDA, ESTADO 00 (GENERA TOKEN) .................................................................................. 22 6.2.2 EJEMPLO DE SALIDA, ESTADO 01 (ERROR:XML INVALIDO (IOEXCEPTION), FUNCIÓN VALSIGNEDXML) ............ 22 6.2.3 EJEMPLO DE SALIDA, ESTADO 02 (ERROR: XML INVALIDO, (SAXEXCEPTION), FUNCIÓN VALSIGNEDXML) ....... 22 6.2.4 EJEMPLO DE SALIDA, ESTADO 03 (ERROR: XML INVALIDO PARSERCONFIGURATIONEXCEPTION), FUNCION VALSIGNEDXML) .............................................................................................................................................. 23 6.2.5 EJEMPLO DE SALIDA, ESTADO 04 (ERROR: XML INVALIDO, ELEMENTO “SIGNATURE” NO EXISTE , FUNCION VALSIGNEDXML) .............................................................................................................................................. 23 6.2.6 EJEMPLO DE SALIDA, ESTADO 05 (ERROR: XML INVALIDO, FIRMA INVALIDA, FUNCIÓN VALSIGNEDXML)........... 23 6.2.7 EJEMPLO DE SALIDA, ESTADO 06 (ERROR: XML INVALIDO, ELEMENTO “SEMILLA” NO EXISTE, FUNCIÓN GETSEED)24 6.2.8 EJEMPLO DE SALIDA, ESTADO 07 (ERROR (MESSAGEEXCEPTION) ............................................................ 24 6.2.9 EJEMPLO DE SALIDA, ESTADO 08 (ERROR :RETORNO ) ............................................................................. 24 6.2.10 EJEMPLO DE SALIDA, ESTADO 09 (ERROR (M ESSAGEEXCEPTION)) ......................................................... 25 6.2.11 EJEMPLO DE SALIDA, ESTADO 10 (ERROR: RETORNO DATOS)........................................................... 25 6.2.12 EJEMPLO DE SALIDA, ESTADO 11 (ERROR: XML INVÁLIDO , ELEMENTO “CERTIFICATE” NO EXISTE, FUNCIÓN GET CERTIFICADO) ........................................................................................................................................... 25 6.2.13 EJEMPLO DE SALIDA, ESTADO 12 (ERROR (12) (MESSAGEEXCEPTION)) .................................................. 26 6.2.14 EJEMPLO DE SALIDA, ESTADO -3 (ERROR EN AUTENTICACIÓN).................................................................. 26

Versión 1.9 del 18.11.2007

Pág.2de 32

SII WS de Autenticación con Certificado Digital

CAPITULO 7..................................................................................................................................................... 27 GUIA PARA REALIZAR PRUEBAS .............................................................................................................. 27 CAPITULO 8..................................................................................................................................................... 28 COMO FIRMAR UNA SEMILLA ............................................................................................................................. 28 ANEXO 1 .......................................................................................................................................................... 32 1.- EJEMPLO DE TOKEN.................................................................................................................................. 32

Versión 1.9 del 18.11.2007

Pág.3de 32

SII WS de Autenticación con Certificado Digital

CONTROL DE VERSIONES Versión

Fecha

1.0

21/01/2003

1.2

17/02/2003 Se Modifico Introducción Se Agrego: Capitulo 3, Capitulo 4, Capitulo 5 1.3 08/03/2004 Se modifico Url en Capitulo 7 (Guía para Pruebas, le faltaba la “s” al http). Donde decía: http://palena.sii.cl/DTEWS/CrSeed.jws? WSDL http://palena.sii.cl/DTEWS/GetTokenFro mSeed.jws?WSDL Se cambio por: https://palena.sii.cl/DTEWS/CrSeed.jws? WSDL https://palena.sii.cl/DTEWS/GetTokenFr omSeed.jws?WSDL

1.4 08/04/2004 Se modifico texto de introducción (como acceder a los WS del SII) 1.5 07/05/2004 Se modifico texto de los mensajes de salida 1.6 31/05/2004 Se agrego Capitulo 8: Como Firmar una semilla. 1.7 18/11/2005 Se agrego Error 21, en punto 5.2.2 1.8 03/07/2006 en punto. Se agrego error 12, en punto 5.2.2 1.9 18/11/2007 Se modifico detalle del errores : 11, 12 y –3 (Capítulo 6).

Versión 1.9 del 18.11.2007

Pág.4de 32

SII WS de Autenticación con Certificado Digital

INTRODUCCIÓN El método de autenticación automática (AUTAUTOM), es un chequeo del uso de la llave privada del certificado del cliente, mediante el uso de Web Services (WS). Para cumplir su objetivo AUTAUTOM, entrega a las empresas dos Web services (WS) “CrSeed y GetTokenFromSeed”, mediante los cuales se podrá obtener un Texto aleatorio o Semilla y un Token (requisitos de la autenticación), los que serán detallados más adelante. Este documento está dirigido a quienes tengan la misión de utilizar y probar los WS mencionados anteriormente (CrSeed y GetTokenFromSeed). Para acceder a los servicios que ofrece el SII, se debe utilizar WSDL(Web Services Definition Language). WSDL es un lenguaje descriptor, basado en XML, que permite conocer en forma abstracta, la gramática de los componentes de un Web Service (ubicación, formato, tipos de datos, servicios, funciones, parámetros de entrada, salida, etc). Para poder acceder a un WSDL, se debe conocer su ubicación, por ejemplo el WSDL de los WS entregados son: https://palena.sii.cl/DTEWS/CrSeed.jws?WSDL. https://palena.sii.cl/DTEWS/GetTokenFromSeed.jws?WSDL. Cuando el cliente conoce el WSDL del servicio, puede construir un Request en formato SOAP (Simple Object Access Protocolo), para luego enviarlo hacia el proveedor de servicio. Requisitos de uso. Para poder utilizar este manual, es necesario tener previo conocimiento de XML, Web Services y Certificado Digital. Recomendaciones: Se recomienda el uso de la herramienta XMLSPY5 de la Altova GmbH http://www.altova.com

Versión 1.9 del 18.11.2007

Pág.5de 32

SII WS de Autenticación con Certificado Digital

CAPÍTULO 1 ANÁLISIS DEL SISTEMA Este sistema permite la implementación de la Autenticación Automática, mediante el uso de WS y Certificado Digital. AUTAUTOM es un sistema implementado bajo la tecnología B2B, que permite que las aplicaciones se comuniquen entre sí con llamadas de programa a programa. A grandes rasgos la utilización de esta aplicación, requiere que un cliente remoto se pueda autenticar en el SII mediante Certificado Digital. Para esto es necesario que dicho cliente solicite a la aplicación del SII un texto aleatorio llamado Semilla. Una vez entregada la semilla al cliente, éste deberá firmarla y enviarla nuevamente hacia el sitio del SII, quien se encargará de validar la firma y la vigencia de dicho texto. Si la validación es OK, la aplicación le entrega al cliente un identificador de autenticación llamado Token. Dicho identificador, le permitirá al cliente navegar por las otras aplicaciones del SII, sin tener que autenticarse nuevamente.

Versión 1.9 del 18.11.2007

Pág.6de 32

SII WS de Autenticación con Certificado Digital

1.1 Quienes pueden utilizar esta aplicación. Esta aplicación puede ser utilizada por todas aquellas Personas o Empresas, que tengan registrada una clave secreta en las BD del SII. Actualmente la aplicación solo permite autenticarse con Certificado Digital Válido para el SII. 1.2 Objetivos de la aplicación. El objetivo de la aplicación es dar solución a la Autenticación Automática del SII.

1. 3 Característica de la aplicación Autenticación programa a programa Autenticación sin intervención de humanos por parte de servidor Desarrollo en base WS Actualmente sólo permite Autenticarse con Certificado Digital Cliente necesita estar registrado en las bases de datos del SII como un contribuyente habilitado para ingresar a las aplicaciones de Internet que requieren autenticación.

Versión 1.9 del 18.11.2007

Pág.7de 32

SII WS de Autenticación con Certificado Digital

CAPÍTULO 2 VISIÓN GENERAL DEL SISTEMA

Lado Cliente

Lado Web Services

Aplicación Usuario

WS Server Request Semilla CrSeed.jws Response Semilla

Semilla Datos Firma Certificado

Envía Semilla Firmada

Envía Token

Valida Semilla Si Ok Genera Token Si NO OK, genera Error en XML GetTokenFromSeed.jws

Figura 1.0

Versión 1.9 del 18.11.2007

Pág.8de 32

SII WS de Autenticación con Certificado Digital

De acuerdo al diagrama superior (figura 2.0), para que un cliente se pueda autenticar, lo primero que debe hacer es solicitar una Semilla mediante un Request, hacia el WS CrSeed.jws. Cuando el WS recibe el requerimiento, genera automáticamente una Semilla en formato XML. Una vez que se ha generado una semilla, es almacenada en una base de datos y luego es enviada al cliente en el “Header” del “Response”. Una Semilla es un número único y aleatorio que sirve como identificador para la sesión de un cliente y que tiene un time out de 2 (dos) minutos. Cuando el cliente recibe la Semilla, debe firmarla, para luego enviarla en formato estándar XML(definido por el SII), hacia nuestro sitio. Una vez recibida la semilla firmada, se validará su firma y su vigencia. Si la validación de la Semilla es OK, se genera automáticamente un Token, el cual es almacenado en una Base de Datos y luego es enviado hacia el cliente. Un Token es un identificador único el cual es almacenado y enviado al cliente en el Body (Cuerpo) del Response. La generación del Token la realiza el WS GetTokenFromSeed.jws Cuando el cliente recibe el Token, ya está Autenticado y puede ingresar a cualquier aplicación del SII. Nota : Ver Ejemplo de Token, ANEXO 1 Si la validación falló, el Web Services envía un mensaje de error en formato XML. Ver ejemplo Mensaje Error en Punto 4.2

Versión 1.9 del 18.11.2007

Pág.9de 32

SII WS de Autenticación con Certificado Digital

La información que debe contener el XML que Firma la Semilla (XML Entrada) es: Semilla Firma Módulo Certificado Digital Ver Ejemplo Archivo XML Entrada (Semilla Firmada) en: Punto 3.2 La validación del XML, consiste en: Validar que su formato XML este OK (que cumpla formato solicitado por el SII). Validar que la Semilla este vigente ( ya que la semilla tiene una duración de 2 min.). Validar su certificado Digital. Validar su firma.

Versión 1.9 del 18.11.2007

Pág.10de 32

SII WS de Autenticación con Certificado Digital

CAPITULO 3 WSDL DE AUTENTICION AUTOMATICA Tal como se menciono anteriormente la AUTAUTOM, entrega dos WS: CrSeed GetTokenFromSeed.jws 3.1.1 WSDL de CrSeed.jws CrSeed , entrega un solo método “getSeed”, el cual permite Obtener una Semilla. La ubicación del WSDL, para CrSeed.jws es: https://palena.sii.cl/DTEWS/CrSeed.jws?WSDL





















Diagrama 1-1 WSDL CrSeed.jws

Versión 1.9 del 18.11.2007

Pág.11de 32

SII WS de Autenticación con Certificado Digital

3.1.2 WSDL de GetTokenFromSeed.jws GetTokenFromSeed, entrega un solo servicio llamado “getToken”, el cual permite Obtener un Token. La ubicación del WSDL, para GetTokenFromSeed.jws: https://palena.sii.cl/DTEWS/GetTokenFromSeed.jws?WSDL

-

-

-

-

- -

-



-

-

-

-

-

-

-



- -



Diagrama 1-2 WSDL GetTokenFromSeed.jws

Versión 1.9 del 18.11.2007

Pág.13de 32

SII WS de Autenticación con Certificado Digital

CAPÍTULO 4 PARÁMETROS DE ENTRADA 4.1.1 Parámetros de Entrada para CrSeed.jws CrSeed.jws no tiene parámetros de entrada, tal como se detalla en el ejemplo 3.1.2

4.1.2 Ejemplo Real Parámetros de Entrada Formato WSDL



4.1.3 Parámetros de Entrada para GetTokenFromSeed.jws Los parámetros de Entrada para GetTokenFromSeed.jws, corresponden a un String formado por los campos del XML, que enviara la Semilla Firmada. 4.1.4 Ejemplo Real Parámetros de Entrada Formato WSDL

String



Versión 1.9 del 18.11.2007

Pág.14de 32

SII WS de Autenticación con Certificado Digital

Los parámetros de entrada que deben formar el XML para el envío de la Semilla Firmada son: Parámetros de Entrada XML: Etiqueta de inicio XML

Semilla, es número único, generado por nuestro Web Server. Url’s Signature Corresponde a la Firma. Módulo de la llave Pública. Exponente de la llave Pública. Certificado.X509

1234567890123

gfnpbQ8vKMQzAJF/nuQxC/Gg= pvzPlABsnc9V4M2Wc+QcI8= AQAB

MlBR08xDjAMBgNVBAcTBUNIRUxFMQww CgYDVQQtvAfDCCQxMeLAtNJKWJDCN199bO5CUiA3iTlr5BEtu DjmnF5dg6L0z03pXOfoaF9bD3zsgPjMRxYAZP33uj/prVHUv0E9g U8d/xvdWE21d6AGKGtklmQGSuW8wKogWokKkP UfKDlmcWkaSAv056hkvzPlABsnc9V4M2Wc+QcI8CAwEAATANB gkqhkiG9w0BAakRk8i3bCCAakRk8i==

Figura 1.3

Versión 1.9 del 18.11.2007

Pág.15de 32

SII WS de Autenticación con Certificado Digital

4.1.5 Ejemplo Formato XML de Entrada Este es un ejemplo del formato XML para el envió de Semilla firmada de acuerdo al Estándar XML Digital Signature. Los demás nombres y etiquetas son Obligatorios. s.

10







8slcL05kmrM8NGw4I9NSfRqYA9E=

jlbzatIIBLW8AjH++5uVTTrGIMVwGButuoAR88y/hvSc1+6/eW1K864fK3cKi76oArqk7lAM4pP okoXme0JT/hRXXGo6ecuKzO18z2WfPWwgnN0f3ac03TDu7PwfqiDG9mhQpYfIkNp6GNJIiqlg9PG2w1fOJ1QoypsrQmKq6 YU=

2Pb4kEB19m7NmOUYew9f36325yrTLTPMU7qzYG2A0/BsubxDdgQw2Op0x6zXvOVX sYI9KkPXtD5orKJMjwxYRv9wUWdyiE776Rv4ljfJO7EQhIK1fDQDnPt0HefBS06Xzg2QLBvLR+pe1vc6C02Dr99v+lnLA8 mnZiJlRHndhNU=

AQAB

MIIF1DCCBLygAwIBAgIDAQNtMA0GCSqGSIb3DQEBBQUAMIHGMQswCQYDVQQG EwJDTDEYMBYGA1UEChMPQWNlcHRhLmNvbSBTLkEuMTgwNgYDVQQLEy9BdXRv cmlkYWQgY2VydGlmaWNhZG9yYSBDbGFzZSAzIHBlcnNvbmEgbmF0dXJhbDFD MEEGA1UEAxM6QWNlcHRhLmNvbSBBdXRvcmlkYWQgY2VydGlmaWNhZG9yYSBD bGFzZSAzIHBlcnNvbmEgbmF0dXJhbDEeMBwGCSqGSIb3DQEJARYPaW5mb0Bh Y2VwdGEuY29tMB4XDTAxMDkyNTIxMDgxMloXDTAyMDkyNTIxMDgxMlowgZ8x CzAJBgNVBAYTAkNMMRgwFgYDVQQKEw9BY2VwdGEuY29tIFMuQS4xLDAqBgNV BAsTI0NlcnRpZmljYWRvIENsYXNlIDMgUGVyc29uYSBOYXR1cmFsMRwwGgYJ KoZIhvcNAQkBFg1uY2hlbGVAc2lpLmNsMSowKAYDVQQDEyFOSUNPTEFTIFpB UFJJQU4gQ0hFTEVCSUZTS0kgQkFFWkEwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANj2+JBAdfZuzZjlGHsPX9+t9ucq0y0zzFO6s2BtgNPwbLm8Q3YE MNjqdMes17zlV7GCPSpD17Q+aKyiTI8MWEb/cFFncohO++kb+JY3yTuxEISC tXw0A5z7dB3nwUtOl84NkCwby0fqXtb3OgtNg6/fb/pZywPJp2YiZUR53YTV AgMBAAGjggJyMIICbjAdBggrBgEEAbVrDwQRFg9BY2VwdGEuY29tIFMuQS4w JQYDVR0RBB4wHKAaBggrBgEEAcEBAaAOFgwxMC40MTEuODcxLTIwDwYIKwYB Jh0z1DR3Pl3xOiaFIjSXsQO2PSzcA3wZXYF+KDrMul8e5lAF2NNiLmMVtXEx ZykMaTGGWS0ZETDhJmBwEZGpP4+lt/JhgwF1Sb6wdrXp7MFCJUc1Tj+/5JqH 1kP0E63/hVElrcP0g8Zn8Z+vr/PMGW1kKgE0IyS4iJ8eIhNSK5phFyKJUn0l BmIZX7u89d5u7X8=



Figura 1.4

Versión 1.9 del 18.11.2007

Pág.16de 32

SII WS de Autenticación con Certificado Digital

CAPÍTULO 5 PARÁMETROS DE SALIDA 5.1.1 Parámetros de Salida La salida de los Servicios corresponden a un “string” XML codificado según estándar XML, por lo tanto es necesario que el programa cliente sea capaz de decodificar el “string” y llevarlo a formato original - decodificado, los campos de retorno son: ESTADO, GLOSA, DATOS(SEED o TOKEN)

Donde Campo

Tipo

ESTADO GLOSA DATOS

String Alfanum String Alfanum. String numérico

Largo Detalle 1-8 1-1 1-5

Código Estado Detalle Estado El nombre de este tag, varia dependiendo de los datos solicitados(Token, Seed), por ejemplo, si estamos solicitando Token el tag de datos se llamaría , lo mismo para el Seed.

Obligatorios S S S

Figura 1.5

5.2.1 Estados de Salida Los Estados de Salida se detallaran dependiendo del WS que corresponda.

5.2.2 Estados de Salida de CrSeed son: Estado

Detalle Estado

00

OK genera Semilla

-1

No se registro línea en el Archivo de Configuración

-2

ERROR: RETORNO.

"ERROR RETORNO" "NO PUEDO CREAR O ACT. TOKEN"

Figura 1.6

Versión 1.9 del 18.11.2007

Pág.17de 32

SII WS de Autenticación con Certificado Digital

5.2.2 Los Estados de Salida de GetTokenFromSeed son: Estado

Detalle Estado

00

Token Creado

01

XML Inválido (IOException), función valSignedXml

02

XML Inválido (SAXException), función valSignedXml

03

XML Inválido (ParserConfigurationException), función valSignedXml

04

XML Inválido, elemento “Signature” no existe, función valSignedXml

05

XML Inválido, firma invalida, función valSignedXml

06

XML Inválido, elemento “Semilla” no existe, función getSeed

07

ERROR (MessageException).

08

ERROR RETORNO : "PARAMETROS INCORRECTOS" "TIME-OUT DEL SEED" "NO GENERA TOKEN func:CreaToken" "NO PUEDO ACT. SEED CON TOKEN" "TIME-OUT del SEED" "NO Existe SEED"

09

ERROR (MessageException).

10

ERROR RETORNO: "ERROR RETORNO DATOS" "NO PUEDO CREAR O ACT. TOKEN"

11

XML Inválido, elemento “Certificate” no existe, función getCertificado

12

ERROR (12) (MessageException)

21

Firma invalida( La llave pública no coincide con la del certificado).

-3

Error en Autenticación

-07

Error (12) parse ERROR en Validación del RUT (verificar que el usuario se encuentre registrado en el SII con la opción de autenticación mediante “Certificado Digital”

Figura 1.7

Versión 1.9 del 18.11.2007

Pág.18de 32

SII WS de Autenticación con Certificado Digital

5.2.3 Ejemplos de Salida A continuación se mostrará una serie de ejemplos de salida en ambos formatos Codificado y Decodificado.

5.2.3.1 Ejemplo Parámetros de Salida WSDL Codificado CrSeed.jws



00 000000000078



Formato Decodificado de los Parámetros de Salida CrSeed.jws

- 00

- 000000000078

Figura 1.8

Versión 1.9 del 18.11.2007

Pág.19de 32

SII WS de Autenticación con Certificado Digital

5.2.3.2 Ejemplo Parámetros de Salida WSDL Codificado GetTokenFromSeed.jws



00 Token CreadoXAuSbYXiNh9Ik& lt;/TOKEN>



5.2.3.4 Ejemplo Parámetros de Salida WSDL Decodificado GetTokenFromSeed.jws

- 00 Token Creado

- XAuSbYXiNhIk

Figura 1.9

Versión 1.9 del 18.11.2007

Pág.20de 32

SII WS de Autenticación con Certificado Digital

CAPÍTULO 6 EJEMPLOS XML DE RESPUESTA

6.1 Ejemplo Salida genera Semilla: 6.1.1 Ejemplo de Salida, Estado 00 (genera Semilla)

- - 00

- 00000000064

6.1.2 Ejemplo de Salida, Estado -1 (Error No genera Semilla)

- - -1 Error : (Message Exception)

6.1.3 Ejemplo de Salida, Estado -2 (Error : BD)

- - -2 ERROR RETORNO

Nota: El estado -2, tiene asociado dos errores, detallados en la tabla “Estados de Salida Genera Semilla”. Aquí se hace mención a sólo uno de ellos a modo de ejemplo.

Versión 1.9 del 18.11.2007

Pág.21de 32

SII WS de Autenticación con Certificado Digital

6.2 Ejemplo Salida genera Token

6.2.1 Ejemplo de Salida, Estado 00 (genera Token)

- 00 Token Creado

- AB82001ABRT

6.2.2 Ejemplo de Salida, Estado 01 (Error:XML invalido (IOException), función valSignedXml)

- 01 XML invalido (IOException), función valSignedXml

6.2.3 Ejemplo de Salida, Estado 02 (Error: XML invalido, (SAXException), función valSignedXml)

- 02 XML Invalido (SAXException), funcion valSignedXml

Versión 1.9 del 18.11.2007

Pág.22de 32

SII WS de Autenticación con Certificado Digital

6.2.4 Ejemplo de Salida, Estado 03 (Error: ParserConfigurationException), funcion valSignedXml)

XML

Invalido

- 03 XML Invalido (ParserConfigurationException), funcion valSignedXml

6.2.5 Ejemplo de Salida, Estado 04 (Error: XML Invalido, elemento “Signature” no existe, funcion valSignedXml)

- 04 XML Invalido, elemento “Signature” no existe, función valSignedXml

6.2.6 Ejemplo de Salida, Estado 05 (Error: XML Invalido, firma invalida, función valSignedXml)

- 05 XML Invalido, firma invalida, funcion valSignedXml



Versión 1.9 del 18.11.2007

Pág.23de 32

SII WS de Autenticación con Certificado Digital

6.2.7 Ejemplo de Salida, Estado 06 (Error: XML Invalido, elemento “Semilla” no existe, función getSeed)

- - 06 XML Invalido, elemento “Semilla” no existe, función getSeed

6.2.8 Ejemplo de Salida, Estado 07 (ERROR (MessageException)

- - 07 ERROR (MessageException)

6.2.9 Ejemplo de Salida, Estado 08 (ERROR :Retorno)

- - 08 TIME-OUT DEL SEED

Nota : El estado 08, tiene varios errores asociados, los que se detallan en la

tabla “Estados de Salida de Genera Token”. Aquí se hace mención a sólo uno de ellos a modo de ejemplo.

Versión 1.9 del 18.11.2007

Pág.24de 32

SII WS de Autenticación con Certificado Digital

6.2.10 Ejemplo de Salida, Estado 09 (ERROR (MessageException))

- - 09 ERROR (MessageException)

6.2.11 Ejemplo de Salida, Estado 10 (ERROR: RETORNO DATOS)

- - 10 ERROR RETORNO DATOS

6.2.12 Ejemplo de Salida, Estado 11 (ERROR: XML Inválido, elemento “Certificate” no existe, función getCertificado)

-

11 XML Invalido, elemento “Certificate” no existe, función getCertificado



Versión 1.9 del 18.11.2007

Pág.25de 32

SII WS de Autenticación con Certificado Digital

6.2.13 Ejemplo de Salida, Estado 12 (ERROR (12) (MessageException))

-

12 ERROR (12) (MessageException)

6.2.14 Ejemplo de Salida, Estado -3 (Error en Autenticación)

-

-3 Error en Autenticación

Versión 1.9 del 18.11.2007

Pág.26de 32

SII WS de Autenticación con Certificado Digital

CAPITULO 7 GUIA PARA REALIZAR PRUEBAS Para probar los WS de Autenticación Automática, se deben seguir los siguientes pasos:

1.- Para obtener una Semilla, se debe invocar el servicio: https://palena.sii.cl/DTEWS/CrSeed.jws?WSDL 2.- Firmar Semilla Mediante un Cliente (ver Formato XML Entrada) 3.- Invocando el servicio GetTokenFromSeed.jws, para el envió del XML con las Semilla Firmada. https://palena.sii.cl/DTEWS/GetTokenFromSeed.jws?WSDL 4.- Se Obtiene Token

Nota: Si bien en este manual se detalla la autenticación automática para el ambiente de producción, el procedimiento es el mismo para el ambiente de certificación, solo se debe cambiar el nombre del servidor, reemplazando a palena.sii.cl por maullin.sii.cl. Por ejemplo: 1.- Para obtener una Semilla en certificación: https://maullin.sii.cl/DTEWS/CrSeed.jws?WSDL

2.- Generar un Token https://maullin.sii.cl/DTEWS/GetTokenFromSeed.jws?WSDL

Versión 1.9 del 18.11.2007

Pág.27de 32

SII WS de Autenticación con Certificado Digital

CAPITULO 8 Como firmar una Semilla Para firmar una semilla, se deben seguir los siguientes pasos: Obtener una semilla (invocando al WS CrSeed.jws de certificación o producción) La salida de CrSeed.jws corresponde al siguiente XML:

000002360958

00

Una vez obtenido el xml, que incluye la semilla, se debe rescatar el campo a firmar, el campo a firmar corresponde a: 000002360958

Una vez determinado el campo a firmar, este debe ser entregado al objeto (getToken), tal como se muestra en la figura 1.10.

000002360958

Figura 1.10

Versión 1.9 del 18.11.2007

Pág.28de 32

SII WS de Autenticación con Certificado Digital

Una vez integrado el objeto getToken con la semilla, se deben realizar los siguientes pasos. Aplicar la transformación y la canonicalización a este objeto.(Corresponde a una función interna propia de la librería de firma). Calcular el hash al objeto, para luego crear el elemento DigestValue (Corresponde a una función interna propia de la librería de firma). Crear el elemento SignedInfo .(Corresponde a una función interna propia de la librería de firma). Canonical izar y calcular la firma .(Corresponde a una función interna propia de la librería de firma) Crear el elemento SignatureValue con el valor de la firma (Corresponde a una función interna propia de la librería de firma)Generar la información de claves (elemento keyInfo). .(Corresponde a una función interna propia de la librería de firma).

Nota: Estos pasos pueden ser realizados en forma manual o mediante el uso de una librería)

Versión 1.9 del 18.11.2007

Pág.29de 32

SII WS de Autenticación con Certificado Digital

Por último se debe construir el elemento Signature que incluye los elementos SignedInfo, SignatureValue y keyInfo, tal como se puede observar en la figura 1.11, el cual comienza con (todo el elemento debe estar codificado ejemplo: < por < etc).

000002248802





kZvDbarenZxZPbWY7gNLxOan/NI=

ozuCSQX5uoHzOOIS0V3bRe5WK8MNMzL6pm2dEpRVLDDAqj8fGtfOjPBAOzoY9MHtB9O1Ml4lpjRYEJ 6+9uAI+g/mC6PT20wFcOMr0J2SmJmlf+6MkNhoHbfVkGJ4zxGvCx1ZvtNLAkJovFqBlFaaoJ08Rvkd2FrSXjRIf+NqUYo=



wFgMvA/vy1BXOBXOWI5fW/n45OHf4g1WYWLvBd68A6vpFlv6bEapsMabeyaQjwa/ UCAt75dNQdfjSTgLxMeKvjuatItAv4Sq4ncAe5POHRVwu9eziU+9+LQBa5FemDEM 7pVHjGR1heSAgeIuPBv7j1TKwv+kRE+iUcYFiKwXH9M=

AQAB

MIIEbDCCA9egAwIBAgIDAgSAMAsGCSqGSIb3DQEBBDCBsTEdMBsGA1UECBQU UmVnaW9uIE1ldHJvcG9saXRhbmExETAPBgNVBAcUCFNhbnRpYWdvMSIwIAYD VQQDFBlFLUNlcnRjaGlsZSBDQSBJbnRlcm1lZGlhMTYwNAYDVQQLFC1FbXBy ZXNhIE5hY2lvbmFsIGRlIENlcnRpZmljYWNpb24gRWxlY3Ryb25pY2ExFDAS BgNVBAoUC0UtQ0VSVENISUxFMQswCQYDVQQGEwJDTDAeFw0wMzA3MTUxODQx NTJaFw0wNDA3MTQwMDAwMDBaMIG6MQswCQYDVQQGEwJDTDEWMBQGA1UECBQN TWV0cm9wb2xpdGFuYTERMA8GA1UEBxQIU2FudGlhZ28xKDAmBgNVBAoUH1Nl cnZpY2lvcyBkZSBJbXB1ZXN0b3MgSW50ZXJub3MxGTAXBgNVBAsUEE9maWNp bmEgSW50ZXJuZXQxHDAaBgNVBAMUE1p1bGVtYSBPbGd1aW4gVHJhcm8xHTAb BgkqhkiG9w0BCQEWDnpvbGd1aW5Ac2lpLmNsMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDAWAy8D+/LUFc4Fc5Yjl9b+fjk4d/iDVZhYu8F3rwDq+kW W/psRqmwxpt7JpCPBr9QIC3vl01B1+NJOAvEx4q+O5q0i0C/hKridwB7k84d FXC717OJT734tAFrkV6YMQzulUeMZHWF5ICB4i48G/uPVMrC/6RET6JRxgWI rBcf0wIDAQABo4IBiTCCAYUwIwYDVR0RBBwwGqAYBggrBgEEAcEBAaAMFgox MDQ1MDM1NC0zMAwGA1UdEwEB/wQCMAAwPAYDVR0fBDUwMzAxoC+gLYYraHR0 cDovL2NybC5lLWNlcnRjaGlsZS5jbC9FY2VydGNoaWxlQ0FJLmNybDAjBgNV HRIEHDAaoBgGCCsGAQQBwQECoAwWCjk2OTI4MTgwLTUwgd8GA1UdIASB1zCB 1DCB0QYIKwYBBAHDUgUwgcQwLwYIKwYBBQUHAgEWI2h0dHA6Ly93d3cuZS1j ZXJ0Y2hpbGUuY2wvMjAwMC9DUFMvMIGQBggrBgEFBQcCAjCBgxqBgEVsIHRp dHVsYXIgaGEgc2lkbyB2YWxpZGFkbyBlbiBmb3JtYSBwcmVzZW5jaWFsLCBx dWVkYW5kbyBoYWJpbGl0YWRvIGVsIENlcnRpZmljYWRvIHBhcmEgdXNvIHRy aWJ1dGFyaW8sIHBhZ29zLCBjb21lcmNpbyB5IG90cm9zMAsGA1UdDwQEAwIE 8DALBgkqhkiG9w0BAQQDgYEAka3Y5VbyjbHwF9sew2+6ZRaL4zIQgv0Cnd9p VGYqSVFQz2YK/AEyasFoWm2evdlo5QJ8TjKqd+QlI674tvAumNIARksCZeUW hpjdD/vLp7exQUoVKOCInQVQQ6LUDAf6v9vgIB9Mwf6yTbnxwdvv1EeiLQEBd 2Af9oF7fVsXKLsY=



Figura 1.11

Versión 1.9 del 18.11.2007

Pág.30de 32

SII WS de Autenticación con Certificado Digital

El elemento “Signature”, indicado en la figura 1.11, corresponde al parámetro de entrada requerido por el WS GetTokenFromSeed.jws, que permite generar un token. Ver punto: 4.1.3 del manual.

https://palena.sii.cl/DTEWS/GetTokenFromSeed.jws?WSDL.

Versión 1.9 del 18.11.2007

Pág.31de 32

SII WS de Autenticación con Certificado Digital

ANEXO 1 1.- Ejemplo de TOKEN En este anexo de muestra un ejemplo de un Token

TOKEN=gd43dh6sfE34Kd3

Versión 1.9 del 18.11.2007

Pág.32de 32

Manual Desarrollador Externo Envío Automático Documentos Tributarios Electrónicos OI2003_UPDTE_MDE_1.5

Oficina Internet Subdirección Informática Servicio Impuestos Internos Fecha:31/10/2003

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

CONTROL DE VERSIONES ...................................................................................................... 3 INTRODUCCIÓN ...................................................................................................................... 4 CAPÍTULO 1............................................................................................................................. 5 ANÁLISIS DEL SISTEMA ....................................................................................................... 5 1.1 QUIENES PUEDEN UTILIZ AR ESTA APLICACIÓN . ...................................................................... 5 CAPÍTULO 2............................................................................................................................. 6 VISIÓN GENERAL ENVÍO AUTOMÁTICO DE DTE ................................................................ 6 2.1 LOS TIPOS DE STATUS SON: ................................ ................................ ................................ . 8 2.2 FORMATO DE SALIDA .......................................................................................................... 9 2. REQUERIMIENTOS DEL REQUEST ..................................................................................... 11 CAPÍTULO 3............................................................................................................................ 12 PRUEBAS DE ENVIO ........................................................................................................... 12 ANEXO 1.................................................................................................................................13 1.- E JEMPLO DE TOKEN.......................................................................................................... 13 ANEXO 2.................................................................................................................................14 1.- FORMATO A RCHIVO PARA ENVÍO POR U PLOAD ( XML) .............................................................. 14 ANEXO 3.................................................................................................................................15 1.- E JEMPLO A RCHIVO GENERADOS POR CLIENTE C ON SU RESPECTIVO HEADER ............................... 15 ANEXO 4.................................................................................................................................16 P ROBLEMAS FRECUENTES D ETECTADOS EN LA IMPLEMENTACIÓN DEL E NVÍO. ...................................16

Versión 1.3 del 28.07.2003

Pág.2 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

CONTROL DE VERSIONES

Versión

Fecha

1.0

27/11/2002

1.1 12/02/2003 Se agrego Capitulo 3 (Pruebas Envío) 1.2 01/04/2003 Se reemplazo parámetro MSIE 5.5 por PROG 1.0, en Requerimiento de Request y en Anexo 3 1.3 Se modificaron los Tipos de Status 1.4 Se agrego Anexo 4 1.5 31/10/2003 Se agregaron Status : 7,8,9, ver punto 2.1

Versión 1.3 del 28.07.2003

CONTROL DE VERSIONES Autor

Revisor

Zulema Olguín T.

Quentin Sherman

Zulema Olguín T.

Quentin Sherman

Zulema Olguín T. Quentin Sherman El cambio en este parámetro permitirá que el formato de Salida sea en XML Zulema Olguín Traro Nicolas Chelebifski Se modificaron mensajes de Status Zulema Olguín T. Nicolas Chelebifski Se detallan problemas frecuentes en uso del manual Zulema Olguín Traro Se agregaron Status 7,8,9

Pág.3 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

INTRODUCCIÓN Este documento está dirigido a quienes tengan la misión de implementar el envío automático de Documentos Tributarios Electrónicos( DTE). La misión del programador, será simular las operaciones de autenticación, mediante certificado digital, y el proceso de upload que normalmente son realizadas por un browser. En este manual se aborda el proceso de Upload. Para poder utilizar este manual, es necesario tener previo conocimiento de Formato RFC1867, XML y Certificado Digital. Nota : Para implementar el envío de DTE, mediante la Autenticación Automática, se recomienda ver: Manual Desarrollador “Ws Autenticación Automática con Certificado Digital ( OI2003_AUTAUTOM_MDE_1.2 ).

Versión 1.3 del 28.07.2003

Pág.4 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

CAPÍTULO 1 ANÁLISIS DEL SISTEMA

Esta aplicación, permite a los usuarios el enviar los de documentos tributarios Electrónicos , mediante upload. Esta es una aplicación basada en los métodos browser programa a programa 1.1 Quienes pueden utilizar esta aplicación. Esta aplicación puede ser utilizada por todas aquellas Empresas que requieran enviar archivos DTE, por Upload.

Versión 1.3 del 28.07.2003

Pág.5 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

CAPÍTULO 2 VISIÓN GENERAL ENVÍO AUTOMÁTICO DE DTE

Ambiente Usuario

Ambiente Servidor

Web Server

Usuario

Autentica-Automática

CGI

Chequea Certificado Valida Cert. Revocados

Se genera Token

DTE Campos C1 C2 C3 XML-RFC

RESPUESTA XML

CRL

Si Ok.

Envía DTE Formato RFC1867

Status, TrackID XML

Figura 2.0

De acuerdo al diagrama superior (figura 2.0), para que un usuario pueda enviar en forma automática los archivos DTE, lo primero que debe hacer es autenticarse, mediante el uso de la Autenticación Automática. Tal como se mencionó anteriormente, esta es una aplicación basada en los métodos browser programa a programa, por lo que se debe simular la autenticación, tal como si se tratara de una autenticación por browser.

Versión 1.3 del 28.07.2003

Pág.6 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

La autenticación valida el certificado y chequea que no esté revocado. Si los datos del certificado no son válidos, el sistema rechaza la autenticación. Si los datos del certificado son válidos, el Web Server genera en forma automática una cookie llamada TOKEN. Un Token es un identificador único el cual es almacenado en el Header del Response, y permite la búsqueda de toda la información relacionada a una sesión del usuario. Ver Ejemplo Token, ANEXO 1 Cuando la aplicación Cliente recibe los datos del Response , el usuario puede enviar su archivo por Upload. Normalmente el envío de archivos mediante Upload se realiza a través del browser, sin embargo como este sistema se basa en el método programa a programa, la parte browser es reemplazada por una aplicación Cliente que simula el tradicional proceso de upload, para lo cual se debe conectar hacia el sitio del SII mediante Socket. El archivo que se enviará por upload debe tener formato XML, cuyos campos deben ser validados contra un archivo Schema entregado por el SII (EnvioDTE.xsd) y debe cumplir con las normas descritas en los estándares RFC1867 ( The Requests for Comments). Ver ejemplo: Formato Archivo para envío por Upload ANEXO 2

Versión 1.3 del 28.07.2003

Pág.7 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

El programa Cliente al momento de hacer upload al archivo DTE (en formato XML), agrega los datos del Response , incluido el Token en el Header del archivo y lo envía hacia el sitio del SII. Ver ejemplo : Archivo Upload generado por Cliente con su Header ANEXO 3 Una vez recibido el archivo DTE, nuestro sistema, genera una salida en formato XML, que indica el status de la recepción del archivo. 2.1 Los tipos de Status son: 0 = Upload OK 1 = El Sender no tiene permiso para enviar 2 = Error en tamaño del archivo (muy grande o muy chico) 3 = Archivo cortado (tamaño al parámetro size) 5 = No está autenticado 6 = Empresa no autorizada a enviar archivos 7= Esquema Invalido 8= Firma del Documento 9= Sistema Bloqueado Otro = Error Interno.

Versión 1.3 del 28.07.2003

Pág.8 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

2.2 Formato de Salida Como se mencionó anteriormente, una vez que el SII, ha recepcionado el archivo DTE, nuestro sistema genera una respuesta en formato XML, que indica el status de la recepción del archivo recibido.

Los Parámetros de Salida son: Rut y Dv de quien envía Rut y Dv de la Compañía Nombre archivo DTE enviado Fecha, Hora, min., seg, de recepción. Estado de la recepción del DTE Indica Número de Atención

1-9 3-5 EnvioEjemplo.xml

2002-11-25 18:51:44 0 39

Ejemplo Formato de Salida, Status 0 (Recepción OK)

- 1- 9 3-5 EnvioEjemplo.xm l 2002-11-25 18:51:44 0 39

Figura 2.1

Nota: De acuerdo a la figura 2.1 ,si la recepción del archivo DTE, tiene status 0, se le asigna un TrackID, que corres ponde al número de atención o identificador del envío. 39

Versión 1.3 del 28.07.2003

Pág.9 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

Ejemplo Formato de Salida, Status 5 (Error Interno (WRT).

- 1- 9 3-5 EnvioEjemplo.xml 2002-11-25 18:51:44 5

Figura 2.2

Ejemplo Formato de Salida, Status 7 (Eschema invalido). < RECEPCIONDTE> < RUTSENDER>07880442-4 < RUTCOMPANY>88888888-8 ENVFIN_100_sign.xml 2003-10-31 10:04:26 7 < DETAIL > LSX-00265: attribute "version" value "3.2" is wrong (must be ".2")

LSX-00213: only 0 occurrences of particle "sequence", minimum is 1

Figura 2.3

Versión 1.3 del 28.07.2003

Pág.10 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

2. REQUERIMIENTOS DEL REQUEST Como se mencionó anteriormente, el programa Cliente, debe incluir en el header del request lo siguiente: POST /cgi_dte/UPL/DTEUpload HTTP/1.0^M Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/ms-excel, application/msword, */*^M Referer: {URL que referencia a upload Ej. http://empresaabc.cl/test.html}^M Accept-Language: es-cl^M Content-Type: multipart/form-data: boundary={boundary data: Ej. --------------------------7d23e2a11301c4}^M Accept-Encoding: gzip, deflate^M User-Agent: Mozilla/4.0 (compatible; PROG 1.0; Windows NT 5.0; YComp 5.0.2.4)^M Host: {Host Id. Ej: https://maullin.sii.cl}^M Content-Length: {largo total de mensaje sin Req. Header. Ej.: 10240}^M Connection: Keep-Alive^M Cache-Control: no-cache^M Cookie: TOKEN={Entregado por Autenticación. Ej.: YZD0II2ApZjlM}^M ^M

Figura 2.3

Nota: El parámetro (PROG 1.0), encerrado en el circulo, ver Figura 2.3, permitirá que el formato de salida sea en un XML

Versión 1.3 del 28.07.2003

Pág.11 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

CAPÍTULO 3 PRUEBAS DE ENVIO

Para realizar un UPLOAD en forma automátic a, el programa cliente debe simular un Browser, es decir, el programa debe realizar la comunicación tipo Socket de TCP/IP con encriptación de datos SSL. Una vez conectado al sitio, el programa debe enviar los datos tal como se muestra en ANEXO 3, para lo cuál, debe reemplazar los campos con sus datos correspondientes. Los siguientes son los datos para realizar la conexión: 1. Host : maullin.sii.cl 2. Puerto : 443 3. Tipo de encriptación : SSL

Versión 1.3 del 28.07.2003

Pág.12 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

ANEXO 1 1.- Ejemplo de TOKEN

TOKEN=gd43dh6sfE34Kd3

Figura 2.4

Versión 1.3 del 28.07.2003

Pág.13 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

ANEXO 2 1.- Formato Archivo para envío por Upload ( XML)

…………………………………………………………………………

Figura 2.5

Versión 1.3 del 28.07.2003

Pág.14 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

ANEXO 3 1.- Ejemplo Archivo generados por Cliente Con su respectivo Header Nota: Lo destacado con rojo corresponde al Header.

POST /cgi_dte/UPL/DTEUpload HTTP/1.0^M Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/ms-excel, application/msword, */*^M Referer: {URL que referencia a upload Ej. http://empresaabc.cl/test.html}^M Accept-Language: es-cl^M Content-Type: multipart/form-data: boundary={boundary data: Ej. --------------------------7d23e2a11301c4}^M Accept-Encoding: gzip, deflate^M User-Agent: Mozilla/4.0 (compatible; PROG 1.0; Windows NT 5.0; YComp 5.0.2.4)^M Host: {Host Id. Ej: https://maullin.sii.cl}^M Content-Length: {largo total de mensaje sin Req. Header. Ej.: 10240}^M Connection: Keep-Alive^M Cache-Control: no-cache^M Cookie: TOKEN={Entregado por Autenticación. Ej.: YZD0II2ApZjlM}^M ^M {Comienzo de Multipart/Form-data} -----------------------------7d23e2a11301c4^M Content-Disposition: form-data; name="rutSender"^M ^M 1^M -----------------------------7d23e2a11301c4^M Content-Disposition: form-data; name="dvSender"^M ^M 9^M -----------------------------7d23e2a11301c4^M Content-Disposition: form-data; name="rutCompany"^M ^M 3^M -----------------------------7d23e2a11301c4^M Content-Disposition: form-data; name="dvCompany"^M ^M 5^M -----------------------------7d23e2a11301c4^M Content-Disposition: form-data; name="archivo"; filename="EnvioEjemplo.xml"^M Content-Type: text/xml^M ^M ^M ^M ^M ……………………………………………………………………………. ^M ^M -----------------------------7d23e2a11301c4--^M

Figura 2.6

Versión 1.3 del 28.07.2003

Pág.15 de 16

BORRADOR SII ENVÍOAUTOMÁTICO (WS) DE DTES

ANEXO 4 Problemas Frecuentes Detectados en la Implementación del Envío. Algunos de los problemas frecuentes detectados en el envió se relacionan con: Campo boundary

Problema

Solución

Diferencia en la composición del El boundary del “Cuerpo del Mensaje”, debe llevar dos boundary (Header y Cuerpo del caracteres “más” que los caracteres del boundary del Header. Mensaje) Además el boundary, del Final de mensaje, debe llevar dos guiones al comienzo y dos guiones al final, antes del control M. Ver Ejemplos. 1-Ejemplo boundary: Header Content-Type: multipart/form-data: boundary=7d23e2a11301c4^M 2-Ejemplo boundary: Cuerpo del mensaje, debe tener 2 guiones al inicio.

--7d23e2a11301c4^M 3-Ejemplo boundary: Final de mensaje, debe llevar dos guiones del comienzo más dos adicionales antes del control M.

--7d23e2a11301c4--^M Largo del Mensaje

El largo del mensaje incluye El largo del mensaje no debe incluir datos del Header, tal datos del Header como se muestra en la figura 2.6 el Header corresponde a los datos encerrado en el recuadro, la línea {Comienzo de Multipart/Form-data}, corresponde a una línea en blanco, por lo que el inicio del mensaje comenzaría en el primer carácter o guión después de {Comienzo de Multipart/Form-data} Ejemplo: {Comienzo de Multipart/Form-data} --7d23e2a11301c4^M

Host

Control M (^M)

Uso del campo Host en programas C y que además están utilizando la librería de OpenSSL Falta el Control M

Donde el circulo indica el inicio del mensaje. Los programas en lenguaje C, los cuales además utilizan la librería OpenSSL, “NO deben incluir el Campo Host”. -Los caracteres Control M (^M), forman parte del archivo, por lo que estos deben ser enviados. -La forma de parsear los Control M (^M), depende del de Cliente: Si el Cliente es un programa en C++ y utiliza el objeto string para la concatenación, se debe indicar cada fin de línea con “\r\n”, para parsear el ^M. Si el Cliente es un programa en C o C++ y utiliza char, se debe indicar cada fin de línea con “\n”.

Versión 1.3 del 28.07.2003

Pág.16 de 16

Manual de Desarrollador Externo Consulta de Estado de Upload Dte OI2004_ CEUPDTE _MDE_1.10

Oficina Internet Subdirección Informática Servicio Impuestos Internos Fecha: 08/11/2004

INDICE

CONTROL DE VERSIONES .................................................................................................................3 INTRODUCCIÓN .................................................................................................................................4 CAPITULO 1........................................................................................................................................5 OBJETIVOS Y CARACTERISTICAS ..................................................................................................5 1. O BJETIVOS DE LA APLICACIÓN................................ ................................ ................................ ............5 2. CARACTERÍSTICA DE LA APLICACIÓN ...................................................................................................5 CAPITULO 2........................................................................................................................................6 WSDL DE Q UERY EST U P ................................ ................................ ................................ ....................6 2.1.1 WSDL DE Q UERY ESTU P. JWS .....................................................................................................6 2.1.2 D ETALLE PARÁMETROS DEL WSDL .........................................................................................9 CAPITULO 3......................................................................................................................................10 DETALLE PARÁMETROS DEL SERVICIO .......................................................................................10 3.1 PARÁMETROS DE E NTRADA ......................................................................................................... 10 3.1.1 EJEMPLO R EAL P ARÁMETROS DE E NTRADA F ORMATO WSDL................................ .......................... 10 3.2 PARÁMETROS DE S ALIDA ............................................................................................................. 11 3.3 ESTADOS DE S ALIDA ................................................................................................................... 11 3.4 EJEMPLOS DE SALIDA ................................................................................................................. 12 3.4.1 EJEMPLO P ARÁMETROS DE S ALIDA WSDL CODIFICADO E STADO EPR ............................................12 CAMBIAR SALIDA DEACURDO A EJEMPLO 3.4.1.1 .................................................................................... 12 3.4.1.1 E JEMPLO PARÁMETROS DE SALIDA D ECODIFICADO ..................................................................... 12 3.5 ESTADOS DE S ALIDA POR ERROR.............................................................................................. 13 3.5.1 Errores de Consulta: ................................ ................................ ................................ ..........13 3.5.2 Errores por Autenticación: ................................ ................................ ................................ .. 14 3.5.3 Otros Errores: .................................................................................................................... 14 3.5.1 EJEMPLODE SALIDA ERROR WSDL CODIFICADO (ERR_CODE 2) .............................................. 15 3.5.1.1 E JEMPLO DE S ALIDA ERROR WSDL D ECODIFICADO ( ERR_CODE 2: ERROR: DE PROCESO) ..... 15 CAPITULO 4......................................................................................................................................16 EJEMPLOS DE SALIDA FORMATO XML........................................................................................ 16 4.1 EJEMPLO P ARÁMETROS DE S ALIDA E STADO RSC (RECHAZADO POR ERROR EN SCHEMA ) .....................16 4.2 EJEMPLO P ARÁMETROS DE S ALIDA E STADO SOK (S CHEMA V ALIDADO ).............................................. 16 4.3 EJEMPLO P ARÁMETROS DE S ALIDA E STADO CRT (CARATULA OK) .....................................................16 4.4 EJEMPLO P ARÁMETROS DE S ALIDA E STADO RFR (P ARAMETROS DE ENTRADA INCOMPLETOS )............... 17 4.5 EJEMPLO P ARÁMETROS DE S ALIDA E STADO FOK (ERROR : RETORNO DATOS) ............................... 17 4.6 EJEMPLO P ARÁMETROS DE S ALIDA E STADO PRD (ERROR : RETORNO DATOS ).................................... 17 4.7 EJEMPLO P ARÁMETROS DE S ALIDA E STADO RCT (RECHAZADO POR ERROR EN CARÁTULA ) .................. 18 4.8 EJEMPLO P ARÁMETROS DE S ALIDA E STADO EPR (ENVÍO P ROCESADO ).............................................. 18 4.9 EJEMPLO P ARÁMETROS DE S ALIDA SRV_CODE 1( ERROR: DE PROCESO )....................................... 18 4.10 EJEMPLO P ARÁMETROS DE S ALIDA ERR_CODE 2(ERROR: DE PROCESO )..................................... 18 4.11 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO-3 (ERROR: RUT USUA RIO NO EXISTE) ................ 19 4.12 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO- 4(ERROR: OBTENCIÓN DE DATOS ).................... 19 4.13 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO-5(ERROR: RETORNO DATOS) ............................... 19 4.14 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO-6(ERROR: USUARIO NO AUTORIZADO) .............. 19 4.15 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO- 7(ERROR: RETORNO DATOS)............................... 19 4.16 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO-8(ERROR: RETORNO DE DATOS) .........................20 4.17 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO-9(ERROR: RETORNO DE DATOS )........................ 20 4.18 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO-10(ERROR: VALIDA RUT)......................................20

1

4.19 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO-11(ERROR: CONSULTA) ......................................... 20 4.20 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO-12(ERROR: RETORNO CONSULTA) ...................... 20 4.21 EJEMPLO P ARÁMETROS DE S ALIDA ESTADO-13(ERROR: USUARIO NULO) ................................ 21 4.22 E JEMPLO P ARÁMETROS DE S ALIDA ESTADO-14 (ERROR: XML RETORNO) .............................. 21 4.23 EJEMPLO P ARÁMETROS DE S ALIDA E STADO 002 (ERROR: TOKEN INACTIVO) ............................. 21 4.24 EJEMPLO P ARÁMETROS DE S ALIDA E STADO 003 (ERROR: TOKEN NO EXISTE)............................ 21 4.25 EJEMPLO P ARÁMETROS DE S ALIDA E STADO 001 (ECOOKIE INACTIVO)........................................21 CAPITULO 5......................................................................................................................................22 GUIA PARA REALIZAR PRUEBAS................................ ................................ ................................ .. 22 REFERENCIAS .............................................................................................................................. 23

2

CONTROL DE VERSIONES Versión

Fecha

CONTROL DE VERSIONES Autor

1.0 29/01/2003 1.1 24/04/2003 1.3 22/04/2003 1.4 11/08/2003 Se agregaron Estados de salida

Zulema Olguín T. Zulema Olguín T. Zulema Olguín T. Zulema Olguín T.

1.5 08/04/2004 Se modifico Url en Capitulo 5 (Guía para Pruebas, le faltaba la “s” al http)

Zulema Olguín T

Revisor Quentin Sherman Quentin Sherman Quentin Sherman

Donde decía: http://maullin.sii.cl/DTEWS/QueryEstUp.j ws?WSDL http://maullin.sii.cl/DTEWS/QueryEstUp.j ws?WSDL

Se cambio por: https://maullin.sii.cl/DTEWS/QueryEstUp .jws?WSDL https://maullin.sii.cl/DTEWS/QueryEstUp .jws?WSDL

1.6 08/04/2004 Se m odifico texto de introducción (como acceder a los WS del SII) 1.7 07/05/2004 Se modifico texto de los mensajes de salida: 3.5.3 Otros Errores 1.8 15/06/2004 Se agrego al XML de salida un número de atención (), ver punto 3.2 1.9 11/08/2004 Se modifica URL WS:

Zulema Olguín T.

Zulema Olguín T.

Zulema Olguín T.

Zulema Olguín T.

https://maullin.sii.cl/DTEWS/QueryE stUp.jws?WSDL 1.10 08/11/2004 Se agrego estado “001” (Cookie Inactivo), ver punto : 3.5.2

Zulema Olguín T .

3

INTRODUCCIÓN Consulta Estado de Upload DTE (CEUPDTE), como parte del proyecto Documentos Tributarios Electrónicos (DTE), entrega a las empresas un servicio (“QueryEstUp”), el cual permite consultar a través de WEB SERVICES, el estado de un archivo DTE enviado al SII, mediante Upload. Este documento está dirigido a quienes tengan la misión de utilizar y probar el servicio mencionado anteriormente (QueryEstUp). Para acceder a los servicios que ofrece el SII, se debe utilizar WSDL(Web Services Definition Language). WSDL es un lenguaje descriptor, basado en XML, que permite conocer en forma abstracta, la gramática de los componentes de un Web Service (ubicación, formato, tipos de datos, servicios, funciones, parámetros de entrada, salida, etc). Para poder acceder a un WSDL, se debe conocer su ubicación, por ejemplo: La ubicación del WSDL, para el ambiente de certificación de QueryEstUp.jws, es: https://maullin.sii.cl/DTEWS/QueryEstUp.jws?WSDL. Cuando el cliente conoce el WSDL del servicio, puede construir un Request en formato SOAP (Simple Object Access Protocolo), para luego enviarlo hacia el proveedor de servicio, previa Autenticación. Respecto a la Autenticación, para poder realizar consultas hacia cualquier Web Service entregado por el SII, los clientes deben estar previamente autenticados a través de la AUTENTICACIÓN AUTOMATICA. Para la implementación de la Autenticación Automática, es necesario ver Manual de Desarrollador – Requisitos de uso. Para poder utilizar este manual, es necesario tener previo conocimiento de XML, Web Services y Certificado Digital. Recomendaciones: Se recomienda el uso de la herramienta XMLSPY5 de la Altova GmbH http://www.altova.com

4

CAPITULO 1 OBJETIVOS Y CARACTERISTICAS

1. Objetivos de la aplicación El objetivo de este servicio es informar el Estado de un archivo DTE, enviado mediante Upload. 2. Característica de la aplicación El servicio QueryEstUp, es de tipo “Consulta” -”Respuesta Es una aplicación B2B. Esta aplicación puede ser utilizada por aquellos usuarios habilitados para su uso.

5

CAPITULO 2 WSDL DE QueryEstUp

La ubicación del WSDL, para esta aplicación (QueryEstUp) es: https://maullin.sii.cl/DTEWS/QueryEstUp.jws?WSDL 2.1.1 WSDL de QueryEstUp.jws

























6



































Figura 2.1.1

8

2.1.2 Detalle Parámetros del WSDL De acuerdo a lo destacado en el recuadro del esquema WSDL figura 2.1.1, QueryEstUp entrega sólo un servicio “getEstUp”, el cual requiere de los siguientes parámetros de entrada: Rut, Dv, TrackId y Token.

9

CAPITULO 3 DETALLE PARÁMETROS DEL SERVICIO

3.1 Parámetros de Entrada Los parámetros de entrada requeridos por el servicio, se detallan en el siguiente ejemplo: 3.1.1 Ejemplo Real Parámetros de Entrada Formato WSDL







Donde: Campo

Tipo

Rut Dv

String numérico String Alfanumérico

Largo 1-8 1-1

TrackId String numérico

1-10

Token

1-40

String Alfanumérico

Detalle Corresponde al Rut Consultado Corresponde al DV del Rut Consultado Corresponde al identificador de Envió(similar al número de atención o folio) Es un Token es un identificador único el cual es almacenado y enviado al cliente en el Header del Response de la Autenticación Automática con Certificado Digital (CD), y permite la búsqueda de toda la información relacionada a una sesión del cliente.

Obligatorios S S S S

10

3.2 Parámetros de Salida La salida del Servicio corresponden a un “string” XML codificado, por lo tanto necesario que el programa cliente sea capaz de decodificar el “string” y llevarlo a formato original, los campos de retorno son: TRACKID, ESTADO y GLOSA, NUM_ATENCIÓN. Donde: Campo

Tipo

TRACKID

String numérico

ESTADO

String numérico

GLOSA

String Alfanumérico

NUM_ATENCION String

Largo 1-10 1-3 1-40 1-40

Detalle identificador de Envió(similar al número de atención o folio) Código Estado Detalle Código Número de Atención, Identificador de la consulta

Obligatorios S S S S

3.3 Estados de Salida El resultado de la consulta puede arrojar uno de los siguientes Estados: Estado RSC SOK CRT RFR FOK PDR RCT EPR

Tipo String String String numérico String numérico String numérico String numérico String numérico String numérico

Glosa Rechazado por Error en Schema Schema Validado Carátula OK Rechazado por Error en Firma Firma de Envió Validada Envió en Proceso Rechazado por Error en Carátula Envió Procesado

11

3.4 Ejemplos de Salida A continuación se mostrará una serie de ejemplos de salida en ambos formatos Codificado y Decodificado. 3.4.1 Ejemplo Parámetros de Salida WSDL Codificado Estado EPR



5329 2EPREnvio Procesado561010 532 ( 2004/06/14 16:44:20)



Cambiar salida deacurdo a Ejemplo 3.4.1.1 3.4.1.1 Ejemplo Parámetros de Salida Decodificado

- - 53292 EPR Envio Procesado

- 56 1 0 1 0 532 ( 2004/06/14 16:44:20)

12

3.5 Estados de Salida por ERROR El resultado de la consulta puede arrojar uno de los siguientes Estados de Error:

3.5.1 Errores de Consulta: SRV_CODE SQL_CODE ERR_CODE

Donde : SRV_CODE 0 1 2

Tipo String numérico String numérico String numérico

Largo 1-1 1-1 1-1

Glosa Todo Ok Error en Entrada Error SQL

SQL_CODE 0 OTRO

Tipo S tring numérico S tring numérico

Largo Glosa 1-2 Schema Validado 1-2 Código de Oracle

ERR_CODE 0 1

Tipo S tring numérico S tring numérico

2

S tring numérico

Largo Glosa 1-1 Se retorna el estado 1-1 El envío no es de la Empresa, faltan parámetros de entrada. 1-1 Error de Proceso

13

3.5.2 Errores por Autenticación:

TOKEN 001 002 003

Tipo S tring S tring S tring

Largo 1-3 1-3 1-3

Glosa Cookie Inactivo(o Token Inactivo) Token Inactivo Token No Existe

3.5.3 Otros Errores: ESTADO -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 -13 -14 Otros

Tipo String numérico String String String String String String String String String String String String String

numérico numérico numérico numérico numérico numérico numérico numérico numérico numérico numérico numérico numérico

Largo Glosa ERROR: RETORNO CAMPO ESTADO, NO 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-2 1-2 1-2 1-2 1-2

EXISTE ERROR RETORNO ERROR: RUT USUARIO NO EXISTE ERROR OBTENCION DE DATOS ERROR RETORNO DATOS ERROR: USUARIO NO AUTORIZADO ERROR RETORNO DATOS ERROR: RETORNO DATOS ERROR: RETORNO DATOS ERROR: VALIDA RUT USUARIO ERR_CODE, SQL_CODE, SRV_CODE ERROR: RETORNO CONSULTA ERROR RUT USUARIO NULO ERROR XML RETORNO DATOS

14

3.5.1 Ejemplode Salida ERROR WSDL Codificado (ERR_CODE 2)



12 532 ( 2004/06/14 16:44:20)



3.5.1.1 Ejemplo de Salida ERROR WSDL Decodificado (ERR_CODE 2: ERROR: De proceso)

- - -1 2

532 ( 2004/06/14 16:44:20)

15

CAPITULO 4 EJEMPLOS DE SALIDA FORMATO XML

En este capítulo, se muestran los ejemplos de los posibles Estados de Salida de la aplicación. 4.1 Ejemplo Parámetros de Salida Estado RSC ( Rechazado por Error en Schema)

- RSC Rechazado por Error en Schema 532 ( 2004/06/14 16:44:20)

4.2 Ejemplo Parámetros de Salida Estado SOK ( Schema Validado)

- SDK Schema Validado 532 ( 2004/06/14 16:44:20)

4.3 Ejemplo Parámetros de Salida Estado CRT (Caratula OK)

- CRT Caratula OK 532 ( 2004/06/14 16:44:20)

16

4.4 Ejemplo Parámetros de Salida Estado RFR (Parametros de Entrada Incompletos)

- - RFR Rechazado por Error en Firma 532 ( 2004/06/14 16:44:20)

4.5 Ejemplo Parámetros de Salida Estado FOK ( Error: RETORNO DATOS)

- - 05 Error: RETORNO DATOS 532 ( 2004/06/14 16:44:20)

4.6 Ejemplo Parámetros de Salida Estado PRD ( Error: Retorno Datos)

- - PRD Error Retorno Datos 532 ( 2004/06/14 16:44:20)

17

4.7 Ejemplo Parámetros de Salida Estado RCT ( Rechazado por Error en Carátula) - - RCT Rechazado por Error en Carátula 532 ( 2004/06/14 16:44:20)

4.8 Ejemplo Parámetros de Salida Estado EPR ( Envío Procesado)

- 251 EPR Envio Procesado 532 ( 2004/06/14 16:44:20)

- 33 1 1 0 0

4.9 Ejemplo Parámetros de Salida SRV_CODE 1(ERROR: De proceso )

- -11

1 532 ( 2004/06/14 16:44:20)

4.10 Ejemplo Parámetros de Salida ERR_CODE 2(ERROR: De proceso)

- -11 2

532 ( 2004/06/14 16:44:20)

18

4.11 Ejemplo Parámetros de Salida ESTADO-3 (ERROR: RUT USUARIO NO EXISTE )

- - -3 ERROR : RUT USUARIO NO EXISTE

4.12 Ejemplo Parámetros de Salida ESTADO-4(ERROR: OBTENCIÓN DE DATOS )

- - -4 ERROR : OBTENCIÓN DE DATOS