Luis Ochoa

 El pasado 6 de julio de 2.010 entro en vigor la nueva Ley 15/2010 por la que se establecen medidas de lucha contra la morosidad en transacciones comerciales. La ley fundamentalmente establece una serie de limitaciones para el cálculo de la fecha de vencimiento de las facturas con el objetivo de reducir los periodos medios de cobro.

 Entre las medidas más destacadas tenemos:

• Cálculo de la fecha de vencimiento tomando como fecha de partida la fecha de entrega de la mercancía o de los servicios prestados.
• No son válidos aquellos acuerdos que excluyen del cálculo del vencimiento los periodos vacacionales.
• Hasta el 31/12/2011 el vencimiento máximo no debe superar los 85 días
• Desde el 1/1/2012 hasta el 31/12/2012 no se deben superar los 75 días
• Desde el 1/1/2013 no se deben superar los 60 días
• Para los productos alimentarios frescos y los perecederos, se establece desde la entrada en vigor de la ley, un máximo de 30 días desde la entrega de la mercancía.

 Obviamente todas estas medidas son de aplicación para los nuevos acuerdos o contratos comerciales que se firmen desde la fecha de la nueva ley, por tanto no quedan afectados todos aquellos acuerdos que estaban en vigor.

 ¿Cómo afecta todo esto a una implantación de JD Edwards?

•  Los programas de impresión de facturas y de actualización de ventas calculan el vencimiento en función de la fecha de factura, por tanto habría que modificar dichos programas para que tuvieran en cuenta la fecha de entrega para el cálculo. En ese punto es muy importante conseguir que la fecha de entrega de la mercancía se grabe correctamente en el campo adecuado de la base de datos de JD Edwards, para todas las transacciones que entren en el sistema, no sólo las manuales si no también las de interfase y por EDI.
• Habría que reparametrizar todas las condiciones de pago, teniendo especial cuidado con aquellas que incluyen días fijos de pago.
• Habría que revisar la parametrización de la facturación cíclica para adaptarla a la nueva ley.

 No es una gran cantidad de trabajo, pero es necesario hacerlo en el menor plazo posible de tiempo.

 El texto completo de la nueva si necesita consultarla, lo puede encontrar en http://www.boe.es/boe/dias/2010/07/06/pdfs/BOE-A-2010-10708.pdf

Angel F. Viartola

EnterpriseOne cuenta con unas cuantas herramientas y utilidades que son muy poco conocidas, y menos utilizadas, que facilitan muchas tareas de desarrollo y permiten simplificar procesos.

Por ejemplo, frente a la tradicional forma de gestionar ficheros de texto (abro fichero, leo líneas de una en una, cierro fichero) disponemos de la posibilidad de invocar a una función que se encarga de abrir el fichero, leerlo, subirlo a una tabla línea a línea, asignándole un número de lote, una descripción, incluso un código de informe y versión para que después pueda ser gestionado leyendo la tabla. Y todo esto únicamente invocando a una función de negocios. El leer un fichero de texto en una tabla permite utilizar cursores para leerlo en dos pasadas, o recorrerlo como queramos conveniente.

Disponemos de API’s que nos permiten leer las opciones de proceso de otras aplicaciones e informes, de manera que no necesitamos agregar opciones de proceso a una aplicación o hacer extrañas llamadas de unas a otras, podemos leer las que queramos desde donde queramos, añadir aplicaciones “dummy” que sólo se usen para asociarles más opciones de proceso, leer las de unas aplicaciones desde otras…

Tampoco solemos utilizar las directivas del preprocesador, opciones de compilación que nos permiten personalizar las funciones de negocio para que se compilen adecuadamente en cada una de las posibles máquinas, de forma que podamos tener código específico para Unix/Linux, Windows o AS/400 dentro de la misma función.

Uso de ftp para la gestión de objetos de medios, posibilidad de invocar directamente a los distintos “mafflets” pasándoles parámetros, inclusión de gráficos de barras o sectores en pantallas y otras muchas posibilidades a nuestra disposición para mejorar el rendimiento, la programación o la visualización de nuestras aplicaciones.

Os iremos contando más cosas.

Saludos.

Juan Sáenz de Tejada

