Un dato importante de un producto está en una hoja de cálculo. Una instrucción para atender a cierto cliente quedó en una conversación antigua. La información necesaria para revisar un pedido depende de que alguien recuerde consultarla. Cuando la operación crece, esos datos necesitan un lugar definido y reglas claras de uso.
PrestaShop 9.2, publicado como versión estable el 30 de septiembre de 2026, incorpora el sistema Extra Properties para asociar campos adicionales a entidades de la plataforma. Su utilidad para el negocio consiste en estructurar información que no tiene un lugar adecuado en el modelo existente. Eso no significa que cada problema operativo deba convertirse en un campo nuevo.
1. Empieza por la información que falta
Antes de crear un campo, describe una situación concreta: qué dato falta, quién lo conoce, cuándo debe registrarse y quién lo utilizará. Después, comprueba si la plataforma o un módulo instalado ya dispone de una función apropiada.
Una característica pública del producto puede pertenecer a su ficha técnica. Una opción de compra, como talla o color, puede necesitar una combinación con SKU, existencias o precio propios. Una nota interna no es necesariamente un atributo que deba ver el comprador. Y una etapa de aprobación requiere algo más que un espacio para escribir un comentario.
Crear otro campo para un dato que ya existe añade una oportunidad de divergencia. Comienza con un pequeño inventario de la información utilizada por el equipo, sus responsables y sus destinos. Así podrás distinguir la ausencia de un campo de un problema de proceso o integración, sin construir un nuevo registro paralelo.
2. Entiende qué aporta Extra Properties
El sistema organiza la definición del campo, su tipo de dato y su asociación con una entidad, como producto, combinación, cliente o pedido. Según la definición y el soporte de la instalación, permite integrar propiedades en formularios y listados del panel y en determinadas operaciones de la Admin API.
Esto proporciona una base compartida para almacenar información adicional. No significa que cualquier campo creado aparezca automáticamente en todos los lugares de la tienda, que se solicite al cliente durante la compra o que pase a existir en el ERP. Debes definir dónde se captura, se presenta y se utiliza el dato.
Hay una precisión importante para el mantenimiento: la documentación oficial marca el código de Extra Properties como @experimental en PrestaShop 9.2. La versión de la plataforma es estable, pero esa clasificación del componente admite cambios excepcionales de compatibilidad. Tenlo en cuenta al planificar módulos y futuras actualizaciones; la estabilidad de la versión no elimina la necesidad de revisar cada interfaz de extensión.
3. Evalúa ejemplos vinculados a la operación
Los siguientes casos son propuestas ilustrativas de modelado, no funciones de un módulo anunciado por AGTI:
| Necesidad | Entidad que conviene evaluar | Decisión necesaria |
|---|---|---|
| Indicar que un producto requiere embalaje reforzado | Producto | Quién mantiene el valor y cómo lo consulta expedición |
| Registrar el código de la sucursal compradora en un proceso B2B | Cliente | Quién controla el código y qué sistema mantiene el valor oficial |
| Registrar un indicador de revisión interna del pedido | Pedido | Quién puede actualizarlo y qué acciones dependen de él |
El primer caso puede resolverse con un indicador booleano si solo existen dos estados bien definidos. El segundo necesita un formato consistente y un procedimiento de actualización. El tercero debe distinguir un dato descriptivo de un flujo que realmente controle la revisión.
En todos los ejemplos, el valor solo aporta utilidad cuando llega a la persona o al sistema que debe actuar. Una instrucción de embalaje que expedición nunca ve sigue siendo información aislada, aunque esté guardada dentro de la plataforma. Define el punto de uso con tanto cuidado como el punto de registro.
4. Elige tipo, alcance y validación de forma deliberada
El tipo debe representar el significado del dato. Un indicador de sí o no, una fecha y una referencia textual tienen requisitos diferentes. Cuando hay un conjunto cerrado de respuestas, una lista de opciones puede evitar distintas formas de escribir la misma condición.
Define también si el valor es compartido, traducido o específico de una tienda:
| Alcance | Uso que conviene evaluar |
|---|---|
common | Un valor compartido entre los contextos aplicables |
lang | Contenido cuyo valor depende del idioma |
shop | Información que puede variar entre tiendas |
La disponibilidad de los alcances depende de la entidad y de su estructura. No supongas que cualquier entidad admite todos ellos. En una operación multitienda, diferencia el contexto de los valores almacenados de las tiendas en las que resulta visible una definición.
Establece límites, valores permitidos y comportamiento cuando no se introduce información. Un valor predeterminado no debe afirmar que se realizó una revisión si nadie la hizo. La documentación también distingue marcar un campo como obligatorio en el formulario de validarlo en el servidor: exigir realmente un valor no vacío requiere la restricción correspondiente, como NotBlank cuando proceda. Comprueba los caminos reales de entrada, no solo el aspecto del formulario.
5. Decide dónde aparece y quién lo mantiene
Un campo útil necesita una etiqueta comprensible, instrucciones y una ubicación coherente. Si queda alejado de la tarea en la que se conoce la información, el equipo puede dejarlo vacío o actualizarlo tarde. Determina si se utilizará en un formulario, un listado, una integración o varios de estos puntos.
Las propiedades creadas desde el panel y las registradas por módulos tienen responsabilidades distintas. Un módulo debe seguir siendo responsable de las definiciones que administra. Cambiar manualmente una estructura controlada por código puede provocar un conflicto en la siguiente instalación o actualización.
Decide de forma explícita si el valor puede exponerse en la tienda pública. La configuración de exposición no sustituye la evaluación del acceso de cada integración ni debe interpretarse como un sistema de permisos granulares por empleado. Los datos internos necesitan un destino deliberado, no una publicación automática por comodidad.
6. Separa almacenamiento, presentación y automatización
Guardar un dato, mostrarlo y ejecutar una acción basada en él son tres trabajos diferentes. Crear una propiedad de embalaje reforzado no modifica por sí mismo la selección del embalaje, el cálculo del envío ni la generación de documentos.
Del mismo modo, un campo adicional no se convierte automáticamente en filtro del catálogo. Una propiedad del cliente no empieza a solicitarse en el formulario público de registro sin adaptar el flujo correspondiente. Y un dato disponible en la Admin API no será consumido por una integración con el ERP que todavía no sabe leerlo.
Diseña el recorrido completo: origen, validación, almacenamiento, lectura y uso operativo. Cuando varios sistemas intercambien el valor, identifica cuál mantiene la versión oficial y cómo deben resolverse actualizaciones incompatibles. De lo contrario, el nuevo campo puede trasladar una discrepancia desde la hoja de cálculo a la plataforma de comercio.
7. Prueba primero un proceso pequeño y verificable
Comienza en un entorno de pruebas con una necesidad bien delimitada. Registra valores nuevos, revisa registros existentes y valida los contextos de idioma y tienda que utiliza la operación. Si participa una integración, comprueba lectura y escritura mediante su camino real de acceso, no solo la presencia del campo en el panel.
Pide a una persona del equipo operativo que realice la tarea. Debe entender la etiqueta, saber cuándo introducir el dato y encontrarlo al necesitarlo. Prueba también qué sucede si el campo queda vacío o recibe un valor inválido.
Planifica los cambios de definición y una posible retirada futura. La documentación diferencia eliminar una definición de eliminar también su columna y sus valores: no son acciones equivalentes. Por eso, los cambios de estructura y la migración de datos requieren un plan propio, sin pruebas destructivas sobre la tienda en producción. Define qué debe ocurrir con los valores históricos antes de modificar el modelo.
8. Utiliza campos para apoyar un proceso comprendido
Una decisión bien explicada puede recogerse en una ficha breve: nombre, entidad, finalidad, tipo, responsable, momento de registro, lugares de consulta, integraciones y criterio de aceptación. Incluye qué no debe ejecutarse automáticamente, especialmente si el dato está relacionado con aprobaciones o responsabilidades de otro sistema.
Si el equipo todavía no sabe quién produce la información o cómo se utilizará, crear el campo no resolverá esa incertidumbre. Cuando esas respuestas están claras, Extra Properties puede evaluarse como parte de una solución coherente, con menos datos dispersos y responsabilidades más visibles.
AGTI puede ayudar a determinar si la necesidad ya está cubierta por la plataforma, por un módulo existente o por una personalización concreta. Consulta con AGTI sobre el proceso de tu tienda.
Referencias técnicas
- Publicación de la versión estable de PrestaShop 9.2.
- Descripción general de Extra Properties.
- Gestión de propiedades adicionales desde el panel.
- Registro de propiedades adicionales desde un módulo.
Fuentes verificadas el 19 de octubre de 2026. El artículo explica criterios de evaluación; no demuestra una instalación concreta ni presupone que sus temas e integraciones ya estén adaptados.