Contenido


UBL e Innovación Disruptiva

XML empresarial listo para usar para diversas industrias

Comments

Bases de UBL

Exploremos los orígenes y algunos de los dispositivos de UBL, incluyendo cómo UBL permite la personalización local dentro de una cadena de suministros. Después examinaremos cómo UBL está siendo utilizado en situaciones del mundo real.

Tim McGrath, uno de los creadores de UBL, dijo: "UBL no es un avance tecnológico; es un avance en la aplicación de una tecnología" (ver Recursos).

Bower y Christensen acuñaron la frase tecnología disruptiva para describir una tecnología que inesperadamente desplaza una tecnología establecida y sostenida. Las tecnologías sostenidas normalmente se basan en mejoras incrementales, mientras que una tecnología disruptiva puede venir de una fuente que no fue diseñada para como es finalmente es utilizada para desplazar otra tecnología.

Por lo tanto, si UBL no es una tecnología disruptiva, es ciertamente lo que Christensen después llamó una innovación disruptiva con el potencial de "permitir que una nueva población completa acceda a un producto o servicio que históricamente sólo era accesible a consumidores con mucho dinero o con mucha habilidad" (ver Recursos).

Contexto

UBL no es una nueva tecnología, y sus bases ciertamente no son nuevas. UBL se convirtió en un estándar de OASIS en 2004, con releases subsiguientes en los años posteriores. La Tabla 1 proporciona un cronograma de los releases de UBL.

Tabla 1. Releases de UBL
VersiónFechasNotas
0,7 (revisión pública)2003Utilizado en Dinamarca en el proyecto OIOXML
1.02004
2.02006Utilizado en Dinamarca en el proyecto OIOUBL
2 Errata 012008
2,1 (revisión pública)2010


UBL se ajusta a la recomendación del Lenguaje de Marcación Extensible (XML) (V1.0 - Recomendación del World Wide Web Consortium, 1998), que está basado en el Standard Generalized Markup Language (SGML) que se convirtió en un estándar de la International Organization for Standardization en 1986. SGML descendió del General Markup Language (GML) de IBM desarrollado en la década de los 60s por Charles Goldfarb, Edward Mosher y Raymond Lorie. Hay casi medio siglo de desarrollo técnico sólido en el dominio de los lenguajes de marcado general.

SGML se enfocó en resolver problemas de documentación a gran escala experimentados por el ejército, la industria aeroespacial y la industria automotriz y por grandes casas de publicidad. El Departamento de Defensa (DoD) de EE.UU., por ejemplo, recibió información técnica de miles de proveedores en una gran cantidad de formatos de propiedad. Esto creó un gran problema cuando intentaron integrar toda la información dentro de una infraestructura electrónica común. So solución fue exigir que todos los proveedores utilizaran SGML. Los proveedores tuvieron que proporcionar información técnica en SGML con base en una definición continua de adquisición y soporte del ciclo de vida (CALS) o, de lo contrario, el DoD no haría negocios con ellos. El resultado fue que el DoD recibió toda la información en un lenguaje de marcado común, lo que eliminó muchos problemas. Nos encontramos en una situación similar con el intercambio de documentos empresariales.

UBL es un lenguaje de marcado XML enfocado a los documentos empresariales que son intercambiados entre compañías en Internet. El esfuerzo de UBL está destinado a inyectar el e-commerce global al simplificar el intercambio intensivo de información empresarial en papel de la actualidad. UBL 2.0 define una biblioteca abierta sin derechos de autor de 31 documentos empresariales de XML estándar electrónico tales como órdenes de compra, facturas y docenas de otros documentos empresariales estándar que pueden ser utilizados globalmente. UBL 2.1 (en desarrollo) tiene más de 60 documentos. El objetivo del diseño de UBL es entrar directamente en las prácticas existentes empresariales, legales, de auditorías y de gestión de registros, para eliminar la re-manipulación de datos en cadenas de suministros existentes de fax y basadas en papel y proporcionar un punto de entrada para el comercio electrónico para pequeñas y medianas empresas.

Es importante entender que al implementar una solución de UBL, no necesita cambiar la forma en que hace negocios actualmente, ni cambiar las aplicaciones de software que está utilizando. UBL puede sustituir el intercambio de documentos empresariales en papel con documentos electrónicos confiables que puedan ser entendidos globalmente. En muchos casos, el usuario final puede no estar consciente del uso de UBL, ya que llevan a cabo sus tareas normalmente utilizando sus aplicaciones actuales. Las prácticas empresariales pulidas con el paso de muchos años son simplemente aplicadas al mundo electrónico.