En estos momentos de incertidumbre económica, la formación interna es uno de los grandes retos que las empresas deben afrontar en los próximos meses.  Según los últimos datos de una prestigiosa consultora, cuatro de cada diez empresas concluyen que es su mayor preocupación; sin embargo, el 60% de las mismas, declaran que no creen que el actual modelo de formación presencial, mucho mas común todavía que los modelos de e-learning, sea la forma más eficaz ni de gestionarla, ni de retener el conocimiento en la compañía en estos nuevos tiempos.

Otro punto a tener en cuenta es que, mientras que el ROI en los procesos de formación basados en las nuevas tecnologías es mucho más alto que en el modelo tradicional, el coste de desarrollo de dichas tecnologías sigue suponiendo un freno a muchas empresas. Entonces, ¿cómo solucionar la dicotomía existente entre coste y beneficio? Y aún más, ¿cómo hacer que una vez realizada dicha formación el conocimiento quede dentro de la compañía?

Una posibilidad que cada día está tomando más fuerza es la utilización de plataformas de contenido que nos permitan tanto la creación de documentación, como la formación y la evaluación de la misma en toda la empresa. Estas plataformas lo que habilitan a la empresa es el crear un conjunto de documentación y demostraciones, totalmente exportables, que faciliten la gestión de la formación interna, y que permitan que el conocimiento permanezca en la empresa aunque el personal deje la compañía. ¿Cómo? Dichos conjuntos de documentación sólo necesitan crearse una vez y se puede, desde crear documentación por procesos específicos (¿cómo introducir una factura en JD Edwards?) hasta procesos más complejos y completos (Gestión del almacén).

Una de estas plataformas es: User Productivity Kit (UPK) de Oracle.

UPK es una plataforma de contenido sincronizada para la creación de documentación, la formación y la asistencia de rendimiento de toda la empresa. Generalmente, su uso se limita a un equipo de autores de contenido, que son los que conocen a fondo los procesos a tratar. Los usuarios finales pueden disponer de dicho contenido bien a través de un  reproductor (Player) o de un documento con todos los pasos a seguir.

UPK le permitirá crear y publicar contenido fácilmente. Este contenido incluye simulaciones, soporte de aplicación y documentación interactiva. De esta forma, los usuarios obtienen un conocimiento completo de la funcionalidad del software, además de comprender los conceptos, al aprender a utilizar un programa en un entorno simulado y mientras trabajan con sus propios datos en un entorno real.

Los modos de utilización del UPK son los siguientes:

• El modo See It! permite a un usuario aprender mientras observa una demostración animada de los pasos de una tarea que se realiza en un entorno simulado. Todas las actividades necesarias como, por ejemplo, el movimiento del ratón y la introducción de datos, se realizan automáticamente.

• El modo Try It! permite a un usuario aprender de forma interactiva en un entorno simulado. El usuario sólo tiene que hacer clic con el ratón o pulsar las teclas para completar la tarea.

• El modo Know It? es un modo de reproducción tipo evaluación en el que los usuarios deben completar una tarea concreta. Los usuarios no recibirán instrucciones paso a paso para completar una tarea. En su lugar, deberán completar los pasos por sí mismos en un entorno simulado y recibirán la puntuación en relación a la precisión con que los realicen.

• El modo Do It! Mode permite a un usuario aprender de forma interactiva con datos reales. El usuario visualiza una pequeña pantalla en la parte superior de la aplicación real en la que se muestra cada paso de una tarea concreta. A medida que el usuario realiza cada paso, puede hacer clic en un botón o utilizar una combinación de teclas de acceso directo para visualizar el siguiente paso del proceso. La ventana Do It! incluye un gráfico en miniatura de la pantalla con un texto resaltado que indica el área en la que debe tener lugar la acción

Como consecuencia el poder utilizar una herramienta como el UPK nos permite minimizar los costes de formación interna, ya que no se requiere la presencia de formadores. Además permite generar en un fichero comprimido la documentación de la formación necesaria para un puesto determinado y que ésta, se encuentre en el PC del alumno de forma local lo que permita su visualización en caso de duda.  Asimismo, el uso de una herramienta como ésta nos permite la estandarización de la formación y lo más importante: que el know-how resida en la compañía.

