OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-eslsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Spanish translation 1st Draft


 

Dear all,

 

Here it is the first draft of the Spanish translation files. We have the index.htm and the OpenOffice files. This August I will generate the excel files so we will have both formats.

 

Regards

 

Oriol Bausà

 

--Aviso--

Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial y/o datos de carácter personal, cuya difusión está regulada por la Ley Orgánica de Protección de Datos y la Ley de Servicios de la Sociedad de la Información. Si usted no es el destinatario indicado (o el responsable de la entrega al mismo), no debe copiar o entregar este mensaje a terceros bajo ningún concepto. Si ha recibido este mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su eliminación irreversible. Las opiniones, conclusiones y demás información incluida en este mensaje que no estén relacionadas con asuntos profesionales de Tradise no están respaldadas por la empresa.

--Notice--

This e-mail message is solely intended for its addressee and may contain confidential information. If you are not the addressee of this e-mail you should know that it is forbidden to read it, copy or use it. Please, notify us of receipt immediately via e-mail and delete it. Opinions, and other informations included in this message not related with Tradise professional activity will not be endorsed.

--Avís--

Aquest missatge electrònic es dirigeix només al seu destinatari. Pot contenir informació privilegiada o confidencial i/o dades de caràcter personal regulades per la Llei Orgànica de Protecció de Dades i la Llei de Serveis de la Societat de la Informació. Si Vostè no n'és el destinatari, ha de saber que la seva lectura, còpia i ús està prohibida. Li preguem que ens avisi immediatament per aquesta mateixa via i que procedeixi a la seva destrucció. Les opinions, conclusions i la resta d'informació inclosa en aquest missatge, que no estiguin relacionades amb assumptes professionals de Tradise, no estan recolzades per l'empresa.

 

Title: Universal Business Language 1.0

Universal Business Language 1.0

Fecha de publicación

26 Mayo 2004

Identificador del documento

cd-UBL-1.0

Estado de la presente edición

Este documento es un Borrador de Comité OASIS.

Ubicación

http://docs.oasis-open.org/ubl/cd-UBL-1.0/

Ubicación de los recursos relacionados con este documento

http://docs.oasis-open.org/ubl/cd-UBL-1.0.zip

Autores

Bill Meadows, Sun Microsystems <bill.meadows@sun.com>

Lisa Seaburg, Aeon LLC <lseaburg@aeon-llc.com>

Colaboradores

Miembros del Comité Técnico

Traductores

Oriol Bausà, Tradise <oriol@tradise.com>

Revisiones

Enric Staromiejski <enric@tradise.com>

Sumario

El presente documento define la especificación UBL, Universal Business Language (Lenguaje Comercial Universal).

Estado actual

El presente documento es un borrador elaborado por el Comité Técnico "Universal Business Language de Oasis" (UBL de Oasis). El Comité Técnico UBL de Oasis invita a las partes interesadas a participar en la revisión de este documento enviando comentarios a través de la siguiente página web:

http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ubl

Índice

1 Introducción

2 Especificaciones y normativas utilizadas

3 Glosario y definiciones

4 Símbolos y abreviaciones

5 Proceso de aprovisionamiento UBL 1.0

6 Esquemas UBL 1.0

Apéndice A (informativo): notas sobre la versión

Apéndice B (informativo): metodología UBL

Apéndice C (informativo): especificaciones para el formateo

Apéndice D (informativo): ejemplos

Apéndice E (informativo): listas de códigos

Apéndice F (informativo): especificación ASN.1

Apéndice H: notas y avisos

1 Introducción

Desde su aprobación en 1998 como recomendación de W3C, XML ha sido adoptado en diversos sectores como lenguaje para la definición de los mensajes intercambiables en comercio electrónico. Su uso generalizado ha conllevado el desarrollo sectorial de múltiples versiones XML de documentos tan básicos como pedidos de compra, albaranes de entrega y facturas.

Si bien la confección de un formato de documento ajustado a un sector específico tiene por ventaja la consecución de una optimización máxima en sus propios contextos de negocio, la existencia de distintos formatos para cumplir el mismo propósito en otros dominios comerciales diferentes conlleva un gran número de desventajas.

La especificación UBL de OASIS pretende ayudar a resolver estos problemas definiendo un formato de intercambio genérico XML para los documentos comerciales. Formato cuya ampliación debe ser posible para cumplir con los requisitos de sectores específicos. En concreto, UBL ofrece lo siguiente:

El hecho de disponer de una plataforma estándar para los esquemas comerciales XML debería tener las siguientes ventajas:

UBL se ha diseñado para ofrecer una sintaxis comercial inteligible, reconocida y aceptada universalmente. Sintaxis que vincula jurídicamente documentos comerciales y opera dentro de un marco estándar como la ISO 15000 (ebXML) para ofrecer una infraestructura completa, basada en estándares que extiende los beneficios de los sistemas EDI actuales a negocios de todos los tamaños. UBL es un lenguaje de libre distribución cuyo uso no conlleva ninguna obligación legal ni licencias o tarifas asociadas.

Los esquemas UBL son modulares, reutilizables y extensibles al estilo XML. Diseñado como una implementación de la Especificación Técnica de Componentes Centrales ebXML 2.01 (ebXML CCTS 2.01), la librería UBL se basa en un modelo conceptual de componentes de información conocidos como Entidades de Información Comercial (Business Information Entities – BIEs). Estos componentes se ensamblan en modelos de documento específicos como el Pedido o la Factura. A continuación, y siguiendo las Reglas de Denominación y Diseño de UBL (UBL Naming and Design Rules), estos modelos de documentos ensamblados se transforman para adecuarse a la sintaxis de los esquema XSD W3C. Dicho enfoque facilita la creación de modelos de documentos basados en UBL más allá de los especificados en esta versión 1.0. En el presente documento se describe el proceso comercial básico pedido-a-factura para los que se han diseñado los correspondientes tipos de documento UBL.

Para incentivar al máximo su difusión, los esquemas UBL estándar van acompañados de gran cantidad de material informativo adicional. Parte de este material se ha incluido en este paquete como apéndices informativos. El resto se halla disponible en los sitios web que se irán mencionado. Estos materiales incluyen:

2 Especificaciones y normativas utilizadas

[ASN.1] ITU-T X.680-X.683: Abstract Syntax Notation One (ASN.1); ITU-T X.690-X.693: ASN.1 encoding rules
http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-X.693-0207w.zip
http://www.oasis-open.org/committees/download.php/6320/X.680-X.693-0207w.zip
[CCTS] UN/CEFACT ebXML Core Components Technical Specification 2.01
http://www.untmg.org/downloads/General/approved/CEFACT-CCTS-Version-2pt01.zip
http://www.oasis-open.org/committees/download.php/6232/CEFACT-CCTS-Version-2pt01.zip
[ISO11179] ISO/IEC 11179-1:1999 Information technology — Specification and standardization of data elements — Part 1: Framework for the specification and standardization of data elements
http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c002349_ISO_IEC_11179-1_1999(E).zip
http://www.oasis-open.org/committees/download.php/6233/c002349_ISO_IEC_11179-1_1999%28E%29.pdf
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels
http://www.faqs.org/rfcs/rfc2119.html
http://www.oasis-open.org/committees/download.php/6244/rfc2119.txt.pdf
[UML] Unified Modeling Language Version 1.5 (formal/03-03-01)
http://www.omg.org/docs/formal/03-03-01.pdf
http://www.oasis-open.org/committees/download.php/6240/03-03-01.zip
[XML] Extensible Markup Language (XML) 1.0 (Second Edition),W3C Recommendation 6 October 2000
http://www.w3.org/TR/2000/REC-xml-20001006
http://www.oasis-open.org/committees/download.php/6241/REC-xml-20001006.pdf
[XSD1] XML Schema Part 1: Structures, W3C Recommendation 2 May 2001
http://www.w3.org/TR/xmlschema-1/
http://www.oasis-open.org/committees/download.php/6248/xsd1.html
[XSD2] XML Schema Part 2: Datatypes, W3C Recommendation 2 May 2001
http://www.w3.org/TR/xmlschema-2/
http://www.oasis-open.org/committees/download.php/6247/xsd2.html

3 Glosario y definiciones

Modelo de ensamblado
Modelo estructurado en árbol que puede ser implementado como un esquema de documento
Diagrama de clases
Notación gráfica utilizada por [UML] que describe la estructura estática de un sistema, incluyendo las clases objeto y sus atributos así como las asociaciones entre los objetos.
Modelo de Componentes
Representación de los componentes de datos normalizados que describen una red potencial de asociaciones y roles entre clases objeto.
Contexto
Circunstancias o eventos que conforman el entorno dentro del cual algo existe o tiene lugar.
Diagrama de dependencia
Refinamiento del diagrama de clases que enfatiza las asociaciones de dependiencia entre las diferentes clases objeto.
Documento
Conjunto de componentes de información que se intercambian como parte de una transacción comercial; por ejemplo, cuando se realiza un pedido.
Dependencia funcional
Modalidad de agregación de componentes basada en verificar si los valores de un conjunto de propiedades varia cuando otro conjunto de propiedades cambia, esto es, si el primero es dependiente del último.
Normalización
Técnica formal para la identificación y definición de las dependencias funcionales .
Modelo de hoja de cálculo
Representación de un modelo de ensamblado en formato tabular.
Esquema XSD
Definición de un documento XML conforme al lenguaje de Esquema W3C XML [XSD1][XSD2].

