La contratación pública electrónica según PEPPOL (2)

Una vez identificada en la entrada anterior los componentes del proyecto PEPPOL, su visión general y su estructura de grupos de  trabajo, vamos a intentar exponer en esta entrada la visión funcional del proyecto. Para qué sirve, por qué se pone en marcha, cuáles son sus objetivos, que piezas utiliza de forma general y qué piezas pone a disposición de otros para que se utilicen. Cómo puedo utilizar estas piezas y qué sentido tienen en las propias decisiones que puedo tomar para implementar la contratación pública electrónica. (En este blog seguimos con la intención de difundir conocimiento que permita la reflexión y el análisis  pasar a la acción con mayores garantías de éxito – inversiones-).

Todas estas cuestiones, no siempre se pueden responder actualmente y las que se responden no siempre se responden en todas las iniciativas de la misma forma.  Aunque todas las cuestiones deben moverse hacia la dirección única de la interoperabilidad.

Estamos hablando mucho de interoperabilidad y empiezo a pensar que  también sería bueno tener  una entrada para poder poner los elementos de la interoperabilidad en claro y que todos tengamos en la cabeza las mismas cosas cuando hablamos de interoperabilidad

Antes de empezar recordamos las acciones fundamentales que hemos venido comentando:

Un Comprador (la Administración pública – cualquier administración pública), notifica a los medios de publicación (perfil de contrante, PLACE, DOUE, Boletines oficiales) que quiere adquirir un bien o servicio.  En esa publicación se recogen los elementos fundamentales:

  • Quién es la administración convocante qué publica y cuándo lo publica.
  • Qué quiere: pliegos de prescripciones técnicas
  • Cuándo y Dónde lo quiere (plazos y lugares de entrega)
  • Por cuánto dinero (precio de licitación, precios unitarios …)
  • Criterios de selección y exclusión de los proveedores: Que identificación y certificados requiere para admitir a los posibles licitadores que están dentro del mercado.
  • Criterios de adjudicación: Cuales son los valores y su peso que va a utilizar para adjudicar a los licitadores aceptados.

El mercado (todos los proveedores posibles de ese bien o servicio) tienen la capacidad de identificarse (criterios de selección y exclusión) ofrecer sus ofertas (técnica de producto) a un precio y demostrar  en que medida soportan y cumplen con  los criterios de adjudicación.  Este mercado (los proveedores) tiene que tener la capacidad de hacer todo esto en formato electrónico, para lo que precisa:

–         Acceso a la oferta pública de contratación de todas las administraciones, legalmente en todas las ofertas que están por encima de los umbrales, pero podría ser a toda la oferta completa.

–         Capacidad de producir y recabar todos los certificados atestados y apostillas que le requieren los criterios de selección y exclusión para poder identificar su empresa y sus representantes y ofrecer la capacidad de que la administración verifique su identidad y el cumplimiento de los citados criterios de selección y exclusión.

–         Transaccionar con la administración para por ejemplo (hay más tipos de transacciones):

  • Presentar una oferta (que incluye la identificación y cualificación de la empresa)
  • Subsanar los documentos que se requiera a petición de la administración convocante.
  • Asistir (virtualmente) a las aperturas de las ofertas  de los licitadores que se han presentado
  • Conocer las valoraciones sobre los criterios de adjudicación
  • Presentar las garantías como adjudicatarios y otras certificaciones (impuestos ..)
  • Firmar electrónicamente un contrato
  • Recibir pedidos
  • Cumplimentar bienes y servicios con albaranes de entrega
  • Presentar facturas al cobro
  • Recibir tiempos de pago previsto
  • Realizar reclamaciones en cualquier punto del proceso en los que considere que se han conculcado derechos propios de la empresa proveedora.

CUIDADO. Un proveedor que tenga la capacidad, formación, herramientas y conocimiento para relacionarse con una administración pública en formato electrónico, tiene que poder relacionarse con cualquier administración pública sin necesidad de utilizar otras herramientas, tener nueva formación, o utilizar capacidades distintas. Si no fuera así, estaríamos segmentando el mercado, o haciéndolo ineficiente por una mala gestión e implementación  de la interoperabilidad.

Por tanto cualquier proveedor debe tener la capacidad de:

–         Acceder a la oferta pública de contratación

–         Utilizar la Red Pública de Contratación que le permita conocer a quién y cómo dirigirse

–         Transaccionar con cualquier administración

