Transacciones electrónicas Business to Business (B2B)

5 respuestas

Para ver como pasa el tiempo, incluyo a continuación un artículo de Miguel Angel Abellán obtenido de su lista de correo electrónico «Noticiero de Nuevas Tecnologías«. Se titula «SEMINARIO EDI/XML’2000 (EDI vs XML). Lo que allí se dijo…»

Para contextualizarlo, conviene recordar que han pasado algo más de 7 años desde que se escribió. Muchos de los temas que se predecían en el 2000, se han cumplido en el 2007. Y otros no. Algunas iniciativas prometedoras no han superado el paso del tiempo.

SEMINARIO EDI/XML’2000 (EDI vs XML)

Miguel Angel Abellán

A continuación resumo algunos de los temas e ideas planteados en el Seminario “Transacciones electrónicas Business to Business (B2B)” que organizó el Institute for International Research (IIR), y se realizó los días 4, 5 y 6 de Abril de 2000 en Madrid.

Quien les iba a decir a las grandes empresas de siempre que sus sistemas EDI se quedarían obsoletos de la noche a la mañana. Durante varios años (casi dos decenas) han estado invirtiendo cantidades ingentes de dinero en estos sistemas de comunicaciones con sus clientes y proveedores sin darse cuenta de que en Internet existen muchísimos más potenciales clientes y proveedores que no están participando en ese canal de comunicación. ¿Y ahora qué? ¿Tiran abajo su EDI y crean un modelo basado en Internet?, o evolucionan paso a paso hacia Internet…

El tema es que la aparición del XML puede producir grandes cambios en la forma de hacer negocios en la vida real y en la red. El entorno EDI necesitaba grandes inversiones y personal dedicado, mientras que XML acabará siendo un estándar por su gran implantación en los entornos ofimáticos, y de software de bases de datos dirigidas a equipos medios (Oracle, SQL Server, …). Por otra parte XML es un lenguaje que puede ser entendido por las personas, al contrario de EDI que estaba orientado a las máquinas.

Todo esto y muchas diferencias más son las que expusieron los ponentes de este seminario. A continuación resumo sus experiencias y opiniones.

El Puerto de Barcelona presentó su proyecto PortIC, como ejemplo de lo que debe hacer, que es migrar de EDI a Web+EDI, fomentando la sinergia EDI-Internet para agilizar las relaciones con los clientes, proveedores, socios, y distribuidores. El sistema PortIC pretende solucionar los problemas típicos de un Puerto Marítimo: que la salida de la mercancía se realice cuanto antes para poder liberar espacio que será ocupado por otra mercancía, minimizando los errores en el proceso.

Los trámites documentales dentro de un puerto marítimo pueden obligar a la rellenar unos 40 documentos entre el agente de la aduana, la autoridad portuaria, el transitario, el consignatario, el armador, la capitanía marítima, etc. desde la entrada de la mercancía, pasando por la admisión del DUA, la emisión del levante, la entrega del manifiesto, etc. Casi todos estos trámites deben reproducirse en el puerto de destino, y no podemos olvidar que el Puerto de Barcelona también funciona como destino para las importaciones.

La situación de partida antes de implantar PortIC, era la siguiente. Se tardaba una media de 6 días en despachar una mercancía; existían 300 empresas en el puerto que no tenían EDI y casi todas las comunicaciones las hacían con papel; y los medios telemáticos utilizados eran muy variados: Fax, EDI, AudioText, etc; los pagos por los servicios no se hacían electrónicamente,…

Para solucionar este problema crearon la sociedad PortIC (37% APB, 14% consignatarios, 14% transitarios. 14% terminales, 14% agentes de aduanas y 7% Cámaras de Comercio, a los que se sumarán en el futuro empresas de trasporte). Desde que comenzaron a desarrollar el sistema PortIC en 1.997, han conseguido los siguientes objetivos:

  • Todos los agentes del puerto utilizan esta plataforma lo que agiliza el procedimiento
  • El sistema está basado en EDI lo que normaliza la información y el procedimiento
  • Los pagos de servicios se realizan vía telemática lo que evita retrasos en las entregas
  • Agiliza los intercambios de transporte.

El Puerto de Barcelona participa en la Asociación e-commerce, de la que son miembros el Banco Sabadell, las Cámaras de Comercio, y La Caixa. Los objetivos de esta asociación son los de tener presencia en los foros internacionales donde se trata el tema del comercio electrónico, participando activamente en las iniciativas que surjan. Actualmente participan en: UN/CEFACT, BOLERO, CCI, Trade Card, ebXML, …

La plataforma que utilizan es: certificados de ChamberSign, red IP, ordenadores SUN, servidores NetScape con SSL, Firewall CheckPoint 1 de OpenVision. Los clientes deben tener líneas de 64Kbps, un sotware desarrollado por ellos y un navegador. Se financió con dinero de la APB, y cobra comisiones a los clientes por los conceptos: alta en el sistema, cuota mensual, y volumen en Kb transmitidos. El uso del sistema divide por 10 el coste documental del proceso.

Lo que les gustaría es que en los puertos destino (extranjeros) de las mercancías existiese otro PortIC. Tienen contactos con otros puertos en el mundo para desarrollar esta idea. Con los puertos españoles han llego a acuerdos para la definición de los mensajes EDI, pero no les interesa compartir el sistema. El siguiente paso es el circuito documental de Exportación CIF: pedido, factura proforma, aceptación de la factura proforma, carta de crédito, B/L, factura, packing list, certificado de origen, certificado de seguro,…, pago, o sea un B2B de Comercio Exterior.

Están trabajando en la incorporación de XML, dentro de un planteamiento de interoperatividad que permita que datos en formato estándar se difundan en formatos independientes: EDIFACT, Fichero plano, XML, FAX…

ORIGIN presentó una ponencia que hablaba sobre una mayor integración de la cadena de suministro, utilizando EDI o Internet en función de las características de cada cliente. Lo que debemos pensar es que un mayor gasto en TI supone unos menores costes para el negocio, ya que el gasto en TI no es coste es estrategia. El B2B está creando nuevas oportunidades de negocio que debemos aprovechar para nuestra empresa. Para ver como estamos posicionados, podemos hacernos esta pregunta ¿nuestros comerciales y gestores de compras visitan asiduamente los portales B2B?

Tenemos que promover una evolución del negocio hacia el e-procurement y el B2B en Internet. La evolución histórica ha sido: primero implantar TI por áreas de negocio, y después crear un Enterprise Resource Planning (ERP) integrado. Ahora tenemos que abordar el ERP extendido a proveedores, clientes y empleados (véase el caso de Ford) basado en sistemas Customers Relationship Management (CRM) y Suppliers Chain Management (SCM), aprovechando las tecnologías Internet basadas en XML para integrar la cadena de suministro en Internet y con ello a los proveedores y clientes en «la empresa extendida».

O sea, innovar a XML o morir.

HENKEL IBERICA, hizo una magnífica ponencia acerca de cómo lograr la eficiencia en la gestión logística, integrando el EDI en los ERP’s. Ellos utilizan EDI integrado en SAP/R3, mediante la herramienta Mercator. Según Henkel, la evolución del EDI en España ha tenido los siguientes problemas: insuficiente marketing del sistema, insuficiente apoyo institucional, elevados costes de desarrollo e integración, no cubría completamente la cadena comercial, etc. aunque a pesar de todo ello, se ha conseguido una implantación de esta tecnología, e incluso la Administración Pública ha aceptado la factura electrónica. Esta evolución ha aumentado el número de mensajes EDI, desde los iniciales ORDERS (Emisiones de Pedido), INVOICE (Emisión de Factura) y COMPAG (Pagos), a los actuales y/o futuros PRICAT (Alineamiento de ficheros maestros de productos, apoyado por la AECOC), INVRPT(Ventas, Stocks y Roturas), DESADV (Aviso de Expediciones), EAN-128 (Embalaje), y RECADV (Confirmación de entregas). El uso de este tipo de mensajes entre proveedores y clientes, puede mejorar sustancialmente la cadena de suministros.

Para darnos una idea de cómo funcionan estos mensajes, veremos el ejemplo del PRICAT. En una base de datos de la AECOC, se almacena información comercial y de logística de los productos (incluida la imagen). Esta información es imprescindible para el proceso del pedido, ya que el cliente puede saber el precio del producto y su información relacionada sin posibilidad de errores. En este mensaje, AECOC realiza las funciones de almacenamiento de la BD, confirmaciones de su mantenimiento, y funcionalidades de suscripción para los compradores de dicho producto; todo ello mediante mensajes PRICAT y consultas al Web.

El reaprovisionamiento continuo (CRP), es la cumbre de la eficiencia en la gestión logística. Este tipo de servicio consigue que el aprovisionamiento de productos se realice en base a la demanda real, mediante técnicas de TI compartidas entre el proveedor y el cliente. Mediante mensajes INVRPT(Ventas, Stocks y Roturas), el proveedor conoce sin demora el stock de su cliente y en base a unos acuerdos preestablecidos de servicio, el proveedor automáticamente realiza propuestas de pedidos ORDERS (Emisiones de Pedido), para que el cliente las confirme. De esta manera el proveedor consigue fidelizar al cliente (ya que le reduce al stock solo al necesario), dar un valor añadido a su relación y recabar conocimiento de la demanda del producto.

Henkel ha conseguido otra mejora de la eficiencia en la logística optimizando la expedición y recepción de mercancías. Entre el almacén de Henkel y su cliente, se envían los siguientes mensajes: DESADV (Aviso de Expediciones), EAN-128 (Embalaje), y RECADV (Confirmación de entregas), bajo unos acuerdo de horarios de entrega, descargadores, calidad concertada (¡¡no se revisan los palets en la entrega!!), y eliminación de pedidos urgentes por la implantación del CRP. El 35% de sus ventas las realizan utilizando EDI, esperan conseguir hasta un 60%. Por el momento solamente tienen a un cliente con calidad concertada (PRYCA) pero esperan aumentar considerablemente esta cifra. Otra parte de la cadena de suministro son los proveedores de Henkel. Con ellos están definiendo un sistema EDI Up-stream que garantice las materias primas en su proceso de fabricación.

Todo ello ayudará a para conseguir que su sistema de fabricación y distribución sea Just-in-Time.

Seguirán trabajando en EDI, ¡¡o en XML si se estandariza su uso!!.

TNT presentó sus ideas de cómo integrar el comercio electrónico en transacciones entre empresas para acelerar los procesos de distribución y logística. Según TNT Europa lleva 2 años de retraso con respecto a EE.UU. en la creación de estrategias de negocio usando tecnologías de Internet. Mientras que en Europa seguimos creando Web Sites, o e-commerce (tiendas), en EE.UU. ya realizan e-business mediante Supply Network (Dell) o e-corporations mediante la integración de la gestión de la cadena de suministros (Cisco Systems). El modelo de sistema B2B de TNT se llama @TNT, mediante este sistema se puede publicar una mercancía, gestionar pedidos, controlar stocks, solicitar recogida de mercancías, hacer un seguimiento del transporte y gestionar las devoluciones, mediante una plataforma XML. Incorpora una pasarela de pagos, WebSite, integración con ERP’s, seguridad en las transacciones y un servicio de atención al cliente. @TNT se ha desarrollado junto a los socios tecnológicos: DESCARTES para hacer posible la visibilidad de la cadena de suministro, OrderTrust como gestión CRM para Internet, y CapGemini.

Según TNT, Internet está provocando cambios en la cadena de distribución. La cadena clásica: Productor -> Distribuidor -> Mayorista -> Minorista -> Consumidor, se está convirtiendo en modelos B2C donde desde el Productor hasta el Minorista pueden llegar al consumidor, y en modelos B2B entre los componentes de la cadena de distribución. Estos nuevos modelos de negocio están provocando grandes cambios en la industria de la distribución. También se están creando problemas en los sectores tradicionales con franquicias, en donde la aparición de un B2C del productor, puede crear competencia a las franquicias existentes. Según TNT, el éxito de la estrategia de negocio debe basarse en la innovación, y nunca en la evolución. Algunos ejemplos de innovación son: Barrabes.com, Cisco.com, Yahooo.com, AOL.com. Y algunos ejemplos de evolución: Toys’R’Us y Levi Strauss & Co. La primera, Toys’R’Us, fracasó en su campaña de Navidad de 1.999. Al no poder procesar el volumen de pedidos, muchos envíos no se entregaron antes del día de Navidad. Levi Strauss & Co fracasó al no poder procesar las devoluciones de los productos. Como contrapartida, también han aparecido otros operadores en Internet, como Homegrocer.com, Tesco Online, Peapod.com o WebVan.com, muchos de ellos aseguran la entrega de los productos en su radio de acción en menos de 1/2 hora.