Entidad de Información Empresarial

UBL está basado en estándares existentes. Por ejemplo, UBL utiliza los Componentes Centrales del United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) como se define en la Parte 8 de la Especificación Técnica de Componentes Centrales (ver Recursos). Esta especificación define una solución de Componente Central como "una metodología para desarrollar un conjunto común de bloques de construcción semánticos que representan los tipos generales de datos empresariales que se utilizan actualmente y aportan a la creación de nuevos vocabularios empresariales y reestructuración de vocabularios empresariales existentes".

Un componente central es un bloque de construcción semántico que puede ser utilizado para todos los aspectos del modelado e intercambio de datos e información. Los componentes centrales son el eje para crear modelos de procesos empresariales interoperables y documentos empresariales. Los componentes centrales son conceptuales por naturaleza y son utilizados para crear Entidades de Información Empresarial (BIEs) específicas de contexto.

UBL define un conjunto de definiciones empresariales que utilizan estos componentes centrales como base. La Figura 1 ilustra cómo UBL correlaciona estos componentes centrales.

La BIE es un concepto clave en el proceso de ensamble de UBL. Una BIE puede ser una BIE Básica (BBIE), una BIE Agregada (ABIE) o una BIE de Asociación (ASBIE).

Una BIE Básica es una entidad atómica, no compuesta por otras entidades. Una BIE Agregada puede estar compuesta de BIEs Básicas y otras BIEs Agregadas. La BIE de Asociación define una asociación entre una ABIE y otra ABIE. Un conjunto de documentos empresariales estándar, tales como las órdenes de compras y facturas, son entonces ensamblados desde la BIE. Ver la Figura 1 para más detalles.

Figura 1. Relación de la BIE con los Componentes Centrales
Relación de la BIE con los Componentes Centrales
Relación de la BIE con los Componentes Centrales

Como se mencionó anteriormente, la BIE es un concepto clave en el proceso de ensamble de UBL, así como lo es el componente central en el proceso de ensamble del componente central. La BIE toma 3 formas: una BIE Básica (BBIE), una BIE Agregada (ABIE) o una BIE de Asociación (ASBIE). Una BIE es una pieza de datos empresariales o un grupo de piezas de datos empresariales con una definición exclusiva de semántica empresarial. Hay una ABIE especial llamada la ABIE de Documento reservada para los distintos tipos de documentos tales como una orden de compra o una factura. Cada una de estas a su vez consistirá en un conjunto de ABIEs, ASBIEs y BBIEs.

La BBIE es una entidad atómica, no compuesta por otras entidades. Representa el bloque de construcción semántico y se correlaciona directamente con el Componente Central Básico. Un ejemplo de una BBIE puede ser AddressTypeCode— un código especificando el tipo de dirección, como una dirección de la empresa o dirección de casa. Una Address es una ABIE, un conjunto estructurado de información sobre una dirección. Una DeliveryAddress o AddressLine sería un ejemplo de una ASBIE. DeliveryAddress hereda las propiedades de la Address más general, mientras que AddressLine hereda las propiedades de la Line más general.

Entidad de Información Empresarial de Muestra

Para ver un fragmento de código de UBL-CommonAggregateComponents-2.0.xsd que ilustra cómo las diversas formas de BIEs están construidas y relacionadas, vea el Listado 1. Entidad de Información Empresarial de Muestra. Las piezas que se ocupan de la noción de una dirección han sido extraídas incluyendo definiciones de elemento para Address y AddressLine.

Los componentes centrales básicos comunes, en los cuales están basadas las BIEs, pertenecen al espacio de nombres de XML cbc. AddressLine (una ASBIE) también es parte de la definición de AddressType que tiene el atributo type="AddressLineType".

AddressLine, con un atributo type="AddressLineType", es una ABIE que consiste en uno o más elementos de Line (una BBIE que también pertenece al Espacio de Nombres de XML cbc). Line es definida como "una línea de dirección expresada como texto no estructurado".

Todo este código define una Address (una ABIE) que consiste en un número de elementos opcionales (BBIEs), incluyendo AddressLine (una ASBIE). AddressLine (ABIE) consiste en uno o más elementos de Line (BBIE).