Los términos Componente Central (Core Component, CC), Componente Central Básico (Basic Core Component, BCC), Componente Central Agregado (Aggregate Core Component, ACC), Componente Central de Asociación (Association Core Component, ASCC), Entidad de Información Comercial (Business Information Entity, BIE), Entidad de Información Comercial Básica (Basic Business Information Entity, BBIE) y Entidad de Información Comercial Agregada (Aggregate Business Information Entity, ABIE) se utilizan en esta especificación de acuerdo con el significado dado en [CCTS].

Las expresiones Clase Objeto (Object Class), Término de Propiedad (Property Term), Término de Representación (Representation Term) y Calificador (Qualifier) se utilizan en esta especificación de acuerdo con el significado dado en la [ISO11179].

Las palabras clave DEBE, NO DEBE, REQUERIDO, DEBERÁ, NO DEBERÁ, DEBERÍA, NO DEBERÍA, RECOMENDADO, PUEDE y OPCIONAL, cuando aparecen en este documento, tienen que ser interpretadas tal y como se describe en el [RFC2119].

4 Símbolos y abreviaciones

ABIE
Entidad de Información Comercial Agregada
ACC
Componente Central Agregado
ASBIE
Entidad de Información Comercial de Asociación
ASCC
Componente Central de Asociación
BBIE
Entidad de Información Comercial Básica
BCC
Componente Central Básico
BIE
Entidad de Información Comercial
CC
Componente Central
EAN
Asociación Europea para la Numeración de Artículos
EDI
Intercambio Electrónico de Datos
ISO
Organización para la Estandarización Internacional
NDR
Reglas de Denominación y Diseño UBL (ver Apéndice B.4)
UML
Lenguage de Modelado Unificado [UML]
UN/CEFACT
Centro para la Facilitación del Comercio Electrónico de las Naciones Unidas.
XML
Lenguaje de Marcas Extensible [XML]
XSD
Lenguaje de Esquema W3C XML [XSD1] [XSD2]

5 Proceso de aprovisionamiento UBL 1.0

Los documentos y la biblioteca de componentes UBL 1.0 se han diseñado para soportar un ciclo de aprovisionamiento típico pedido-a-factura. Esta sección describe las reglas de negocio, la coreografía del proceso genérico y el rol que juega cada uno de los tipos de documento UBL 1.0 en este proceso.

Obsérvese que la biblioteca UBL se ha diseñadado para soportar la construcción de una amplia variedad de tipos de documentos que va más allá de los suministrados en la versión 1.0. A medida que UBL vaya evolucionando se irán incorporando nuevos tipos de documentos.

5.1 El Ciclo pedido-a-factura

Este modelo describe el ciclo comercial básico "pedido a factura" que incumbe a tres partes: un comprador de bienes; un vendedor de bienes; y un receptor de bienes, que puede ser el propio comprador o no. Los tipos de documento que UBL sumistra para dar soporte a este proceso son:

Pedido

Respuesta Sencilla a un Pedido

Respuesta a un Pedido (Detallada)

Modificación de un Pedido

Cancelación de un Pedido

Albarán de Entrega

Notificación de Recepción

Factura

Las cajas y textos que aparecen en negrita en el diagrama inferior muestran el rol que cada tipo de documento adopta en el proceso genérico.

[order-to-invoice diagram]

Figura 1. Proceso comercial pedido-a-factura

5.2 Reglas de negocio de los documentos

Esta sección describe las reglas de negocio de un proceso genérico pedido-a-factura que son asumidas como requisitos de información para los tipos de documento UBL 1.0.

5.2.1 Pedido

El Pedido puede especificar instrucciones de descuentos y cargos (e.g., transporte, documentación, etc.) que identifican el tipo de cargo y quien paga qué cargos. El Pedido se puede cargar “en cuenta”-contra una cuenta de crédito del Vendedor-, contra una tarjeta de crédito/débito o contra un acuerdo directo de débito. El Pedido permite establecer una moneda por defecto para todos los precios y también una moneda específica a utilizar cuando se emita la Factura. Dentro de un Pedido, se pueden especificar monedas adicionales para establecer precios de elementos individuales o para cualquier descuento o cargo.

El descuento comercial se puede especificar a nivel de Pedido. El Comprador puede no conocer el descuento comercial, en cuyo caso no se especifica. Esto hace que sea necesaria una respuesta detallada del vendedor; ver "Respuesta a un Pedido" (5.2.3).

El Pedido puede especificar condiciones de entrega y restricciones que se aplican por lugar de entrega en relación a la siguiente información que normalmente no debería aparecer hasta el Albarán de Entrega:

El Pedido tiene múltiples "Líneas de Pedido". Cada Línea de Pedido contiene la especificación de un único lugar de entrega, una previsión de cantidades y fechas de entrega solicitadas.

El Pedido puede especificar condiciones de entrega, mientras que la línea de pedido puede especificar intrucciones de entrega.

El Comprador puede indicar otras alternativas de uso habitual, generalmente aceptadas. Por cada Línea de Pedido, puede incluirse un "Elemento Alternativo". El Elemento Alternativo puede especificarse mediante cualquiera de los Rangos de Identificadores del Elemento. Por ejemplo, la cantidad especificada puede variar, e.g. 20x6-packs como alternativa a 10x12-packs.

5.2.2 Respuesta sencilla a un Pedido

La Respuesta Sencilla a un Pedido es el medio por el cual el Vendedor confirma la recepción del Pedido del comprador, indicando así el compromiso de llevar a cabo la transacción sin cargo o, por el contrario, el rechazo del Pedido.

5.2.3 Respuesta a un Pedido

Los cambios propuestos por el Vendedor se realizan a través del documento completo del tipo "Respuesta a un Pedido".

La Respuesta a un Pedido propone la sustitución del pedido original. Refleja el nuevo estado de una transacción de Pedido. También es el medio por el cual el Vendedor confirma u ofrece al Comprador detalles relativos al Pedido que no estaban disponibles o especificados por el Comprador en el momento de realizar el Pedido. Puede incluir:

5.2.4 Modificación de un Pedido

El Comprador puede modificar un Pedido de dos maneras. En primer lugar, cumpliendo el contrato legal o acuerdo comercial, enviando una Modificación de Pedido; o en segundo lugar, enviando una "Cancelación de un Pedido" (ver 5.2.5) seguido de un Pedido nuevo y completo que lo remplace.

La Modificación de un Pedido refleja todo el estado actual de una transacción de pedido.

Los compradores pueden solicitar la modificación de un pedido previamente aceptado por diversas razones, como por ejemplo para cambiar los elementos solicitados, la cantidad, la fecha de entrega, la dirección de entrega, etc. Los proveedores pueden aceptar o rechazar la Modificación de un Pedido ya sea utilizando la Respuesta a un Pedido, ya sea mediante la Respuesta Sencilla a un Pedido.

5.2.5 Cancelación de un Pedido

En cualquier punto del proceso, un comprador puede cancelar una transacción de Pedido utilizando el documento Cancelación de Pedido. Los contratos legales, acuerdos entre socios comerciales y las reglas de negocio definirán en qué momento será ignorada una Cancelación de Pedido (p.e. en el momento de iniciar el proceso de manufactura o de entrega). Según los acuerdos y reglas establecidos, una Cancelación de Pedido puede constituir una transacción comercial automática o no. Los términos y condiciones contractuales de las obligaciones comerciales dictarán qué restricción o guía debe aplicarse, si ello es pertinente.

5.2.6 Albarán de Entrega

En el Albarán de Entrega puede aparecer la siguiente información:

El Albarán de Entrega contempla dos situaciones:

En el Albarán de Entrega también se puede indicar:

Las líneas de albarán no tienen por qué corresponderse una a una con las líneas de pedido, y se enlazan por referencia. La estructura de la información de un Albarán de Entrega puede consistir en múltiples líneas de albarán originadas por una única línea de pedido. Del mismo modo, el envío parcial puede conllevar que algunas líneas de pedido no tengan correspondencia con ninguna línea del albarán.

Dentro de un Albarán de Entrega, un elemento también puede indicar el país de origen y la naturaleza peligrosa del artículo.

5.2.7 Aviso de Recepción

El Aviso de Recepción es enviado por el receptor (comprador) al vendedor para confirmar la recepción de mercancía y para informar de la ausencia o deterioro de algún producto.

El Aviso de Recepción se usa en dos casos. Para contrastar de forma sencilla las mercancías recibidas respecto de las solicitadas, éste debe organizarse del mismo modo que el Albarán de Entrega correspondiente:

El Aviso de Recepción permite al receptor notificar la ausencia de productos al comparar la cantidad especificada con la cantidad entregada. También le permite indicar los productos que va a rechazar y los motivos de su rechazo.