Según TNT, las empresas de transporte han empleado Internet para «vender» sus servicios o simplificar la operativa, y lo que deben hacer es «ayudar a vender» apoyándose en los nuevos modelos de negocio que están apareciendo de la mano de nuevos actores (VerticalNet, TradeZone, PaperExchange, Chemdex, eMarketer, eBay, Priceline, etc.) Los nuevos modelos de negocio integran e-procurement para optimizar las compras, e-auctions para conseguir nuevos clientes y venta de pequeños stocks, Virtual Comunity para aunar intereses comunes, Value Chain Service Provider para integrar todo lo anterior en la cadena de valor, y Trust Services para garantizar las transacciones.

Como resumen según TNT, o se hace e-business o se estará «out of business», pero siempre con XML.

BBVA realizó una ponencia centrada en temas de seguridad en EDI, en cuanto a la situación del EDI Financiero para pagos y cobros. Destacó las ventajas de XML:

  • Costes y plazos muy bajos de desarrollo
  • Conectividad total en Internet
  • Facilidad de integración con otros sistemas empresariales
  • Los datos están unidos a su estructura lo que facilita su difusión y facilita el tráfico de ficheros FTP. La estructura (Document Type Definition -DTD-) puede hacerse pública en un repositorio de documentos. Existen herramientas de software que nos separan la información en las dos partes: datos y estructura.
  • Independencia del medio de visualización (PC, WAP, etc)
  • Buscadores y Agentes personales más eficientes
  • Se pueden crear lenguajes específicos para un sector, p.e. ebXML, MathXML o FinXML
  • Representa de manera más fidedigna que las Bases de datos Relacionales, los modelos de datos de la realidad.

Estas ventajas son las que hacen de XML una herramienta muy útil para las entidades financieras, en cuanto a la creación de servicios de Banking y comercio electrónico. En la actualidad, el EDI Financiero dispone de los siguientes mensajes: PAYMUL (orden de pago, con o sin confirming y/o pago certififcado), DIRDEB (orden de cobro), FINSTA (extracto de cuentas), DEBMUL (aviso de débito), CREMUL (aviso de crédito), BANSTA (acuse de recibo), CIPHER o CONFID (para cifrar datos), KEYMAN (pàra transmitir las claves de cifrado), y AUTACK (para transmitir la firma electrónica). El EDI Financiero se utiliza sobre todo con multinacionales. Ultimamente se está incrementando mucho el uso de FTP Internet con firma electrónica y cifrado para la transmisión de datos.

Según el BBVA, se producirá una convergencia de los mundos XML y EDI, con los objetivos de: estandarizar el uso de Internet, acceso a la PYME, y reutilización de todo lo realizado en EDI. Ya existen numerosas iniciativas en esta dirección: ISIS XML/EDI, ISIS EXPERTS, ebXML, EFMA, XMLEPR (Sanidad), e IBERION (Financiero), demasiadas iniciativas para un solo estándar.

En resumen, para el futuro: EDI/XML.

INDRA presentó una ponencia sobre como utilizar plataformas EDI para construir soluciones de negocio electrónico B2B sobre Internet. Primero hizo una diferenciación entre los distintos tipos de EDI: Diferidos (intercambio de datos posteriores a la transacción comercial) o Interactivos síncronos o asíncronos (el intercambio de datos produce la transacción comercial). Los del primer tipo suelen ser operaciones de envío de información (p.e. el envío de los TC2), mientras que los del tipo interactivo son enfocados a sistemas mensaje a mensaje o pregunta -> respuesta, que requiere un acoplamiento total entre los sistemas que se comunican.

Presentó algunas de las funcionalidades de los EDI que han desarrollado bajo su arquitectura EDItran:

  • EDI de recaudación para la AEAT, el Ayuntamiento de Madrid y el Ayuntamiento de Barcelona.
  • EDI de facturación, banca electrónica y transferencias para la Asociación Española de Banca (AEB)
  • EDI para la presentación del TC2.

Según Indra, Internet aportará todas las ventajas del uso de la Red para conseguir el aumento de las plataformas EDI transformadas a este nuevo entorno. Las ventajas se materializarán implementando funcionalidades sobre protocolos estándares (HTTP, FTP, …), con formatos más flexibles (XML), con capacidades de integración (BizTalk), y con mecanismos de seguridad más fiables (certificados X.509).

En resumen, EDI sobrevivirá como una tecnología integrada en Internet.



Software AG (the XML company) presentó una ponencia sobre el aprovechamiento de XML para la realización de transacciones electrónicas B2B, basándose en la necesidad de manejar información más especializada, más sofisticada, más personalizada, más fácil de procesar electrónicamente, y más fácil de localizar.


En la ponencia se comparó como HTML es un lenguaje pensado en la visualización de la información, mientras que XML es un lenguaje pensado en la difusión de la información independientemente del medio, ya que gracias a la existencia de las hojas de estilo XSLT, un mismo documento XML puede tener su versión HTML para PC, otra versión WML para WAP, otra versión XML para un software basado en XML, u otra versión EDI para un software basado en EDI.


También recordó que XML, por sí solo, no es un estándar sino una familia de estándares que definen: la forma de realizar consultas a las Bases de Datos nativas en XML (XML Query language -XQL-), el  lenguaje de transformación de datos (Extensible Stylesheet Language Transformation -XSLT-), la forma de incorporar enlaces en la información (XML Linking Language -Xlink o Xpointer-) y la forma de comprobar si un documento tiene una sintaxis correcta y de como acceder a la estructura de datos (Simple API for XML -SAX-  pensado para procesamiento masivo y Document Object Model -DOM- pensado para crear documentos, el uso de uno u otro suele ser transparente para el programador).


La aparición de XML ha provocado la creación de numerosas iniciativas para la normalización de datos y mensajes, las más «horizontales» son:


    

  • eCO Framework (promocionado por CommerceNet) que define etiquetas XML y reglas de procesamiento, y no parte de EDI
    • 

  • ebXML (promocionado por OASIS), que también define etiquetas y reglas, pero en este caso parte de toda la tecnología EDI implantada. 
    • 

  • BizTalk (de Microsoft) que según Software AG, solamente define documentos comerciales.
    • 



A Software AG, le interesa lanzar el mensaje (cierto por otro lado) de que XML funcionará mejor con bases de datos que no sigan un modelo relacional puro (ADABAS no lo sigue ya que admite campos múltiples y grupos periódicos). Por lo tanto, una vez descartado el almacenamiento de la información XML en ficheros por sus problemas de integridad con los sistemas de información de la empresa, XML necesita de un motor de base de datos capaz de manejar XML en nativo, sin transformaciones; y para ello presenta su software TAMINO como un servidor de información para negocio electrónico. TAMINO es capaz de manejar XML nativo y de acceder a los sistemas de información empresariales para convertir a XML cualquier información existente, convirtiendo la información en información XML portable y reutilizable.


Como puede observarse, Software AG apuesta por la implantación total de XML.


Microsoft, realizó una ponencia en la que se comentaba el impacto que tendrá XML en el comercio electrónico B2B. Internet presenta nuevas formas de trabajar y hacer negocios, lo que antes era una carga administrativa, una orientación interna de las transacciones, y unas miras locales o nacionales, ahora se ha transformado en un Self Service, una mayor preocupación por las relaciones externas, el Business Intelligence, y el mercado global. La «empresa extendida»establece relaciones entre empleados, clientes, partners, y proveedores.


Microsoft presentó algunas funcionalidades de su producto BizTalk (está en versión beta, la versión comercial saldrá al mercado este verano), para construir integrar, construir y promocionar la estrategia de comercio electrónico en una «empresa extendida».


Además de un servidor de software, BizTalk es una iniciativa de Microsoft y partners, que define DTD’s con el objetivo de conseguir la integración de aplicaciones y datos existentes en el comercio electrónico. El esquema de funcionamiento de un BizTalk Server está basado en Site Server Commerce Edition, SQL Server y Windows NT. BizTalk gestiona documentos XML y puede conectar sistemas basados en EDI (en redes VAN), IDOC (en sistemas SAP) o ficheros planos, aunque la idea de Microsoft es que exista un sistema BizTalk en cada rincón de este planeta. Teniendo en cuenta que decenas de miles de  Web funcionan con Windows NT y el 64% de los e-procurement están desarrollados en Windows NT, no sería de extrañar que lo consiguiesen.


BizTalk se crea con el objetivo de mejorar las cadenas de valor, desde proveedores a clientes, integrando la información de diferentes sistemas, y permitiendo la visibilidad de datos en tiempo real. Como proyectos estratégicos de Microsoft presentó los siguientes:


    

  • B2C. Supermercado de «El Corte Inglés», versión en XML y BizTalk
    • 

  • B2C. Alcoste.com con sus 2.000.000 hits en el primer día con Site Server Commerce Edition 
    • 

  • B2C. Supertienda ViaPlus.com. Se desarrolló en 2 meses (quizás de ahí le vengan los problemas) con Site Server Commerce Edition 
    • 

  • B2C. Submarino.com, desarrollado  con Site Server Commerce Edition
    • 

  • B2C. Infotel, desarrollado  con Site Server Commerce Edition, evolucionará a XML para integrar proveedores de contenidos. 
    • 

  • B2B. Bankinternet. Gestión de compras corporativas utilizando XML y Site Server Commerce Edition 
    • 

  • B2B. Amena. Gestión de relaciones con distribuidores, desarrollado con Site Server Commerce Edition, y evolucionará a XML con BizTalk Server. 
    • 

  • B2B y B2C. Infonegocio.com de Telefónica. 
    • 

  • B2C y B2B. Agencia de Viajes SAVIA. Desarrollado utilizando XML y Site Server Commerce Edition
    • 



Como colofón a este abanico de éxitos, Microsoft recordó la necesidad de gastar un poco de dinero en hardware con el fin de conseguir escalabilidad y disponibilidad de nuestro negocio en Internet, y también recordó la famosa frase de Charles Darwin: «No sobrevivirán las especies más fuertes, tampoco las más inteligentes, lo harán aquellas que mejor se adapten al cambio».


Los partners de Microsoft en BizTalk, han sido Commerce One (utiliza 100% plataformas de Microsoft), Ariba (si no es el 100%, casi, casi) y todas las empresas desarrolladoras de ERP’s.


Como resumen, XML para todos.


El Banco de Sabadell, presentó una ponencia titulada: ¿la aprobación de la firma digital supondrá el despegue del comercio electrónico B2B a través de Internet?.


Para ellos, las ventajas para las empresas del uso del e-business son muy claras:


    

  • Ahorra entre un 10% y un 50% los costes de la gestión de los pedidos 
    • 

  • Reduce el tiempo de proceso de los pedidos entre un 50% y un 96%
    • 

  • Reduce los errores en el ciclo pedido – recepción – facturación – cobro al 0,2% del total 
    • 

  • Reduce un 50% los costes de distribución de los productos manufacturados, y de un 90% la de productos que viajan por la red
    • 

  • Reduce un 25% los costes de almacenaje 
    • 

  • Reduce un 60% las inversiones en inmovilizado y activos
    • 



Las empresas tienen ahora la posibilidad de utilizar Internet como nuevo canal de ventas, o como nuevo canal de comunicación, o puede integrar toda la cadena de valor del producto con Internet, o pueden transformar el proceso productivo al Web (primero se vende y luego se fabrica), o pueden volver a diseñar el negocio (Netgocio) de la empresa creando una estrategia basada en Internet. Para tener éxito tienen que conseguir que el flujo de mercancías, el flujo de información y el flujo financiero estén sincronizados, y ordenados y que se utilice eficazmente Internet. La  «punto.comización» de las empresas tiene por objetivo conseguir que todos los procesos de negocio estén integrados con Internet. (Back Office, Front Office y «empresa extendida»).


Según ellos, la aprobación de la firma digital fomentará su uso, y esto provocará que las barreras existentes de seguridad, privacidad, y confianza sean superadas. El Banco de Sabadell ha participado activamente en el sistema PortIC presentado por la APB, y también está trabajando en su sistema World Trade Area, que pretende ser un punto de encuentro en Internet con el comercio exterior de España, facilitando las tareas de exportación e importación. Por ahora solamente facilita contactos en el extranjero y en España, pero están deseando que alguien dicte la normativa necesaria para poder realizar los trámites de exportación electrónicamente. El proyecto lo han iniciado hace 18 meses, y harán un lanzamiento después del verano. No se especificó si utiliza XML, pero hizo mucho hincapié en el tema de los certificados y en el almacenamiento de todos los envíos firmados.