Si quieres ver una demostración de cómo funciona el UPK, pincha en el siguiente enlace. Si te pregunta si deseas cerrar la ventana, selecciona ‘NO’. A continuación pincha en el logo que te aparecerá en el centro de la ventana y se iniciará la demostración con la que podrás interactuar en los diferentes modos de utilizacíón, tal y como te he explicado en este artículo.

                                                               Demostración de la solución User Productivity Kit (UPK)

 Esperamos tus comentarios sobre esta solución.

Luis Ochoa

El día 25 de septiembre de 2009 se aprobó la nueva Ley de Presupuestos Generales del Estado en el Consejo de Ministros. Aunque pueda sufrir cambios en su tramitación en el parlamento, dicha ley conlleva una subida de los impuestos sobre la rentas del capital del IVA:

• El IVA general pasará de 16% a 18%. Es el tipo impositivo general y se aplica a la mayoría de los productos y servicios: ropa, calzado, mobiliario, electrodomésticos, bricolaje, tabaco, bebidas alcohólicas…

• El IVA reducido pasará del 7% a 8%. Aunque la lista es muy larga, los principales bienes y servicios a los que no aplica este tipo son los alimentos no incluidos en el IVA súper reducido, transporte de viajeros; servicios de hostelería; entradas a espectáculos; servicios funerarios; peluquerías; dentistas; edificios, viviendas y  y complementos para el diagnóstico o alivio de enfermedades.

• El IVA superreducido permanecerá inalterado en el 4%. Se gravan con este IVA bienes y servicios calificados como de primera necesidad: pan, leche, quesos, huevos, verduras, frutas, hortalizas y tubérculos naturales, que no hayan sido modificados de ninguna forma. También se aplica este tipo de IVA a libros, periódicos y revistas no publicitarios; medicamentos de uso humano; sillas de ruedas para minusválidos y prótesis y Viviendas de Protección Oficial (VPO).

Todos los clientes de JD Edwards tendrán que realizar adaptaciones en los módulos financieros, de compras, ventas y gestión de inventario.

Las áreas concretas en las que habrá que analizar posibles cambios de parametrización son:

1) Áreas Fiscales:

a) Nuevas áreas fiscales

b) Áreas fiscales compuestas

2) Configuración del IVA por artículo

3) Áreas Fiscales de Clientes y Proveedores

4) ICAS

5) Informes oficiales de IVA

6) Convivencia de los dos tipos de IVA durante el año 2.010

Además, habría que analizar las operaciones futuras que podamos tener registradas en nuestra contabilidad y que caiga entre ambos periodos (anticipos, contratos anuales, etc.). Es decir, este cambio impositivo traerá la necesidad de revisar de manera escrupulosa y detallada los sistemas financieros de la empresa.

Si has tenido la suerte o desgracia de haber estado en un proyecto realizando cambios similares en alguna instalación de JD Edwards, te agradecería nos contaras tu experiencia.

Angel F. Viartola

En toda implantación de un sistema de gestión llega el momento de hablar de seguridad: copias de seguridad, qué usuarios pueden acceder a qué datos, o qué aplicaciones pueden ser usadas por distintos usuarios, quien puede generar determinados tipos de datos…

En mi experiencia como consultor de implantación de sistemas de gestión he encontrado que, normalmente, cuando se inicia un proyecto se comenta el tema, se explica al cliente las posibilidades de seguridad que tiene EnterpriseOne y a partir de ese momento se espera que sea la empresa quien decida qué tipos de empleado va a tener, qué va a poder hacer cada uno y todas las opciones de seguridad.

Las posibilidades de seguridad en EnterpriseOne son muy amplias: puedo limitar qué acciones puede efectuar un usuario en una pantalla, qué puntos de menú puede o no puede ver, qué filas o columnas de tablas puede visualizar, y opciones de seguridad más avanzadas, específicas algunas de EnterpriseOne, que además se pueden combinar con configuraciones de seguridad de la base de datos, puesto que el sistema permite que los usuarios de la aplicación utilicen distintos perfiles de usuario de base de datos, esto es, según a qué entornos de la aplicación entra su usuario de base de datos puede ser uno u otro, y siempre se respetará la configuración de seguridad de la base de datos añadida a la que se realice en EnterpriseOne.

Así pues, tenemos muchas posibilidades en cuestión de seguridad. Tenemos al usuario del sistema informado de estas posibilidades, tenemos un proyecto en marcha y, ¿qué suele ocurrir?