Personalizaciones de UBL

Los diseñadores de UBL no trataron de forzar a todos los usuarios en una solución individual, gestionada centralmente, que abarque todo. Más bien, diseñaron UBL para ajustarse al 80-90 por ciento de los requisitos globales y reconocieron que existen requisitos locales que los usuarios tendrán que gestionar mediante la personalización.

Por ejemplo, podría utilizar sólo ciertos documentos de UBL dentro de una comunidad dada. Podría sólo necesitar ciertas porciones de esos documentos de UBL. Y podría agregar extensiones personalizadas a ellos para su comunidad. Podría incluso restringir los valores que los elementos de información individual puedan tomar.

Los diseñadores de UBL tomaron una decisión exclusiva para separar la validación estructural y léxica de la validación de valor. Esto es muy distinto de otros vocabularios empresariales basados en XML que combinan las dos validaciones en un esquema único.

En UBL, las restricciones estructurales y léxicas son definidas (y validadas) mediante el esquema; una segunda expresión abstracta de listas de códigos (utilizando Xpath, genericode y contexto para valorar la asociación) y otras restricciones de valor son utilizadas para la validación de valor. La Figura 2 ilustra esta separación. Este paso secundario de validación de valor permite que una comunidad de interés (digamos un proveedor y un conjunto de clientes) acuerden y especifiquen un conjunto de valores a ser utilizados sólo dentro de esa comunidad. Por ejemplo, un código de producto podría ser restringido al conjunto de productos ofrecidos por el proveedor.

Figura 2. Validación de UBL
Validación de UBL
Validación de UBL

En la Figura 2, puede ver cómo el esquema W3C XSD estándar es para validación estructural y léxica. Como en todo el XML, una instancia de entrada puede ser declarada válida si pertenece a la clase de documentos formalmente descritos por el esquema W3C.

La validación de valor involucra listas de códigos. Las listas de códigos, o vocabularios controlados, son específicamente utilizadas para restringir los valores permitidos para un elemento de información. Las listas de códigos pueden ser gestionadas globalmente (tales como los códigos de país de dos caracteres) o localmente (tales como una lista del proveedor de códigos de producto en su catálogo).

No entraremos en una larga descripción de listas de códigos aquí, pero las Preguntas Frecuentes de UBL 2.0 describen cómo son procesadas las listas de códigos.

“UBL 2.0 también presenta una respuesta al problema de la gestión de la lista de códigos. En lugar de obligar valores predeterminados de lista de códigos directamente en los esquemas de documento, lo que hace el ajuste de listas de código específico de socio comercial virtualmente imposible, UBL 2.0 expresa valores de lista de códigos en archivos separados utilizando el nuevo formato genericode. Los valores predeterminados son entonces utilizados para generar un script XSLT que valide los valores de código independientemente de los esquemas estándar. Este enfoque de dos fases no sólo resuelve la mayoría de los problemas de la gestión de la lista de códigos; también permite que subconjuntos distintos de listas de códigos sean asociados con contextos distintos en la misma instancia de documento, proporciona gran flexibilidad para especificar los valores de código aceptados en cada relación comercial y establece una plataforma para la implementación sofisticada de normas empresariales - todo sin modificar los esquemas UBL 2.0 estándar.

Para un enlace a las Preguntas Frecuentes de UBL 2.0, vea Recursos.

Guías para la Personalización de OASIS UBL 2, Primera Edición proporciona una descripción detallada de cómo manejar la personalización (ver en enlace en Recursos).

Problemas con el intercambio de documentos empresariales

Ahora examinemos el problema de intercambiar datos empresariales entre compañías en una cadena de suministros. Una compañía podría actuar como un cliente para un proveedor que entregará al cliente los bienes o servicios que requiera para llevar a cabo sus negocios. Cada cliente típicamente tiene N proveedores (ver la Figura 3).

Figura 3. Cadena de suministros
Cadena de suministros

La Tabla 2 muestra actividades típicas de este acuerdo empresarial.

Tabla 2. Actividades Típicas
Actividad
Descubrimiento¿Qué proveedores podrá utilizar?
Provisión¿El proveedor tiene los componentes que usted requiere?
PedidosPedir bienes o servicios de un proveedor.
CumplimientoEl proveedor envía todo o parte de su pedido.
Facturación de proveedorLe factura por el producto enviado.
PagoEl cliente paga al proveedor.