Moulinex España realizó una ponencia sobre la forma de integrar la cadena suministro-fabricante mediante EDI estableciendo una extranet para reducir tiempos y costes en la atención al cliente en los servicios de post-venta, tomando como ejemplo el sistema EDI@SAT de la Federación Española de fabricantes de Pequeños Electrodomésticos (FAPE) que está funcionando desde hace 4 años. Con EDI@SAT han conseguido que los pequeños comercios que arreglan los electrodomésticos dispongan de una solución  tecnológica que les sirve para gestionar las relaciones con todos los fabricantes, y todos los trabajos y servicios del taller de reparación. Desde FAPE se ha financiado la implantación de este sistema mediante la cesión gratuita del software, la financiación del hardware, y el uso de tarifa plana de comunicaciones. En la actualidad, el sistema se utiliza por las compañías Braun, Moulinex-Krups, Philips, Solac, Soler&Palau, Taurus, Tefal-Rowenta y Ufesa, que representan el 90% de este  mercado; y gestiona la entrada automática de tarifas, descuentos, precios, y pedidos; la gestión de stocks; la actualización automática de defectos de garantía; y las facturas EDIFACT, todo sin papel. AL principio utilizaron redes VAN, y desde el año pasado están migrando a Internet como medio de transporte.


Los beneficios del uso del sistema EDI@SAT son tangibles:


    

  • Reduce un 50% el tiempo de envío de los materiales
    • 

  • Reduce un 90% los errores de los pedidos
    • 

  • Reduce un 20% la carga de trabajo administrativo
    • 

  • Conocimiento en menos de 5 días de defectos de la línea de fabricación
    • 

  • No obsolescencia de stocks de piezas
    • 



En el futuro, integrarán EDI@SAT en Internet, pero sin abandonar EDI.


La Agencia Estatal de la Administración Tributaria (AEAT) presentó una ponencia que hablaba de los requisitos que deben cumplir las empresas para conseguir la validez de la factura electrónica, mediante el Sistema de Facturación Telemática.


El ponente hizo un rápido resumen de las ventajas de EDI (respuesta Just In Time, reducción de costes y de precios, aumento de la competitividad, reducción de tareas administrativas, e incluso ecológicas por la eliminación de papel) y de sus desventajas (incluido el aumento de paro por la automatización del proceso).


También resaltó las diferencias entre la facturación electrónica y la facturación firmada electrónicamente, haciendo hincapié en la legislación aplicable a la factura telemática: Artículo 88 de la ley 37/92 de 28 de Diciembre, Real Decreto 2402/85 de 18 de Diciembre, Artículo 9 bis del Real Decreto  2402/85 modificado por el Real Decreto 80/1996, y Orden Ministerial del 22 de Marzo de 1996, todo ello teniendo en cuenta que la mayoría de las empresas inclumplen la ley y procesan electrónicamente a su manera las facturas. En cuanto a la firma electrónica de las facturas la legislación aplicable es el Real Decreto ley 14/1999 de 17 de Septiembre que garantiza que una factura telemática firmada electrónicamente mediante la aplicación de una firma avanzada tiene la misma validez que una firma en papel, bueno no solamente tiene la misma validez, sino que prevalece una firma electrónica sobre una firma manuscrita.


La AEAT promovió el uso del Sistema de Intercambio de facturas por medios electrónicos (SIFME), que por diversos motivos (entre otros su complejidad para su implantación) no ha sido aceptado por los empresarios españoles que siguen utilizando EDIFACT y generan la factura en el acto si se la pide la AEAT. En el SIFME aparecían diversos actores que intervenían en el envío de las facturas: el Promotor que ejerce la iniciativa ante la AEAT (quien le autoriza a ser promotor), el Centro Servidor que sirve de notario de las transacciones, los Usuarios que son las empresas que emiten y reciben facturas (también deben ser autorizadas por la AEAT), y los Prestadores de Servicios Informáticos que son empresas de TI que ofrecen soluciones que utilizan el SIFME.


Según la AEAT, el SIFME no tendrá mucha evolución, una vez que la firma electrónica avanzada (PKI) se puede incorporar a la factura telemática. ¿EDI o XML? La respuesta es en todo lo que circule por la red.


La Universidad Politécnica de Cataluña (UPC) realizó una ponencia sobre como garantizar la seguridad en EDI sobre HTML y comercio electrónico, tarea clave para garantizar el desarrollo de EDI sobre Web.  Las vulnerabilidades en el comercio electrónico pueden agruparse según su porcentaje de aparición en:


    

  • Suplantación de Identidad: 12%
    • 

  • Robo de información: 11%
    • 

  • Modificación de la Información: 9%
    • 

  • Denegación de servicio: 8%
    • 

  • Sniffers: 6 %
    • 

  • Repudio: Sin especificar
    • 



La firma electrónica puede resolver los casos  de suplantación de Identidad, modificación de la información, sniffers y repudio, o sea aproximadamente un 28% de los casos de vulnerabilidad; siempre que las herramientas de seguridad permitan claves de cifrado de 128 bits, y las claves caduquen como mucho a los 2 años.


Como temas importantes a tener en cuenta en un sistema de firma electrónica, debemos saber que no está reglamentado el uso de la firma electrónica que provenga de un medio automático sin intervención humana. Para que tenga valor la firma electrónica el proceso de firma debe ser iniciado voluntariamente por una persona, incorporando en los mensajes de dicho proceso su firma.


La UPC no recomienda publicar mucha información (clave pública, identidad de la firma, etc.) del poseedor de una firma electrónica ya que podría ir en contra de la LORTAD; tampoco recomienda el cifrado de mensajes a no ser que sea necesario ya que puede impedir auditar los mensajes y la caducidad de la clave nos puede impedir descrifrar el mensaje a lo largo del tiempo. El ponente hizo mucho hincapié en la limitar el valor de las transacciones que se realizan con un certificado digital, ya que de no hacerlo así, la Autoridad de Certificación debe tener un seguro de responsabilidad civil de 1.000 Millones de Pesetas, lo que puede suponer una cuota muy alta de seguro. También describió las diferencias entre firmar un mensaje, firmar y fechar y mensaje y por último, firmar, fechar y que alguien dé fe de estos datos (CESCE es fedatario de firmas electrónicas).


Pero ojo, no es oro todo lo que reluce, existe software que solamente pide el PIN del certificado una vez en casa sesión de trabajo, lo que permite a cualquier persona que tenga acceso a ese ordenador utilizar el certificado sin ser el verdadero propietario.


Por último hizo un repaso de los métodos de seguridad utilizados en EDIFACT, que dispone de segmentos especiales («Security Headers and Trailers») y mensajes especiales (como AUTACK, y KEYMAN ya comentados anteriormente), y de la iniciativas DEDICA y TEDIC para aumentar la seguridad  de los mensajes EDIFACT en Internet.


En resumen, XML o EDI, seguro.


Por último se realizó una mesa redonda en donde participó personal de: Microsoft, Fonocom, Origin e Indra, cada uno con su opinión sobre la pregunta ¿puede XML proporcionar un modelo integrador de EDI?.


La respuesta, en mi opinión, después de haber oido a los ponentes es que sí, pero si se llega a tiempo de ello, si tardamos existirán muchos modelos de XML para integrarse entre sí y con EDI.


También se impartió un seminario técnico sobre XML, del cual pueden sacarse muchas conclusiones importantes, como por ejemplo que cuando firmamos un mensaje en XML, al aplicarle una transformación XLST para WAP por ejemplo, perdemos la firma al cambiar el contenido, un problema importante a resolver…


CONCLUSIONES


Mi opinión personal es que XML se convertirá en el estándar del futuro para el intercambio de información comercial, por los siguientes motivos:


    

  •  Es un entorno más fácil de usar por las PYMES, ya que no requieren grandes inversiones para su implantación
    • 

  • La normalización de XML ha lanzado un proceso selectivo de la evolución de los diversos modelos de mensajes en XML, sobrevivirá aquél que más se implante o más compatible sea con las iniciativas mundiales como ebXML (aunque a esta iniciativa le falte algo de interactividad en Web)
    • 

  • El modelo EDI de procesos offline por lotes entre dos empresas que se conocen a priori, está obsoleto. Esa relación sirve para las relaciones comerciales de toda la vida pero no genera nuevas relaciones comerciales. Los modelos basados en XML son procesos online, interactivos (más pensados para Web) entre una empresa y muchos que quieren comerciar con ella, y pueden ser desconocidos al comienzo de la comunicación electrónica.
    • 

  • Otras ventajas de XML con respecto a EDI es que la estructura incluida en los datos de XML es mucho más flexible que la estructura predefinida con anterioridad en EDI, además de la visibilidad Web, Wap, etc sin trabajo adicional, mientras que en EDI es necesaria la traducción a HTML, WML, etc. 
    • 

  • Se habla mucho de XML en Web, pero no he escuchado ninguna propuesta orientada a email. Sería una fuente importante de proceso comercial, el poder enviar emails en formato XML y que el destinatario nos pudiese contestar otro mensaje XML. Los procesos en este medio son más del estilo EDI entre 2 empresas conocidas, pero
    
pueden ser muy efectivos en este medio o vía FTP. 
    • 

  • En España existen unas 1.800 empresas que utilicen EDIFACT, mientras que el número de usuarios potenciales de XML es enorme.
    • 



Como hemos podido observar de las ponencias se deduce que no solamente es necesario publicarse o vender en Internet, sino que además hay que hacerlo bien, a tiempo, sin roturas de stock, integrando en Back Office con el Front Office, además saber controlar las devoluciones, todo un problema.


Los ponentes están muy divididos en cuento al futuro de XML o EDI:


    

  • A favor de XML: ORIGIN, TNT, Software AG, Microsoft
    • 

  • A favor de EDI: Henkel Iberica, Moulinex España
    • 

  • A favor de EDI/XML: APB, BBVA, Indra
    • 

  • No se define: Banco de Sabadell, AEAT, UPC
    • 



Los de Tecnologías de la Información apoyan XML (supongo que para lograr implantar una nueva necesidad), los fabricantes apoyan EDI (supongo que para sacarle más provecho a las inversiones realizadas), y los nuevos actores apoyan independientemente EDI y/o XML, pero en Internet e integrado en la cadena de valor de la empresa.


Según yo (MAAJ) , el futuro pasa por crear modelos de negocio interactivos, entre desconocidos, y pensados para usar con tecnología Internet (Web, email y FTP), o sea, el futuro es XML, XSLT, Xlink, Xschemas y todo lo que les rodee.


ALGUNAS CIFRAS


IDC, Diciembre 1.998. Uso de Internet y e-commerce en Europa del Occidental desde 1.998 hasta el 2.002. El crecimiento de B2C será del 2.500%, mientras que el crecimiento en B2B será de 4.500%. En el 2.002 el B2B representará el 78% del total del e-commerce, mientras que el B2C será el 22% (¿incluye C2C?)


Computer Industry Almanac, 2.000. Millones de Usuarios de Internet por regiones. En el año 2.000: América del Norte 150,9. Europa Occidental 87,7. Asía/Pacífico 72,1. Sudamérica/América Central 19,6. Europa del Este 10,8. Total 349,2. En el año 2.005: América del Norte 231,5. Europa Occidental 213,7. Asía/Pacífico 189,7. Sudamérica/América Central 56,1. Europa del Este 45,5. Total 765,8.


Forrester Research, 1.999. Volumen de negocio de B2C y B2B. En Europa en el año 2.000: B2C 8,800 millones de $USA, B2B 76.000 millones de $USA. En Europa en el año 2.004: B2C 239.600 millones de $USA, B2B 1.361.100 millones de $USA. En el 2.001, Internet representará  el 0.9% del PIB en Europa, mientras que en EE.UU. será el 2,7% del PIB.


Andersen Consulting. Estudio sobre el uso de Internet entre las 100 mayores empresas españolas. El 74% usa Internet, el 31% e-commerce, el 10% se reinventa, el 34% no tiene una estrategia, y el 35% es reticente al comercio electrónico. El 48% cree que Internet afectará poco o nada a la estructura de la empresa, frente al 52% que piensa que será mucho o bastante. En el 49% de los casos, es el Dpto. de Informática el que toma las decisiones sobre el comercio electrónico.


