Conserva el siguiente cobro y el periodo pagado, no solo una marca temporal

El ancla establece el punto de referencia del ciclo recurrente. En una suscripción mensual puede coincidir con un día habitual; en una anual, con el aniversario. Sin embargo, la siguiente factura también depende del momento de creación, el inicio, una prueba, el comportamiento de prorrateo y las reglas del producto.

Durante una migración, el objetivo económico es mantener el servicio que el cliente ya pagó y asignar el próximo periodo a una sola cuenta. Dos suscripciones con la misma fecha visible pueden producir resultados distintos si una tiene partidas pendientes, uso medido, factura abierta o método `send_invoice`.

`start_date` indica cuándo comienza el calendario o la programación de destino. `billing_cycle_anchor` fija la cadencia. `trial_end` puede retrasar el primer cobro y no debe utilizarse como una prueba ficticia sin entender sus efectos en informes y eventos. El método de cobro decide si Stripe intenta un pago automático o envía una factura.

Añade cantidad, múltiples partidas, moneda, impuesto, descuento y prorrateo. Comprueba la zona horaria usada al convertir fechas. La validación debe mostrar tanto los valores configurados como la próxima factura esperada y el periodo que cubre.

Supón que un cliente ya ha pagado hasta su próxima renovación. La nueva suscripción no debe cobrar al crearse si eso repite el periodo. El equipo puede programar el inicio o ajustar la configuración admitida por el flujo elegido, verificar la vista previa y asegurarse de que el origen no cobre de nuevo después de la frontera.

No conviertas el ejemplo en una regla única para todas las suscripciones. Una prueba activa, un plan anual, una factura manual o una renovación demasiado próxima requieren tratamiento diferente. El kit de migración de Stripe incluye campos de inicio y ancla precisamente porque creación y cadencia son decisiones separadas.

En planes anuales o prepagados, registra el final del servicio ya pagado y evita generar una segunda factura. Las pruebas deben conservar su fecha y su intención comercial. Las suscripciones con varias partidas pueden compartir ciclo, pero cada precio y cantidad necesita una equivalencia.

Para `send_invoice`, valida días hasta vencimiento, estado y proceso de cobro manual. Los estados `past_due` o `unpaid` no deben transformarse silenciosamente en un cliente al corriente. Cuando una fecha está muy cerca del corte, puede ser más seguro dejar que el origen produzca el último cobro y programar el destino después, tal como explica Stripe para su flujo.

La facturación por uso necesita una decisión sobre dónde se cierra y factura el uso acumulado. Los calendarios de suscripción y cambios futuros también pueden tener fases que no se representan con un único ancla.

MoveMRR puede revisar anclas, pruebas y fechas dentro del proyecto y exponer advertencias antes de escribir. El operador sigue siendo responsable de definir la intención comercial, resolver configuraciones no admitidas y aprobar la acción del origen.

En el ensayo, compara la siguiente fecha e importe esperados con el origen. En producción, verifica la suscripción y cualquier factura o calendario creado. Después del corte, observa la primera renovación y ambas colas de facturas. Una simulación no garantiza autorizaciones bancarias ni elimina requisitos de autenticación.