Actualmente, la línea de recibo sólo permite especificar el rechazo de un producto y el motivo por el que se rechaza. Sin embargo, se podrían establecer motivos adicionales para rechazar diversas cantidades del mismo elemento subdividiendo la línea de recibo de forma que haya múltiples líneas de recibo por cada línea de albarán.

5.2.8 Factura

La Factura normalmente se emite en base a un evento de entrega que genera una factura. También se puede emitir una Factura en base a un prepago completo o parcial. Las posibilidades son:

La Factura sólo contiene la información que se necesita con el objeto de facturar. No se reitera ninguna información ya establecida en el Pedido, Modificación de Pedido, Respuesta a Pedido, Albarán de Entrega, o Aviso de Recepción que no sea necesaria cuando se factura. Si es necesario, la Factura hace referencia al Pedido, al Albarán de Entrega o a la Aviso de Recepción a través de una Referencia a dichos documentos.

El sistema de impuestos en la Factura permite la composición de impuestos, la secuencia de cálculo viene dada por la secuencia de la información en el fichero de datos (p.e., impuesto de energía, con IVA – Impuesto de Valor Añadido – sobreimpuesto).

Los cargos se pueden especificar bien como una cantidad global o por porcentaje aplicado a todo el valor de la Factura antes de calcular los impuestos. Estos cargos incluyen:

Cada Línea de Factura se refiere a alguna Línea(s) de Pedido y también puede referirse a la Línea de Albarán y/o Línea de Recibo.

La Factura no contiene Notas de Débito y Crédito, el proceso tampoco incluye una Declaración de Cuenta de Cliente que resuma Facturas, Notas de Crédito y Notas de Débito a pagar.

5.3 Reglas de Negocio del Elemento

Las estructuras de los elementos se encuentran por todos los tipos de documento en el proceso genérico.

5.3.1 Identificación de Elemento

Un identificador identifica cada Elemento (p.e.un identificador de producto), que debe ser uno de los siguientes:

La Identificación de Elemento asume que cada empaquetado distinto de un Elemento (p.e. un 6-pack y un 12-pack del mismo elemento) tienen un Identificador de Elemento distinto.

El Elemento se puede definir más con la especificación de Medida(s) o Atributo(s) Físico(s). Esto permite la especificación de los siguientes tipos de elementos:

5.3.1.1 Elemento que Requiere Descripción

Este es un elemento que no está identificado por un código de producto procesable de forma no ambígua y requiere información descriptiva adicional para identificarlo de forma precisa.

5.3.1.2 Elemento Definido por el Cliente

Este es un elemento que el cliente describe de acuerdo a sus necesidades, y en su especificación, el cliente puede realizar algunas referencias a elementos comparables “estándar”.

5.3.1.3 Elemento que Requiere Medidas

Este es un elemento para el que es preciso especificar una o más medidas como parte de su especificación descriptiva.

5.3.2 Tarifas de Elementos

Para cualquier Elemento dado, los rangos de precio por total, cantidad, etc no se repiten al Vendedor; sólo se especifican los precios activos. El Comprador puede no conocer el Precio Base del Elemento, en cuyo caso no se especifica. Esto genera una respuesta detallada del Vendedor; ver Respuesta a Pedido.

5.3.3 Otros Detalles de Elemento

Aunque los elementos solicitados pueden incluir materias Peligrosas, no es necesario especificar esta información en la fase de pedido. El Comprador puede no ser consciente de la naturaleza del Elemento. En el Albarán de Enrega se debe indicar la naturaleza peligrosa de un Elemento y cualquier otra información relevante.

6 Esquemas UBL 1.0

Los esquemas UBL XSD son implementaciones de los modelos de documento definidos por UBL. Son la única representación normativa de los tipos de documentos y de las librerías UBL 1.0.

Todos los esquemas UBL 1.0 XSD se encuentran en el subdirectorio xsd/ del paquete UBL 1.0 (ver Apéndice A para mayor información acerca de la estructura del paquete 1.0 y la Sección 6.4 para información acerca de las dependencias entre módulos de esquema). El directorio xsd/ se subdivide en los subdirectorios xsd/maindoc/, xsd/common/, y xsd/codelist.

Para facilitar la implementación de los esquemas, se ofrece un directorio paralelo (y técnicamente no normativo) xsdrt/ con un conjunto “de ejecución” con los elementos de anotación eliminados.

6.1 Esquemas de Documento UBL

Los esquemas XSD que definen los ocho tipos de documentos básicos que soporta el proceso pedido-a-factura UBL 1.0 están ubicados en el directorio xsd/maindoc/, tal y como se detalla a continuación.

Pedido
xsd/maindoc/UBL-Order-1.0.xsd
Respuesta a Pedido
xsd/maindoc/UBL-OrderResponse-1.0.xsd
Respuesta a Pedido Sencilla
xsd/maindoc/UBL-OrderResponseSimple-1.0.xsd
Modificación de Pedido
xsd/maindoc/UBL-OrderChange-1.0.xsd
Cancelación de Pedido
xsd/maindoc/UBL-OrderCancellation-1.0.xsd
Albarán de Entrega
xsd/maindoc/UBL-DespatchAdvice-1.0.xsd
Aviso de Recepción
xsd/maindoc/UBL-ReceiptAdvice-1.0.xsd
Factura
xsd/maindoc/UBL-Invoice-1.0.xsd

6.2 Esquemas Comunes UBL

El directorio xsd/common contiene seis esquemas referenciados por los ocho esquemas de documentos de xsd/maindoc. Dos de estos esquemas comunes contienen la librería UBL de componentes de datos reusables desde los que se generan los esquemas de los documentos principales; tres contienen definiciones necesarias para implementar conforme a [CCTS] ; y uno ofrece un formato consistente para metadatos de esquema. A continuación se da el nombre de cada fichero de esquema junto con una breve descripción de su contenido.

 

6.2.1 Esquemas BIE Reusables

Componentes Básicos Comunes
xsd/common/UBL-CommonBasicComponents-1.0.xsd
Este esquema define las Entidades de Información Comercial Básicas (BBIE) que se utilizan en UBL, sirviendo, en efecto, como una “base de datos global de tipos BBIE” para construir documentos. Tal y como se especifica en las Reglas de Denominación y Diseño, este esquema no incluye los BBIEs que tengan tipos de datos Código o Identificador; éstos se definen localmente cuando son utilizados.
Componentes Agregados Comunes
xsd/common/UBL-CommonAggregateComponents-1.0.xsd
Este esquema define las Entidades de Información Comercial Agregada (ABIEs) utilizadas en UBL, sirviendo, en efecto, como una “base de datos de tipo ABIE” para construir los documentos principales.

6.2.2 Esquemas de Tipos de Datos Reusables

Tipos de Componentes Centrales
xsd/common/UBL-CoreComponentTypes-1.0.xsd
Este esquema facilita los Tipos de Componentes Centrales tal y como se definen en [CCTS]. Estos tipos se utilizan para construir tipos de datos de nivel superior de forma estandarizada y consistente. Este esquema no debería ser modificado.
Tipos de Datos No Especializados
xsd/common/UBL-UnspecializedDatatypes-1.0.xsd
Este esquema define los Tipos de Datos No Cualificados para formas de representación primarias y secundarias tal y como está especificado por [CCTS]. Basadas en los Tipos de Componentes Centrales, estas estructuras XSD de tipo complejo son los tipos de datos básicos desde los que tienen que proceder cualquier otro tipo de datos .
Tipos de Datos Especializados
xsd/common/UBL-SpecializedDatatypes-1.0.xsd
Este esquema facilita los Tipos de Datos Cualificados tal y como se define en [CCTS]. Estas estructuras XSD de tipo complejo se basan en los Tipos de Datos No Especializados por extensión, restricción, y otras limitaciones contextuales, como por ejemplo las facetas. Los Tipos de Datos Especializados se han personalizado para el proceso de aprovisionamiento de UBL 1.0 y se pueden ampliar más para soportar tipos de datos adicionales para otros contextos comerciales.

NOTA: Los términos “especializado” y “no especializado” se utilizan en lugar de los términos “cualificado” y “no cualificado” para evitar confusiones con las denominaciones "cualificado" y "no cualificado" de [XSD1][XSD2].

6.2.3 Esquema de Metadatos de Documentación

Parámetros de Componentes Centrales
xsd/common/UBL-CoreComponentParameters-1.0.xsd
Este esquema define la estructura de las secciones de anotación/documentación que aparecen en todos los demás esquemas, ofreciendo un formato consistente para los metadatos como por ejemplo clases de objetos, formas de representación, descripciones semánticas, y otra información adicional.

6.3 Esquemas de Listas de Códigos UBL

Los trece esquemas de listas de códigos que requiere UBL 1.0 se incluyen en el directorio xsd/codelist. Estos esquemas de listas de códigos permiten validar contra los valores de estas listas de códigos a todas las instancias de componentes de cualquiera de los esquemas de los documentos principales. Ver Apéndice E para más información acerca de la forma de representación utilizada por las listas de códigos UBL.