–         E-identificación de la empresa y sus representantes

Para volver a utilizar el acrónimo del A.R.T.E. en la contratación pública para las empresas proveedoras.

Vamos con PEPPOL. (Visión personal fruto del estudio y la interpretación subjetiva, y por tanto sujeta a cambios)

Para qué sirve: Fundamentalmente para dotar de la capa de interoperabilidad necesaria a todos los proyectos de contratación pública electrónica que están surgiendo (algunos ya llevan tiempo) en Europa. Todos los proyectos que están en marcha no han tenido en cuenta (no han podido) los elementos de interoperabilidad necesarios para no generar islas de proceso. Esto ha provocado que ni las soluciones, ni sus herramientas sean universales (pan europeas). Es decir cuando una administración convoca al mercado en formato electrónico, solo puede convocar al mercado que conoce la solución tecnológica de la administración convocante. Esto produce el doble efecto de que el mercado (los proveedores) está acotado tecnológicamente, y además provoca que la administración convocante no consigue la mejor oferta posible, porque  no puede convocar a todo el mercado potencial.

Qué utilizar PEPPOL para esto.

Convocar al mercado se puede hacer a través de TED (tenders Electronic daily – Suplemento al Diario Oficial de las Comunidades Europeas), pero esta convocatoria, que puede permitir conocer las posibles ofertas, no permite realizar la identificación ni la transacción.

La parte del ACCESO a la oferta esta cubierta con TED y el DOUE, PLACE y los boletines oficiales. Es cierto que de momento ahí solo se recogen las publicaciones por encima de los umbrales. Pero por algo se empieza.

La parte de la Red Pública de Contratación es la que ha generado el proyecto PEPPOL con su grupo de trabajo de infraestructura de trasporte. Nos da acceso a la capacidad de transaccionar.

La parte de Transaccionar, son los estándares CEN BII que se están utilizando en PEPPOL para conseguir colocar en formato electrónico todos los diálogos y sus flujos que se producen en el proceso de contratatación, tanto en la fase de pre-adjudicación como en la fase de post-adjudicación.

La parte de de E-Identificación, es el que corresponde al grupo denominado VCD (Virtual Company Dossier) que es la parte que identifica de forma suficiente a cualquier empresa dentro del ámbito europeo en formato electrónico.  En el caso español esta función está cubierta por el ROLECE.

Que elementos aporta PEPPOL que puedo utilizar para la toma de decisiones.

Una vez más el problema (o la ventaja) está en que todo esto es voluntario. De hecho España no pertenece al consorcio de países participantes en PEPPOL. No conozco las razones.

No obstante. la aportación de PEPPOL personalmente me parece muy interesante y merecedora de tenerse muy en cuenta.

Constituye una red pública de contratación que puede ser panueropea o nacional. Esta red esta basada en internet y con una superestructura que permite su acceso a través de unos puntos de acceso que pueden ser suministrados por las propias administraciones o por iniciativas privadas.  La red no tiene coste para los integrantes de la red, aunque si alguna compañía da esos servicios de acceso a los proveedores puede lógicamente cobrarlos. Para dar estos servicios se requieren unos requisitos bastante fuertes de seguridad, rendimiento, fiabilidad….

Hay fórmulas muy sencillas para que las PYMES accedan a esta red con programas open source  en sus instalaciones de forma sencilla y sin costes gravosos (el  protocolo que se conoce como LIME, y que está incorporado en esa herramienta open source).

Ya tenemos los principales puntos que puede aportar PEPPOL.

–         Red pública

–         Herramientas de Software libre que puedo utilizar para acceder a la red pública y cambiar para incorporar los elementos de personalización que considere.

–         Capacidad para que cualquier administración acceda al mercado y para que cualquier proveedor acceda a cualquier administración.

Analizamos ahora como se pueden utilizar estas herramientas para conseguir el acceso al mercado de forma interoperable.

Para ello seguimos utilizando la presentación del propio Director de Peppol en la conferencia de Troyes Francia.

En la imagen siguiente  se puede apreciar cómo se puede conseguir. Es una simplificación, por favor no intentéis casarlo al pie de la letra con un procedimiento normal, solo pretende describir la funcionalidad de la red, las herramientas que se han generado y los estándares. Todo ello para dotar al sistema en su conjunto de la interoperabilidad que se busca.:

Ejemplo de un proceso de pre-adjudicación simplificado