Normalmente el tema de seguridad se va retrasando, diluyendo en distintas áreas de responsabilidad y se termina por llegar a la fecha del arranque sin un modelo de seguridad adecuado, y es cuando deprisa y corriendo se pretende construir una estructura de la organización desde la que se deduzca la configuración de seguridad, lo que normalmente no funciona.

Y todo esto suele ocurrir porque al implementar la solución de gestión no se tiene en cuenta, desde el principio, que un cambio de herramienta puede conllevar cambios en la organización, así como cambios en la forma de trabajar (todos hemos oído la famosa frase “es que en mi sistema yo hago…”), y todos estos cambios deben intentar ser descubiertos y tenidos en cuenta durante la fase de implantación, así como la configuración de seguridad asociada a las nuevas metodologías de trabajo. Porque, si quieres que todo sea como antes, ¿por qué cambias el sistema?

Juan Carlos García Fito

Hagamos un poco de historia sobre el producto original de donde y como nació el producto que hoy en día Oracle abandera como uno de sus productos líderes en plataformas iSeries.

En 1977 nace JD Edwards World Solution Company en Denver, Colorado y desarrolló una aplicación básica de contabilidad para sistemas /34 y /36 de IBM. Con posterioridad, IBM lanzo su nuevo sistema llamado AS/400 que incorporaba como base de datos DB2/400, esto hizo que JD Edwards lanzara al mercado su producto totalmente remodelado y adaptado a las nuevas necesidades del mercado con nuevas funcionalidades que le hizo convertirse en una aplicación ERP llamada “WorldSoftware” o popularmente “World”. En 1996, ante el boom de sistemas con arquitectura cliente/servidor, JD Edwards lanza al mercado su versión denominada “OneWorld” (que nada tiene que ver con “Oneworld”, la alianza de aerolíneas comerciales), la cual era independiente a las plataformas iSeries, (aunque compatible ya que se puede utilizar el iSeries como Enterprise Server), con la cual se abarcaba el nuevo mercado emergente y a la vez cubría todo el espacio de mercado con las dos versiones del producto, que indudablemente tenían y tienen tecnologías totalmente diferentes.

En 2003 Peoplesoft absorbe a JD Edwards, renombrando los dos productos por Peoplesoft Word y Peoplesoft One adaptándolos a los nombres de todos los productos Peoplesoft, a mi entender un error que provocaba perder una referencia a tantos años de experiencia. Esta situación duró poco tiempo, ya que en 2005 Oracle Corporation firmó la adquisición de Peoplesoft y devolvería, con nuevas versiones de los dos productos totalmente remodelados, su antigua entidad y nombre, “JD Edwards World” y “JD Edwards EnterpriseOne”.

En la actualidad, y después de más de 30 años en el mercado, el hermano mayor de los productos “JD Edwards World” sigue siendo el Nº 1 con la mayor base instalada en plataformas IBM iSeries.

Fernando Álvarez

Voy a dedicar estas líneas a intentar resumir y clarificar la localización y clases de objetos utilizados en las aplicaciones de JD Edwards EnterpriseOne, en concreto para la versión 8.12 y tools superior a la 8.96.

Hay diferentes tipos de objetos: aplicaciones interactivas, reports, funciones de negocio, tablas, etc.

Atendiendo a su forma de almacenamiento, se distinguen tres tipos de objetos: Objetos Centrales, Objetos Replicados y Objetos Serializados.

Objetos Centrales : son especificaciones y componentes C. Las especificaciones se almacenan en una Base de Datos en el Servidor de BBDD. Los componentes C se guardan en directorios en el Deployment.

Objetos Replicados : se crean durante el proceso de construcción de Paquetes a partir de los Objetos Centrales. En este caso las especificaciones se almacenan en formato XML y se guardan (según el spec.ini del Deployment) tanto en una BD MSDE en el Deployment (a la que accederán los Clientes Pesados), como en un repositorio compartido de specs en el Servidor de BBDD (según el spec.ini del Enterprise, y al que accederán tanto el Enterprise como el Web Server), por ejemplo: Central Objects – DV812. En el caso de los Objetos Replicados, los componentes C ya se encuentran vinculados y compilados y se almacenan en directorios del Deployment, Enterprise y Clientes Pesados.