Código de Acuse de Recibo
xsd/codelist/UBL-CodeList-AcknowledgementResponseCode-1.0.xsd
Código de Motivo de Descuento o Cargo
xsd/codelist/UBL-CodeList-AllowanceChargeReasonCode-1.0.xsd
Código de Canal
xsd/codelist/UBL-CodeList-ChannelCode-1.0.xsd
Código Chip
xsd/codelist/UBL-CodeList-ChipCode-1.0.xsd
Código de Identificación de País
xsd/codelist/UBL-CodeList-CountryIdentificationCode-1.0.xsd
Código de Moneda
xsd/codelist/UBL-CodeList-CurrencyCode-1.0.xsd
Código de Estado de Documento
xsd/codelist/UBL-CodeList-DocumentStatusCode-1.0.xsd
Código de Latitud
xsd/codelist/UBL-CodeList-LatitudeDirectionCode-1.0.xsd
Código de Estado de Línea
xsd/codelist/UBL-CodeList-LineStatusCode-1.0.xsd
Código de Longitud
xsd/codelist/UBL-CodeList-LongitudeDirectionCode-1.0.xsd
Código de Operador
xsd/codelist/UBL-CodeList-OperatorCode-1.0.xsd
Código de Medios de Pago
xsd/codelist/UBL-CodeList-PaymentMeansCode-1.0.xsd
Código de Estado de Sustitución
xsd/codelist/UBL-CodeList-SubstitutionStatusCode-1.0.xsd

6.4 Dependencias de Esquemas

El siguiente diagrama muestra las dependencias entre los módulos de esquema comprendidos en un esquema de documentos UBL 1.0. Notar que (como en los demás diagramas UML utilizados en esta versión) los componentes dependientes apuntan a los componentes de los que dependen.

[schema dependency diagram]

Figura 2. Dependencias de Esquemas UBL

Apéndice A (Informativo): Notas de Versión

A.1 Disponibilidad

Las versiones online y descargables de esta versión están disponibles en las ubicaciones especificadas al principio de este documento.

A.2 Estructura de paquete

La especificación UBL 1.0 se ha publicado en un archivo zip denominado cd-UBL-1.0.zip. El desempaquetado de este archivo crea un directorio denominado cd-UBL-1.0 que contiene un documento maestro de hipertexto (este documento, index.html) y un número de subdirectorios. Los ficheros de estos subdirectorios, enlazados mediante index.html, contienen las distintas piezas de información normativa de la versión 1.0. A continuación se detalla una descripción de cada subdirectorio.

art/
Diagramas e ilustraciones utilizadas en esta especificación
asn/
Especificación ASN.1; ver Apéndice F
doc/
Documentos de soporte creados por el UBL TC y referenciados en esta especificación
fs/
Especificaciones de formato; ver Apéndice C
mod/
Modelos de hojas de cálculo UBL; ver Apéndice B.3
uml/
Diagramas UML; ver Apéndices B.2, B.3 y B.6
xml/
Instancias de ejemplo; ver Apéndice D
xsd/
Esquemas XSD; ver Sección 6
xsdrt/
Esquemas XSD “de ejecución”; ver Sección 6

A.3 Herramientas

UBL ha inspirado la creación de herramientas UBL libres y comerciales. Se puede encontrar una lista de herramientas para UBL disponibles actualmente en la página web del SubComité de Herramientas y Técnicas de UBL:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl-ttsc.

A.4 Soporte

UBL es un proyecto voluntario de la comunidad internacional. Las preguntas referentes a UBL se pueden dirigir a la lista pública ubl-dev, los mensajes de la lista se pueden encontrar en

http://lists.oasis-open.org/archives/ubl-dev/

Las suscripciones a la lista ubl-dev se pueden realizar a través del gestor de listas de OASIS en

http://lists.oasis-open.org/ob/adm.pl

A.5 Estructuras Recursivas

Algunos componentes de la librería permiten anidado recursivo. Por ejemplo, un Paquete puede contener otros Paquetes, una Entrega puede especificar otra Entrega, etc. Estas estructuras comerciales de datos son legítimas. La mayoría de las aplicaciones del mundo real limitarán la profundidad de recursión de estas estructuras, pero los esquemas XSD son incapaces de expresar esta limitación. Los implementadores tienen que ser conscientes de este punto y deberían establecer los límites de profundidad de las estructuras recursivas en sus aplicaciones.

Apéndice B (Informativo): Metodología UBL

B.1 Aproximación al Desarrollo con UBL

UBL no obliga a utilizar un método formal de desarrollo específico. El propósito de esta sección consiste en describir el proceso que ha evolucionado durante el desarrollo de UBL de modo que los implementadores puedan entender el rol de los diversos mecanismos técnicos incluídos en el paquete. Los implementadores también pueden escoger adaptar esta aproximación para cumplir con sus requisitos.

La aproximación utilizada para desarrollar UBL 1.0 se muestra en el diagrama siguiente.

[development process diagram]

Figura B-1. El Proceso de Desarrollo UBL

La librería UBL inicial de componentes de datos se basaba en la librería de esquemas xCBL 3.0, que a su vez se basaba en las librerías de componentes UN/EDIFACT y ANSI X12 EDI. Una vez revisada, se creyó necesaria la creación y abstracción del modelo conceptual de las entidades de la forma que mejor soportara un ciclo iterativo de desarrollo.

El UBL utiliza dos tipos de modelos conceptuales, un modelo sencillo para definir los componentes de información y un conjunto de modelos para describir como estos componentes se ensamblan en definiciones de documentos. El primero se referencia modelo de componentes de documento y generalmente se representa utilizando diagramas de clases UML (ver B.2 más adelante); los segundos se denominan modelos de ensamblaje de documentos y generalmente se representan utilizando hojas de cálculo.

La identificación y ensamblaje de los componentes requeridos por el Proceso de Aprovisionamiento UBL 1.0 se diseñó manualmente utilizando conocimiento comercial del dominio, el modelo de componentes, y los requisitos de [CCTS]. Las hojas de cálculo individuales se desarrollaron para cada tipo de documento en el escenario de aprovisionamiento de UBL 1.0, y todos los componentes reutilizables se combinaron en una hoja de cálculo separada. Se utilizaron hojas de cálculo adicionales para modelar los Tipos de Componentes Centrales (CCTs), Tipos de Datos No Especializados (UDTs), y Tipos de Datos Especializados (SDTs) tal y como están especificados en [CCTS]. El conjunto completo de los modelos de ensamblaje en hojas de cálculo utilizado por UBL 1.0 se describe en la Sección B.3.

Los esquemas UBL contenidos en la Sección 6 de esta especificación se han generado automáticamente desde los modelos de ensamblaje en hojas de cálculo siguiendo las Reglas de Denominación y Diseño de UBL referenciadas en la Sección B.4 y de acuerdo al proceso descrito en la Sección B.5. Los modelos de implementación se generaron desde los esquemas para servir de ayuda a la implementación de UBL. Estos diagramas de clases UML, detallados en la Sección B.6, representan la implementación de los modelos de ensamblaje de documentos descritos en las hojas de cálculo.

B.2 Modelo de Componentes

El modelo de componentes de documentos UBL describe los componentes de información utilizados en todos los documentos definidos por UBL 1.0.

El modelo de componentes de documentos es el resultado de un análisis detallado de los requisitos de datos para soportar el Proceso de Aprovisionamiento de UBL 1.0 (ver Sección 5). Durante el proceso de modelado, los elementos comunes de datos eran identificados por el proceso de normalización para identificar agregados basados en dependencias funcionales. Cuando era conveniente, éstos eran generalizados de forma que podían ser reutilizados para soportar varios documentos comerciales.

El modelo de componentes de documentos se utiliza con los siguientes objetivos :

El modelo de componentes se entiende mejor como una serie de Diagramas de Clases UML. Para facilitar la legibilidad, el modelo no contiene todos los metadatos requeridos para el ensamblado del documento.

La figura B-2 muestra el modelo de componentes de documentos UBL completo.

[ubl document component model]

Figura B-2. Modelo de Componentes de Documentos UBL (haga click en la imagen para ampliar)

Para facilitar la comprensión de este diagrama, se ha descompuesto en diversos paquetes. Cada paquete representa una agrupación lógica de componentes y es descrito por su propio diagrama de clases UML, que muestra los atributos (BIEs Básicos) y clases objeto (BIEs Agregados) pertenecientes a los componentes agrupados en el paquete. El alcance de cada paquete es arbitrario y no tiene ninguna significación más allá de estos diagramas.

Por ejemplo, a continuación se muestra el paquete de componentes reutilizables Party.

[party component diagram]

Figura B-. Paquete de Componentes Party

El conjunto completo de paquetes para todos los componentes UBL se lista a continuación.

Paquete Dirección
uml/concept/comp/UBL-1.0-AddressPackage.jpg
Paquete Contrato
uml/concept/comp/UBL-1.0-ContractPackage.jpg
Paquete Entrega
uml/concept/comp/UBL-1.0-DeliveryPackage.jpg
Paquete Referencia Documento
uml/concept/comp/UBL-1.0-DocumentReferencePackage.jpg
Paquete Mercancía Peligrosa
uml/concept/comp/UBL-1.0-HazardousItemPackage.jpg
Paquete Elemento
uml/concept/comp/UBL-1.0-ItemPackage.jpg
Paquete Parte
uml/concept/comp/UBL-1.0-PartyPackage.jpg
Paquete Pago
uml/concept/comp/UBL-1.0-PaymentPackage.jpg
Paquete Aprovisionamiento
uml/concept/comp/UBL-1.0-ProcurementPackage.jpg
Paquete Impuesto
uml/concept/comp/UBL-1.0-TaxPackage.jpg