Preparando la publicación del anuncio

La administración:

1.- la autoridad contraten hace una lista con los criterios de selección y exclusión

2.- Especifica los bienes y servicios  que se quieren comprar utilizando una herramienta de descripción de catálogo

3.- Publica el anuncio en TED

4.- Publica los pliegos

El operador económico

5.- Recibe el anuncio (por suscripción por ejemplo)

6.- Recupera los pliegos

En la siguiente imagen vemos una simplificación de que estándares y herramientas se utilizan para generar una oferta por parte de los operadores económicos.

Ejemplo de un proceso de pre-adjudicación simplificado

Creando y enviando la oferta

El operador económico

1.-Prepara los documentos, certificados evidendias para la cualificación. Utiliza la herramienta de VCD.

2.- Evalúa los elementos que se le van a pedir y como aportarlos.

3.- Especifica los bienes y servicios utilizando que puede proporcioar,  utilizando la herramienta de catálogo

4.- Comprueba si es precisa documentación adicional.

5- Firma y submite la oferta

La administración pública

6.- Recoge la oferta y valida las firmas.

Por último, en la imagen siguiente, se muestra con la misma simplificación como se puede utilizar las herramientas para implementar una compra por catálogo. Sistemas Dinámicos de Adquisición cuando lo organizamos para la administración pública.

El proceso de post-adjudicación

Comprando bienes y servicios por catálogo

El operador económico

1,. Actualiza las clasificaciones desde una institución que ofrece la descripción de bienes y servicios para la industria de forma estándarizada

2.- Actualiza el catálogo en función de la petición de la administración

La administración públic a

3.- Aprueba la actualización del catálogo

4.- Realiza un pedido

El operador económico

5.- Procesa la orden

6.- Genera y envía la factura

La administración

7.- Procesa la factura

Esta visión es  una simplificación que no puede relacionarse paso a paso con un procedimiento de compra pública, pero la intención es generar la evidencia de que hay herramientas y estándares que pueden integrarse en un flujo o procedimiento administrativo y conseguir la contratación pública electrónica interoperable.

Esa es la meta. Y es lo que persigue PEPPOL. O al menos así es como yo lo he entendido. Pero el proyecto PEPPOL habilita, da la capacidad pero no implementa. Los planes para conseguir los objetivos son siempre de cada administración pública.

PEPPOL es hoy en día una realidad, y según ellos, es tiempo de CONECTARSE.

Si te interesan estos temas únete a la red formal de contratación pública electrónica

·blog de compras pública eficaces

·blog de contratación pública electrónica.

·Wiki de contratación pública

·Comunidad de prácticas de contratación pública

·Grupo en linkedin

·Grupo en Facebook

·Usuario en Twitter (@econtratacion).

Te esperamos (necesitamos)

El proyecto de contratación pública electrónica pan-Europea: PEPPOL (1)

En esta primera entrada sobre el proyecto PEPPOL vamos a describir de forma somera los objetivos, la arquitectura y los grupos que componen el proyecto.

Para esta primera aproximación me voy a basar en la propia presentación que el director de proyecto hizo en la reciente conferencia de PEPPOL en Troyes Francia durante los días 8. 9 y 10 de noviembre de este año.

El proyecto

  • PEPPOL es un proyecto cofinanciado por el programa Europeo de Competitividad e Innovación (CIP) y el Programa de Soporte a la Política TIC (ICTPSP) de los años 2007 al 2009.
  • Es un  piloto europeo del  tipo A con el objetivo de Capacitar la contratación pública electrónica en toda la Unión Europea
  • Con una contribución del 50% del presupuesto por parte de la Unión Europea para conseguir la interoperabilidad, el otro 50% lo ofrecen los miembros del consorcio a través de los proyectos que inicien.
  • Coordinado por la Agencia noruega de Gobierno Electrónico y Gestión Pública (DIFI)
  • Formado por un consorcio con el alcance siguiente:
    • 18 beneficiarios de 12 paises.
    • Presupuesto total de 30,8 millones de euros.
    • 8 grupos de trabajo con un esfuerzo de 1600 personas/mes y 10 millones de euroess en subcontratación
  • el proyecto comenzó en mayo de 2008 con una duración de 48 meses

La visión

Cualquier proveedor (incluidas las PYMES) en la Unión Europea puede comunicar electrónicamente con cualquier órgano de contratación en todos los procedimientos de contratación.