Objetos Serializados : son creados y almacenados en el Web Server a partir del repositorio compartido de especificaciones. Se convierten en código Java y se hacen visualizables a través de un navegador web. Estos objetos serializados se almacenan en las tablas F989998 y F989999.

Si esto ha aclarado algo a alguien, habrá valido la pena.

Un saludo y hasta pronto.

Angel F. Viartola

En una implantación de EnterpriseOne llega el momento de hacer una personalización.  ¿Qué se hace? ¿Se copia el objeto estándar y se modifica o se trabaja directamente contra el estándar? Es un debate que frecuentemente se da en los foros de JD Edwards. Yo tengo mi opinión al respecto: modificar el estándar siguiendo las recomensaciones de Oracle, siempre y cuando sea posible.

¿Cuales son las razones que me hacen elegir esa opción?

Copiar los estándares modificados a objetos nuevos implica perder toda posibilidad de mantenimiento por parte de Oracle: los parches se aplican sobre programas del estándar JD Edwards, no sobre programas de usuario. Y además, bajo determinadas condiciones, la aplicación de un parche no va a suponer la pérdida de nuestras modificaciones, siempre y cuando se hayan hecho con la metodología adecuada. Oracle en su serie de documentos “EnterpriseOne Modifications General Recommendations and Guidelines” explica detalladamente cómo se debe modificar el estándar, qué cambios son fácilmente reaplicables, qué cambios se perderán en el caso de actualización

En uno de los documentos de esa serie (ott-03-0020) se señala lo siguiente:

“Should I make a copy or should I modify the standard object? This is a judgment call. If the application has a lot of ER, is heavily used, often requires ESU’s, and is a big part of the day’s daily process, then modifying the standard object may be the best option.

If you make a copy of an object, you are making a snapshot of that object at a point in time when the copy is performed. When an ESU becomes available for the standard PeopleSoft EntepriseOne application that fixes a bug or adds functionality to the object you copied, the change is not included for the copied custom object. You can not direct the changes in the ESU to any object you want, such as a copy of the same object the ESU is intended for. The changes in the ESU are only applied to the object they are intended for.  Therefore any changes would have to be manually retrofitted to the custom object when an ESU is applied.”

“¿Debo hacer una copia o debería modificar el objeto estándar? Este es un juicio personal. Si la aplicación tiene un montón de ER, es muy usada, a menudo requiere de ESU (parches de la aplicación), y es una gran parte del proceso diario, entonces modificar el objeto estándar puede ser la mejor opción.

Si usted hace una copia de un objeto, usted está haciendo la copia de objeto en un momento concreto. Cuando un ESU que se disponga para el estándar de EntepriseOne corrija un error o aumente la funcionalidad del objeto que se ha copiado, el cambio no se incluye en cada objeto personalizado copiado (únicamente en el objeto original). Usted no puede aplicar los cambios del ES  a cualquier objeto que desee, como por ejemplo una copia del objeto estándar. Los cambios en los ESU sólo se aplican al objeto que están destinados. Por lo tanto, cualquier modificación tendría que ser manualmente aplicada para el objeto personalizado cuando se aplique un ESU al objeto original.”

Esto es: trabajar con programas copiados implica perder el mantenimiento, perder las posibles ampliaciones de funcionalidad, perder todo soporte por parte de Oracle.

Utilizar el estándar siempre es la mejor opción, sólo hay que diseñar las personalizaciones bajo un prisma de conocimiento adecuado de la aplicación, saber qué se guarda y qué se pierde (”what preserves and what replaces”) cuando se hace una actualización y ser conscientes de lo que es el desarrollo en EnterpriseOne. Hay herramientas y técnicas más que suficientes tanto para personalizar como para reaplicar los cambios sin perder nada y con una inversión de tiempo mínima si se hacen las cosas correctamente.

Un saludo a todos.

Luis Ochoa

¿Es JD Edwards un buen producto? La respuesta es categóricamente sí, no sólo es un buen producto, sino que es de los mejores ERP del mercado actual como lo demuestra su gran implantación en empresas de todos los sectores y tamaños. El gráfico siguiente detalla su amplia funcionalidad, así como la existencia de módulos específicos para determinados verticales.

¿Entonces porqué no aumenta su cuota de mercado si prácticamente estamos en todos los procesos de selección de software importantes?

A mi criterio hay varios motivos, aunque seguramente algunos de ellos son mis percepciones y no serán compartidas por todo el mundo:

