Saltar al contenido principal

Cap 7: Estructura XML del DE

  1. Características tecnológicas del formato En este capítulo se abordan las características tecnológicas de la facturación electrónica, que involucran la utilización de certificados digitales, el lenguaje utilizado para el intercambio de información, XML o lenguaje de marcado o extensible1 , juntamente con los Servicios Web, esenciales para el intercambio seguro de los DE. También se identifican los Servicios Web contemplados en el modelo conceptual de comunicación, se establecen las definiciones acerca de la utilización del XML, así como los estándares de comunicación entre el SIFEN y los sistemas de los contribuyentes. 7.1. Modelo conceptual de comunicación El SIFEN, disponibilizará los siguientes Servicios Web: • Recepción de DE • Recepción lotes de DE • Consulta resultado lote • Recepción evento • Consulta DE • Consulta RUC (por demanda) • Consulta DE a entidades u organismos externos autorizados (a futuro) Cada servicio se encuentra respaldado por un Servicio Web específico. El modelo de comunicación e interoperabilidad siempre iniciará en el sistema del contribuyente (sea de manera directa o prestado por un tercero), por medio del consumo del servicio correspondiente. Ver gráfica Nº 05 Gráfica Nº 05: Flujo de comunicación 1 https://es.wikipedia.org/wiki/Extensible_Markup_Language FLUJO DE COMUNICACIÓN Cliente Sistema de FE Sistema de FE Facturas Servicios Sincrónicos Facturas Electrónicas SIFEN Servicios Asincrónicos Transacciones https Flujo de la Comunicación Contribuyente SET septiembre de 2019 29 Existen dos tipos de procesamiento de Servicios Web: Síncronos: Se consideran a aquellos en los cuales el procesamiento y respuesta del servicio se realizan en la misma conexión de consumo. Ver gráfica Nº 06. Gráfica Nº 06: WS Sincrónico Asíncronos: Son aquellos en los cuales el resultado del procesamiento del servicio requerido no es entregado en la misma conexión de la solicitud de consumo (Ver gráfica Nº 07). Consta de un mensaje y un número de lote descriptos a continuación: • Un mensaje con un recibo (ticket) que confirma que el archivo remitido ha superado las primeras validaciones y se ha recepcionado el lote, y • El número de lote, incluido en esta respuesta, con el cual el cliente (sistema del contribuyente) podrá consultar el resultado del procesamiento, consumiendo el Web Service correspondiente, en otra conexión. Gráfica Nº 07: WS Asincrónico Web Service 1 a 1 Sistema de Información FE Contribuyente Sincrónico SIFEN Sistema de Recepción y Procesamiento 5 Recibe mensaje de solicitud Direcciona al sistema de recepción y procesamiento 2 Realiza procesamiento Devuelve msj resultado al WS 3 4 Recibe mensaje con resultado Direcciona al Sistema del Contribuyente 1 Establece conexión Envía mensaje de solicitud Recibe Respuesta Termina conexión septiembre de 2019 30 7.2. Estándar del formato XML El formato de documentos y protocolos de servicios, utilizan el lenguaje de marcas expansible (XML – Expansible Markup Language). La definición de cada archivo XML sigue un estándar denominado “Schema XML”, o lenguaje de esquema, utilizado para describir la estructura y restricciones de los documentos XML2 . Esta estructura reside en un archivo con extensión “.xsd” (XML Schema Definition), el que establece qué elementos contendrá el documento, como están organizados, cuáles son los atributos y de qué tipo deben ser estos elementos. 7.2.1. Estándar de codificación La especificación de los documentos XML es el estándar 150, con la codificación de caracteres UTF-8, por lo cual todos los documentos se inician con la declaración:
(*)