AECE, 1.999. Estudio sobre el uso de Internet entre 2.000 empresas de todos los sectores. El 16% tiene presencia en Internet, y de ellas, el 56% vende por Internet; el 50% tiene dominio propio; el 29% gastó menos de 500.000 ptas en Internet.


ALGUNAS FRASES,  IDEAS Y DEFINICIONES


    

  • XML, Enterprise Resource Planning (ERP), Customers Relationship Management (CRM),  Suppliers Chain Management (SCM), e-procurement, e-auctions, Virtual Comunity, Value Chain Service Provider, Trust Services, Business Intelligence, Self Service, Global Markets: cambiarán la forma de hacer negocios.
    • 

  • El gasto en TI no es coste es estrategia.
    • 

  • «Un mes Internet» es un año real (otros estiman que son necesarios «tres meses Internet»).
    • 

  • «No sobrevivirán las especies más fuertes, tampoco las más inteligentes, lo harán aquellas que mejor se adapten al cambio» (Charles Darwin)
    • 

  • Fabricación en serie: primero se fabrica, luego se vende. Fabricación en Web: primero se vende y luego se fabrica
    • 

  • Ahora solamente se pueden reducir costes en la cadena logística o en suministros, ya que en la producción casi es imposible hacerlo. 
    • 

  • O se hace e-business o se estará «out of business».
    • 



ALGUNOS ENLACES DE INTERES



(Nota: algunos enlaces ya no están activos en el 2007)

					

		
		
	

							
	

				

			
						

				Javier Solá, colabora en el desarrollo de lenguas minoritarias
			

										

					3 respuestas				

					


				

			

Javier Sola - KhemerOS


Javier Solá, un amigo que durante bastante tiempo fue el Gerente de la Asociación de Usuarios de Internet, marchó un dia a Camboya y… se quedó.


Español, nacido en Santiago de Chile en 1960, se graduó en Ingeniería Informática en la Universidad de Duke en 1984, iniciando su carrera profesional en los laboratorios de Inteligencia Artificial (IA) de Honeywell Bull en París. Dos años más tarde regresó a Estados Unidos para cursar un master en Informática y Ciencias de la Información (en Ohio 1987), tras lo que vuelve a París a trabajar dos años más con Bull en IA. Volviendo a España en 1990 en donde compagina su trabajo como consultor, con la docencia en programas de Master.


En 1995, se une a los fundadores de la Asociación de Usuarios de Internet, asumiendo el cargo de Director y desde la que empezó en 1996 a organizar el Congreso nacional de Usuarios de Internet: Mundo Internet en sus dos eventos de Madrid y Barcelona. En 1999 es nombrado miembro del Consejo de Nombres de Dominio de ICANN (Inet Corp for Names & Numbers). En 2001 trabaja en la creación de un Plan de Dominios para mejorar la escasa penetración de éstos en España.


He recogido este artículo suyo, que cuenta como fue la cosa,  del web de  Proscritos. La revista.


Pasaba por ahí… 


por Javier Solá 


Cada vez que me preguntan por qué me fui a vivir a Camboya contesto lo mismo. Pasaba por ahí… y me quedé. No puedo decir que me quedara poco a poco. No fue un proceso gradual por el que fui retrasando mi vuelta. Sencillamente… nunca pensé en irme. Era un momento de mi vida en el que el futuro ya no existía, y por tanto no existía tampoco ningún otro sitio, excepto en el que estaba.


Había trabajado los siete años anteriores en la Asociación de Usuarios de Internet, viendo como Internet se convertía en lo que es ahora. Nos habíamos asignado el trabajo de promover el uso de Internet (cuando estaba empezando), intentar que las leyes fueran un poco más benignas con los usuarios, y que los legisladores acordaran de vez en cuando lo que es la privacidad.


Es curioso el concepto de privacidad. En Camboya no existe ni siquiera la palabra. No es necesaria en un mundo donde todo es público, fuera de las ciudades no hay habitaciones, donde uno se ducha delante de los demás, tapado con lo mínimo, y donde las parejas se encuentran brevemente debajo de una manta, en la sala que comparten con toda la familia. Es difícil para nosotros entender un mundo en el que todo es público, en el que una mirada de complicidad con alguien del sexo opuesto será inmediatamente compartida con sus amigos o amigas. No hay secretos, excepto los que son demasiado viles como para contarse.


Diferente es el caso de occidente, donde la privacidad es violada no por el mayor bien social, sino por el ansia de poder y control de los gobernantes, que ambicionan perdurar eternamente en el poder… pero de esto ya me he olvidado, he conseguido incluso que la mayor parte del tiempo ni siquiera me cabree.

En Camboya aterricé en un hogar para niños minusválidos. Me gusto y me quedé. No con ansias de ayudar, ni haciendo algo fundamental para el futuro de estos niños. Me quedé porque me gustó, porque estar ahí me hacía feliz, y no tenía nada mejor que hacer en mi vida. No recuerdo un mundo más feliz que aquel de risas y sonrisas en el que niños de 7 a 10 años tomaban el control de su propia vida. Se levantaban a las seis para limpiar la casa, lavaban su propia ropa, los platos; estudiaban y aprovechaban cada momento para disfrutar de su niñez, esa época en la que no poder andar, ser manco o ciego no es un problema.

Vivían entonces en un mundo que les aceptaba, sin pensar que en el futuro la sociedad les arrinconaría. Y sin pensar tampoco en su pasado de niños reptiles, de niños que se arrastraban por el suelo cuando vivían con sus familias en el campo y sus vidas no valían nada.


Estuve allí varios meses, haciendo los trabajos más sencillos, aprendiendo a vivir con el calor y con los mosquitos, y aprendiendo jemer, el idioma de Camboya. El jemer no tiene las complicaciones tonales del Chino o el Tailandés, pero –con más de 50 vocales- es una pesadilla fonética, y tiene –probablemente- la escritura más compleja del mundo, no por cantidad de caracteres, como el Chino o el Japonés, sino por cómo se combinan, haciendo que la escritura a veces se tenga que leer en espirales, en vez de izquierda a derecha.


Con los niños comprendí lo que quería hacer en los años siguientes. Había salido de España con idea de volver en algún momento y dedicarme a escribir, no con esperanzas de ser publicado, sino como forma de existencia plena.


En el futuro estos niños no podrían desempeñar trabajos físicos, la informática sería una buena opción para ellos., pero darles acceso a la informática no era tan fácil. Todos los programas de ordenador estaban en inglés, y esto era una barrera insalvable para estos niños que se peleaban con los primeros años de primaria.


Y me puse a pensar y a buscar… ¿Sería posible hacer una informática en lengua jemer? un idioma ignorado por los grandes de la informática, por la obvia falta de rentabilidad de la traducción en un país en el que sólo los ordenadores de la ONU y pocos más tienen software legal (y estos no necesitan ni quieren ordenadores en jemer).


Encontré lo que buscaba en el mundo del software libre. Programas gratuitos, desarrollados por grupos de voluntarios, que se podían traducir al jemer. Me puse a buscar y a escribir, a meterme en un mundo técnico y de colaboración que no se aprende en la universidad ni en las empresas. Aprendí las normas de una sociedad en la que casi siempre es posible encontrar a alguien que te ayude, si lo sabes pedir entendiendo el espíritu del que lo ofrece.


Finalmente entendí, y escribí un proyecto de cuatro años para cambiar el idioma en el que Camboya hacía su informática, pasando de usar software propietario a software libre y gratuito. Cuarenta páginas de descripción y un presupuesto: un millón de dólares.


Pero quien era yo… nadie. Alguien que –en una pequeña ciudad de provincia- de vez en cuando hacía de chofer para ir a buscar o dejar un niño aquí o allí. ¿Tenía un millón de dólares? Pues, no, tampoco, pero confiaba encontrar el dinero necesario en alguna parte.


Y me fui a Phnom Penh, la capital, a buscar algún tipo de organización, o crearla, si fuera necesario, para poder llevar a cabo el proyecto en su seno. Durante varios meses busqué, e incluso intenté crear un consorcio de empresas de informática, pero no conseguí interesarles. Finalmente, alguien me puso en contacto con Norbert, un alemán de 70 años que trabajaba en una ONG local. Curiosamente Norbert y yo nos habíamos visto muchas veces en los últimos años en distintas partes del mundo, en reuniones relacionadas con el gobierno de Internet, mucho antes de que yo llegara a Camboya, pero nunca habíamos llegado a conocernos directamente o a hablar.


A Norbert le entusiasmó el proyecto y me invito a realizarlo dentro de su ONG, Open Forum of Cambodia, una organización dedicada a restablecer la comunicación entre personas, rota tras 30 años de guerra que incluyeron un millón de muertos por los bombardeos americanos, así como el genocidio de los jemeres rojos.


¡Ya tenía casa! Nos pusimos a trabajar inmediatamente, bajo el nombre de Iniciativa KhmerOS. Contratamos a dos informáticos para que empezaran a hacer un diccionario de términos informáticos. El jemer no tenía los términos informáticos que necesitábamos para las traducciones, y crearlos era el primer paso.Estudiamos cómo habían sido creadas las palabras en español o francés, y decidimos seguir el mismo proceso, derivando palabras existentes, ampliando su significado para que tuvieran también usa semántica informática. Sabíamos que inventar significados no era suficiente, lo que hiciéramos tenía luego que llegar a la gente por medio de formación, libros, etc.


Y así empezamos. En 2004 empezamos a traducir programas de correo electrónico, un navegador, un procesador de texto, hoja de cálculo y otros programas básicos. Habíamos encontrado algo de dinero y nuestro equipo crecía.


Yo me iba metiendo más y más en el mundo del software libre. Nuestra experiencia se convertía en documentación que incorporábamos a los programas libres. Todas las preguntas que yo había hecho y alguien había contestado sobre cómo traducir OpenOffice se convirtieron el la documentación sobre cómo traducir OpenOffice (programas de tratamiento de texto, hojas de calculo y otras aplicaciones, parecidos a los de Microsoft Office). Lo mismo pasó con otros proyectos.


En 2005 conseguimos interesar al gobierno Camboyano para que se uniera a KhmerOS. Terminamos de traducir todos los programas que nos hacían falta y creamos materiales de formación para repartir a los profesores. El equipo de KhmerOS creció a 10 personas, incluyendo a cuatro formadores cuyo trabajo era empezar a formar profesores. Durante 2005, junto con el gobierno, formamos a más de 300 profesores de informática que ya tenían experiencia enseñando programas de Microsoft, y a casi 500 estudiantes, trabajadores y funcionarios. Nuestros productos en jemer empezaban a ser conocidos por todo el mundo interesado por la informática en Camboya. A final del año el vicepresidente en persona entregó los títulos a los profesores que habíamos formado.


Ahora –en 2006- seguimos nuestro trabajo. Casi todos los colegios de Camboya que enseñan informática lo hacen con los programas que hemos creado, y con nuestros materiales de formación. Más y más funcionarios públicos lo usan, y la demanda crece. Por el momento nuestros programas son utilizados en ordenadores que todavía utilizan Microsoft Windows, pero ya estamos trabajando en una estrategia para que el año que viene los ordenadores también cambien su sistema operativo a Linux (que ya hemos traducido al jemer) llegando a tener ordenadores que estarán completamente en jemer y usarán sólo software gratuito. El Gobierno –con nuestra asistencia- ha desarrollado una de las políticas informáticas más avanzadas del mundo, recomendando que todo el mundo utilice software libre, y obligando a los que quieren comprar software propietario a justificar su decisión. También se ha desarrollado un Plan Maestro para que todo el Gobierno migre a Linux, librándose de la esclavitud de tener que comprar software para cada nuevo ordenador.


Lo increíble es que todo está ocurriendo como yo lo soñé en 2003. La verdad es que nunca me lo hubiera creído cuando empecé. Mi actitud fue siempre de «yo empujo… y que sea lo que Dios quiera». No era tan importante conseguir cosas como intentarlo. Si no hubiera ocurrido nada no habría sentido que había fracasado. Conocedor del poco control que tenemos sobre el mundo, sencillamente habría entendido que no se daban las circunstancias para que ocurriera. Cuando necesitábamos dinero, aparecía, no el millón de dólares que había previsto al principio, sino lo justo para seguir, pequeñas cantidades que nos permitían hacer un trabajo de guerrillas, en vez de armar el ejército completo que yo había previsto para KhmerOS al principio, pero siempre suficiente para continuar, y para hacer todo lo que necesitábamos.