Estructura de PEPPOL

Los ocho grupos del proyecto son los siguientes:

  • El grupo 1 trata los temas de firma electrónica. Es un grupo que quiere conseguir cierta armonización de las firmas electrónicas dentro de la contratación pública.
  • El grupo 2 trata de la identificación de las empresas, y lo hace a través del VCD (Virtual Company Dossier)
  • El grupo 3 trata de los catálogos y de todo lo que tiene que ver con el concepto de “sourcing”. Es decir establecer la relación de posibles proveedores de las administraciones para agilizar en la medida de lo posible la adquisición de los bienes y servicios recursivos (comprados habitualmente)
  • El grupo 4 trata sobre la gestión de pedidos electrónicas
  • El grupo 5 trata sobre las facturas electrónicas.
  • El grupo 6 es el grupo de la propia gestión del proyecto
  • El grupo 7 es la coordinación, formación y generación de consensos dentro y fuera del proyecto.
  • El grupo 8 es la generación de una infraestructura de transporte. Lo que hemos venido en denominar red de contratación pública.

En las siguientes entradas describiremos los componentes del proyecto y que utilidad pueden tener para nuestros propios proyectos.

Si te interesan estos temas únete a la red formal de contratación pública electrónica

·blog de compras pública eficaces

·blog de contratación pública electrónica.

·Wiki de contratación pública

·Comunidad de prácticas de contratación pública

·Grupo en linkedin

·Grupo en Facebook

·Usuario en Twitter (@econtratacion).

Te esperamos (necesitamos)

Estándares en contratación pública electrónica: CEN BII

Independientemente de que con posterioridad vamos a tratar de unir todas las piezas de la contratación pública electrónica que estamos viendo en un puzzle con sentido, hoy vamos a examinar los elementos básicos del estándar de CEN sobre Interfaces de Negocio Interoperables (BII Business Interoperable Interfaces).

Con este nombre es probable que nos quedemos un poco despistados. Pero si decimos que son las formas normalizadas de publicar un anuncio, publicar una petición de ofertas, confeccionar una oferta, enviar una oferta, actualizar un catálogo, recibir un pedido, enviar una factura … todo ello visto desde los puntos de vista de comprador y vendedor en el ámbito de la contratación pública  (y en general del comercio electrónico entre empresas )…. Entonces ya vamos entendiendo más de qué se trata.

Los trabajos alrededor de los estándares CEN BII empezaron a mediados de 2007. Han tenido una primera fase que ha durado hasta el 2009 y en el 2010 han iniciado una segunda fase que se prolongará hasta mediados de 2012. La primera fase ha producido una serie de especificaciones que están disponibles y en la segunda se pretende conseguir la utilización real de los estándares definidos.

Estos estándares son los utilizados con algún matiz por el proyecto PEPPOL del que hablaremos en otra entrada.

CEN BII Fase 1 constaba de cuatro grupos que son los siguientes

  • el grupo que define los perfiles
  • el grupo que ha trabajado la convergencia con estándares internacionales UN-CEFACT
  • el grupo de herramientas
  • el grupo de prueba piloto

En la imagen se aprecian mejor los grupos de CEN BII fase 1 y sus cometidos:

Desde mi punto de  vista la contribución a los estándares formales del taller CEN BII ha venido de la mano del grupo 1,  los denominados perfiles. La traducción de perfiles no sugiere de forma inmediata todo lo que un perfil conlleva  en su definición. Vamos a identificar los elementos que componen un perfil.

Hay definidos (26) los siguientes Grupos/ Perfiles (en original como en las especificaciones). Aquí vemos algunos de ellos:

  • Publication
    • o Prior Information Notification
    • o Tender Notification
  • Tendering
    • o Qualification
    • o Call For Tender
    • Tendering Simple
  • Sourcing
    • o Catalogue only
    • o Catalogue Update
    • o Catalogue Deletion
    • o Multi Party Catalogue
    • o Punch out
    • o Customer Initiated Sourcing
  • Ordering and Billing
    • o Order Only
    • o Invoice only
    • o Invoice only with dispute
    • o Billing
    • o Procurement