En estos modelos no se definen direcciones específicas en las asociaciones; se puede navegar en cualquier dirección. El camino de navegación específico para cada asociación se define cuando se ensamblan los documentos.

B.3 Modelos de Ensamblaje de Documentos

Para definir distintos tipos de documentos, los componentes descritos en la sección anterior se ensamblan mediante unas estructuras jerárquicas basadas en los requisitos del contexto – en este caso el Proceso de Compra de UBL 1.0 – y los requisitos de metadatos de [CCTS].

El ensamblaje de documentos empieza con la definición de cada uno de los documentos comerciales en UBL 1.0 como un BIE Agregado (clase objeto) para el tipo de documento. Todos los demás BIEs Agregados (clases objeto) para el tipo de documento se derivan de las asociaciones de estos BIE Agregados hasta formar la jerarquía requerida. Los roles escogidos para cada asociación entre BIEs Agregados conforman una Asociación de BIEs.

Por ejemplo, el modelo de ensamblaje de documento para el nivel superior del documento Pedido UBL 1.0 se muestra a continuación utilizando un diagrama de clases UML.

[order assembly diagram]

Figura B-4. Modelo de Ensamblaje del Documento Pedido

El nivel superior de los modelos de ensamblaje de documento para los ocho documentos comerciales definidos por UBL 1.0 se muestra a continuación.

Modelo de ensamblaje de Pedido
uml/concept/assy/UBL-1.0-OrderDocumentAssembly.jpg
Modelo de ensamblaje de Respuesta a Pedido
uml/concept/assy/UBL-1.0-OrderResponseDocumentAssembly.jpg
Modelo de ensamblaje de Respuesta a Pedido Sencilla
uml/concept/assy/UBL-1.0-OrderResponseSimpleDocumentAssembly.jpg
Modelo de ensamblaje de Modificación de Pedido
uml/concept/assy/UBL-1.0-OrderChangeDocumentAssembly.jpg
Modelo de ensamblaje de Cancelación de Pedido
uml/concept/assy/UBL-1.0-OrderCancellationDocumentAssembly.jpg
Modelo de ensamblaje de Albarán de Entrega
uml/concept/assy/UBL-1.0-DespatchAdviceDocumentAssembly.jpg
Modelo de ensamblaje de Aviso de Entrega
uml/concept/assy/UBL-1.0-ReceiptAdviceDocumentAssembly.jpg
Modelo de ensamblaje de Factura
uml/concept/assy/UBL-1.0-InvoiceDocumentAssembly.jpg

Aunque es posible desarrollar modelos de ensamblaje de documentos utilizando UML, se pensó que era más sencillo en la práctica el uso de hojas de cálculo,siendo las ventajas principales :

Se creyó que estas ventajas pesaban más que las principales desventajas de la notación en hojas de cálculo, que es la falta de controles de integridad referencial en el mismo lenguaje de modelado; se requiere edición manual para controlar el impacto de los cambios. En este caso, afortunadamente, la herramienta comercial utilizada para generar los esquemas finales desde las hojas de cálculo también era capaz de verificar la integridad del modelo.

B.3.1 Modelos de Hojas de Cálculo

UBL utiliza las hojas de cálculo para describir el ensamblaje de componentes en tipos de documentos específicos. Hay una modelo de ensamblaje en hoja de cálculo para cada tipo de documento.

Siguiendo la terminología de [CCTS], los modelos de ensamblaje de documentos se componen de una combinación de Entidades de Información Comercial Básicas (los atributos del modelo de componentes BBIEs), Entidades de Información Comercial Agregadas (las clases objeto del modelo de componentes, ABIEs), y la Asociación de Entidades de Información Comercial (los roles de las asociaciones en el modelo de componentes). Los BBIEs se pueden considerar las “hojas” de la estructura de datos, los ABIEs son estructuras que contienen los BBIEs, y los ASBIEs son los contenedores de un ABIE dentro de otro.

Los modelos de hojas de cálculo utilizan filas para definir componentes. Los componentes son BIEs o Tipos de Datos. Las columnas definen los metadatos asociados con cada tipo de componente. Muchas de las columnas de las hojas de cálculo las determinan los requisitos de [CCTS].

Un modelo de ensamblaje de hoja de cálculo consistirá entonces en una ABIE “raíz”, un conjunto de BBIEs, y un conjunto de ASBIEs. Las ABIEs asociadas con la ABIE “raíz” se definen en un modelo de hoja de cálculo de BIE Reutilizable.

Los tipos de datos para todas las BBIEs se definen o bien en el modelo de hoja de cálculo de Tipos de Datos No Especializados, o bien en el modelo de hoja de cálculo de Tipos de Datos Especializados.

Las dependencias entre estos modelos de ensamblaje de hojas de cálculo se muestran en el diagrama siguiente .

[spreadsheet model dependency diagram]

Figura B-5. Dependencias entre Modelos de Hojas de Cálculo

Las hojas de cálculo incluídas en este paquete se ofrecen tanto en formato Microsoft Excel (.xls) como en formato Open Office (.sxc) tal y como se describe más adelante.

NOTA: Los esquemas de documentos UBL se generan de forma automática desde estos modelos de hojas de cálculo . Sin embargo, las formas normativas de los documentos UBL no son estos modelos de hojas de cálculo sinó los esquemas XSD en sí mismos, que se detallan en la Sección 6 .

B.3.2 Hojas de Cálculo de Documentos

Cada entidad de información comercial (BIE) está definida en una única fila. El color de fondo de la fila distingue entre BBIE (blanco), ABIE (rosa), y ASBIE (verde) .

Hoja de cálculo del documento Pedido
mod/maindoc/UBL-Order-1.0.sxc
mod/maindoc/UBL-Order-1.0.xls
Hoja de cálculo del documento Respuesta a Pedido
mod/maindoc/UBL-OrderResponse-1.0.sxc
mod/maindoc/UBL-OrderResponse-1.0.xls
Hoja de cálculo del documento Respuesta a Pedido Sencilla
mod/maindoc/UBL-OrderResponseSimple-1.0.sxc
mod/maindoc/UBL-OrderResponseSimple-1.0.xls
Hoja de cálculo del documento Modificación de Pedido
mod/maindoc/UBL-OrderChange-1.0.sxc
mod/maindoc/UBL-OrderChange-1.0.xls
Hoja de cálculo del documento Cancelación de Pedido
mod/maindoc/UBL-OrderCancellation-1.0.sxc
mod/maindoc/UBL-OrderCancellation-1.0.xls
Hoja de cálculo del documento Albarán de Entrega
mod/maindoc/UBL-DespatchAdvice-1.0.sxc
mod/maindoc/UBL-DespatchAdvice-1.0.xls
Hoja de cálculo del documento Aviso de Recepción
mod/maindoc/UBL-ReceiptAdvice-1.0.sxc
mod/maindoc/UBL-ReceiptAdvice-1.0.xls
Hoja de cálculo del documento Factura
mod/maindoc/UBL-Invoice-1.0.sxc
mod/maindoc/UBL-Invoice-1.0.xls

B.3.3 Hojas de Cálculo de Componentes Comunes

Hoja de cálculo de BIEs reutilizables
Este modelo proporciona las Entidades de Información Comercial Agregada (ABIEs) que se utilizan en UBL, sirviendo, en efecto, como una “base de datos de tipos ABIE” para la construcción de los documentos principales. Este modelo se puede modificar en el proceso de personalización .
Clave: Cada entidad de información comercial (BIE) se define en una única fila. El color de fondo de la fila distingue entre BBIE (blanco), ABIE (rosa) y ASBIE (verde).
mod/common/UBL-Reusable-1.0.sxc
mod/common/UBL-Reusable-1.0.xls
Hoja de cálculo de Tipos de Componentes Centrales
Este modelo proporciona los Tipos de Componentes Centrales tal y como están definidos por [CCTS]. Estos tipos se utilizan para construir tipos de datos de alto nivel de forma estandarizada y consistente. Este modelo no se debería modificar.
Clave: cada tipo de componente central (CCT) se define en una única fila. El color de fondo de la fila distingue entre Componentes Suplementarios (blanco) y los tipos de componentes centrales (rosa).
mod/common/UBL-CoreComponentTypes-1.0.sxc
mod/common/UBL-CoreComponentTypes-1.0.xls
Hoja de cálculo de Tipos de Datos No Especializados
Este modelo especifica los Tipos de Datos No Especializados tal y como están definidos por [CCTS]. Estos tipos se utilizan para construir tipos de datos de alto nivel de forma estandarizada y consistente. Este modelo no se debería modificar.
Clave: cada tipo de datos (DT) se define en una única fila. El color de fondo de las filas distingue entre Componentes Suplementarios (blanco) y tipos de datos (rosa).
mod/common/UBL-UnspecializedDatatypes-1.0.sxc
mod/common/UBL-UnspecializedDatatypes-1.0.xls
Hoja de cálculo de Tipos de Datos Especializados
Este modelo especifica los Tipos de Datos Especializados tal y como están definidos por [CCTS]. Estos tipos se utilizan para construir tipos de datos de alto nivel personalizados para implementaciones específicas. UBL ha decidido definir a los tipos de datos para las BBIEs que requieren validación contra la lista de códigos como Tipos de Datos Especializados. Son formas especializadas del tipo de datos Code con valores fijos. Notar que estas listas de códigos se implementan como esquemas individuales para cada una de las listas de códigos.Este modelo puede ser modificado cuando se personaliza.
Clave: cada tipo de datos (DT) se define en una única fila. El color de fondo de la fila distingue entre Componentes Suplementarios (blanco) y tipos de datos (rosa).
mod/common/UBL-SpecializedDatatypes-1.0.sxc
mod/common/UBL-SpecializedDatatypes-1.0.xls