1.- JD Edwards es un producto que se ha posicionado en un nicho de empresas que ni son las grandes ni las muy pequeñas. Esto provoca que nuestra competencia sea prácticamente todo el plantel de soluciones ERP que existen actualmente, desde SAP hasta la más pequeña de las empresas de origen regional/provincial que han desarrollado alguna aplicación empresarial.

2.- Igualmente nos hemos quedado en un entorno de precios que es muy elevado para las pequeñas y que se queda corto para las grandes.

3.- La estrategia de Oracle en cuanto a verticalización del producto y su distribución a través de canal llega tarde. Otros fabricantes han desarrollado una extensa verticalización desde hace años, como Microsoft, y algunos han desarrollado un canal de forma muy inteligente consiguiendo que las grandes consultoras actúen como prescriptoras en grandes multinacionales, tal es el caso de SAP.

4.- Las bajas rentabilidades de los proyectos, entre otras cosas debido a que el parque de consultores de JD Edwards no ha crecido y por tanto las tarifas y los salarios no son competitivos, hacen que las empresas de consultoría prefieran implantar otros productos obteniendo más beneficios.

5.- Finalmente tengo que decir que nos encontramos con que muchos directores de sistemas prefieren implantar SAP por su propia supervivencia, sin pararse a analizar si es la solución idónea para sus compañías. ¿Quién va a criticar a un responsable de sistemas por elegir SAP?, aunque el proyecto sea un desastre en cuanto a coste y plazos, lo tienen todas las grandes.

A pesar de todo, ¿podemos seguir en este mercado?

No sólo podemos sino que debemos seguir, somos una alternativa válida para todas esas empresas que no sufren de “sapitis”, y que necesitan una solución funcional y tecnológicamente muy robusta, y de fácil y corta implantación.

Las empresas de servicios tenemos que cambiar profundamente en nuestra forma de trabajar, consiguiendo hacer crecer el número de consultores, y lo que es más importante crear soluciones sectoriales adaptadas sobre todo para las Pymes, que es donde nos vamos a batir el cobre en el futuro.

Saludos

Angel F. Viartola

Una de las afirmaciones sobre Oracle  JD Edwards EnterpriseOne es que es una aplicación independiente de la base de datos.

¿Qué significa “independiente de la base de datos”?

En muchas instalaciones de EnterpriseOne no se tiene en cuenta la posibilidad de que EnterpriseOne funcione de forma absolutamente independiente de la base de datos, siendo irrelevante que ésta sea Oracle, SQL Server o DB2. La aplicación es la misma en todos los casos, sólo variando en el proceso de instalación la forma de crear la base de datos o instalar el Enterprise Server, que lógicamente varía en función de la plataforma utilizada. Pero una vez realizada la instalación, desde el punto de vista de desarrollo y en el día a día, el hecho de que la base de datos o la plataforma sea una u otra es absolutamente irrelevante.

En muchas ocasiones encontramos que para realizar cargas de datos desde otros sistemas se exportan los datos a ficheros planos para después cargarlos de nuevo en JD Edwards, con lo que ello conlleva tanto a nivel de desarrollo como en posibilidades de error.

Pero si tenemos nuestro sistema corriendo en una BBDD Oracle y el control de almacén en SQL Server, ¿qué nos impide acceder directamente desde EnterpriseOne a una información almacenada en ese SQL Server? ¡¡Nada!!

Para tomar o dejar datos bastaría con crear un “Database Datasource” que apuntara al servidor al que queremos acceder, configurar el usuario de sistema adecuado, asociarlo al usuario que necesitar ese acceso y eso es todo: nos olvidamos de exportar, importar, carpetas de intercambio y demás complicaciones, simplificándolo y dejándolo en un acceso directo a la base de datos que necesitemos.

A partir de ahí la integración con otros sistemas, tanto a la hora de tomar como de dejar información se simplifica. Más aún cuando podemos jugar con toda la tecnología de JD Edwards a la hora de utilizar ese acceso: creación de pantallas, aplicaciones batch, uso del diccionario de datos, tablas, triggers de tabla, todo ello será perfectamente válido a la hora de acceder a esa nueva fuente de datos, sea o no una de las estándares de EnterpriseOne.

Probadlo… os sorprenderá.

Un saludo a todos.