# Envío Automático de Documentos Tributarios Electrónicos **Archivo fuente:** `envio.pdf` **Páginas:** 16 > Conversión automática a Markdown a partir del PDF cargado. Se conserva el texto extraído y se agregan separadores por página. Las figuras o diagramas se mencionan cuando el texto extraído los referencia; no se incrustan imágenes. --- ## Página 1 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 --- ## Página 2 ## 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 UTILIZAR 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 --- ## Página 3 ## BORRADOR SII ## ENVÍOAUTOMÁTICO (WS) DE DTES ## CONTROL DE VERSIONES ## CONTROL DE VERSIONES Versión Fecha Autor Revisor 1.0 27/11/2002 Zulema Olguín T. Quentin Sherman ?? 1.1 12/02/2003 Zulema Olguín T. Quentin Sherman Se agrego Capitulo 3 (Pruebas ?? Envío) 1.2 01/04/2003 Zulema Olguín T. Quentin Sherman Se reemplazo parámetro MSIE ?? El cambio en este parámetro permitirá que el 5.5 por PROG 1.0, en formato de Salida sea en XML Requerimiento de Request y en ## Anexo 3 1.3 Zulema Olguín Traro Nicolas Chelebifski Se modificaron los Tipos de ?? Se modificaron mensajes de Status Status 1.4 Zulema Olguín T. Nicolas Chelebifski Se agrego Anexo 4 ?? Se detallan problemas frecuentes en uso del manual 1.5 31/10/2003 ?? Zulema Olguín Traro Se agregaron Status : 7,8,9, ver ?? Se agregaron Status 7,8,9 punto 2.1 --- ## Página 4 ## 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 ). --- ## Página 5 ## 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. --- ## Página 6 ## BORRADOR SII ## ENVÍOAUTOMÁTICO (WS) DE DTES ## CAPÍTULO 2 ## VISIÓN GENERAL ENVÍO AUTOMÁTICO DE DTE Ambiente Usuario Ambiente Servidor Usuario Web Server CGI Autentica-Automática Chequea Certificado Valida Cert. Revocados CRL Se genera Token Si Ok. DTE Campos Envía DTE Formato C1 C2 C3 RFC1867 XML-RFC RESPUESTA Status, TrackID XML 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. --- ## Página 7 ## 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 RFC- 1867 ( The Requests for Comments). Ver ejemplo: Formato Archivo para envío por Upload ANEXO 2 --- ## Página 8 ## 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. --- ## Página 9 ## 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 1-9 ?? Rut y Dv de la Compañía 3-5 ?? Nombre archivo DTE enviado EnvioEjemplo.xml ?? Fecha, Hora, min., seg, de 2002-11-25 18:51:44 recepción. ```xml 0 ``` ?? Estado de la recepción del DTE ?? Indica Número de Atención 39 Ejemplo Formato de Salida, Status 0 (Recepción OK) ```xml 1- 9 3-5 EnvioEjemplo.x m 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. ```xml 39 ``` --- ## Página 10 ## BORRADOR SII ## ENVÍOAUTOMÁTICO (WS) DE DTES Ejemplo Formato de Salida, Status 5 (Error Interno (WRT). ```xml 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 ```xml 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 --- ## Página 11 ## 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 --- ## Página 12 ## 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 --- ## Página 13 ## BORRADOR SII ## ENVÍOAUTOMÁTICO (WS) DE DTES ## ANEXO 1 1.- Ejemplo de TOKEN TOKEN=gd43dh6sfE34Kd3 Figura 2.4 --- ## Página 14 ## BORRADOR SII ## ENVÍOAUTOMÁTICO (WS) DE DTES ## ANEXO 2 1.- Formato Archivo para envío por Upload ( XML) ```xml ```xml ``` ………………………………………………………………………… ```xml ``` Figura 2.5 --- ## Página 15 ## 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 ```xml ^M ^M ```xml ^M ``` ……………………………………………………………………………. ```xml ^M ``` ^M -----------------------------7d23e2a11301c4--^M Figura 2.6 --- ## Página 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 Problema Solución boundary 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 Mensaje) Header. 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 Donde el circulo indica el inicio del mensaje. Host Uso del campo Host en Los programas en lenguaje C, los cuales además utilizan programas C y que además la librería OpenSSL, “NO deben incluir el Campo están utilizando la librería de Host”. OpenSSL Control M (^M) Falta el Control M -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”. ---