← Prev in month
← Prev in thread
Next in thread →
Next in month →
Spanish translation 1st Draft
MHonArc v2.5.0b2 --> ubl-eslsc message [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home] Subject: Spanish translation 1st Draft From: Oriol Baus� <> To: <>, "'Fabio Arciniegas'" <> Date: Thu, 5 Aug 2004 09:26:45 +0200 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 <> Lisa Seaburg, Aeon LLC <> Colaboradores Miembros del Comit� T�cnico Traductores Oriol Bausà, Tradise <> Revisiones Enric Staromiejski <> 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. 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: Reducción del coste de integración, tanto en relaciones entre empresas como intraempresariales, mediante la reutilización de estructuras de datos comunes. Disminución del coste de producción de las aplicaciones comerciales: las aplicaciones escritas para procesar un conjunto de etiquetas XML dado es mucho más sencillo de desarrollar que las aplicaciones que pueden manejar un número ilimitado de conjuntos de etiquetas. Una curva de aprendizaje más corta: los usuarios sólo deben estudiar y dominar el uso de una única librería . Menos barreras de entrada y una adopción más rápida por parte de las pequeñas y medianas empresas (PYMEs). Formación estandarizada: mucho personal cualificado en menos tiempo. Disponibilidad universal de un gran número de integradores de sistemas. Herramientas económicas y estandarizadas para la producción y consumo de datos. 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. 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. 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: 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. 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: 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. 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: 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. 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: Indicando la recepción por unidad de tramitación de transporte y por línea de recibo, contrastadas una a una con el Albarán de Entrega tal y como detalló la parte vendedora. Indicacando la recepción por línea de recibo y especificando la unidad de tramitación de transporte, contrastándolas una a una con el Albarán de Entrega, tal y como detalló la parte vendedora . 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: 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: Empaquetado Entrega/portes Fletes Documentación 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: Identificador de Elemento del Comprador, o Identificador de Elemento del Vendedor, o Identificador de Elemento del Fabricante, o Identificador de Elemento de Catálogo, o Identificador de Elemento de acuerdo a un sistema promulgado por un organismo de estándares. 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. 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. 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 : Facilita la identificación de componentes reutilizables— p.e. las estructuras de datos que son comunes en los documentos comerciales UBL 1.0 Ayuda a entender los requisitos de información de todo el escenario Es la fuente desde la que se derivan y documentan los BIEs en los modelos de ensamblaje de documentos UBL 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. 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. 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. 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 Los expertos de negocio responsables del modelado de datos están familiarizados con las hojas de cálculo El formato se ha demostrado portable entre aplicaciones 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 . 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: 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 : 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 : Lectura en el modelo de datos de la hoja de cálculo Construcción desde cada hoja de cálculo de un modelo interno basado en UML 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 Aplicación de las Reglas de Denominación y Diseño UBL 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. 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 . 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. 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 : 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) Restricciones en Objetos Binarios para tipos de datos Gráficos, Imágenes, Sonido y Video Patrones para tipo de datos Indicador 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]
← Prev in month
← Prev in thread
Next in thread →
Next in month →