Poco a poco me fui metiendo también en el mundo de la traducción, y los problemas que tenían los países pequeños para hacer lo mismo que nosotros en Camboya. Junto con unos amigos sudafricanos que trabajaban en lo mismo (traduciendo al Zulú, al Xhosa y nueve idiomas más) creamos un proyecto para desarrollar los programas informáticos que hubiéramos soñado tener para nuestros traductores, el proyecto WordForge ( la forja de palabras), conseguimos convencer a un donante importante para que financiara (la Fundación Soros) y ahora estamos desarrollándolo como una cooperación sur-sur entre Camboya y Sudáfrica, formando a los programadores y enseñándoles a trabajar juntos.


Paso la mitad de mi tiempo viajando, intentando facilitar la labor de traducción en el mundo del software libre, participando en grupos de trabajo, dando conferencias, escribiendo, y la otra mitad en Camboya, buscando nuevas formas para que la gente aprenda a utilizar la informática en su propia lengua. En este momento tenemos nuestra ilusión puesta en un concurso para que la gente aprenda a teclear sin mirar lo más rápido posible, creemos que puede ser la puntilla final para el cambio.


El futuro sigue sin existir para mí. Existe el futuro de mis proyectos, y mi compromiso con ellos (mientras sigan siendo divertidos), pero es un compromiso presente. Sí que tengo otros sueños, en Camboya y fuera de ella, y quizás intentaré ponerlos en marcha. El que más me tira en este momento es hacer un nuevo diccionario de jemer, y un manual de ortografía, pero estos son grandes proyectos y tendrán que esperar a que los astros permitan su comienzo.


Lo que he aprendido en estos años es que es posible hacer cosas, que el motor del cambio son personas, nunca instituciones. Si fallan las personas falla el cambio, porque se queda sin su fuerza vital. Esto se ve todos los días en el mundo de las ONGs (o las oenegés, como diría mi amiga Inar). Los creadores de ONGs suelen ser gente con ideas, y con fuerza para implementarlas, pero este tipo de personas con el tiempo tienen que seguir su camino para crear cosas nuevas, son reemplazados en muchos casos por gestores que no tienen ni su fuerza ni su empuje. Los proyectos continúan, pero más y más de forma autómata, y acaban muriendo por falta de renovación y de ideas.


Es curioso como esto se parece a los mecanismos la Historia de las Civilizaciones de Toimbee, dónde explica que las civilizaciones nacen en defensa de un enemigo común, empujadas por líderes ideólogos con empuje… que pronto son reemplazados por políticos interesados en su propio poder… y finalmente por militares, en el momento en que la civilización comienza sus siglos de decadencia. Toimbee definía (entre otros) dos síntomas interesantes que muestran que una sociedad está en decadencia: el avance tecnológico para la comodidad y la expansión militar (conquista de otros países, normalmente debida a control militar de la civilización).


Pero esto ya son ideas, y no experiencias, que era de lo que yo venía a contaros hoy, y para ideas ya hay otros que saben más que yo…


Javier Solá – Madrid (de paso) – 14 de Mayo de 2006

					

		
		
	

							
	

				

			
						

				Blog Day 2007
			

										

					7 respuestas				

					


				

			

31 de Agosto.


Mi cumpleaños y … Blog Day.


Vamos a ver los blogs que he seleccionado hoy:


    

  • La Libreria.
    
Blog literario (bien escrito), sobre literatura (una de las referencias permanentes del blog), arte y reflexiones personales.
    • 

  • Godel,Escher,Bach
    
Blog seleccionado por hacer referencia al libro  de Douglas R. Hofstadter: Gödel, Escher, Bach  an Eternal Golden Braid (un Eterno y Grácil Bucle).
    • 

  • Ciencia para impacientes.
    
Bitácora dedicada a la divulgación científica y la interacción entre ciencia y sociedad.
    • 

  • Física en la Ciencia Ficción
    
Blog de Sergio L. Palacios dedicado a la difusión y divulgación de la Física utilizando la Ciencia Ficción como disculpa. Sergio posee una personalidad dual. En ocasiones es como las ondas y puede interferir y difractarse. Otras veces, en cambio, es como las partículas y colisiona con lo que se le ponga por delante.
    • 

  • Blog de Notas.
    
Blog colectivo con curiosidades, matemáticas y reflexiones tecnológicas. Saben que es el Geocaching
    • 



Además, sobre este tema escribí hace unos dias y el año pasado.


Actualización. Veo que Pedro Solbes también cumple años el 31 de agosto (65 en esta ocasión).

					

		
		
	

							
	

				

			
						

				Recursos para desarrolladores de proyectos de firma electrónica
			

										

					1 respuesta				

					


				

			

Gracias a Luis Molina tenemos un punto de contacto para compartir recursos de programación en torno a la firma y a la factura electrónicas.


Se trata del Proyecto Certificados alojado en Google Code.


El ya ha dejado alguna información para .net, y está abierto a otras colaboraciones.


Podéis acceder a http://code.google.com/p/certificados/downloads/list

					

		
		
	

							
	

				

			
						

				Revista del Colegio de Registradores Mercantiles y de la Propiedad
			

										

					2 respuestas				

					


				

			

Revista RegistradoresEl Colegio de Registradores de la Propiedad y Mercantiles de España publica una interesante revista cuyos números anteriores pueden descargarse on-line (ir a +servicios > Prensa > Revista Registradores) en formato PDF.


Por cierto, en su web incluyen una referencia a la pasada celebración del Tercer Congreso de Registradores que tuvo lugar desde el pasado 30 de octubre hasta el 1 de noviembre de 2006.  Aunque la navegación es compleja, es posible acceder a las ponencias y comunicaciones presentadas, y a algunas intervenciones en video.

					

		
		
	

							
	

				

			
						

				PDF 417 y Facturas Electrónicas
			

										

					6 respuestas				

					


				

			

https://inza.wordpress.com/2006/09/14/pdf-417-que-es-y-para-que-sirve/Hace algún tiempo escribí el post «PDF 417 ¿qué es y para qué sirve?» que ha logrado cierta popularidad.


Uno de los motivos de que se lleve a cabo la búsqueda del término PDF-417 en Google es sin duda la referencia a este tipo de codificación en la norma HAC-3134/2002 (hoy derogada) y en la EHA-962/2007 (precisamente la norma que la deroga).


Lo cierto es que no es complicado generar códigos de barras PDF-417, y para ello existen diferentes mecanismos, algunos de ellos gratuitos como el servicio de Jaxo Systems.


Sin embargo el problema aparece por la mayor complejidad de volver a obtener el documento electrónico original que es el que debe estar disponible en caso de auditoria o inspección tributaria (lo que exige contar con un lector de código de barras adecuado).


En realidad la utilidad del PDF 417 solo se da en el caso de que quisiéramos descartar el fichero recibido que contiene la factura electrónica (y su correspondiente firma electrónica), pero desde luego hay que reconocer que es más fácil conservar el fichero en otros soportes (memoria USB, CD-ROM, diskette,…) que en papel (que además es proclive a manchas, goterones, transferencias de tinta a la hoja contigua y otros  incidentes que pueden dificultar la lectura del papel) .


Y tampoco la manipulación del papel es más fácil que la de otros soportes. Intente resolver este reto: lea el código de barras que adunto a este post. Independientemente de que lo logre o no, ese es el reto a resolver cada vez que debamos gestionar una factura electrónica en papel: primero imprimirla con ese código, luego guardarla en papel de forma que se facilite su búsqueda, y depués ser capaz de leerla del papel e interpretarla para obtener el fichero original. 


Demasiado esfuerzo si solo queremos disponer de una hoja de papel con el contenido de la factura como evidencia en otras instancias. Porque está claro que si el contenido de la factura se puede leer en un papel, la presunción de validez se aproxima al 100%, independientemente de los detalles técnicos. Sin embargo, estos detalles técnicos que en un primer vistazo se ignoran,  al final son lo más importantes.


Pero hay otra solución prevista en el Artículo 6 de la Orden EHA-962/2007


(…)


5. Cuando el emisor y/o receptor de facturas y documentos sustitutivos electrónicos sea un tercero que actúa en nombre y por cuenta de los obligados tributarios, deberá cumplir con los requisitos expresados anteriormente. No obstante, cumplidos éstos, podrán poner a disposición de sus clientes aplicaciones informáticas que gestionen un repositorio de facturas y documentos sustitutivos emitidos o recibidos, según corresponda, junto con la firma electrónica generada o verificada en los términos de esta Orden, proporcionando un código de autenticación de mensajes asociado a cada documento. Este código permitirá el acceso al documento asociado existente en el repositorio y garantizará, al que accede, que cumple con los requisitos contemplados en esta Orden.


En el supuesto del párrafo anterior, un documento impreso a papel con este código es válido, como en el artículo 8, siempre que se mantenga el mencionado repositorio en el que se encuentra el documento y su firma electrónica, exista un mecanismo de verificación de la firma en el mismo y se pueda acceder de forma completa al documento mediante dicho código electrónico de autenticación.


Y en mi opinión, esta es la mejor solución: indicar en la factura impresa la URL o el LOCALIZADOR del documento electrónico del que procede la factura en papel. Así se cuenta con la misma validez intuitiva que puede aportar la impresión con PDF-417, pero la conversión a electrónico es inmediata, accediendo a la fuente, de forma que cualquiera puede cotejar el contenido del papel con el del documento electrónico.


(Adjunto seguidamente el artículo 8 en donde se explica la «otra» forma de conservar facturas electrónicas en papel, la del PDF 417)


Artículo 8. Impresión de facturas y documentos sustitutivos remitidos en formato electrónico.


En general, las facturas y documentos sustitutivos remitidos electrónicamente deben ser conservados por los destinatarios en el mismo formato electrónico de remisión, sin conversión alguna, junto con los medios que garanticen su autenticidad de origen e integridad del contenido. No obstante, cuando los documentos sean remitidos por medios electrónicos y firmados con firma electrónica en los términos de los artículos anteriores de esta Orden, los contribuyentes destinatarios que deseen conservarlas de forma impresa en papel, después de verificada la firma, podrán realizar dicha conversión de soporte mediante la correspondiente opción de software que permita la impresión a papel, junto a los contenidos del documento, de dos conjuntos de códigos PDF-417, considerados como sendas marcas gráficas de autenticación, en el primero de los cuales se incluirá íntegramente el contenido de los datos de la factura o documento sustitutivo, tal y como fueron firmados en su expedición, y en el segundo la firma electrónica del fichero anterior y todos los elementos que de forma estandarizada permitan, previa lectura, la verificación de la firma. En el supuesto de estar la firma electrónica embebida en el fichero que contiene la factura o documento sustitutivo o de que los datos del documento estén contenidos en el formato de firma electrónica, bastará con la impresión de un solo conjunto de marca gráfica que incluya todos los datos del fichero o formato de firma electrónica. 

					

		
		
	

							
	

				

			
						

				La CAN abrirá 92 sucursales en poco más de un año y tendrá el 60% de su red fuera de Navarra
			

										

					Deja un comentario				

					


				

			

Caja Navarra adelantará la expansión prevista en su plan estratégico 2007-2010, con la apertura de 92 nuevas sucursales para final de 2008 y la entrada en cuatro nuevas comunidades: Andalucía, Levante, Galicia y Asturias. Su objetivo es «consolidarse» como una entidad «con cobertura nacional». Su red alcanza ya al 70% de la población y llegará al 90%.


Expansión de la CAN en 2008

La caja navarra se halla embarcada en un ambicioso plan de expansión desde 2005, que ha ido intensificando sobre la marcha en los últimos años. En 2006, decidió incorporar en el punto de mira al País Vasco, donde ya cuenta con 38 oficinas. Ahora pretende echar el resto, con la apertura de 92 oficinas entre lo que resta de 2007 y el próximo año. Cuarenta de ellas se ubicarán en la comunidad vecina.


El plan estratégico prevé implantar cerca de 200 oficinas en cuatro años. Partiendo de las 319 que tenía en 2006, el objetivo es alcanzar las 510 sucursales a final de 2010. Esta expansión, que habitualmente se hace con la compra y equipamiento de locales en propiedad, supondrá una inversión de 600 millones de euros (según la entidad, la está financiando con las plusvalías de su Corporación) y la contratación de 700 trabajadores, hasta situar la plantilla en 2.500 personas.