Para mejor comprensión, se puede utilizar el siguiente enlace: http://www.w3.org/TR/REC-xml Cada archivo XML, debe poseer solo una declaración (), para el caso de los envíos de lotes, la estructura completa del archivo debe contener solo una declaración. 7.2.2. Declaración namespace El comúnmente denominado “Espacio de Nombres”3 en XML, es utilizado para proporcionar elementos y atributos con nombre único en un documento XML. Este espacio de nombres se declara utilizando el atributo xmlns, el cual estará incluido en el elemento raíz del documento como, por ejemplo: <rDE xmlns=”http://ekuatia.set.gov.py/sifen/xsd” xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ekuatia.set.gov.py/sifen/xsd siRecepDE_v150.xsd"> Namespace utilizado en Eventos: 2 https://es.wikipedia.org/wiki/XML_Schema () 3 https://es.wikipedia.org/wiki/Espacio_de_nombres_XML www.w3.org/TR/REC-xml septiembre de 2019 31 Cabe aclarar que no se podrá utilizar: • Namespace distintos a los definidos en el presente documento • Prefijos de namespace Cada documento XML tendrá su namespace individual en su correspondiente elemento raíz. 7.2.2.1. Particularidad de la firma digital La declaración namespace de la firma digital debe realizarse en la etiqueta , conforme con el siguiente ejemplo: 150 7.2.2.2. Particularidad del envío de lote En el caso de envío de lote, cada DE debe contener la declaración de su namespace individual, conforme el ejemplo: septiembre de 2019 32 <rDE xmlns="http://ekuatia.set.gov.py/sifen/xsd" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://ekuatia.set.gov.py/sifen/xsd/siRecepDE_v150.xsd"> 150 ... ... <rDE xmlns="http://ekuatia.set.gov.py/sifen/xsd" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://ekuatia.set.gov.py/sifen/xsd/siRecepDE_v150.xsd"> 150 ... ... 7.2.3. Convenciones referenciadas en tablas La Gráfica Nº 08 muestra la relación entre los elementos del archivo XML Gráfica N° 08: Relación elementos XML La definición de las columnas de las tablas, conforme los esquemas relacionados a los archivos XML, se expone a continuación en la Tabla A: Tabla A – Convenciones Utilizadas en la Tablas de Definición de los Formatos XML Título Descripción Grupo Conjunto de campos ID Identificación del campo para fines de referencia Campo Nombre del campo. La primera letra indica: c: código integrante de una tabla existente en el Capítulo 16 septiembre de 2019 33 Tabla A – Convenciones Utilizadas en la Tablas de Definición de los Formatos XML Título Descripción i: código integrante de una tabla que se encuentra en la columna “Observaciones” d: nombre de un campo común g: nombre de un grupo r: raíz de XML Descripción Descripción del campo y su significado Nodo Padre Referencia al ID del campo de grupo que contiene este campo específico (campo padre) Tipo de Dato Tipo de dato (ver Tabla B) Longitud Tamaño del campo (ver Tabla C) Ocurrencia Ocurrencias, en el formato m-n, en el cual m: número mínimo de veces que el campo debe aparecer en el grupo n: número máximo de veces que el campo puede aparecer en el grupo Observaciones Observaciones importantes sobre el campo, incluyendo listas de valores posibles, validaciones relevantes entre otras. Versión Versión que el campo fue introducido en el formato, o versión en la cual ha sido modificado por la última vez Los tipos de campos de los archivos XML tienen su contenido descrito en la Tabla B. Tabla B – Tipos de Datos en los Archivos XML Tipo Descripción XML Documento XML, descripto en un schema contenido en esta ficha técnica G Grupo de elementos y/o grupos de elementos CG “Choice Group”, elemento que excluye la ocurrencia de otro Choice Group, con el mismo padre CE “Choice Element”, elemento que excluye la ocurrencia de otro Choice Element con el mismo padre • Por ejemplo los varios tipos de RUC El tipo de elemento aparece luego al lado • Por ejemplo, “CEA” indica un Choice Element alfanumérico A Alfanumérico N Numérico: Vea los diversos formatos en la Tabla C F Fecha: Los campos de fecha, según corresponda, deberán contener fecha y hora en el formato: AAAA-MM-DDThh:mm:ss o AAAA-MM-DD • Por ejemplo, para expresar 2:23 PM de 01 de febrero de 2018: 2018-02-01- 14:23:00 Por ejemplo, para expresar 01 de febrero de 2018: 2018-02-01 B Binario en Base64 para envío de lote septiembre de 2019 34 Los tamaños de campo utilizados en los archivos XML tienen su contenido descripto en la Tabla C. En el caso de campos con tamaño exacto los espacios no utilizados deben ser llenados con ceros no significativos (a la izquierda del campo). Tabla C: Tamaños de campos Título Descripción X Tamaño exacto del campo • ej.: 2 x-y Tamaño mínimo x, máximo y • ej.: 0-10 (es posible expresar ningún valor, porque se permite el tamaño 0) Xpn Tamaño exacto del campo x, con n cifras decimales exactamente • ej.: 22p4 xp(n-m) Tamaño exacto del campo x, con cifras decimales entre n y m • ej.: 22p(0-7) (x-y)p(n-m) Tamaño mínimo x, máximo y, con cifras decimales entre n y m • ej.: 1-11p(0-6) (es obligatorio expresar algún valor, porque no se permite el tamaño 0, pero la parte decimal es opcional) Valores separados por comas El campo deberá ser informado con tamaño exacto de una de las opciones listadas • ej.: 1, 3, 5, 8. Significa que se debe informar el campo con uno de estos cuatro tamaños fijos En la Tabla D se ejemplifica la manera de informar los formatos numéricos. Tabla D: Formatos numéricos Formato Para Informar Llenar campo con 0-11p0-6 1.105,13 1105.13 1.105,137 1105.137 1.105 1105 0 0 para no informar cantidad No incluir 0-11 1.105 1105 0 0 para no informar cantidad No incluir 1-11 1.105 1105 0 0 para no informar cantidad no es posible NOTA: De manera a simplificar y utilizar toda la potencia del lenguaje, el punto (.) se utilizará como separador de decimales, tal y como lo muestra la Tabla D 7.2.4. Recomendaciones mejores prácticas de generación del archivo Como buenas prácticas al momento de la generación de los DE, tener precaución de NO incorporar: • Espacios en blanco en el inicio o en el final de campos numéricos y alfanuméricos. • Comentarios, anotaciones y documentaciones, léase las etiquetas annotation y documentation. septiembre de 2019 35 • Caracteres de formato de archivo, como line-feed, carriage return, tab, espacios entre etiquetas. • Prefijos en el namespace de las etiquetas. • No incluir etiquetas de campos que no contengan valor, sean estas numéricas, que contienen ceros, vacíos o blancos para campos del tipo alfanumérico. Están excluidos de esta regla todos aquellos campos identificados como obligatorios en los distintos formatos de archivo XML, la obligatoriedad de los mismos será plenamente detallada. • No utilizar valores negativos • El nombre de los campos es sensible a minúsculas y mayúsculas, por lo que deben ser comunicados de la misma forma en la que se visualiza en el presente manual técnico. • Ej: el grupo gOpeDE, es diferente a GopeDE, a gopede y a cualquier otra combinación distinta a la inicial. 7.3. Contenedor de documento electrónico Un contenedor del DE es un archivo XML que contiene el DE, con su validación de recepción, por parte del SIFEN, así como cualquier evento, registrado que lo involucre. La estructura está definida en la sección 9.4, correspondiente al SW “SiConsDE”. 7.4. Estándar de comunicación La comunicación entre los contribuyentes y la SET está basada en los Servicios Web disponibles por el SIFEN. El medio para establecer esta comunicación es la Internet, apoyado en la utilización del protocolo de seguridad TLS versión 1.2, con autenticación mutua. Esto garantiza una comunicación segura, considerando la identificación del cliente consumidor del servicio por medio de certificados digitales. El modelo de comunicación sigue el estándar de Servicios Web definido por el WS-I 4 BasicProfile5 . El intercambio de documentos o mensajes entre el SIFEN y el sistema de los contribuyentes, utiliza el estándar SOAP, versión 1.26 , con intercambio de mensajes XML basados en Style/Encoding: Document/Literal. La llamada o Request a cualquiera de los Servicios Web del SIFEN, es realizada con el envío de un mensaje XML incluido en el campo soap:Body. Request de ejemplo utilizando SOAP: 4Web Services Interoperability Organization (WS-I, http://www.ws-i.org/about/Default.aspx) 5 http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html 6Web Services Interoperability Organization (WS-I, http://www.ws-i.org/about/Default.aspx) 6 http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html 6 https://www.w3.org/TR/soap12/ septiembre de 2019 36 <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> soap:Header/ soap:body 10000011111111 <rDE xmlns="http://ekuatia.set.gov.py/sifen/xsd" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://ekuatia.set.gov.py/sifen/xsd/siR ecepDE_v150.xsd"> ... </soap:body> </soap:Envelope> Response de ejemplo utilizando SOAP: <env:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> env:Header/ env:body <ns2:rRetEnviDe xmlns:ns2="http://ekuatia.set.gov.py/sifen/xsd"> ns2:rProtDe ns2:dId00000000000000000000000000000000000000000000</ns2:dId> ns2:dFecProc2019-06-03T12:00:00</ns2:dFecProc> ns2:dDigVal0000000000000000000000000000</ns2:dDigVal> ns2:gResProc ns2:dEstResRechazado</ns2:dEstRes> ns2:dProtAut0000000000</ns2:dProtAut> ns2:dCodRes0160</ns2:dCodRes> ns2:dMsgResXML malformado</ns2:dMsgRes> </ns2:gResProc> </ns2:rProtDe> </ns2:rRetEnviDe> </env:body> </soap:Envelope> 7.5. Estándar de certificado digital El SIFEN utiliza un certificado digital, emitido por cualquiera de los PSC7 , habilitados por el Ministerio de Industria y Comercio8 en su carácter de Administrador de la Autoridad Certificadora Raíz del Paraguay9 y ente regulador. El certificado será utilizado para firmar digitalmente y para autenticarse en los servicios del SIFEN. Puede ser del TIPO F110 o F211 de persona física o jurídica. En el caso de optar por el certificado de persona jurídica, el RUC del contribuyente estará contenido en el campo SerialNumber. En el caso de optar por el certificado de persona física, éste debe ser de un personal dependiente del contribuyente y el certificado debe 7 (PSC) Prestador de Servicios de Certificación https://www.acraiz.gov.py/html/Certif_1PrestaServ.html 8 www.acraiz.gov.py 9 (AA) Según la Ley N°4017 de Firma Digital es el Ministerio de Industria y Comercio 10 Tipo F1: corresponde a Certificado de Firma Digital por Software 11 Tipo F2: corresponde a Certificado de Firma Digital por Hardware septiembre de 2019 37 contar obligatoriamente con el nombre y el RUC de la entidad en el que presta servicio el titular del certificado. En este último caso el RUC del contribuyente estará contenido en el campo SubjectAlternativeName. Estos certificados digitales serán exigidos por la SET en los siguientes momentos: • Para firma de mensajes de datos: Se refiere al archivo de documento electrónico, registro de evento y/o cualquier otro archivo XML admisible por el SIFEN, que requiera ser firmado digitalmente. El certificado digital debe contener el RUC del contribuyente emisor y la clave prevista para la función de firma digital. • Para establecimiento de conexiones y autenticaciones mutuas: (Comunicación entre el servidor del contribuyente y el servidor del SIFEN). Para este efecto, el certificado digital debe contener el RUC del contribuyente emisor y propietario responsable por la trasmisión del mensaje, con la extensión Extended Key Usage con el permiso clientAuth. Aclaración: • Certificado de persona jurídica: el RUC del contribuyente debe estar informado en el: o Campo X509 V3: Subject o Nombre: “Serial Number” OID: 2.5.4.5 • Certificado de persona física: el RUC del contribuyente emisor debe estar informado en el: o Campo X509 V3: SubjectAlternativeName o Nombre: “SerialNumber” OID: 2.5.4.5 Para ambos casos, la información del RUC debe informarse de la siguiente manera: RUCXXXXXXXXX-X -> es decir, se escribe la palabra RUC con mayúsculas, seguido del número de RUC correspondiente con guion y el dígito verificador, sin ningún espacio en toda la cadena. 7.6. Estándar de firma digital Los archivos enviados al SIFEN son documentos electrónicos construidos en lenguaje XML y deben estar firmados con la firma digital amparada con el certificado correspondiente al RUC del contribuyente emisor del documento. Existen elementos que se encuentran presentes en el certificado digital del emisor de forma natural, lo que implica innecesaria su exposición en la estructura XML. En este contexto los DE firmados digitalmente no deben contener los siguientes elementos: De igual manera se debe evitar el uso de los siguientes elementos, ya que esta información será obtenida a partir del certificado digital del emisor. septiembre de 2019 38 Los DE utilizan el subconjunto del estándar de firma digital definido según W3C, http://www.w3.org/TR/xmldsig-core/, conforme a lo expuesto en el Schema XML1. Cada Documento Electrónico deberá ser firmado por el contribuyente emisor abarcando el grupo de información A001, con sus respectivos subgrupos, identificado por el Atributo “Id” cuyo valor será el CDC (Código de Control). Véase la Tabla de Formato de Campos de un Documento Electrónico (DE). El mismo literal único (CDC) precedido por el caracter “#” deberá ser informado en el atributo URI del tag Reference. Schema XML 1: xmldsig-core-schema- v150.xsd (Estándar de la Firma Digital) ID Campo Descrip ción Nodo Padre Ocurren cia Observaciones XS01 Signature - - Raíz XS02 SinnedInfo G XS01 1-1 Grupo de información de la firma XS03 CanonicalizationMetho d G XS02 1-1 Grupo del método canónico XS04 Algorithm A XS03 1-1 Atributo Algorithm de CanonicalizationMethod https://www.w3.org/TR/2001/REC-xml-c14n20010315 XS05 SignatureMethod G XS02 1-1 Grupo del método de firma XS06 Algorithm A XS05 1-1 Atributo Algorithm de SignatureMethod: Sha256RSA http://www.w3.org/2001/04/xmldsig-more#rsasha256 XS07 Reference G XS02 1-1 Grupo Reference XS08 URI A XS07 1-1 Atributo del Tag Reference que identifica los datos que se están firmandos XS10 Transforms G XS07 1-1 Grupo Algorithm Transforms XS12 Transforms G XS10 2-2 Grupo del Transform XS13 Algorithm A XS12 2-2 Atributos válidos Algorithm de Transform: https://www.w3.org/TR/xmldsig-core1/#secEnvelopedSignature http://www.w3.org/2001/10/xml-exc-c14n# XS14 XPath E XS12 0-n XPath XS15 DigestMethod G XS07 1-1 Grupo del método del DigestMethod XS16 Algortihm A XS15 1-1 Atributo del algoritmo utilizado para el DigestMethod: https://www.w3.org/TR/2002/REC-xmlenc-core20021210/Overview.html#sha256 XS17 DigestValue E XS07 1 Digest Value (HASH SHA256) XS18 SignatureValue G XS01 1-1 Grupo del Signature Value XS19 KeyInfo G XS01 1-1 Grupo del KeyInfo XS20 X509Data G XS19 1-1 Grupo X509 XS21 X509Certificate E XS20 1-1 Certificado Digital X509.v3 septiembre de 2019 39 Significado de la columna Descripción del Schema XML 1: • G: Grupo • A: Algoritmo • RC: Regla • E: Elemento Esta estructura se debe utilizar para todos los archivos firmados, utilizando el CDC, para el atributo Id <rDE xmlns=http://ekuatia.set.gov.py/sifen/xsd xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://ekuatia.set.gov.py/sifen/xsd/siRecepDE_v150.xsd"> 150 ... Nt2UmpjUHuu2DT6CJc2mtKhhqbq94LHSak1IsEOtuWk= DWN1my9sH4FI7ygPT3KF1ce... MIIIxzCCBq+gAwIBAgITXAA... En el proceso de verificación de los certificados, el SIFEN se encargará de consultar la lista de certificados revocados (LCR) al momento de la validación correspondiente, de manera que el contribuyente no necesitará anexar esta lista al firmar el documento. 7.7. Especificaciones técnicas del estándar de certificado y firma digital • Estándar de Firma: XML Digital Signature, se utiliza el formato Enveloped http://www.w3.org/TR/xmldsig-core/ • Certificado Digital: Expedido por una de los PSC habilitados en la República del Paraguay, estándar http://www.w3.org/2000/09/xmldsig#X509Data https://www.acraiz.gov.py/html/Certif_1PrestaServ.html septiembre de 2019 40 • Tamaño de la Clave Criptográfica: RSA 2048, para cifrado por software, para cifrado por hardware pueden ser de RSA 2048 o RSA 4096. • Función Criptográfica Asimétrica: RSA conforme a (https://www.w3.org/TR/2002/REC-xmlenc-core20021210/Overview.html#rsa-1_5 ). • Función de “message digest”: SHA-2 https://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#sha256 • Codificación: Base64 https://www.w3.org/TR/xmldsig-core1/#sec-Base-64 • Transformaciones exigidas: Útil para canonizar el XML enviado, con el propósito de realizar la validación correcta de la firma digital: Enveloped, https://www.w3.org/TR/xmldsig-core1/#sec-EnvelopedSignature C14N, http://www.w3.org/2001/10/xml-exc-c14n# 7.8. Procedimiento para la validación de la firma digital: a) Extraer la clave pública del certificado digital, b) Verificar el plazo de validez del certificado digital del emisor c) Validar la cadena de confianza, identificando al PSC, así como la lista de certificados revocados de la cadena d) Verificar que el certificado digital utilizado es del contribuyente y no de una autoridad certificadora e) Validar la integridad de las LCR utilizadas f) Verificar el Plazo de validez de cada LCR (Effective Date y NextUpdate) en relación al momento de la firma (campo fecha de la firma). 7.9. Síntesis de definiciones tecnológicas La Tabla E resume los principales estándares de tecnología utilizados. Tabla E: Estándares de tecnología utilizados Característica Descripción Web Services Estándar definido por WS-I Basic Profile 1.1 Medio lógico de comunicación Web Services disponibilizados por la SET Medio físico de comunicación Internet Protocolo de Internet TLS versión 1.2, con autenticación mutua utilizando los Certificados Digitales. Estándar de intercambio de datos SOAP versión 1.2 Estándar de Mensaje XML en el Estándar Style/Encoding: Document/Literal. Estándar de Certificado Digital ITU-T X.509 V.3 Information Technology Open Systems Interconnection. The Directory: Public-key and attribute certificate frameworks. Emitido por un PSC habilitado por el MIC. https://www.acraiz.gov.py/html/Certif_1PrestaServ.html Estándar de la Firma Digital XML Digital Signature, Enveloped, con Certificado Digital X.509 versión 3, con clave privada de 2048 y estándares de criptografía asimétrica RSA, RFC5639 y algoritmo SHA-256 Validación de la Firma Digital Se validarán la integridad y la autoría, además la cadena de confianza, por medio de las LCR en relación al momento de la firma (campo fecha de la firma). Estándares de utilización XML Definidos según las mejores prácticas a la hora de armar un archivo XML septiembre de 2019 41 7.10. Resumen de las Direcciones Electrónicas de los Servicios Web para Ambientes de Pruebas y Producción URL Ambiente https://sifen.set.gov.py/de/ws/sync/recibe.wsdl?wsdl Producción https://sifen.set.gov.py/de/ws/async/recibe-lote.wsdl?wsdl Producción https://sifen.set.gov.py/de/ws/eventos/evento.wsdl?wsdl Producción https://sifen.set.gov.py/de/ws/consultas/consulta-lote.wsdl?wsdl Producción https://sifen.set.gov.py/de/ws/consultas/consulta-ruc.wsdl?wsdl Producción https://sifen.set.gov.py/de/ws/consultas/consulta.wsdl?wsdl Producción https://sifen-test.set.gov.py/de/ws/sync/recibe.wsd?wsdl Test https://sifen-test.set.gov.py/de/ws/async/recibe-lote.wsdl?wsdl Test https://sifen-test.set.gov.py/de/ws/eventos/evento.wsdl?wsdl Test https://sifen-test.set.gov.py/de/ws/consultas/consulta.wsdl?wsdl Test https://sifen-test.set.gov.py/de/ws/consultas/consulta-lote.wsdl?wsdl Test https://sifen-test.set.gov.py/de/ws/consultas/consulta-ruc.wsdl?wsdl Test 7.11. Servidor para sincronización externa de horario Las direcciones para acceder a los servidores NTP para sincronización de horario son: • aravo1.set.gov.py • aravo2.set.gov.py El acceso a los servicios, citados en los puntos 7.10 y 7.11, dependerá de la política de seguridad establecida por la SET. Por lo que, podrá limitar y/o restringir la utilización de los servicios por contribuyente, por direcciones IP u otros, de tal forma a asegurar la disponibilidad de los recursos según cada etapa del plan general del SIFEN.