Hola @lorena_89 y @joaquin_deco,
@joaquin_deco tiene razón. Tu enfoque actual, aunque la lógica del cálculo de antigüedad es correcta, está intentando integrar una funcionalidad compleja directamente en una clase central como Customer.php. Esto es muy frágil. PrestaShop 8.2.0, aunque robusto, no tiene un hook específico para 'modificar puntos de fidelidad por antigüedad' en el proceso de pedido.
Lo ideal para este tipo de lógica es un módulo propio que se encargue de ello y utilice los hooks adecuados. Por ejemplo, podrías usar actionPaymentConfirmation para añadir los puntos extra después de que un pedido se haya confirmado y pagado. Así, los puntos se añaden solo cuando la compra es final.
Aquí tienes un ejemplo de cómo podrías implementar la lógica de antigüedad dentro de un hook de un módulo custom, que es mucho más seguro que un override directo de la clase Customer:
public function hookActionPaymentConfirmation(array $params)
{
$order = $params['order'];
$customer = new Customer((int) $order->id_customer);
if (Validate::isLoadedObject($customer)) {
$registrationDate = new DateTime($customer->date_add);
$now = new DateTime();
$interval = $now->diff($registrationDate);
$seniorityYears = (int) $interval->format('%y');
if ($seniorityYears >= 5) {
Esta forma te permite encapsular la lógica y evitar conflictos con futuras actualizaciones. Para tiendas en producción que necesitan una implementación fiable y con interfaz de administración, un desarrollo a medida o una solución ya hecha como la solución para fidelidad – recompensas que ofrece estas reglas de antigüedad de forma más robusta y configurable, es lo más recomendado. Evitarás quebraderos de cabeza cada vez que actualices el core o tu tema.