Elegir el enfoque adecuado para una migración hacia osCMax exige algo más que comparar cantidades de registros. Las tiendas osCMax suelen combinar registros similares a los de osCommerce con funcionamiento propio del paquete, contribuciones antiguas, plantillas, archivos personalizados, tablas personalizadas y supuestos del entorno de hosting. Por eso, la ruta de servicio adecuada depende de cuánto de la tienda corresponde a datos estándar y cuánto del significado empresarial proviene de comportamientos heredados que rodean esos datos.
Una tienda osCMax sencilla puede encajar en una ruta directa de servicio de migración. Una tienda compleja puede necesitar Managed Service, Add-ons, Custom Service o una combinación de componentes del servicio. La decisión debe basarse en evidencia: claridad de versión, dependencia de contribuciones, estructura de la base de datos, personalización de archivos, funcionamiento de plantillas, calidad de los registros, requisitos de configuración de la plataforma de destino y esfuerzo de validación.
El objetivo de seleccionar el servicio no es complicar la migración, sino impedir que una suposición incorrecta se incorpore al proyecto. Si la tienda solo necesita trasladar registros principales, el plan debe mantenerse enfocado. Si depende de lógica controlada por contribuciones, campos personalizados, módulos modificados o funcionamiento heredado del proceso de compra, el plan debe reconocerlo desde el principio.
Dentro de los servicios de migración de Next-Cart, la evidencia de osCMax debe diferenciar registros compatibles, responsabilidad de ejecución, Add-ons con alcance limitado, datos controlados por contribuciones, personalizaciones heredadas y configuración de destino.
Empiece por el alcance de la migración, no por la etiqueta del servicio
El primer paso es describir qué debe trasladarse y qué debe seguir funcionando después de la migración. Products, Customers, Orders, Categories, Reviews, Coupons, CMS Pages y Blog Posts pueden ser áreas de datos elegibles, pero el alcance de osCMax puede ir más allá de esas etiquetas. Un Product puede incluir atributos, campos personalizados, convenciones de imágenes, precios especiales o comportamientos de presentación controlados por contribuciones. Un Order puede incluir etiquetas de pago, referencias de envío, campos de exportación personalizados, contexto de grupos de Customer o un significado de estado modificado.
La ruta de servicio debe seleccionarse después de dividir la tienda en cuatro grupos:
- registros estándar que pueden migrarse mediante comportamiento compatible;
- registros que necesitan filtrado, asignación o ajustes de configuración;
- comportamiento del destino que debe configurarse o reconstruirse fuera de la migración de datos;
- datos personalizados o controlados por contribuciones que requieren revisión específica.
Esta separación evita sobrecargar Standard Service con comportamientos personalizados heredados. También evita utilizar Custom Service sin necesidad cuando el requisito solo consiste en una condición limitada para un tipo de datos, una expresión de valor o un destino diferente para un campo de origen compatible.
| Señal del alcance | Implicación probable para el servicio | Qué debe confirmarse |
|---|---|---|
| Products, Customers y Orders limpios | Standard Service puede ser suficiente. | Confirmar la integridad de los campos y la precisión de las muestras. |
| Muchos registros pero estructura estándar | Managed Service puede ayudar a coordinar una ejecución y validación de mayor escala. | Confirmar calendario, alcance y responsabilidades de lanzamiento. |
| Se necesita una condición específica para un tipo de datos, una expresión sobre el valor de un campo o un destino compatible para un campo de origen admitido | Data Filter, Advanced Data Mapping o Data Transformation pueden cubrir esa necesidad acotada. | Confirmar tipos de datos, campos, expresiones y destinos compatibles. |
| Tablas controladas por contribuciones o campos personalizados cuyo tratamiento requerido supera el alcance de asignación compatible | Puede requerirse Custom Service. | Confirmar ubicación de los datos, significado empresarial y expectativa en el destino. |
| Deben seguir funcionando módulos antiguos o lógica de plantilla | Puede requerirse una sustitución en el destino o una revisión mediante Custom Service. | Separar la migración de datos de la implementación en el destino. |
La mejor pregunta inicial no es qué servicio parece más completo, sino qué evidencia demuestra el alcance real de la migración de la tienda.
Cuándo Standard Service encaja bien
Standard Service es adecuado cuando la migración de osCMax se centra principalmente en registros principales compatibles y el comercio acepta que la configuración del destino, la implementación del tema, la instalación de aplicaciones y el desarrollo personalizado son independientes de la migración de datos. Puede encajar en tiendas con Categories, Products, Customers, Orders, Reviews, Coupons, CMS Pages y otros datos elegibles relativamente directos que no dependan en gran medida de tablas personalizadas o lógica heredada de contribuciones.
En osCMax, Standard Service debe elegirse igualmente con cuidado. Una tienda puede parecer estándar desde la parte visible y ocultar módulos antiguos o campos personalizados en la base de datos. Antes de considerar suficiente Standard Service, el comercio debe confirmar que el valor empresarial principal reside en registros transferibles, no en comportamiento controlado por contribuciones.
Standard Service suele ser una opción más sólida cuando:
- se conoce la versión de la tienda;
- la estructura de la base de datos es comprensible;
- Products y Orders utilizan principalmente campos esperados;
- las plantillas no se consideran entregables de la migración;
- no se requiere que los módulos antiguos funcionen igual en la plataforma de destino;
- las muestras de validación demuestran que los registros migrados conservan su significado empresarial.
La señal de decisión es sencilla: Standard Service resulta adecuado cuando el objetivo es transferir datos compatibles, no recrear el antiguo entorno osCMax.
Cuándo Managed Service aporta valor
Managed Service es valioso cuando el comercio necesita coordinación, apoyo para planificar la migración, control del alcance y validación guiada. No convierte cada comportamiento heredado no compatible en un entregable estándar, pero ayuda a gestionar una migración en la que hay que revisar evidencia, secuenciar decisiones y aplicar una validación más disciplinada.
En osCMax, Managed Service suele tener sentido cuando la tienda es antigua, cuenta con varias contribuciones, presenta una calidad de datos incierta o requiere coordinación entre responsables técnicos y revisores de negocio. El comercio puede no necesitar una transformación a medida en cada área, pero sí ayuda para decidir qué migrar, qué excluir, qué asignar y qué validar antes de Full Migration.
Managed Service es especialmente útil cuando:
- el comercio tiene un catálogo grande o un historial considerable de Orders;
- existe evidencia de versión, pero los cambios antiguos requieren interpretación;
- varios responsables deben aprobar resultados de catálogo, Customers, Orders, contenido y SEO;
- se espera que los resultados de Demo Migration influyan en decisiones de asignación o configuración;
- el calendario de lanzamiento requiere una revisión disciplinada en lugar de comprobaciones improvisadas.
| Necesidad de Managed Service | Ejemplo en osCMax | Beneficio para la planificación |
|---|---|---|
| Coordinación del alcance | Algunas contribuciones siguen activas y otras están abandonadas. | Ayuda a decidir qué pertenece al alcance de la migración. |
| Planificación de la validación | Deben revisarse imágenes, atributos, Orders y contenido. | Reduce sorpresas antes del lanzamiento. |
| Secuencia de decisiones | Demo Migration puede revelar campos personalizados o dependencias de módulos antiguos. | Permite tomar decisiones por etapas antes de Full Migration. |
| Alineación de responsables | El responsable técnico y el responsable de negocio conocen partes distintas de la tienda antigua. | Mantiene conectadas la evidencia, el alcance y la aprobación. |
Managed Service no sustituye a Custom Service cuando deben transformarse datos no compatibles. Es una ruta de gestión más sólida para migraciones que necesitan supervisión y decisiones estructuradas.
Dónde encajan los Add-ons en una migración de osCMax
Los Add-ons cubren necesidades de migración acotadas. Son útiles cuando el requisito es específico, compatible y se controla mediante filtrado de registros con condiciones basadas en campos para cada tipo de datos, transformación de valores de campos mediante expresiones o reasignación de campos de origen. En osCMax, los Add-ons pueden ayudar cuando los datos heredados necesitan un tratamiento selectivo que no requiere ingeniería a medida ni interpretar estructuras de origen no compatibles.
Algunos ejemplos son aplicar una condición compatible sobre un campo de Product para excluir Products inactivos, aplicar una expresión para transformar el valor de un campo compatible o reasignar un campo de origen conocido a un campo compatible del destino.
Los Add-ons no deben utilizarse como respuesta genérica a comportamientos antiguos de contribuciones. Si una contribución crea tablas personalizadas, almacena datos en campos poco habituales, modifica el proceso de compra o genera un informe del que todavía depende el negocio, el requisito puede necesitar Custom Service o una sustitución en el destino. Este límite es importante porque los Add-ons no prometen recrear módulos antiguos, plantillas, funciones administrativas ni aplicaciones personalizadas.
| Necesidad | Un Add-on puede encajar cuando | Un Add-on no basta cuando |
|---|---|---|
| Data Filter | La entidad, el campo de origen, la condición y la regla de inclusión o exclusión son compatibles y están claros. | El filtro depende de lógica personalizada oculta en el código. |
| Data Transformation | El campo de origen, la expresión y los valores de salida esperados son compatibles y pueden probarse. | La transformación depende de tablas personalizadas, comportamiento derivado o lógica a medida. |
| Advanced Data Mapping | El campo de origen y el campo de destino compatible son conocidos y están admitidos. | El destino requiere una estructura o un comportamiento no compatibles. |
La regla práctica es que los Add-ons son apropiados para ajustes de migración acotados, no para conservar comportamientos heredados desconocidos.
Cuándo se requiere Custom Service
Custom Service se requiere cuando la necesidad queda fuera del comportamiento de migración compatible y necesita una revisión específica. osCMax es una plataforma en la que este límite aparece con frecuencia porque las tiendas antiguas pueden contener registros controlados por contribuciones, campos personalizados cuyo tratamiento necesario supera el alcance de asignación compatible, tablas personalizadas, archivos modificados, informes a medida, lógica antigua de exportación, contenido vinculado a plantillas o funciones de la tienda creadas mediante código en lugar de datos estándar.
Custom Service puede ser necesario cuando el comercio quiere conservar un resultado empresarial, pero la evidencia muestra que ese resultado depende de estructuras no estándar. Por ejemplo, un formulario mayorista, lógica de contenido restringido, comportamiento especial de envío, una exportación personalizada de Orders, tratamiento antiguo de imágenes o navegación específica de una plantilla pueden no pertenecer a una migración de datos ordinaria. Primero debe identificarse si el requisito corresponde a datos, configuración, funcionalidad del destino o una transformación personalizada.
Custom Service debe delimitarse con precisión. No debe prometer automáticamente la configuración completa de la tienda de destino, la implementación de aplicaciones, desarrollo personalizado o rediseño del tema. Es una ruta de revisión y tratamiento personalizado para requisitos que necesitan un enfoque no estándar. En algunos casos, Custom Service puede migrar o transformar datos concretos. En otros, la recomendación correcta puede ser reconstruir el comportamiento directamente en la plataforma de destino.
Las señales de Custom Service incluyen:
- tablas o campos personalizados de base de datos vinculados a procesos empresariales activos;
- archivos principales modificados que cambian el significado del catálogo, Customers, Orders o proceso de compra;
- registros controlados por contribuciones sin un equivalente estándar en el destino;
- comportamiento de módulos antiguos que debe conservarse para mantener la continuidad operativa;
- transformaciones a medida necesarias antes de que los datos puedan utilizarse;
- necesidades de plataforma personalizada o comportamiento de origen no compatible.
Para osCMax, Custom Service debe entenderse como una herramienta de precisión. Evita que el proyecto trate comportamiento heredado personalizado como si fueran datos ordinarios.
Custom Service no incluye automáticamente reconstruir contribuciones heredadas, sustituir plantillas, recrear el comportamiento del proceso de compra, actualizar la aplicación antigua o desarrollar la plataforma de destino, salvo que esas responsabilidades se incluyan expresamente en el alcance acordado.
Separe la migración de datos de las decisiones de reconstrucción en el destino
Una de las decisiones más importantes sobre la ruta de servicio en un proyecto osCMax es determinar si una función heredada debe migrarse, reconstruirse, sustituirse o retirarse. Muchas tiendas osCMax incorporaron funcionalidad mediante contribuciones y cambios en archivos. Algunas de esas funciones almacenan datos que pueden migrarse. Otras crean comportamientos que pertenecen a la configuración o desarrollo del destino. Tratar todo como migración de datos genera expectativas poco realistas.
Una galería de imágenes de Product, una tabla especial de envíos, una regla de contenido restringido, una exportación personalizada de Orders o un bloque de navegación basado en plantilla pueden ser importantes para el comercio. Pero no necesitan la misma respuesta. Los registros de imágenes pueden migrarse si la estructura es compatible y los recursos están disponibles. La lógica de envío puede requerir configuración del destino. El acceso restringido puede necesitar asignación de grupos de Customer, funciones del destino o un nuevo enfoque de control de acceso. Las exportaciones de Orders pueden sustituirse por herramientas de informes de la plataforma de destino. Los bloques de plantilla pueden convertirse en contenido, trabajo de tema o elementos de interfaz retirados.
Por tanto, la ruta de servicio debe incluir una revisión del destino de cada comportamiento. Cada función heredada importante debe recibir uno de cuatro resultados: migrar como datos compatibles, ajustar mediante Add-ons, revisar mediante Custom Service o reconstruir fuera del alcance de migración de datos. Así se controla mejor el proyecto y se evita convertir Custom Service en una categoría general para cualquier función antigua.
| Tipo de comportamiento heredado | Primera pregunta adecuada | Ruta de tratamiento probable |
|---|---|---|
| Datos almacenados en campos compatibles | ¿Puede asignarse el campo correctamente a la plataforma de destino? | Standard Service, Managed Service o Add-ons. |
| Datos almacenados en tablas personalizadas | ¿Qué significado empresarial debe conservarse? | Revisión mediante Custom Service. |
| Comportamiento creado por módulos antiguos | ¿Sigue necesitándose ese comportamiento en la nueva tienda? | Configuración o sustitución en el destino, o revisión mediante Custom Service. |
| Presentación basada en plantillas | ¿Se trata de contenido, navegación o diseño? | Planificación de tema/contenido en el destino, no migración automática de datos. |
| Funciones de conveniencia administrativa | ¿Afectan a datos históricos o solo a productividad administrativa? | Normalmente sustitución, retirada o configuración separada en el destino. |
Esta separación es especialmente importante para comercios que quieren que la nueva tienda sea más estable que la anterior. El enfoque de migración debe conservar la continuidad empresarial, no reconstruir todas las soluciones provisionales acumuladas históricamente.
Defina quién es responsable de cada decisión de validación
La selección del servicio también depende de quién sea responsable de validar los resultados. Una migración puede estar bien ejecutada técnicamente y, aun así, no superar la revisión previa al lanzamiento si nadie confirma el significado empresarial. Las migraciones de osCMax suelen necesitar revisores distintos para datos del catálogo, expectativas de plantilla, historial de Orders, grupos de Customer, referencias de envío y comportamiento heredado de contribuciones. La ruta de servicio debe tener en cuenta esta carga de coordinación.
Un comercio pequeño con registros limpios puede validar directamente los resultados después de Demo Migration. Una tienda mayor o más personalizada puede necesitar Managed Service porque la revisión exige coordinación entre propietario de la tienda, desarrollador, operaciones, SEO y atención al cliente. Custom Service puede ser necesario cuando un revisor técnico debe interpretar tablas personalizadas o comportamiento del código antes de cerrar el plan de migración.
La responsabilidad de validación debe definirse antes de Full Migration. El revisor del catálogo debe confirmar estructura de Products, atributos, imágenes y Categories. El revisor de operaciones debe confirmar estados de Orders, etiquetas de pago, referencias de envío y necesidades de informes. El revisor de la tienda debe confirmar CMS Pages, navegación y recursos importantes. El revisor técnico debe determinar si los datos personalizados necesitan tratamiento específico. Esta división mantiene la ruta de servicio ajustada a la realidad porque muestra si el comercio solo necesita ejecución o también coordinación e interpretación personalizada.
| Función de revisión | Área de osCMax que debe confirmar | Impacto en la ruta de servicio |
|---|---|---|
| Propietario de la tienda | Significado comercial y prioridades de lanzamiento. | Aclara qué debe continuar y qué puede cambiar. |
| Revisor del catálogo | Products, atributos, Categories, imágenes, ofertas especiales. | Confirma si Standard Service o Add-ons son suficientes. |
| Revisor de operaciones | Orders, estados, envío, pago, exportaciones. | Identifica señales para Managed Service o Custom Service. |
| Revisor técnico | Archivos, tablas, módulos y plantillas personalizados. | Determina si hace falta una revisión específica. |
| Revisor de SEO/contenido | CMS Pages, URL, metadatos, recursos de navegación. | Separa el alcance de la migración del trabajo SEO en el destino. |
Una ruta de servicio que ignore la responsabilidad de validación está incompleta. La complejidad de osCMax suele descubrirse no en la exportación, sino al revisar qué significa esa exportación.
Utilice Entity Points para dimensionar el alcance, no para puntuar la complejidad
Entity Points ayudan a dimensionar la migración de registros elegibles. Los nuevos Products, Customers, Orders y Blog Posts elegibles consumen Entity Points cuando se migran por primera vez. En actividades posteriores de osCMax, los registros elegibles ya contabilizados siguen contándose una sola vez en la misma ruta de migración; la complejidad de contribuciones, plantillas, tablas personalizadas y código heredado se evalúa por separado.
En osCMax, esta regla es importante porque la complejidad y el número de registros no siempre avanzan juntos. Una tienda con muchos Products estándar puede ser amplia pero manejable. Una tienda con menos registros y varias contribuciones activas puede requerir más revisión específica. Entity Points ayudan a planificar el volumen de registros elegibles, pero no miden la incertidumbre de versión, dependencia de contribuciones, riesgo de tablas personalizadas, acoplamiento de plantillas ni comportamiento antiguo del proceso de compra.
El comercio debe utilizar Entity Points para responder a una pregunta: ¿cuántos datos elegibles se están migrando? La evaluación de la ruta de servicio responde a otra distinta: ¿qué complejidad existe alrededor de esos datos?
| Pregunta de planificación | ¿Usar Entity Points? | ¿Usar revisión de la ruta de servicio? |
|---|---|---|
| ¿Cuántos Products, Customers, Orders o Blog Posts nuevos y elegibles se migran por primera vez? | Sí | A veces |
| ¿Una contribución personalizada necesita tratamiento específico? | No | Sí |
| ¿El comportamiento antiguo de imágenes o plantillas necesita validación? | No | Sí |
| ¿Una segunda acción de migración debe consumir Entity Points para los mismos registros ya contabilizados? | No | Revisar solo si se añaden nuevos registros elegibles |
| ¿La tienda necesita Add-ons o Custom Service? | No por sí solo | Sí |
Esta distinción evita un error habitual de planificación: asumir que una cantidad pequeña de registros implica una migración sencilla de osCMax.
Utilice Demo Migration para elegir la ruta final
Demo Migration es la forma más segura de comprobar si el enfoque seleccionado es realista. En osCMax, Demo Migration debe incluir algo más que Products limpios y Orders recientes. Debe incluir registros representativos que expongan supuestos sobre linaje de versiones, contribuciones, plantillas, imágenes, Customers, contenido y Orders.
Demo Migration debe responder varias preguntas. ¿Llegan correctamente los registros principales? ¿Los atributos e imágenes de Product conservan un significado utilizable? ¿Siguen siendo comprensibles las relaciones entre Customers y Orders? ¿Los estados antiguos, descuentos, referencias de envío y etiquetas de pago tienen sentido en el contexto del destino? ¿CMS Pages y los registros de contenido se representan adecuadamente? ¿Existen registros en la base de datos antigua que no aparecen en los resultados compatibles de migración porque pertenecen a estructuras personalizadas o específicas de contribuciones?
Si Demo Migration confirma los resultados esperados, el proyecto puede avanzar hacia Full Migration con la ruta de servicio seleccionada. Si Demo Migration revela campos ausentes, relaciones inesperadas, estructuras no compatibles o comportamiento personalizado, la ruta de servicio debe ajustarse antes de Full Migration. El ajuste puede implicar Add-ons, coordinación mediante Managed Service, revisión mediante Custom Service o la decisión de sustituir el comportamiento antiguo en la plataforma de destino en lugar de migrarlo.
Demo Migration no es una vista previa ceremonial. Es el punto de decisión en el que las suposiciones se convierten en evidencia.
Planifique cuidadosamente las Additional Migration Options
Las Additional Migration Options son relevantes cuando se necesita una migración posterior sobre la ruta inicial. En osCMax, esta planificación resulta especialmente útil cuando el comercio debe continuar después de que se hayan creado nuevos registros, ajustar la configuración tras los resultados de Demo Migration o reiniciar con supuestos de alcance sustancialmente distintos.
Hay tres rutas prácticas. El comercio puede Continue the Migration with the Last Used Configuration cuando la configuración original siga siendo válida. Puede continuar la migración con una nueva configuración cuando hayan cambiado decisiones de asignación, filtrado o configuración. O puede Perform a New Migration cuando el proyecto necesite un resultado migrado distinto y el resultado anterior ya no deba seguir siendo la base de trabajo, manteniendo sin cambios la ruta de migración adquirida.
En osCMax, la elección debe basarse en evidencia. Si después de la última migración solo aparecieron nuevos Orders elegibles, continuar con la última configuración puede ser suficiente. Si Demo Migration mostró que los campos de Product, grupos de Customer o tratamiento de contenido necesitan una configuración diferente, una nueva configuración puede ser más segura. Si el comercio descubre una capa importante de datos controlada por contribuciones, puede ser más adecuado generar un nuevo resultado migrado después de resolver el alcance. Una plataforma de destino diferente exige adquirir otro servicio de migración porque la ruta de migración comprada no puede cambiar.
| Situación posterior | Opción más adecuada | Motivo |
|---|---|---|
| Mismo alcance, misma configuración, nuevos registros elegibles | Continue the Migration with the Last Used Configuration | Mantiene coherente la ruta de migración. |
| Misma tienda, pero cambian la asignación o el filtrado | Continue the Migration with a New Configuration | Refleja las decisiones de migración actualizadas. |
| Cambio importante del alcance o del resultado de destino dentro de la misma ruta de plataformas adquirida | Perform a New Migration | Evita arrastrar el resultado migrado anterior a un proyecto modificado; una ruta de plataformas diferente exige un servicio de migración independiente. |
| Se descubren datos personalizados después de Demo Migration | Revisar antes de elegir | Puede requerir Custom Service en lugar de una simple continuación. |
Las Additional Migration Options deben ayudar a mantener el control. No deben utilizarse para posponer decisiones difíciles sobre el alcance.
Conclusión
El enfoque adecuado para migrar hacia osCMax depende de cuánto de la tienda antigua sean datos limpios y cuánto dependa del funcionamiento de contribuciones, archivos personalizados, plantillas, historial de versiones y supuestos del hosting. Standard Service puede encajar con registros compatibles y limpios. Managed Service añade coordinación y control de validación. Los Add-ons cubren necesidades acotadas de filtrado de registros, transformación de valores de campos y reasignación de campos. Custom Service trata registros no estándar, tablas personalizadas, transformaciones a medida y comportamiento controlado por contribuciones que exige revisión específica.
Demo Migration debe convertir las suposiciones en evidencia antes de Full Migration. Las Additional Migration Options solo deben utilizarse cuando la ruta posterior esté clara. Así, la migración de osCMax se mantiene práctica, controlada y alineada con la tienda real en lugar de con una etiqueta simplificada.
Preguntas frecuentes
¿Puede una migración de osCMax utilizar Standard Service?
Sí, cuando la migración se centra principalmente en registros principales compatibles y el comercio no espera que el comportamiento de contribuciones antiguas, plantillas, módulos o código personalizado se recree como parte de la migración de datos.
¿Cuándo requiere osCMax Custom Service?
Custom Service es adecuado cuando el significado empresarial activo depende de tablas personalizadas, campos personalizados cuyo tratamiento requerido supera el alcance de asignación compatible, archivos modificados, registros controlados por contribuciones, transformaciones a medida, comportamiento de origen no compatible o requisitos de plataforma personalizada.
¿Cómo debe influir Demo Migration en la ruta de servicio?
Demo Migration debe confirmar si la ruta seleccionada trata correctamente los registros representativos. Si revela estructuras no compatibles, campos personalizados ausentes o comportamiento controlado por contribuciones, la ruta de servicio debe ajustarse antes de Full Migration.
¿Qué evidencia debe prepararse para una revisión de Custom Service en una migración de osCMax?
Prepare ejemplos de osCMax que permitan rastrear campos controlados por contribuciones, tablas personalizadas y comportamiento del código heredado hasta la tienda, administración, informes o integración que todavía los utiliza. El alcance de Custom Service debe indicar la representación esperada en el destino, el responsable de la dependencia y la evidencia necesaria para la aceptación.