Los perfiles de CEN BII

  • La intención es
    • Facilitar la implementación de la contratación pública electrónica y el  comercio electrónico  de una forma normalizada.
    • Habilitar el desarrollo de soluciones software conformes con los estándares
    • Permitir conexiones eficientes entre las partes
    • Sin tener que especificar caso por caso el intercambio de datos
  • El objetivo último es reducir el coste del soporte para implementar la contratación pública electrónica en un nivel que sea económicamente asequible incluso para las pequeñas y medianas empresas y administraciones pequeñas.
  • A través de una descripción técnica que define:
    • La coreografía de los procesos de negocio, es decir, una descripción de la forma en que los partes del negocio colaboran para realizar sus respectivos roles y compartir la responsabilidad de conseguir el acuerdo común y los objetivos propuestos con el soporte de sus respectivos sistemas de información.
    • Las transacciones de negocio Una transacción de negocio representa una función expresada (orden aceptada, orden rechazada) por el intercambio de un documento de negocio (respuesta de una orden)  entre dos partes de un negocio o mas precisamente entre dos roles.
    • Las reglas de negocio que gobiernan estos procesos de negocio, sus colaboraciones y sus transacciones así como las restricciones sobre los elementos de información utilizados en los modelos de datos de cada transacción.
    • Los elementos de información de las transacciones de negocio intercambiada en cada modelo de datos de cada transacción de negocio.

Al final de la fase 1 del  taller de CEN BII se llego a la conclusión de que:

  • Aunque se han conseguido logros relevantes en este primer taller hay que reconocer que muy pocos entregables se han probado en la vida real.
  • Para representar un valor sostenible en el valor de la comunidad se requiere continuar el trabajo y proporcionar un apropiado gobierno de los estándares y las especificaciones

Y se determinó la necesidad de una segunda fase del taller CEN BII 2

En la fase 2 de CEN BII 2 que se inicio en 2010 y pretende llegar hasta mediados de 2012 los objetivos son los siguientes.

El objetivo general del taller BII2 es continuar el  trabajo iniciado por CEN WS/BII para soportar la interoperabilidad de la contratación pública electrónica y el comercio electrónico a través de soluciones para:

  • Proporcionar un foro de gobierno, gestión del ciclo de vida y evolución del CWA 16073:2010 (CEN BII 1),
  • Proporcionar soporte para los implantadores iniciales del CWA 16073:2010,
  • Contribuir a la armonización entre las iniciativas europeas de contratación pública
  • Asegurar que los requerimientos de los talleres son tenidos en cuentas en foros internacionales de desarrollo y continuar hacia la convergencia de CEN WS/BII con estándares relacionados.

En esta imagen se aprecian estos objetivos de forma gráfica

Bueno hasta aquí una descripción del contenido de los estándares CEN BII que hay que conocer a la hora de tomar decisiones sobre los proyectos de contratación pública electrónica.

Los estándares formar parte de la función de interoperabilidad (veremos este tema en otra entrada) sin la que formaríamos islas de proceso, introduciendo una segmentación del mercado que impediría conseguir ninguno de los objetivos propuestos.

Si te interesan estos temas únete a la red formal de contratación pública electrónica

·blog de compras pública eficaces

·blog de contratación pública electrónica.

·Wiki de contratación pública

·Comunidad de prácticas de contratación pública

·Grupo en linkedin

·Grupo en Facebook

·Usuario en Twitter (@econtratacion).

Te esperamos (necesitamos)

Publicada el
Categorizado como Europa Etiquetado como

Factura electrónica en el ámbito de la contratación pública

La factura electrónica en la administración es algo que está bastante unido a la contratación pública . Si bien no todas las facturas electrónicas son del ámbito de la contratación pública, si sería conveniente, y así lo marca la disposición final novena de la ley 30/2007 de contratos del sector público, que todos los contratos puedan ser facturados por vía electronica.

Ya hay paises como Dinamarca y Suecia que llevan años comprobando los beneficios de la factura electrónica en la contratación pública. Lo que no significa que su implantación haya sido fácil.

Aquí en España parece ser que a 30 de octubre de 2010 es cuando se había establecido la necesidad de que los proveedores facturaran electrónicamente a la administración.

Esto es lo que nos comenta la compañía Seres a traves de Computing:

El próximo 30 de octubre se cumplen la suma de los plazos para cumplir con la Ley 30/2007 de Contratos con el Sector Público, donde se establece que “el uso de la factura electrónica será obligatorio en todos los contratos del sector público estatal; no obstante, en los contratos menores, la utilización de la factura electrónica será obligatoria cuando así se establezca expresamente en estas Órdenes de extensión”.