B.3.4 Personalizando Modelos

Mientras que quien desee personalizar UBL debería seguir las guías para la personalización de los esquemas UBL 1.0 descrita en el apartado B.7 más abajo, quien desee modificar los modelos de Componentes o de Ensamblaje directamente y utilizar UBL como la base para un nuevo vocabulario debería ser consciente de las siguientes consideraciones que pueden causar incompatibilidades con UBL:

Los modelos de componentes de documento y de ensamblaje de documentos UBL 1.0 son el producto del SubComité de Librería de Contenido OASIS UBL (LCSC). El trabajo del UBL LCSC se puede ver en la página web de LCSC :

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-lcsc

B.4 Reglas de Denominación y Diseño UBL

La lista de control de las Reglas de Denominación y Diseño UBL XML (NDR) incluída en este paquete describe las reglas utilizadas para determinar las estructuras de los esquemas XSD UBL 1.0 y los nombres de elementos y atributos. La lista de control NDR se puede encontrar en este paquete en el siguiente fichero :

doc/ndr/UBL-NDR-Checklist-1.0.pdf

Las Reglas de Denominación y Diseño UBL son el producto del SubComité NDR UBL de OASIS. El trabajo del UBL NDRSC se puede ver en la página web de NDRSC :

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ndrsc

B.5 Generación de Esquema

Los esquemas XSD UBL 1.0 son el resultado de una transformación que aplica reglas de construcción de esquemas al Modelo de Datos representado por las hojas de cálculo UBL descritas en B.3. El proceso de transformación consiste en los siguientes pasos :

  1. Lectura en el modelo de datos de la hoja de cálculo
  2. Construcción desde cada hoja de cálculo de un modelo interno basado en UML
  3. Identificación de estándares externos para las listas de códigos y inclusión de los valores de las listas de códigos estándar en su caso
  4. Aplicación de las Reglas de Denominación y Diseño UBL
  5. Extracción de los esquemas XSD compatibles

Se ha utilizado una herramienta comercial compatible-CC de generación de esquemas, GEFEG EDIFIX ® 5.0 para leer las hojas de cálculo como modelos de datos UML, realizar el Control de Calidad sobre éstos, y producir una representación de esquema conforme a las Reglas de Denominación y Diseño UBL 1.0, tal y como se ilustra más abajo. Para mayor información al respecto de GEFEG EDIFIX ®, ver http://www.gefeg.com/en/standard/xml/ubl.htm. El Lector UBL GEFEG EDIFIX ® 5.0 es gratuito y ofrece una manera sencilla de visualizar esquemas y modelos de datos UBL. Para más información acerca del Lector UBL GEFEG EDIFIX ®, ver http://www.gefeg.com/en/edifix/reader-ubl.html.

[ubl schema generation]

Figura B-6. Proceso de Generación de Esquemas UBL

Los borradores anteriores de la especificación UBL utilizan distintas herramientas para ejecutar este proceso. Para ver una descripción del proceso utilizado para la producción de los esquemas Beta UBL 1.0, ver Apéndice D del Borrador del Comité Beta 1.0 en http://www.oasis-open.org/committees/ubl/lcsc/UBLv1-beta/.

La generación de esquemas UBL 1.0 se realizó bajo la dirección del SubComité de Herramientas y Técnicas UBL de OASIS (TTSC). El trabajo del TTSC UBL se puede ver en la página web de TTSC en :

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ttsc

B.6 Modelo de Implementación

El modelo de implementación de UBL representa los esquemas XSD UBL actuales como un modelo UML. Se producen transformando automáticamente los esquemas en un modelo conforme al Lenguaje de Modelado Unificado [UML]. Entonces se utiliza este modelo para producir un conjunto de diagramas de clases que ilustran cada uno de los documentos principales y diversas vistas de los componentes reutilizables. La transformación automatizada y la creación de diagramas se realizó utilizando una herramienta comercial de transformación de esquema-a-UML: Ontogenics hyperModel. Para más información acerca de este producto, ver http://www.xmlmodeling.com/.

Los diagramas de clases UML contenidas en esta sección pretenden ayudar a entender los esquemas UBL sin necesidad de entender la sintaxis de XSD. Para hacer esto, los diagramas eliminan intencionadamente parte del detalle contenido en los esquemas. Por ejemplo, la información acerca del orden de los elementos dentro de la definición de un tipo complejo no se preserva en los diagramas. Se han realizado otros cambios para hacer que el modelo UML sea usable para la ingeniería del software, por ejemplo, se eliminan los sufijos “Type” de los nombres de Tipos complejos cuando se crea el nombre de clase UML para producir un nombre de Clase Objeto independiente de la sintaxis XSD, y los elementos hijo de tipo complejo que contienen valores sencillos se representan como atributos de la clase, mientras que los elementos con contenido complejo se representan como asociaciones a estos tipos de clases.

Estos diagramas son el equivalente UML de los modelos de ensamblaje de documentos en hojas de cálculo.

B.6.1 Diagramas de Implementación de Documentos

Para cada uno de los ocho tipos de documento UBL 1.0 se ha creado un diagrama de implementación de clases. Como se ha indicado más arriba, los diagramas de implementación son vistas simplificadas que eliminan detalle de los tipos contenidos en estas estructuras agregadas. Como ejemplo, el diagrama de clases del documento UBL Pedido se muestra en la figura a continuación .

[order implementation model]

Figura B-7. Modelo de Implementación para el Documento Pedido

Los diagramas de clases de la implementación de documentos que contiene el paquete UBL 1.0 se listan a continuación.

Diagrama de implementación de Pedido
uml/implem/doctypes/UBL-OrderImplementationDiagram-1.0.gif
Diagrama de implementación Respuesta a Pedido
uml/implem/doctypes/UBL-OrderResponseImplementationDiagram-1.0.gif
Diagrama de implementación Respuesta a Pedido Sencilla
uml/implem/doctypes/UBL-OrderResponseSimpleImplementationDiagram-1.0.gif
Diagrama de implementación de Modificación de Pedido
uml/implem/doctypes/UBL-OrderChangeImplementationDiagram-1.0.gif
Diagrama de implementación de Cancelación de Pedido
uml/implem/doctypes/UBL-OrderCancellationImplementationDiagram-1.0.gif
Diagrama de implementación de Albarán de Entrega
uml/implem/doctypes/UBL-DespatchAdviceImplementationDiagram-1.0.gif
Diagrama de implementación de Aviso de Recepción
uml/implem/doctypes/UBL-ReceiptAdviceImplementationDiagram-1.0.gif
Diagrama de implementación de Factura
uml/implem/doctypes/UBL-InvoiceImplementationDiagram-1.0.gif

B.6.2 Diagramas de Implementación de Componentes Reusables

Además de los diagramas de los documentos principales, esta versión contiene diez diagramas de clases que representan vistas de los paquetes de componentes reusables utilizados en los documentos. Por ejemplo, el diagrama Pedido incluye asociaciones a Party, SellerParty, y BuyerParty. El siguiente diagrama de implementación muestra estos componentes en detalle.

[party implementation model]

Figura B-8. Modelo de Implementación para los Componentes Party

Los diagramas de implementación de componentes ofrecidos con UBL 1.0 son los siguientes:

Diagrama de implementación de Dirección
uml/implem/packages/UBL-AddressImplementationDiagram-1.0.gif
Diagrama de implementación de Contrato
uml/implem/packages/UBL-ContractImplementationDiagram-1.0.gif
Diagrama de implementación de Línea de Albarán
uml/implem/packages/UBL-DespatchLineImplementationDiagram-1.0.gif
Diagrama de implementación de Referencia de Documento
uml/implem/packages/UBL-DocumentReferenceImplementationDiagram-1.0.gif
Diagrama de implementación de Materia Peligrosa
uml/implem/packages/UBL-HazardousItemImplementationDiagram-1.0.gif
Diagrama de implementación de Elemento
uml/implem/packages/UBL-ItemImplementationDiagram-1.0.gif
Diagrama de implementación de Parte
uml/implem/packages/UBL-PartyImplementationDiagram-1.0.gif
Diagrama de implementación de Pago
uml/implem/packages/UBL-PaymentImplementationDiagram-1.0.gif
Diagrama de implementación de Aprovisionamiento
uml/implem/packages/UBL-ProcurementImplementationDiagram-1.0.gif
Diagrama de implementación de Envío
uml/implem/packages/UBL-ShipmentImplementationDiagram-1.0.gif
Diagrama de implementación de Impuestos
uml/implem/packages/UBL-TaxImplementationDiagram-1.0.gif