Si generamos una trama de compañías donde el eje vertical es el número de proveedores y el eje horizontal es un pedido de todos los clientes por número de proveedores, vemos una curva Pareto estándar. Alrededor del 20 por ciento de los clientes tiene un gran número de proveedores y normalmente tienen una gran escala de aplicaciones instaladas para manejar este largo número de proveedores. Estas podrían ser sistemas de intercambio electrónico de datos (EDI) que pueden entregar una transacción tal como una factura a otro usuario de EDI electrónicamente (ver la Figura 4).

Figura 4. Compañías ordenadas por número de proveedores.
Compañías ordenadas por número de proveedores.
Compañías ordenadas por número de proveedores.

El otro 80 por ciento de los clientes tienen menos proveedores y utilizan aplicaciones menos sofisticadas (o incluso herramientas de oficina como una hoja de cálculo o un procesador de texto) para generar transacciones empresariales como una factura. Muchos de estos clientes utilizan papel como el medio para transmitir la transacción empresarial al proveedor.

Figura 5. Intercambiando documentos en papel
Intercambiando documentos en papel
Intercambiando documentos en papel

El problema para el cliente con un gran número de proveedores es que tienen un sistema que requiere que los datos de facturación sean ingresados en su sistema electrónicamente. Cuando reciben facturas de proveedores como una página impresa mediante correo regular o quizás un PDF enviado por e-mail, gastan tiempo y recursos para reintroducir la información o realizan una exploración y OCR para obtener la información en forma electrónica. En Europa, un costo estimado para procesar una factura típica es entre 7 y 15 euros. Eliminar este costo podría generar ahorros enormes para una empresa grande.

Por ejemplo, considere el Gobierno de Dinamarca que debe procesar 1,4 millones de facturas por mes de 440.000 proveedores. Perseguir estos ahorros puede ser bastante costeable. KPMG, en su análisis formal de la situación danesa en 2003, encontró que sería posible eliminar al menos diez minutos de manejo de facturación por factura, resultando en ahorros de €94 millones. Eliminar los 17 minutos gastados en comparar la factura con la orden de compra produciría un ahorro de costo adicional de €160 millones.

El problema para el cliente con un pequeño número de proveedores es que muchos sistemas existentes con muy complejos y costosos para cumplir con sus necesidades.

Aplicaciones de UBL

En general, para que dos empresas intercambien efectivamente documentos empresariales, deben hablar el mismo idioma dentro de estos documentos y deben tener una forma de intercambiar estos documentos electrónicamente — sin cambiar sus procesos empresariales existentes. Y el proceso debe ser escalable al tamaño de las empresas involucradas, desde una empresa muy pequeña hasta un gobierno o una gran corporación.

UBL proporciona el lenguaje estándar para los intercambios de documentos empresariales con base en un conjunto común de estándares semánticos. Toda compañía puede intercambiar sus documentos empresariales con otras compañías y tener sus documentos entendidos.

Por ejemplo, OASIS (2006) proporciona un número de ejemplos de documentos de UBL. El Listado 2 es un extracto para un LineItem de un pedido de 100 kilos de cera de abejas.

Listado 2. Extracto para un LineItem para una orden de cera de abejas
<cac:LineItem> 
    <cbc:ID>1</cbc:ID> 
    <cbc:SalesOrderID>A</cbc:SalesOrderID> 
    <cbc:LineStatusCode>NoStatus</cbc:LineStatusCode> 
    <cbc:Quantity unitCode="KG">100</cbc:Quantity> 
    <cbc:LineExtensionAmount currencyID="GBP">
        100.00    
    </cbc:LineExtensionAmount> 
    <cbc:TotalTaxAmount currencyID="GBP">17.50</cbc:TotalTaxAmount> 
    <cac:Price> 
        <cbc:PriceAmount currencyID="GBP">100.00</cbc:PriceAmount> 
        <cbc:BaseQuantity unitCode="KG">1</cbc:BaseQuantity> 
    </cac:Price> 
    <cac:Item> 
        <cbc:Description>Acme beeswax</cbc:Description> 
        <cbc:Name>beeswax</cbc:Name> 
        <cac:BuyersItemIdentification> 
            <cbc:ID>6578489</cbc:ID> 
        </cac:BuyersItemIdentification> 
        <cac:SellersItemIdentification> 
            <cbc:ID>17589683</cbc:ID> 
        </cac:SellersItemIdentification> 
    </cac:Item> 