La Can concentrará el grueso de las aperturas en los próximos 16 meses, con la inauguración de 92 nuevas sucursales, hasta sumar 437, ya que ha decidido «acelerar en un 50%» su plan de expansión. Además del País Vasco, profundizará su presencia en Madrid, donde abrirá 7 nuevas sucursales; Cataluña, con 14 locales más; Aragón, donde la Caja centra su implantación en la provincia de Zaragoza, con otras 5 oficinas, y La Rioja, donde pese a tener ya una «saturación importante» de red, sumará una oficina más a las 16 que ya tiene.


Pero durante el próximo año, la Can quiere dar también el salto, con su nuevo modelo de oficinas y banca cívica, a otras cuatro comunidades. Así, entrará en Andalucía, con 3 sucursales; Galicia, con 3 oficinas; Asturias, con 5 y Levante, con 14. La Can había proyectado introducirse en la comunidad mediterránea en 2007, pero antes de abordar una nueva zona ha preferido digerir el frenético ritmo de aperturas de estos años. En Galicia, Andalucía y Asturias la red será de oficinas representativas en capitales de provincias y ciudades importantes.


«El motivo fundamental por el que aceleramos la expansión es que se ha demostrado que nuestro modelo diferencial funciona. Es verdad que el mercado está saturado. Pero nosotros ofrecemos otra cosa», indica Guillermo Catalán, director de Comunicación de la Caja, en alusión a las «canchas». Según la Caja, este tipo de oficinas son más eficientes ya que facturan más y recortan el tiempo en que llegan a ser rentables.


País Vasco, con 78 «canchas» abiertas en 3 años, será la segunda región con más presencia


El mayor peso de las nuevas aperturas tendrá lugar en el País Vasco, donde la entidad, que inició su implantación en la comunidad vecina en 2006, ya cuenta con 38 sucursales. Inicialmente, Can se propuso abrir 50 oficinas en las tres provincias vascas hasta 2008. Sin embargo, el nuevo plan prevé que sean 78 las oficinas que instale allí para el próximo año. El País Vasco se convertirá así, en tan solo tres años, en la segunda comunidad con mayor implantación de la Can después de Navarra.


En este tiempo, los directivos de Caja Navarra han reiterado la buena acogida que les han brindado a la entidad en la comunidad limítrofe, donde el negocio «va muy bien» tanto por su volumen de población, actividad empresarial, su alto nivel de renta, así como afinidad territorial y de negocios.


Además, al haber sido la última donde se han estrenado, es la «única» donde todas las oficinas son «canchas», diseñadas conforme al nuevo concepto de oficina de barrio y participativa, que cede sus locales a los clientes para uso propio (leer prensa, tomarse un café, navegar por internet o participar en espectáculos).

					

		
		
	

							
	

				

			
						

				Ofertas de trabajo (Ruby on Rails, Java, XML, SOA)
			

										

					3 respuestas				

					


				

			

Estos días estamos reclutando programadores y otros perfiles en Albalia Interactiva.


Si lees el blog y ves la página de Albalia, ya sabes más o menos a qué nos dedicamos.


Si te gustan estos temas y no te importa trabajar duro, estamos deseando recibir tu Curriculum Vitae.


En principio, los puestos de trabajo están en Madrid, pero no descartamos candidaturas para nuestra Delegación de Barcelona que dirige Santi Casas. 

					

		
		
	

							
	

				

			
						

				Free Lotto y otros fraudes de loterías
			

								


				

			

Muchas personas acceden a este Blog buscando información sobre supuestos sorteos que aparecen en mensajes de e-mail que reciben. A pesar de las explicaciones que he ido poniendo, y que otros lectores han ido enriqueciendo siguen preguntando si su caso concreto tiene premio o no.


De hecho, algunos de los posts de este blog se han hecho muy populares gracias a Google, en función de esa duda ilusionada de muchas personas que reciben los mails fraudulentos y tras ellos investigan términos de su email en buscadores.



Los comentarios que ponen en el blog son siempre agradecidos por el autor, pero no puedo atenderlos todos de forma individualizada.


Por favor, lean lo que ya está escrito y no dejen preguntas personales ni escriban su dirección de e-mail porque los delincuentes utilizan programas automáticos para captar direcciones de e-mail de todo tipo de páginas web.


Respecto a Free Lotto, es cierto que hubo una empresa Free Lotto que se caracterizaba por su marketing agresivo. Permitían jugar en sorteos a cambio de ver publicidad. Aunque sus técnicas de marketing son ilegales en la mayor parte del mundo, la empresa aparentemente existe y podría ser legal en Estados Unidos.


Sin embargo, no solo con el nombre de Free Lotto, sino con el de muchas organizaciones legales de loterías (como «Lotería Nacional», «El Gordo» y otras) y a veces inventándose sorteos falsos (de Microsoft, Google, Yahoo y otras marcas conocidas), ciertos delincuentes ofrecen premios con técnicas de SCAM nigeriano, de forma que hay que dar ciertos datos y hacer ciertos pagos para liberar el supuesto premio.


Estos premios no existen.


La regla de oro es: Si usted no la jugado en una lotería, es imposible que le haya correspondido un premio.


De modo que la probabilidad de que el correo que ha recibido sea un fraude es del 100%.


Incluso si ha jugado de verdad en cualquier tipo de juego (lo cual debería saber, ya que deberá conservar el billete de lotería o el el justificante de haber pagado por su participación, y conocerá la fecha de celebración del sorteo y el local en el que realizó la adquisición), la probabilidad de obtener un premio es muy baja y ninguna organización confirma los premios individualmente: usted deberá comprobar en la publicación de premios si su participación resulta agraciada.


Nunca informe de datos personales, especialmente financieros y nunca realice ningún tipo de pago incitado por mensajes de correo electrónico.


Nunca haga click en enlaces que vengan en un correo electrónico, especialmente si es para acceder a un formulario en el que haya que introducir ningún tipo de dato, como nombre, número de cuenta o de tarjeta VISA o MAsterCArd, código de usuario o clave.


Se puede hacer «phishing» de muchas maneras.


Y un último ruego: en los mensajes intenten cuidar la ortografía. Aunque fallos los tenemos todos, y yo puedo editar los mensajes que ustedes dejan, a veces  recibo mensajes horrorosos que no me queda más remedio que borrar.

					

		
		
	

							
	

				

			
						

				Orden EHA/1077/2005, de 31 de marzo, por la que se establecen los formatos y especificaciones de los medios informáticos y telemáticos para la remisión de datos de contratos al Registro Público de Contratos
			

										

					1 respuesta				

					


				

			

Tras el post de ayer, no se puede dejar de mencionar laOrden EHA/1077/2005, de 31 de marzo, por la que se establecen los formatos y especificaciones de los medios informáticos y telemáticos para la remisión de datos de contratos al Registro Público de Contratos.


(versión obtenida en Noticias Jurídicas)


El Texto refundido de la Ley de Contratos de las Administraciones Públicas, aprobado por el Real Decreto Legislativo 2/2000, de 16 de junio, establece el Registro Público de Contratos de la Junta Consultiva de Contratación Administrativa como instrumento de soporte de la estadística sobre contratación pública para fines estatales, para permitir el conocimiento de los contratos celebrados por las distintas Administraciones públicas, imponiendo a todos sus órganos de contratación la obligación de remitir a la Junta Consultiva de Contratación Administrativa la información sobre los contratos reglamentariamente determinada, a efectos del cumplimiento de la normativa internacional.


Por otra parte, las Directivas de la Unión Europea sobre coordinación de los procedimientos de adjudicación de contratos imponen a todos los Estados miembros de la Unión Europea la obligación de comunicar los datos básicos de los contratos adjudicados por los poderes adjudicadores contemplados en ellas, constituyendo el Registro Público de Contratos la fuente de información para el cumplimiento de dicha obligación.


Las previsiones de la Ley de Contratos de las Administraciones Públicas relativas al Registro Público de Contratos fueron desarrolladas por el Reglamento general de la Ley de Contratos de las Administraciones Públicas, aprobado por el Real Decreto 1098/2001, de 12 de octubre, estableciendo en su artículo 114 el contenido del Registro, y en su artículo 115 y Anexo IX la forma de remisión de datos, tanto por los órganos de contratación de las distintas Administraciones públicas y entidades obligadas como por los Registros Públicos de Contratos de las Comunidades Autónomas y de las entidades Locales que los hubieran establecido en su ámbito de competencia.


Al objeto de facilitar tanto el procesamiento automatizado del gran volumen de información a recoger, como su tratamiento homogéneo, consolidación y análisis, el citado artículo 115 del Reglamento prevé su remisión por medios informáticos con formatos y especificaciones normalizados, establecidos por Orden del Ministro de Hacienda.


Por otra parte, la diversidad de órganos, Administraciones y entidades obligadas a remitir sus datos sobre los contratos adjudicados y las incidencias que en ellos se produzcan, con organización, infraestructura informática y volumen de información a transmitir muy dispares, hace necesario proporcionar mecanismos alternativos de remisión de datos, que faciliten tanto la notificación en línea de los datos de uno o varios contratos como el envío masivo de todos los adjudicados en un determinado período.


Con tal finalidad, se han desarrollado dos aplicaciones funcionalmente equivalentes, que facilitan la generación de archivos de notificación de contratos conformes con los formatos y especificaciones que son objeto de aprobación por la presente Orden. La primera, que exige conexión a Internet, permite la cumplimentación y remisión en línea de la notificación de los datos de los contratos. La segunda aplicación, que se ejecuta de modo autónomo en cualquier ordenador, permite la generación de los archivos de notificación de contratos conforme con los formatos y especificaciones establecidas, para su posterior remisión a la Junta Consultiva de Contratación Administrativa. Sin perjuicio de ello, los órganos de contratación podrán utilizar cualquier otra aplicación o herramienta informática de su elección, siempre que el formato y especificaciones del archivo generado se ajuste a los establecidos en la presente Orden.


La habilitación para la determinación del formato y especificaciones de los medios informáticos a utilizar para la remisión de los datos de los contratos adjudicados, que el artículo 115 del Reglamento general de la Ley de Contratos de las Administraciones Públicas defiere al Ministro de Hacienda, debe entenderse en la actualidad conferida al Ministro de Economía y Hacienda, de acuerdo con lo dispuesto en el artículo 5 del Real Decreto 553/2004, de 17 de abril, por el que reestructuran los departamentos ministeriales.


En su virtud, previo informe de la Junta Consultiva de Contratación Administrativa, dispongo:


Primero. Objeto y ámbito de aplicación.


Uno. La presente Orden tiene por objeto establecer, al amparo de lo dispuesto en el artículo 115 del Reglamento general de la Ley de Contratos de las Administraciones Públicas, aprobado por el Real Decreto 1098/2001, de 12 de octubre, el formato y especificaciones de los medios informáticos a emplear por los órganos de contratación, así como por los titulares de los Registros Públicos de Contratos de las Comunidades Autónomas y Entidades locales, para la remisión de los datos indicados en el artículo 114 del citado Reglamento y en su Anexo IX.


Dos. Quedan sujetos a dicho formato y especificaciones las comunicaciones relativas a los contratos que se adjudiquen con posterioridad al 1 de enero de 2005 que no hayan sido efectuadas a la fecha de entrada en vigor de la Orden.


Segundo. Formato y especificaciones de las comunicaciones.


Uno. Las comunicaciones de los datos indicados en el artículo 114 y en el Anexo IX del Reglamento general de la Ley de Contratos de las Administraciones Públicas se ajustarán al formato y especificaciones establecidas en el Anexo I.


Dos. El Ministerio de Economía y Hacienda mantendrá en su página web una aplicación informática, que permitirá la comunicación telemática, a través de Internet, de los datos de los contratos adjudicados, así como sus modificaciones, prórrogas o resolución.


Las comunicaciones efectuadas mediante el uso de dicha aplicación se tendrán por válidas y conformes con el formato y especificaciones establecidas a partir del momento en que la aplicación confirme su correcta recepción por la Junta Consultiva de Contratación Administrativa.


Los requisitos técnicos necesarios para la utilización de esta aplicación informática estarán permanentemente disponibles en la página web del Ministerio de Economía y Hacienda.


Tres. El Ministerio de Economía y Hacienda mantendrá igualmente en su página web una aplicación informática que permitirá la generación, de modo autónomo, de los archivos de notificación de datos de contratos que resulten necesarios, con formato y especificaciones conformes con las establecidas en la presente Orden, para su posterior remisión a la Junta Consultiva de Contratación Administrativa.


