Inna
cccc70338d
El prefijo venía del nombre de la app Django (`home`), jubilada y borrada hoy, así que ya no significaba nada: home_stripelog -> stripelog. La BD se sigue llamando django_wow por historia (renombrarla es otra operación). Comprobado antes de tocar nada: 0 colisiones con nombres existentes, 0 palabras reservadas (contrastado contra las 260 de MySQL), sin vistas ni triggers que dependieran de ellas. El RENAME va en una sola sentencia porque así es atómico, y MySQL reapunta solo las 4 claves ajenas entre estas tablas. 170 referencias actualizadas en 37 ficheros. Se dejó a propósito sql/drop_home_securitytoken_authuser_fk.sql sin tocar: es una migración ya aplicada y reescribirla sería falsear el historial. De paso salió un fallo previo: prices.ts consultaba `home_restoreitemprice`, una tabla que NO existe. El try/catch de priceFrom se comía el error y devolvía siempre el precio por defecto, así que el precio de restaurar objetos nunca fue configurable. Se deja documentado en el código; crear la tabla es otra decisión. Verificado tras aplicar: 0 tablas home_, las 51 siguen ahí, y el conteo exacto de filas cuadra con el volcado previo (store_item 3068, item_data 44873, stripelog 35, store_order 26, noticia 50). La web responde 200 en todas las rutas y la portada carga las noticias sin errores. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
46 lines
1.9 KiB
TypeScript
46 lines
1.9 KiB
TypeScript
/**
|
|
* Precios de la tienda en euros: conversión y mínimos de las pasarelas.
|
|
*
|
|
* Módulo PURO (sin acceso a BD), para que lo importen tanto la ruta de servidor
|
|
* como el componente de cliente y no puedan divergir: lo que enseña el carrito
|
|
* es exactamente lo que valida y cobra `/api/store/send`.
|
|
*/
|
|
|
|
// Duplicados a propósito de PD_PER_UNIT (lib/dpoints) y VP_PRICE_FACTOR
|
|
// (lib/pay-with-dpoints): esos módulos importan la BD y no pueden llegar al
|
|
// bundle del cliente. Mantener sincronizados (mismo criterio que
|
|
// PaymentMethodSelect). 100 PD = 1 €; los PV cuestan el doble: 200 PV = 1 €.
|
|
export const PD_PER_EUR = 100
|
|
export const PV_PER_EUR = 200
|
|
|
|
/**
|
|
* Importe mínimo por pasarela, en euros. Por debajo, la API de la pasarela
|
|
* rechaza el cobro, así que hay que impedirlo ANTES de crear el pedido.
|
|
*/
|
|
export const CARD_MIN_EUR: Record<'stripe' | 'sumup', number> = {
|
|
stripe: 1,
|
|
sumup: 1,
|
|
}
|
|
|
|
/**
|
|
* Máximo de copias de un mismo ítem por línea del carrito (igual que el MAX_QTY
|
|
* de send-gift). OJO con la diferencia: `copies` es cuántas VECES compras la
|
|
* línea, y no se confunde con `store_item.quantity`, que es el tamaño del
|
|
* lote que entrega cada copia (Paño de lino = 20). 2 copias de Paño de lino =
|
|
* 40 telas, y se envían como dos entradas `2589:20`.
|
|
*/
|
|
export const MAX_COPIES = 100
|
|
|
|
/** Euros de una línea, SIN redondear: un ítem en PV de precio impar cuesta medio céntimo. */
|
|
export function lineEur(price: number, currency: 'pd' | 'pv'): number {
|
|
return price / (currency === 'pv' ? PV_PER_EUR : PD_PER_EUR)
|
|
}
|
|
|
|
/**
|
|
* Coste del carrito en euros. Se redondea UNA vez, sobre el total: es el importe
|
|
* que se cobra, y NO la suma de las líneas redondeadas (que daría otro número).
|
|
*/
|
|
export function storeEuroTotal(pdTotal: number, vpTotal: number): number {
|
|
return Math.round((pdTotal / PD_PER_EUR + vpTotal / PV_PER_EUR) * 100) / 100
|
|
}
|