</cac:LineItem>

Tome en cuenta que es legible para los humanos. Es muy fácil darse cuenta de que este es un pedido de 100 kilos de cera de abejas, por un precio total de 100 libras esterlinas más 17,50 libras esterlinas de impuestos. Ya que es XML, puede ser procesado con componentes disponibles en el mercado.

Los dos espacios de nombres, cbc y cac, se refieren a componentes básicos y agregados respectivamente. Puede ver que <cbc:Name> es un componente básico, mientras que <cac:BuyersItemIdentification> es un componente agregado que consiste en un componente básico <cbc:ID>. También puede ver que <cbc:ID> es también utilizado en <cac:SellersItemIdentification> y es semánticamente lo mismo pero utilizado en contextos distintos.

La importancia de las listas de código controladas localmente externas al esquema puede ser ilustrada aquí. Si usted intentó incluir la lista de valores válidos para SellersItemIdentification en la definición de esquema, necesitaría un esquema separado para cada comunidad de usuarios, y tendría que mantener continuamente cada uno como la lista de valores válidos cambiados

En la Figura 6, puede ver lo fácil que es cambiar cómo las compañías intercambian datos empresariales electrónicamente simplemente al conectar una conversión de fondo de sus datos empresariales de intercambio impreso a electrónico, sin cambiar sus sistemas existentes.

Figura 6. Intercambiando documentos con UBL
Intercambiando documentos con UBL
Intercambiando documentos con UBL

UBL en Europa

Ahora echemos un vistazo a cómo diversos países han adoptado UBL para obtener una mejor idea del poder y los ahorros que pueden conseguirse al implementar diversas soluciones de UBL.

La experiencia danesa

Dinamarca fue uno de los primeros en adoptar UBL como una solución para el e-commerce. El gobierno de Dinamarca se dio cuenta de que podría obtener reducciones de costos significativas en su proceso de facturación si pudieran recibir todas las facturas en una forma estándar, y UBL proporcionó el estándar para esa implementación. Dado su poder como un gobierno, legisló el uso de UBL.

Más allá de simplemente legislar el uso de UBL, tuvieron que proporcionar la infraestructura para todas las empresas, grandes y pequeñas, para cumplir con la ley. Desarrollaron un portal de contratación pública, un mercado electrónico accesible a todos los compradores y proveedores públicos en Dinamarca, y agencias de escaneo para proporcionar la conversión de papel a UBL.

Aunque la factura fue el primer documento de UBL manejado por Dinamarca, esta es de hecho la última parte de la cadena de adquisición. Procesar electrónicamente los otros documentos en la cadena de adquisición de licitación mediante la facturación puede aumentar en gran medida la eficiencia y los ahorros de costos. El trabajo hacia este objetivo y la adopción de UBL 2.0 llevó a la adopción de un subconjunto danés de UBL 2.0 llamado OIOUBL.

La experiencia de la Unión Europea

Liderados por Dinamarca, representantes de Dinamarca, Suecia, Noruega, Finlandia, el Reino Unido e Islandia establecieron un grupo de trabajo para desarrollar un Subconjunto de Europa del Norte (NES) de documentos de UBL 2.0.

El propósito del subconjunto NES es facilitar la armonización de distintos tipos de documentos de e-procurement en países que ya están utilizando UBL o que están considerando utilizar documentos de UBL 2.0. Esto proporciona una oportunidad para basar documentos y procesos de e-procurement en un subconjunto coordinado de NES.

UBL será la base para el proyecto Pan European Public Procurement On-Line (PEPPOL) (ver Recursos). La amplia visión de PEPPOL es que cualquier compañía en la Unión Europea, incluyendo empresas pequeñas a medianas, pueda comunicarse electrónicamente con cualquier institución gubernamental de la Unión Europea para todos los procesos de adquisición.

UBL en América del Norte

Sorprendentemente, parece que hay muy poca adopción de UBL en América del Norte. Ni siquiera parece estar en la pantalla del radar de alguien. Una excepción a destacar es el trabajo que está llevando a cabo el Departamento de Transportes de EE.UU. Su proyecto piloto de Gestión Electrónica de Carga utiliza los siguientes documentos de UBL:

  • Estado del Transporte
  • Aviso de Entrega
  • Aviso de Recibo

Este proyecto piloto enlazó a dos fabricantes chinos de ropa, dos promotores de carga, un operador de terminal de carga aérea, dos compañías de fletes aéreos, un comprador de ropa de EE.UU., una compañía de logística de terceros de EE.UU. y un agente de importación en una demostración de comercio electrónico moderno en un escenario complejo del mundo real. La arquitectura creó efectivamente una base de datos federada sin un solo punto de falla y sin duplicación de datos como en las soluciones de bases de datos centralizadas tradicionales.

UBL como una innovación disruptiva

Si examinamos cómo UBL podría incursionar en América del Norte, vemos a partir de la experiencia europea distintos caminos en que esto podría conseguirse:

  • Legislar el uso de UBL. Los gobiernos pueden pasar leyes obligando el uso de UBL en todas las transacciones empresariales con el gobierno.
  • Decretar el uso de UBL. Organizaciones muy grandes (como el ejército) pueden rehusarse a hacer negocios con organizaciones que no usen UBL.
  • Evolucionar el uso de UBL. Los proveedores actuales ofrecen la salida de UBL como una opción en su oferta de software actual.

¿Cómo podría ocurrir la tercera vía?

Existen dos formas:

  1. Los proveedores de aplicaciones de e-commerce existentes pueden agregar la exportación e importación de UBL como dispositivos.
  2. Los proveedores pueden proporcionar nuevos servicios de UBL que puedan interactuar con las aplicaciones existentes.

La primera opción es un ejemplo de lo que Christensen llama innovación sostenida. Sin embargo, sólo aquellos que tienen o compran esa aplicación tienen acceso a esta habilidad.

Un ejemplo de la segunda es el enfoque distinto ofrecido por Tradeshift® (ver Recursos). Ellos proporcionan un Software como un Servicio (SaaS) basado en la computación en nube para el intercambio de documentos empresariales electrónicos de UBL, incluyendo facturación electrónica gratuita. Se concentran en este intercambio de documentos de UBL, no en las aplicaciones. En el extremo inferior proporcionan una interfaz basada en navegador para generar e intercambiar facturas. En el extremo superior proporcionan una API Abierta de forma que los proveedores de software existente puedan agregar el UBL de fondo con un costo más bajo (ver la Figura 6). Es interesante notar que agregaron funcionalidad de "redes sociales" para implementar una "hebra de discusión" para cada documento.

Un planeta más verde

Ya que finalmente nos alejamos de los sistemas basados en papel y nos acercamos al intercambio electrónico, podemos contribuir con un planeta más verde. Por ejemplo, hasta el diez por ciento de los árboles talados en este planeta son utilizados para crear el papel en el que son impresas las facturas. Eliminar la necesidad de este papel puede contribuir con la reducción de la deforestación, sólo una de las iniciativas que el estudio Smart2020 identifica sobre cómo las Tecnologías de la Información y de la Comunicación pueden contribuir con la economía baja en carbono en la Era de la Información.

Conclusión

Hemos demostrado que UBL es una tecnología basada en XML que tiene su base en más de 40 años de desarrollo sólido en el dominio de lenguajes de marcado general. UBL está diseñado para ajustarse a las prácticas existentes empresariales, legales, de auditoría y de gestión de registros, y mediante la reducción del uso de documentos de papel, puede contribuir con un planeta más verde.

Más que tratar de sustituir aplicaciones existentes en la industria de servicios financieros, UBL pretende ser utilizado para convertir los intercambios actuales de documentos empresariales entre organizaciones de basados en forma de papel a basados en forma electrónica en un estándar internacional.

UBL está diseñado para manejar 80-90 por ciento de los requisitos empresariales comunes con el porcentaje restante manejado por personalizaciones de UBL. Las personalizaciones incluyen utilizar subconjuntos de los documentos definidos por UBL. Puede utilizar sólo aquellas piezas opcionales de un documento individual de UBL que sean necesarias, puede extender un documento de UBL o puede incluso proponer un nuevo documento de UBL. Además, la validación de los contenidos de elementos de información puede ser gestionada localmente con listas de códigos basados en el cliente.

Utilizar UBL puede ser considerado una innovación disruptiva ya que finalmente permite a una toda una población nueva (hasta el 80 por ciento de las organizaciones actuales) acceder a intercambios electrónicos en lugar de documentos basados en papel para conducir la empresa.


Recursos para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Industries
ArticleID=645598
ArticleTitle=UBL e Innovación Disruptiva
publish-date=04072011