B.7 Guías de Personalización

Se pueden encontrar guías para realizar una personalización compatible de los esquemas UBL, junto con sugerencias de cómo proceder cuando no sea posible una personalización compatible en

doc/cm/wd-ubl-cmsc-cmguidelines-1.0.html

Las Guías de Personalización UBL son el resultado del trabajo del SubComité de Metodología de Contexto UBL de OASIS (CMSC). El trabajo del CMSC UBL se puede ver en la página web de CMSC :

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-cmsc

Apéndice C (Informativo): Especificaciones de Formato

El paquete UBL 1.0 incluye un extenso conjunto de especificaciones de formato en documentos html localizados en

fs/index.html

Esta parte del paquete también incluye PDFs de las instancias de ejemplo del Apéndice D .

Las Especificaciones de Formato UBL son el producto del SubComité de Formularios de Presentación UBL de OASIS (FPSC). El trabajo del FPSC UBL se puede ver en la página web de FPSC :

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-fpsc

Apéndice D (Informativo): Instancias Ejemplo

Este apéndice da instancias de ejemplo de documentos UBL utilizados en dos versiones distintas del proceso pedido-a-factura. El primer conjunto de ejemplos ilustra la compra de material de oficina, y el segundo conjunto ilustra la compra de carpintería (elementos para la construcción). También se incluyen versiones impresas de cada documento de ejemplo creados de acuerdo a las especificaciones de formato referenciadas en el Apéndice C .

D.1 Ejemplo Uno: Compra de Material de Oficina

El comprador, Bill Microdevices, pide distintos elementos a un atienda de suministro de material de oficina. El comprador conoce los códigos de artículo del proveedor y sus precios .

Ejemplo de instancia de Pedido a Proveedor de Material de Oficina
xml/office/UBL-Order-1.0-Office-Example.xml
Impresos
fs/Order/pdf/OfficeOrder.Example-a4.pdf
fs/Order/pdf/OfficeOrder.Example-us.pdf

El comprador decide cambiar el pedido original .

Ejemplo de instancia de Modificación de Pedido
xml/office/UBL-OrderChange-1.0-Office-Example.xml
Impresos
fs/OrderChange/pdf/OfficeOrderChange.Example-a4.pdf
fs/OrderChange/pdf/OfficeOrderChange.Example-us.pdf

El vendedor, Material de Oficina Joe, contesta con una Respuesta a Pedido Sencilla para indicar la aceptación del pedido. El vendedor también da su número de referencia de pedido, i.e., el pedido de venta en su sistema, y le dice al comprador quien es el contacto si tiene consultas.

Ejemplo de instancia de Respuesta a Pedido Sencilla
xml/office/UBL-OrderResponseSimple-1.0-Office-Example.xml
Impresos
fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-a4.pdf
fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-us.pdf
El comprador cancela un pedido (para ilustrar el circuito, no es el mismo) .
Ejemplo de instancia de Cancelación de Pedido
xml/office/UBL-OrderCancellation-1.0-Office-Example.xml
Impresos
fs/OrderCancellation/pdf/OfficeOrderCancellation.Example-a4.pdf
fs/OrderCancellation/pdf/OfficeOrderCancellation.Example-us.pdf
El vendedor avisa al comprador del despacho de los artículos solicitados.
Ejemplo de instancia de Albarán de Entrega
xml/office/UBL-DespatchAdvice-1.0-Office-Example.xml
Impresos
fs/DespatchAdvice/pdf/OfficeDespatchAdvice.Example-a4.pdf
fs/DespatchAdvice/pdf/OfficeDespatchAdvice.Example-us.pdf

El comprador notifica al vendedor los artículos perdidos .

Ejemplo de instancia de Aviso de Recepción
xml/office/UBL-ReceiptAdvice-1.0-Office-Example.xml
Impresos
fs/ReceiptAdvice/pdf/OfficeReceiptAdvice.Example-a4.pdf
fs/ReceiptAdvice/pdf/OfficeReceiptAdvice.Example-us.pdf

El vendedor emite una Factura automaticamente cuando ocurre el despacho, y la resolución de minoraciones etc se gestiona después de la facturación. La Factura muestra la cantidad de impuestos. El vendedor señala que el pago es a 30 días fecha Factura.

Ejemplo de instancia de Factura
xml/office/UBL-Invoice-1.0-Office-Example.xml
Impresos
fs/Invoice/pdf/OfficeInvoice.Example-a4.pdf
fs/Invoice/pdf/OfficeInvoice.Example-us.pdf

D.2 Ejemplo Dos: Compra de Carpintería (Material de construcción)

El comprador, Jerry Builders, PLC en el Reino Unido, pide un número de ventanas, un conjunto de puertas, y cierta cantidad de madera para entregar a un edificio en construcción. Jerry conoce los códigos del proveedor de los artículos, y también tiene que especificar los atributos físicos para obtener los elementos que desea: algunas ventanas son asimétricas y se “abren” por la izquierda o por la derecha; la mayoría de puertas tienen bisagras en un lado; se tiene que especificar la madera y su acabado, así como los “accesorios” (pomos, tiradores,etc.). Los elementos pueden contener distintos acabados de cristal. La madera suelta se codifica de acuerdo a su sección transversal, y se tiene que especificarla longitud. Aunque el comprador conoce estas cosas por el catálogo, no conoce los precios actuales o el tipo de descuento que puede obtener.

Ejemplo de instancia de Pedido de Carpintería
xml/joinery/UBL-Order-1.0-Joinery-Example.xml
Impresos
fs/Order/pdf/JoineryOrder.Example-a4.pdf
fs/Order/pdf/JoineryOrder.Example-us.pdf

El vendedor, Especialista en Ventanas, S.A., contesta con una Respuesta a Pedido detallada indicando el precio por unidad de cada artículo y el descuento comercial que se le realizará. Al mismo tiempo, el vendedor le da su número de referencia de pedido, i.e. la identidad del pedido en su sistema, y también le dice al comprador con quién debe contactar si tiene alguna pregunta.

Ejemplo de instancia de Respuesta a Pedido de Carpintería
xml/joinery/UBL-OrderResponse-1.0-Joinery-Example.xml
Impresos
fs/OrderResponse/pdf/JoineryOrderResponse.Example-a4.pdf
fs/OrderResponse/pdf/JoineryOrderResponse.Example-us.pdf

El vendedor avisa al comprador del despacho de los artículos solicitados, que se entregarán en dos palets (i.e. unidades de transporte) identificados como “A” y “B”. El Albarán de Entrega lista los artículos en la secuencia de líneas de pedido y hace referencia al palet en el que se entrega el artículo.

Ejemplo de instancia de Albarán de Entrega
xml/joinery/UBL-DespatchAdvice-1.0-Joinery-Example.xml
Impresos
fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-a4.pdf
fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-us.pdf
El Albarán de Entrega viaja con la entrega, se firma una copia en papel y se devuelve como prueba de recepción. Por lo tanto no se utiliza el Aviso de Entrega .

El Vendedor emite la Factura automáticamente cuando se despacha la mercancía, y la resolución de cualquier incidencia se gestiona después de la facturación. La Factura debe contener la fecha de impuesto, la categoria de IVA (Impuesto de Valor Añadido) al que pertenece cada artículo, y también el tipo de IVA y el total para cada categoría impositiva de la factura. También se aplica IVA a los cargos como los portes. Para potenciar el pago rápido de la cantidad debida, el Vendedor ofrece un descuento por pronto pago, que el comprador se puede deducir si paga en 30 días.

Ejemplo de instancia de Factura de Carpintería
xml/joinery/UBL-Invoice-1.0-Joinery-Example.xml
Impresos
fs/Invoice/pdf/JoineryInvoice.Example-a4.pdf
fs/Invoice/pdf/JoineryInvoice.Example-us.pdf
Este ejemplo se basa en los productos, identificación de productos, requisitos comerciales, y prácticas de un fabricante y de un vendedor de carpintería real del Reino Unido. Tiene su propia flota de transporte especializada, y entrega en todo el Reino Unido e islas cercanas.

Apéndice E (Informativo): Listas de Códigos

Los esquemas de listas de códigos incluídos en UBL 1.0 son conformes a la especificación UBL para la Representación de Listas de Códigos, que puede encontrarse en

doc/cl/wd-ublclsc-codelist-20040420.pdf

La especificación UBL para la Representación de Listas de Códigos es el resultado del SubComité de Listas de Códigos UBL de OASIS (CLSC). El trabajo desarrollado por el CLSC UBL se puede ver en la página web del CLSC:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-clsc

Apéndice F (Informativo): Especificación ASN.1