Los requisitos técnicos necesarios para la utilización de esta aplicación informática estarán permanentemente disponibles en la página web del Ministerio de Economía y Hacienda.


Cuatro. Sin perjuicio de lo establecido en los puntos dos y tres de este apartado, los órganos y entidades a los que se refiere el artículo 115 del Reglamento general de la Ley de Contratos de las Administraciones Públicas podrán utilizar cualquier programa informático de su elección para la generación de los archivos de notificación de datos de contratos, siempre que éstos se ajusten al formato y especificaciones establecidos en el punto Uno de este mismo precepto.


Tercero. Procedimiento de remisión de las comunicaciones.


Uno. Siempre que las comunicaciones se efectúen por un procedimiento distinto del descrito en el punto Dos del apartado Segundo, el archivo conteniendo las notificaciones de los contratos se remitirá por correo electrónico, dirigido al buzón de notificaciones del Registro Público de Contratos, ajustándose a las especificaciones establecidas en el Anexo II.


Dos. Cuando, por razón del tamaño del archivo u otras causas excepcionales, no sea posible su remisión por correo electrónico, el archivo conteniendo la información de los contratos adjudicados, modificados o resueltos será remitido a la Junta Consultiva de Contratación Administrativa en soporte magnético u óptico normalizado, de acuerdo con las especificaciones establecidas en el Anexo III, junto con el correspondiente escrito de remisión del órgano o autoridad que efectúa la notificación.


Cuarto. Entrada en vigor.


La presente Orden entrará en vigor al día siguiente de su publicación.


Madrid, 31 de marzo de 2005.


Solbes Mira.


ANEXO I.

FORMATO Y ESPECIFICACIONES DE LOS ARCHIVOS DE COMUNICACIÓN DE DATOS.


1. Juego de caracteres: ISO/IEC – 8859 – 1 («latin alphabet – 1»).


2. Formato: conforme con XML 1.0 (W3C Recommendation de 4 de febrero de 2004).


3. Estructura y codificación del archivo a remitir.


    

  •  

      

    •  

        <nombre>Nombre del usuario que envía la información </nombre>
        

        <apellido1>Primer apellido del usuario </apellido1>
        

        <apellido2>Segundo apellido del usuario </apellido2>
        

        <cargo>Cargo del usuario</cargo>
        

        <direccion>Dirección postal del organismo</direccion>
        

        <provincia>Codigo de la provincia (Tabla 5)</provincia>
        

        <municipio>Código del municipio (Tabla 7)</municipio>
        

        <codPostal>Código postal</codPostal>
        

        <telefono>Número de teléfono</telefono>
        

        <fax>Número de Fax</fax>
        

        <mail>Correo electrónico</mail>
      

        <tipoAdmin>Código de tipo de Administración (Tabla 1)</tipoAdmin>
        

        <tipoAdminLocal>Código de tipo de Administración Local (Tabla 2) Sólo si los contratos son de una Entidad Local</tipoAdminLocal>
      

      • 

      <usuario>
      

      </usuario>
      

      <RegistrosEnviados>Número de contratos que se envian en la remesa </RegistrosEnviados>
    

      

    •  

        

      •  

          

        •  

            <descripcion>Nombre del contratista </descripcion>
            

            <nacionalidad>Nacionalidad del contratista</nacionalidad>
          

          • 

          <contrato numero=»numero de contrato»>
          

          <tipoContrato>Tipo de contrato (Tabla 9)</tipoContrato>
          

          <provincia>Código de la provincia donde se realiza el contrato (Tabla 5) </provincia>
          

          <modalidad>Sólo en los contratos tipos B (Tabla 10)</modalidad>
          

          <objeto> objeto del contrato </objeto>
          

          <codigoCpa>Código Cpa del objeto del contrato (6 dígitos) </codigoCpa>
          

          <caracteristicaBienes>Solo en los contratos tipo C (Tabla 11) </caracteristicaBienes>
          

          <conMixto>si/no.No aplica en los contratos tipo F o I </conMixto>
          

          <conMarco>si/no. No aplica en los contratos tipo B, F o I </conMarco>
          

          <complementario>si/no. Sólo aplica en contratos tipo D </complementario>
          

          <publicidad>si/no</publicidad>
          

          <anuncioBoe>Fecha anuncio Boletín Oficial del Estado </anuncioBoe>
          

          <anuncioDOUE>Fecha anuncio Diario Oficial Unión Europea </anuncioDOUE>
          

          <anuncioBoca>Fecha anuncio Boletín Oficial Comunidad Autónoma </anuncioBoca>
          

          <anuncioBop>Fecha anuncio Boletín Oficial de la Provincia </anuncioBop>
          

          <tramite>Tipo de tramitación del expediente (Tabla 12) </tramite>
          

          <procedimientoAdjud>Procedimiento de adjudicación (Tabla 13) </procedimientoAdjud>
          

          <procNegArticulo>Artículo y apartado de la LCAP por el que se aplica procedimiento negociado </procNegArticulo>
          

          <procNegSubapartado>Subapartado de la LCAP por el que se aplica procedimiento negociado </procNegSubapartado>
          

          <invitaciones>Número de invitaciones </invitaciones>
          

          <formaAdjud>Forma de adjudicación (tabla 14)</formaAdjud>
          

          <importePresupuesto>Importe presupuesto licitación (en euros, sin puntuación ni decimales)</importePresupuesto>
          

          <plazo>De ejecución en meses</plazo>
          

          <plazoConcesion>en meses, sólo en los contratos de tipos B o H </plazoConcesion>
          

          <plurianual>Si/no</plurianual>
          

          <anualidad1>Importe para la primera anualidad, sin puntuación ni decimales </anualidad1>
          

          <anualidad2>Importe para la segunda anualidad, sin puntuación ni decimales </anualidad2>
          

          <anualidad3>Importe para la tercera anualidad, sin puntuación ni decimales </anualidad3>
          

          <anualidad4>Importe para la cuarta anualidad, sin puntuación ni decimales </anualidad4>
          

          <anualidad5>Importe para la quinta anualidad, sin puntuación ni decimales </anualidad5>
          

          <revisionPrecios>Si/no </revisionPrecios>
          

          <formulaTipo>Numero que identifica la fórmula tipo de revisión de precios aplicada (sólo para contratos de obras)</formulaTipo>
          

          <contratista nif=»Nif del contratista»>
          

          </contratista>
          

          <paisOrigen>Código ISO del pais de origen de los productos, en los contratos de suministro</paisOrigen>
          

          <fechaAdjudicacion>Fecha de adjudicación</fechaAdjudicacion>
          

          <importeAdjudicacion>Importe de adjudicación (en euros, sin decimales ni puntuación)</importeAdjudicacion>
          

          <esIngreso>si/no (Sólo en contratos tipo I)</esIngreso>
          

          <modalidadImporte>Sólo en contratos tipo B o H (Tabla 15) </modalidadImporte>
          

          <valorModalidad>Sólo en contratos tipo B o H</valorModalidad>
          

          <unidadModalidad>Sólo en contratos tipo B o H</unidadModalidad>
          

          <aportacionAdministracion>Sólo en contratos tipo B o H </aportacionAdministracion>
          

          <fechaFormalizacion>Fecha de formalización del contrato </fechaFormalizacion>
          

          <observaciones>Observaciones</observaciones>
          

          </contrato>
        

        • 

        <organoContratante codigoOrganoContratante=»xxxxx» nombreOrganoContratante=»nombre del órgano, organismo o ente contratante» (Nota 3)>
        

        </organoContratante>
      

      • 

      <departamento codigoDepartamento=»nn» (Código del Ministerio, Consejería o Departamento asignado en los Presupuestos del año del contrato) nombreDepartamento=»nombre Ministerio, Consejería o Departamento» (Nota 2)>
      

      </departamento>
    

      

    •  

        <nombre>Nombre del usuario que envía la información </nombre>
        

        <apellido1>Primer apellido del usuario </apellido1>
        

        <apellido2>Segundo apellido del usuario </apellido2>
        

        <cargo>Cargo del usuario</cargo>
        

        <direccion>Dirección postal del organismo</direccion>
        

        <provincia>Codigo de la provincia (Tabla 5)</provincia>
        

        <municipio>Código del municipio (Tabla 7)</municipio>
        

        <codPostal>Código postal</codPostal>
        

        <telefono>Número de teléfono</telefono>
        

        <fax>Número de Fax</fax>
        

        <mail>Correo electrónico</mail>
      

        <tipoAdmin>Código de tipo de Administración (Tabla 1)</tipoAdmin>
        

        <tipoAdminLocal>Código de tipo de Administración Local (Tabla 2) Sólo si los contratos son de una Entidad Local</tipoAdminLocal>
      

      • 

      <usuario>
      

      </usuario>
      

      <RegistrosEnviados>Número de contratos que se envian en la remesa </RegistrosEnviados>
    

      

    •  

        

      •  

          

        •  

            <articuloAplicado>Artículo LCAP aplicado en la resolución si la hubiere </articuloAplicado>
            

            <apartadoAplicado>Apartado LCAP aplicado en la resolución si la hubiere </apartadoAplicado>
            

            <causaResolucion>Motivo de la resolución si la hubiere</causaResolucion>
            

            <fechaAcuerdoRes>Fecha acuerdo resolución</fechaAcuerdoRes>
            

            <modifImporte>Importe de todas las modificaciones realizadas </modifImporte>
            

            <modifPlazo>Incremento total de plazo por todas las modificaciones realizadas</modifPlazo>
            

            <perdidaGarantia>si/no</perdidaGarantia>
            

            <resolucionContrato>si/no</resolucionContrato>
          

          • 

          <modificacionContrato numero=»Número del contrato» numeroMod=»Número de la modificación»>
          

          </modificacionContrato>
        

        • 

        <organoContratante codigoOrganoContratante=»xxxxx» nombreOrganoContratante=»nombre del órgano, organismo o ente contratante» (Nota 3)>
        

        </organoContratante>
      

      • 

      <departamento codigoDepartamento=»nn» (Código del Ministerio, Consejería o Departamento asignado en los Presupuestos del año del contrato) nombreDepartamento=»nombre Ministerio, Consejería o Departamento»(Nota 2)>
      

      </departamento>
    

      codEnteContratante: código de la Administración pública o Entidad contratante, de acuerdo con la tabla de códigos que corresponda por su naturaleza o tipo (Tablas 3 a 8).
      

      En el caso de la Administración General del Estado, se asignará el valor «0».
      

      En el caso de Mancomunidades o Consorcios, se asignará su código en el Registro de Entidades Locales.
      

      En el caso de empresas, se asignará su CIF, prescindiendo de la letra.
      

      nombreEnteContratante: se incorporará la denominación oficial de la Administración pública o Entidad contratante. En el caso de órganos de la Administración General del Estado, se tomará el valor «Estado».
    

      Sólo aplicable a la Administración General del Estado y a las de las Comunidades Autónomas.
      

      Para cada Ministerio, Departamento o Consejería se usará la codificación asignada en los respectivos presupuestos anuales y su denominación oficial.
    

      Aplicable a todos los casos.
      

      Se usará la codificación y denominación oficiales que en cada caso corresponda.
      

      Si la Entidad que notifica los contratos sólo tiene un órgano contratante, se podrá asignar, por defecto, el valor «1» al atributo codigoOrganoContratante.
    

    • 

    3.1. Adjudicaciones de contratos.
    

    Este esquema se utilizará para enviar información relativa a adjudicaciones de contratos. Se podrán notificar tantos contratos como se deseen en un único archivo. Únicamente se tendrá que repetir tantas veces como contratos se envíen los datos comprendidos entre las etiquetas <contrato …> y </contrato>.
    

    En caso necesario, dentro de cada contrato se podrán introducir los datos de más de un adjudicatario, repitiendo la información comprendida entre las etiquetas <contratista …> y </contratista>.
    

    ESTRUCTURA DEL FICHERO.
    

    <?xml version=»1.0″ encoding=»iso-8859-1″?>
    

    <dgp_sitt_schema anio=»Año del contrato»>
    

    <cabecera>
    

    </cabecera>
    

    <enteContratante codEnteContratante=»nnnnnnnn» nombreEnteContratante=»nombre de la Administración pública o Entidad contratante» (Nota 1)>
    

    </enteContratante>
    

    </dgp_sitt_schema>
    

    3.2. Modificaciones, prórrogas y resoluciones de contratos.
    

    Este esquema se utilizará para enviar información relativa a las modificaciones, prórrogas y resoluciones de contratos cuya adjudicación ya fue comunicada. Se podrán notificar tantos contratos como se deseen en un único archivo. Únicamente se tendrá que repetir tantas veces como contratos se envíen los datos comprendidos entre las etiquetas <contrato …> y </contrato>.
    

    ESTRUCTURA DEL FICHERO.
    

    <?xml version=»1.0″ encoding=»iso-8859-1″?>
    

    <dgp_sitt_schema anio=»Año del contrato»>
    

    <cabecera>
    

    </cabecera>
    

    <enteContratante codEnteContratante=»nnnnnnnn» nombreEnteContratante=»nombre de la Administración pública o Entidad contratante» (Nota 1)>
    

    </enteContratante>
    

    </dgp_sitt_schema>
    

    3.3. Reglas de cumplimentación.
    

    

    