A falta de unos días para llegar a ese horizonte, más de la mitad de las administraciones públicas aún no utilizan la factura electrónica. Esta es una de la principales conclusiones que se desprende de un estudio realizado por Seres que analiza la implantación de la eFactura en las entidades públicas, tanto a nivel local, como autonómico y estatal. Según los datos recogidos, con fecha de 31 de agosto de 2010, “sólo el 40% de las 286 entidades estudiadas (el 72% pertenecían a ayuntamientos, y el restante corresponde a personas de 16 sedes ministeriales y 19 a entidades de las diferentes comunidades autónomas), hacen uso de la factura electrónica, o tienen previsión de hacerlo próximamente; frente a un 59, 84% que no la utiliza o no tiene previsión de hacerlo”.

Si desglosamos los datos dividiendo los obtenidos en ministerios, comunidades autónomas y ayuntamientos, de acuerdo con el estudio de Seres, los primeros son los que peores resultados han mostrado. En este sentido, el texto dice que la necesidad de crear crear un entorno común entre ministerios donde todos ellos puedan trabajar con la factura electrónica ha sido el motivo por el que se ha producido un retraso en la puesta en marcha de la mayoría de los proyectos ministeriales. De momento, “el único ministerio que cuenta con un sistema de facturación electrónica es el Ministerio de Industria, Turismo y Comercio”, se explica desde Seres. Algunos ministerios, como el de Fomento, han realizado alguna implantación sin que tenga en la actualidad resultado operativo.

Por su parte, y según este estudio, un 37% de las comunidades autónomas ya cuentan con un sistema para que sus proveedores puedan emitir la factura electrónica. Junto con el 26% de entidades que van a poner en marcha a corto plazo la e-factura muestra que más del 60% de las comunidades autónomas están o van a estar en poco tiempo dispuestas a recibir e-facturas.

Finalmente, dentro del marco de los ayuntamientos, La Rioja se sitúa a la cabeza en el uso de la eFactura al contar con el mayor porcentaje de ayuntamientos que pueden facturar telemáticamente, con un 20% de implantación, seguida de Cataluña, con un 19%; Cantabria con un 15% y la Comunidad de Madrid, con un 14%. En el lado opuesto, hay comunidades como Asturias, Castilla-La Mancha, Extremadura y Canarias, en las que casi ninguno de los ayuntamientos encuestados usaba la factura electrónica.

En cualquier caso, la Unión Europea sigue aportando informes y estándares para la normalización de la factura electrónica. Este documento Analysis of Business Requirements for eInvoicing in a Public Procurement Co ntext-Final Study .

El informe es uno de los resultados del programa IDABC sobre facturación electrónica y Orden electrónica, en una iniciativa conjunta de la Dirección General de Mercado Interior y Servicios y la Dirección General de Informática de la Comisión Europea.

El informe está destinado a ser leído por

  • todas las partes implicadas en la iniciación y gestión de la facturación electrónica y la orden electrónica.
  • todas las partes involucradas en la inicicación y gestión de los proyectos de IDABC para las facturas y ordenes electrónicas de la contratación pública.  Incluyendo en particular a la Dirección General del Mercado Interior y a la Dirección general de Informáticas de la Comisión Europea, relacionados con el Programa PEGS (Pan European e-Goverment Services) entre los que se encuentra la contratación pública.
  • Todos los contratantes comprometidos en la ejecución del proyecto .
  • El grupo de expertos en factura Electrónica de la Comisión.

Contiene

  • los resultados de los requerimientos de negocio recogidos para la contratación electronica en el contexto de la contratación pública, habiendo sido estos requerimientos recogidos desde múltiples fuentes:
  • entrevistas con los Estados Miembreso que ya han implemento la facdturación electrónica y el archivo electrónico
  • requisitos legales para la facturación electrónica y el archivo electronico (fundamentalmente relacionados con el IVA)
  • Otras iniciativas de estandarización sobre factura electrónica.
  • Entrevistas con los interesados como pequeñas, medidas y grandes empresas (financieras y tecnologicas, que proporcionan soluciones.

En cualquier caso, y esta es la reflexión, ¿no sería conveniente generar un programa de adopción de la factura electrónica ( a ser posible utilizando estándares europeos e internacionales) que pusieran el acento en la colaboración y cooperación de las administraciones (de cualquier nivel) y las empresas (de cualquier tamaño)?

Únete a la red social de contratación pública electrónica: