[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. |
26 Mayo 2004
cd-UBL-1.0
Este documento es un Borrador de Comité OASIS.
http://docs.oasis-open.org/ubl/cd-UBL-1.0/
http://docs.oasis-open.org/ubl/cd-UBL-1.0.zip
Bill Meadows, Sun Microsystems <bill.meadows@sun.com>
Lisa Seaburg, Aeon LLC <lseaburg@aeon-llc.com>
Oriol Bausà, Tradise <oriol@tradise.com>
Enric Staromiejski <enric@tradise.com>
El presente documento define la especificación UBL, Universal Business Language (Lenguaje Comercial Universal).
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:
2 Especificaciones y normativas utilizadas
5 Proceso de aprovisionamiento 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
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.
El desarrollo y mantenimiento de múltiples versiones de documentos comerciales habituales como pedidos y facturas supone realizar el mismo esfuerzo tantas veces como versiones distintas tengan que realizarse.
La creación y mantenimiento de diversos adaptadores que permitan el establecimiento de relaciones entre dominios comerciales diferentes también representa un esfuerzo considerable.
La existencia de numerosos formatos XML hace muy difícil la integración de mensajes comerciales XML con los sistemas de gestión ya existentes.
La necesidad de soportar un número arbitrario de formatos XML hace que las herramientas de transformación se vuelvan más caras y que el personal cualificado sea cada vez más difícil de encontrar.
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:
Una biblioteca de esquemas XML para componentes de datos reusables, como por ejemplo “Dirección”, “Producto” y “Pago”—elementos de datos que aparecen en los documentos comerciales del día a día.
Un pequeño conjunto de esquemas XML para documentos comerciales usuales, como por ejemplo “Pedido”, “Albarán” y “Factura” que se construyen a partir de los componentes de la librería de componentes UBL y que pueden utilizarse en un contexto comercial genérico pedido-a-factura.
Soporte para la personalización de UBL en relaciones comerciales específicas.
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:
Diagramas de clases UML de los componentes del documento en los que se basan los esquemas
Diagramas de clases UML que describen todos los documentos ensamblados.
Modelos de hojas de cálculo donde se definen los documentos ensamblados.
Descripción de dos implementaciones de ejemplo
Instancias de muestra de cada uno de los documentos UBL utilizados en esas dos implementaciones
Especificaciones de formato para la interpretación de todos los documentos en los casos de uso de ejemplo
Especificaciones de formato para la correspondencia entre las Claves de Presentación de las Naciones Unidas (United Nations Layout Keys) y cada tipo de documento comercial básico UBL.
Una especificación ASN.1 para permitir la transmisión binaria de mensajes UBL.
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].
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.
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.
Figura 1. Proceso comercial pedido-a-factura
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.
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:
Transporte
Medios
Modo
De una a muchas etapas del envío
Fechas
Ubicaciones
“Ventana” de llegada
Empaquetado de la mercancía
Tipo, e.g. contenedor, palet
Identificador, e.g. SSCC, etiqueta de envío (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.
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.
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:
Fecha de entrega, suministrada por el Vendedor de no haberla solicitado específicamente el Comprador.
Precios
Descuento comercial
Cargos
Códigos de clasificación arancelaria para las mercancías
Utilizando la Respuesta a un Pedido, el Vendedor puede notificar la necesidad de realizar reemplazos o sustituciones. El Elemento sustituto, o de remplazo, puede especificarse mediante uno de los Rangos de Identificadores de Elementos. Por ejemplo, la cantidad especificada puede variar, e.g. 20x6-packs como alternativa a 10x12-packs.
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.
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.
En el Albarán de Entrega puede aparecer la siguiente información:
Transporte
Medios
Modo
De una a muchas etapas de transporte
Fechas
Ubicaciones
“Ventana” de llegada
Empaquetado de envío
Tipo, e.g. contenedor, palet
Identificador, e.g. SSCC, etiqueta de envío (Albarán de Entrega)
El Albarán de Entrega contempla dos situaciones:
Organización del conjunto de elementos a entregar, en "Unidades de Tramitación de Transporte", de forma que el receptor puede controlar una unidad de tramitación y, en consecuencia, los elementos que contiene. Las cantidades del mismo elemento, presentes en la misma línea de Pedido, pueden separarse en distintas unidades de tramitación de transporte, pudiendo aparecer por lo tanto en líneas de albarán separadas, dentro de una misma unidad.
Organización del conjunto de elementos a entregar por línea de albarán, indicando la unidad de tramitación de transporte en la que están colocados para facilitar el control del Pedido. Por comodidad, cada línea de pedido separada en múltiples unidades de tramitación de transporte resultará en una línea de albarán para cada unidad de tramitación de transporte.
En el Albarán de Entrega también se puede indicar:
Entrega completa — indica al receptor y/o comprador que todos los elementos del pedido serán o están siendo entregados en una remesa completa y en una fecha determinada.
Entrega parcial — indica al receptor y/o comprador que todos los elementos del pedido serán o están siendo parcialmente entregados en una remesa y en una fecha determinada.
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.
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.
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:
Factura prepago (pago esperado)
Factura proforma (pre aviso, pago no esperado)
Factura normal, emitida por la entrega de mercancías
Factura después de la llegada de un Aviso de Recepción
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.
Las estructuras de los elementos se encuentran por todos los tipos de documento en el proceso genérico.
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:
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.
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”.
Este es un elemento para el que es preciso especificar una o más medidas como parte de su especificación descriptiva.
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.
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.
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.
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
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.
- 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.
- 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].
- 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.
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
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.
Figura 2. Dependencias de Esquemas UBL
Las versiones online y descargables de esta versión están disponibles en las ubicaciones especificadas al principio de este documento.
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
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:
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
Las suscripciones a la lista ubl-dev se pueden realizar a través del gestor de listas de OASIS en
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.
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.
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.
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 :
Facilita la identificación de componentes reutilizables— p.e. las estructuras de datos que son comunes en los documentos comerciales UBL 1.0
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.
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.
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.
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.
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 :
Los metadatos adicionales requeridos por [CCTS] se definen fácilmente
Se pueden aplicar fórmulas a las reglas de denominación
Las hojas de cálculo se pueden mapear directamente al formato requerido por el TBG17 de UN/EDIFACT para la candidatura de Componentes Centrales
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.
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 .
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 .
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
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:
Primero, cualquier modificación de los modelos de hojas de cálculo requiere una comprensión de su estructura, de la Especificación Técnica de los Componentes Centrales de ebXML [CCTS], y de diversos integrantes de la librería UBL. Por ejemplo, algunas columnas se modifican directamente, mientras que otras tienen fórmulas en sus celdas que implementan [CCTS] y Reglas de Denominación y Diseño UBL. Es necesario tener esto en consideración cuando se añadan o editen las filas de contenido. Se debería tener cuidado para evitar modificar celdas que contengan fórmulas
Segundo, la generación de esquemas debería ser compatible con las Reglas de Denominación y Diseño UBL (B.4 a continuación) para promover la compatibilidad con otras librerías de componentes UBL .
Tercero, los tipos de datos definidos en los modelos de los Tipos de Componentes Centrales y de los Tipos de Datos No Especializados son implementaciones directas definidas por [CCTS] y no deberían ser modificadas de forma inconsciente. El modelo de Tipos de Datos Especializados se ofrece para la implementación específica de tipos de datos.
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 :
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 :
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 :
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 :
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.
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 :
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.
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 .
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
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.
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
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
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 :
El paquete UBL 1.0 incluye un extenso conjunto de especificaciones de formato en documentos html localizados en
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 :
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 .
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.
El comprador cancela un pedido (para ilustrar el circuito, no es el mismo) .
- 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 vendedor avisa al comprador del despacho de los artículos solicitados.
- 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
- 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
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.
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 .
- 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 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.
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.
- 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
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
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:
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.
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 .
- Especificación ASN.1 UBL
- asn/ASN.1-UBL-1.0.html
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.
Los siguientes elementos están relacionados con las Reglas de Denominación y Diseño UBL (NDR).
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.
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.
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 .
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.
Los siguientes temas tienen relación con el almacenamiento y registro de esquemas UBL .
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 .
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 .
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 .
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.
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 .
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 :
Denominación de Componentes Suplementarios como atributos
Utilización del normalizedString XSD para los componentes código, identificador y texto
Utilización de tipos de datos incorporados XSD con formato de Componentes Suplementarios (Fecha Hora, Indicador y Numérico)
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.
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 .
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.
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 .
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]