DATO
TIPO, TAMAÑO Y REGLAS DE CUMPLIMENTACIÓN

    

    
Anio:
Numérico de 4 dígitos.

    

    
Nombre:
Alfanumérico de 50 posiciones.

    

    
Apellido1:
Alfanumérico de 50 posiciones.

    

    
Apellido2:
Alfanumérico de 50 posiciones.

    

    
Cargo:
Texto libre de 100 posiciones.

    

    
Direccion:
Alfanumérico de 50 posiciones.

    

    
Provincia:
Numérico de 2 dígitos, compuesto según la codificación oficial del Instituto Nacional de Estadística.

    

    
Municipio:
Numérico de 4 dígitos, compuesto según la codificación oficial del Instituto Nacional de Estadística.

    

    
CodPostal:
Numérico de 5 dígitos.

    

    
Telefono:
Numérico de 9 dígitos.

    

    
Fax:
Numérico de 9 dígitos.

    

    
Mail:
Alfanumérico de 50 posiciones.

    

    
tipoAdmin:
Tipo de Administración o entidad contratante (Tabla 1).

    

    
tipoAdminLocal:
Tipo de Administración Local contratante (Tabla 2).

    

    
enteContratante:
Ver Nota 1.

    

    
departamento:
Ver Nota 2.

    

    
OrganoContratante:
Ver Nota 3.

    

    
 
 

    

    
Numero de contrato:
Alfanumérico de 30 posiciones, permitiendo introducir además los siguientes caracteres: / – _ ( )

    

    
Objeto:
Texto libre de 120 posiciones.

    

    
CodigoCpa:
Numérico de 6 posiciones como máximo.

    

    
Fechas:
aaaa-mm-dd (10 posiciones).

    

    
Importes:
Numérico de 10 posiciones, sin puntuación ni decimales.

    

    
Plazo:
Numérico de 4 posiciones.

    

    
PlazoConcesion:
Numérico de 4 posiciones.

    

    
Plurianual:
Alfabético de 2 posiciones (si/no).

    

    
RevisionPrecios:
Alfabético de 2 posiciones (si/no).

    

    
FormulaTipo:
Numérico de 2 posiciones.

    

    
ConMixto:
Alfabético de 2 posiciones (si/no)

    

    
ConMarco:
Alfabético de 2 posiciones (si/no)

    

    
Complementario:
Alfabético de 2 posiciones (si/no)

    

    
Publicidad:
Alfabético de 2 posiciones (si/no)

    

    
ProcNegArticulo:
Alfanumérico de 5 posiciones: nnn.n

    

    
ProcNegSubapartado:
Alfanumérico de 2 posiciones

    

    
Invitaciones:
Numérico de 4 posiciones

    

    
ValorModalidad:
Numérico de 10 posiciones sin puntuación ni decimales.

    

    
UnidadModalidad:
Alfanumérico de 12 posiciones.

    

    
AportacionAdministracion:
Texto libre de 50 posiciones.

    

    
Observaciones:
Texto libre de 120 posiciones.

    

    
País:
Código alfabético de 2 posiciones, según norma ISO-3166-1:1997. (código de España = es).

    

    
 
 

    

    
Datos Contratistas:
 

    

    
Nif:
Carácter de 9 posiciones.

    

    
Descripcion:
Carácter de 120 posiciones.

    

    
Nacionalidad:
Código alfabético del país, de 2 posiciones, según norma ISO3166-1:1997. (código de España = es).

    

    

    3.4. Tablas.
    

    

    
TABLA 1
 

    

    
TIPO DE ADMINISTRACIÓN
 

    

    
 
 

    

    
CÓDIGO
TIPO

    

    
1
Órgano Constitucional

    

    
2
Estado

    

    
3
CCAA

    

    
4
Entidad Local

    

    
5
Otros

    

    
 
 

    

    
TABLA 2
 

    

    
TIPO DE ADMINISTRACIÓN LOCAL
 

    

    
 
 

    

    
CÓDIGO
TIPO

    

    
A
Ayuntamiento

    

    
C
Cabildo / Consell Insular

    

    
D
Diputación Provincial/Foral

    

    
M
Mancomunidad

    

    
X
Consorcio

    

    
 
 

    

    
TABLA 3
 

    

    
ÓRGANOS CONSTITUCIONALES
 

    

    
 
 

    

    
CÓDIGO
ÓRGANO

    

    
0100001
CASA S.M. EL REY

    

    
0200001
CORTES GENERALES

    

    
0200002
CONGRESO DE LOS DIPUTADOS

    

    
0200003
SENADO

    

    
0200004
JUNTA ELECTORAL CENTRAL

    

    
0200005
DEFENSOR DEL PUEBLO

    

    
0300001
TRIBUNAL DE CUENTAS

    

    
0400001
TRIBUNAL CONSTITUCIONAL

    

    
0500001
CONSEJO DE ESTADO

    

    
0800001
CONSEJO GRAL DEL PODER JUDICIAL

    

    
 
 

    

    
TABLA 4
 

    

    
COMUNIDADES AUTÓNOMAS
 

    

    
 
 

    

    
CÓDIGO
COMUNIDAD AUTÓNOMA

    

    
01
ANDALUCÍA

    

    
02
ARAGÓN

    

    
03
ASTURIAS

    

    
04
ILLES BALEARS

    

    
05
CANARIAS

    

    
06
CANTABRIA

    

    
07
CASTILLA-LA MANCHA

    

    
08
CASTILLA-LEON

    

    
09
CATALUÑA

    

    
10
EXTREMADURA

    

    
11
GALICIA

    

    
12
MADRID

    

    
13
MURCIA

    

    
14
NAVARRA

    

    
15
PAÍS VASCO

    

    
16
RIOJA

    

    
17
COMUNIDAD VALENCIANA

    

    
18
CEUTA

    

    
19
MELILLA

    

    
 
 

    

    
TABLA 5
 

    

    
PROVINCIAS/DIPUTACIONES PROVINCIALES Y FORALES
 

    

    
 
 

    

    
Se usarán los códigos numéricos de 2 dígitos asignados por el Instituto Nacional de Estadística para la codificación de las provincias.

    

    
 
 

    

    
TABLA 6
 

    

    
CABILDOS/CONSELLS
 

    

    
 
 

    

    
CÓDIGO
CABILDO/CONSELL

    

    
07006
CONSELL INSULAR IBIZA Y FORMENTERA

    

    
07008
CONSELL INSULAR MALLORCA

    

    
07009
CONSELL INSULAR MENORCA

    

    
35002
CABILDO FUERTEVENTURA

    

    
35004
CABILDO GRAN CANARIA

    

    
35007
CABILDO LANZAROTE

    

    
38003
CABILDO GOMERA, LA

    

    
38005
CABILDO HIERRO, EL

    

    
38010
CABILDO PALMA, LA

    

    
38011
CABILDO TENERIFE

    

    
 
 

    

    
TABLA 7
 

    

    
AYUNTAMIENTOS/MUNICIPIOS
 

    

    
 
 

    

    
Para la cumplimentación del campo «municipio» se usarán los códigos numéricos de 4 dígitos asignados por el Instituto Nacional de Estadística para la codificación de los municipios.

    

    
En el caso de contratos adjudicados por un Ayuntamiento, el campo «ayuntamiento» se formará con los 2 dígitos del código de la provincia seguidos de los 4 dígitos del código del municipio.

    

    
 
 

    

    
TABLA 8
 

    

    
MANCOMUNIDADES
 

    

    
 
 

    

    
Código alfanumérico de 8 posiciones, todas ellas obligatorias.

    

    
El código estará formado por el número de registro en el R.E.L.

    

    
 
 

    

    
TABLA 9
 

    

    
TIPO DE CONTRATO
 

    

    
 
 

    

    
CÓDIGO
TIPO

    

    
A
Obras

    

    
B
Gestión de servicios públicos

    

    
C
Suministros

    

    
D
Consultoría y asistencia

    

    
E
Servicios

    

    
F
Administrativos especiales

    

    
G
Sectores agua, energía, transportes y comunicaciones

    

    
H
Concesión Obras públicas

    

    
I
Privados

    

    
 
 

    

    
TABLA 10
 

    

    
MODALIDAD
 

    

    
 
 

    

    
CÓDIGO
MODALIDAD

    

    
C
(Concesión)

    

    
G
(Gestión Interesada)

    

    
M
(Concierto o sociedad de economía mixta)

    

    
 
 

    

    
TABLA 11
 

    

    
CARACTERISTICAS DE LOS BIENES
 

    

    
 
 

    

    
CÓDIGO
SIGNIFICADO

    

    
1
Entrega sucesiva y por precio unitario (Art. 172.1.a)

    

    
2
(Equipos, sistemas y programas TIC (Art. 172.1.b)

    

    
3
(Suministro de Fabricación (Art. 172.1.c)

    

    
4
(Otros)

    

    
 
 

    

    
TABLA 12
 

    

    
TRÁMITE
 

    

    
 
 

    

    
CÓDIGO
TRÁMITE

    

    
O
(Ordinario)

    

    
U
(Urgente)

    

    
E
(Emergencia)

    

    
 
 

    

    
TABLA 13
 

    

    
PROCEDIMIENTO ADJUDICACIÓN
 

    

    
 
 

    

    
CÓDIGO
PROCEDIMIENTO

    

    
A
(Abierto)

    

    
R
(Restringido)

    

    
N
(Negociado)

    

    
 
 

    

    
TABLA 14
 

    

    
FORMA ADJUDICACIÓN
 

    

    
 
 

    

    
CÓDIGO
FORMA ADJUDICACIÓN

    

    
C
(Concurso)

    

    
S
(Subasta)

    

    
N
(Otras)

    

    
 
 

    

    
TABLA 15
 

    

    
MODALIDAD IMPORTE
 

    

    
 
 

    

    
CÓDIGO
MODALIDAD

    

    
C
(Canon Global)

    

    
T
(Tarifas)

    

    
P
(Precios Unitarios)

    

    

    3.5. Notas.
    

    Nota 1. enteContratante.
    

    Nota 2. departamento.
    

    Nota 3. organoContratante.


ANEXO II.

Formato y especificaciones del mensaje de correo electrónico.


1. Formato del mensaje: se ajustará a los estándares SMTP/MIME.


2. Campo asunto: se rellenará con la palabra contratos, seguida del número indicativo del año de adjudicación de los contratos comunicados (con cuatro dígitos) y, si fuera aplicable, la letra T seguida del número cardinal del trimestre a que corresponden. Finalmente se incluirá el nombre de la Administración, Entidad u órgano a quien corresponden los contratos. Se dejará un espacio en blanco entre cada uno de los términos.


Ejemplos:


    contratos 2005 Comunidad Autónoma de XX
    

    contratos 2005 T2 Ministerio de Economía y Hacienda


3. Cuerpo del mensaje: podrá contener, opcionalmente, información complementaria descriptiva del envío que se efectúa.


4. Anexos: el mensaje llevará anexado únicamente el archivo con la información de los contratos que se comunican. El nombre del fichero se ajustará a las mismas reglas indicadas en el punto 2 para el campo asunto, sin dejar espacios en blanco, usando únicamente caracteres ASCII, y abreviando en caso necesario el nombre de la Administración, Entidad u órgano.


Ejemplos:


    contratos2005CAXX
    

    contratos2005T2MEconomiayHacienda


ANEXO III.

Formato de los soportes de datos.


1. Soporte magnético. Disquete magnético estándar de tres pulgadas y media y 1,44 Mb, con formato compatible MS-DOS.


2. Soporte óptico. CD-R estándar en formato conforme con la norma ISO-9660: 1988.