La especificación ASN.1 UBL referenciada a continuación ofrece una definición de esquema alternativa para documentos UBL de acuerdo con la ITU-T X.680-X.693 [ASN.1]. La especificación ASN.1 UBL define los mismos documentos UBL que los esquemas XSD UBL de la Sección 6 que constituyen las definiciones normativas de los documentos UBL válidos. El esquema XML ASN.1 UBL permite utilizar herramientas ASN.1 para pasar a UBL, y junto con las Reglas de Codificación Empaquetadas ASN.1, ofrece una especificación para la codificación binaria eficiente de mensajes UBL.

Especificación ASN.1 UBL
asn/ASN.1-UBL-1.0.html
La especificación ASN.1 UBL se creó utilizando una herramienta de OSS Nokalva (http://www.oss.com/) compatible con la Recomendación ITU-T X.694 | ISO/IEC 8825-5 para convertir Esquemas XSD a ASN.1. Después de la conversión, el ASN.1 generado se formateó con la herramienta PrettyPrint en ASN.1 Information Site (http://asn1.elibel.tm.fr) para producir los ficheros HTML incluídos en este paquete .

Apéndice G (Informativo): Trabajos en curso

UBL 1.0 alcanza el objetivo básico de la primera fase de los estatutos de UBL - desarrollar una librería estándar de documentos comerciales XML. La segunda fase (UBL 2.0) pretende producir añadidos a la librería y al conjunto de esquemas UBL y un mecanismo para la generación automática de esquemas comerciales de contextos específicos.

Entre estos hitos existen un número de tareas que por un motivo u otro no han pudieron ser finalizados a su debido tiempo para entregar en UBL 1.0. Algunos de estos elementos representan tareas de interés; otros representan casos donde un tema no llegó a una solución de consenso en el período establecido para la entrega de UBL 1.0 pero para los que se debió adoptar una estrategia aceptable para el corto plazo con poco o nulo impacto en la validez de las instancias de documentos UBL 1.0 en el largo plazo. El TC UBL pretende resolver estas cuestiones y publicar una versión modificada llamada UBL 1.1 que será compatible con las instancias UBL 1.0 .

Después, estas tareas han sido agrupadas bajo cuatro cabeceras: Tareas de NDR, Tareas de Interoperabilidad, Tareas de Registro y Tareas de Localización. El OASIS TC UBL invita a las personas interesadas a participar en este proyecto.

G.1 Tareas de NDR

Los siguientes elementos están relacionados con las Reglas de Denominación y Diseño UBL (NDR).

G.1.1 Publicación de la NDR UBL como una Especificación Separada

Las obligaciones temporales han impedido la finalización del documento Reglas de Denominación y Diseño UBL (NDR) como una especificación separada para entregar con UBL 1.0; el documento incluído en este paquete y referenciado como [NDR] sólo contiene una lista de reglas para la 1.0. Se continúa trabajando en la preparación del documento NDR para su presentación como una especificación técnica OASIS separada.

G.1.2 Grupos de Sustitución para la Personalización de las Listas de Códigos

El SubComité de Listas de Códigos de UBL ha producido una solución comprensible para las listas de códigos (ver Apéndice E) que depende de los grupos de sustitución en XSD para la personalización de las listas de códigos. Debido a una falta de consenso clara en el uso de los grupos de sustitución XSD en los esquemas de documentos comerciales, el TC UBL ha retrasado la adopción de este mecanismo de extensión de listas de códigos pendiente de nuevos debates. Se ha tenido cuidado al construir UBL 1.0 de forma que permita la adopción de los grupos de sustitución (si se considera apropiado) en versiones posteriores sin invalidar instancias de UBL 1.0.

G.1.3 Importación de Módulos de Esquemas de Listas de Códigos

Existe un debate acerca de si es mejor importar los módulos de esquema de las listas de códigos (Sección 6.3) indirectamente a través del esquema de Tipos de Datos Especializados (Sección 6.2.2) o directamente en el esquema de Componentes Agregados Comunes (Sección 6.2.1) y en cualquier esquema de documento individual donde se utilicen. En UBL 1.0, los módulos de esquemas de listas de códigos se importan directamente, pero existe preocupación debido a un posible impacto en el rendimiento. Las implementaciones de UBL 1.0 darán información acerca de como resolver este asunto. No se espera que un cambio de alternativa afecte a las instancias UBL 1.0 .

G.1.4 Ubicación de Definiciones de Propiedades de Elementos BBIE Cualificados

En UBL 1.0, todas las propiedades de los BBIE se declaran como elementos y se definen como tipos complejos en el esquema de Componentes Básicos Comunes (Sección 6.2.1). Alternativamente, se pueden declarar las propiedades de elementos BBIE cualificados en el esquema de Componentes Agregados Comunes o en los esquemas individuales de documentos donde se utilicen. Este asunto permanece abierto, pero cualquier cambio en futuras versiones no afectará a las instancias UBL 1.0.

G.2 Tareas de Registro

Los siguientes temas tienen relación con el almacenamiento y registro de esquemas UBL .

G.2.1 Paths Relativos en Módulos de Esquema

Para asegurar consistencia, claridad, y garantía absoluta que los esquemas normativos UBL están siendo utilizados, el UBL NDR identificó como requisito necesario para los esquemas basados en estándares el uso de nombres de path absolutos para las ubicaciones de esquemas. Sin embargo, las limitaciones en la arquitectura actual de OASIS impiden la disponibilidad de un registro/repositorio adecuado para soportar este requisito. Como resultado, UBL 1.0 se ha publicado utilizando nombres de path relativos para la ubicación de esquemas con el objetivo de facilitar la validación offline y para evitar estas limitaciones. La utilización de paths absolutos y un registro para la librería de componentes se implementará en versiones futuras en tanto en cuanto la infraestructura de soporte esté disponible .

G.2.2 Versión de Elemento en la Documentación de Cada BIE

UBL 1.0 asume que el número de versión de cada tipo de datos UBL y BIE también es 1.0. Sin embargo, existe cierto debate acerca de si esto es un mecanismo de construcción de esquema o un mecanismo de almacenamiento. La consecuencia de esta decisión puede resultar en un requerimiento para asignar un número de versión en la documentación de anotación para cada constructor de tipo de datos y de esquema de BIE .

G.3 Tareas de Interoperabilidad

Las siguientes tareas están relacionadas con la interoperabilidad de los documentos UBL entre industrias y en relación con otros documentos comerciales estándares .

G.3.1 Compatibilidad UBL

Aunque se ha realizado mucho trabajo para definir el concepto de compatibilidad UBL en las Guías de Personalización UBL 1.0 (ver Apéndice B.7), es necesario seguir trabajando para crear una definición de compatibilidad UBL que sea usable en contextos legales y regulatorios.

G.3.2 Perfiles sectoriales

Se considera probable que UBL 1.0 sea modificado de acuerdo a las Guías de Personalización UBL para crear versiones que sean estándar dentro de sectores en particular y de regiones geográficas. Se requiere más trabajo para desarrollar guías específicas a estos casos de uso .

G.3.3 Esquemas Comunes CCTS

Los esquemas para los Tipos de Componentes Centrales y Tipos de Datos incluídos en este paquete (Sección 6.2.2) se desarrollaron en cooperación con representantes de Open Applications Group, Inc., pero las versiones utilizadas actualmente por las dos organizaciones no son todavía idénticas. Las diferencias entre los esquemas CCTS utilizados en UBL 1.0 y OAGIS 9.0 se han identificado en estas cinco áreas :

Se espera disponer de un conjunto común de esquemas CCTS para UBL 1.1, momento en el que serán incluídos. No se espera que esto afecte a la validez de las instancias UBL 1.0.

G.3.4 Armonización de Componentes Centrales

Al ser una implementación de [CCTS], UBL soporta el concepto de una librería semántica común de componentes comerciales. Para conseguirlo, UBL está trabajando con el Grupo de Trabajo para la Armonización del UN/CEFACT International Trade and Business Procedures, conocido como el TBG17 (http://webster.disa.org/cefact-groups/tbg/wg/tbg17_main.cfm). Este grupo es responsable de la consistencia y armonización de los modelos de proceso comercial y componentes centrales a través de dominios comerciales y sectores, contribuyendo a un glosario conciso y bien definido de términos comerciales, definiciones semánticas de datos comerciales, y estructuración de intercambio de datos. La cooperación con el TBG17 es una tarea continua para UBL .

G.3.5 Metodología de Contexto

Aunque la entrega de una metodología de contexto automática pertenece a UBL 2.0, el trabajo en este punto continúa en el calendario de UBL 1.1. Esto incluye mayor refinamiento de las Guías de Personalización referenciadas en B.7 de esta especificación.

G.4 Tareas de Localización

UBL ha formado diversos subcomités de localización (L10N) para traducir la especificación UBL y documentación asociada en lenguajes distintos al Inglés y representar el esfuerzo UBL en contextos regionales de habla no inglesa. Estas iniciativas regionales desarrollaran mucha parte del trabajo a obtener en UBL 1.1. Hasta Abril del 2004 se han establecido subcomités de localización UBL para Chino, Japonés, Coreano, y Español .

Apéndice H: Avisos

Copyright © 2001-2004 OASIS Open, Inc. Todos los derechos reservados.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

mod.zip



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]