Botellones y bases
Esta es la sección más importante del dominio, y la que hace que Aquazaku no sea un punto de venta común.
Aquazaku tiene dos activos que salen pero no se venden. Se rastrean de forma distinta a propósito.
Dos activos, dos granularidades
Sección titulada «Dos activos, dos granularidades»Estado: ✅ Confirmada — definido por Aquazaku.
| Botellón | Base | |
|---|---|---|
| Qué es | El envase de agua | El soporte donde se apoya |
| Identificación | Solo cantidad | ID individual |
| Se entrega | En intercambio | En préstamo |
| Se asigna a | El cliente (cantidad) | Una dirección del cliente |
| Fricción del intercambio | Baja, se cambia sin trámite | Alta, es un activo asignado |
Por qué no todos los activos se rastrean igual
Sección titulada «Por qué no todos los activos se rastrean igual»Esta es una decisión de modelado deliberada, y vale entenderla antes de escribir una tabla.
El botellón se intercambia sin fricción. El cliente entrega uno vacío y
recibe uno lleno; a ninguna de las dos partes le importa cuál específicamente.
Ponerle ID a cada botellón obligaría al seller a escanear envases en la calle,
sin señal, en cada visita — y a cambio no responderías ninguna pregunta que la
cantidad no responda ya.
La base se presta. Es un activo asignado, va a una dirección concreta y tiene que volver de esa dirección. Ahí sí necesitás saber cuál: qué base está en qué lugar, desde cuándo, y a quién reclamársela.
Botellones
Sección titulada «Botellones»Fungibles. Se controlan por cantidad, nunca por unidad.
RN-ENV-01 — El botellón no tiene identificador individual
Sección titulada «RN-ENV-01 — El botellón no tiene identificador individual»Estado: ✅ Confirmada
El sistema conoce cantidades, no unidades. No existe “el botellón número 4728”.
Se conoce:
- La cantidad total en stock de la empresa, por ubicación.
- La cantidad que tiene cada cliente en su poder.
Por qué: el intercambio es de baja fricción para ambas partes y tiene que seguir siéndolo. Identificar cada envase agregaría un paso a cada visita sin responder ninguna pregunta nueva.
RN-ENV-02 — La cantidad de botellones se conserva
Sección titulada «RN-ENV-02 — La cantidad de botellones se conserva»Estado: 🟡 Supuesto
En todo momento:
botellones en bodega+ botellones en rutas+ botellones en poder de clientes+ botellones descartados= total de botellones registradosEsta igualdad siempre se cumple. Si no cuadra, hay un bug o un movimiento sin registrar.
Por qué: es el invariante del sistema — la ley de conservación del inventario de botellones. Sin ID individual, esta igualdad es lo único que te avisa que algo se perdió.
RN-ENV-07 — El estado lleno/vacío queda fuera del alcance inicial
Sección titulada «RN-ENV-07 — El estado lleno/vacío queda fuera del alcance inicial»Estado: ✅ Confirmada — no se modela por ahora, a pedido de Aquazaku.
Hoy se empaca bajo demanda: no hay stock de botellones llenos esperando, se llenan cuando hay venta. Con ese modo de operación, distinguir lleno de vacío no responde ninguna pregunta que hoy alguien se haga.
Cuando el volumen crezca y se pase a envasar contra stock, la distinción sí va a hacer falta:
| Estado | Qué significa |
|---|---|
| Vacío | Volvió del cliente. Espera lavado y llenado. |
| Lleno | Sellado y listo para despachar. Ya consumió agua, tapa y sello. |
La pregunta que hoy no existe y mañana sí: ¿cuántos botellones tengo listos para salir mañana?
Cuando llegue el momento, el inventario pasa a ser una matriz de ubicación × estado:
vacío llenoBODEGA 12 40RUTA:3 5 8CLIENTES — 63 ← siempre llenos al entregarEl invariante de conservación (RN-ENV-02) sigue valiendo sobre el total, sin importar el estado.
RN-ENV-03 — Una recarga intercambia un botellón, no lo vende
Sección titulada «RN-ENV-03 — Una recarga intercambia un botellón, no lo vende»Estado: 🟡 Supuesto
Al recargar, el cliente entrega un envase vacío y recibe uno lleno. Su saldo de botellones no cambia: sigue teniendo la misma cantidad.
Si el cliente no entrega el vacío, su saldo aumenta en uno. No se le cobra nada por eso: el envase queda registrado en su poder, no facturado (RN-BAS-08 — botellones sin garantía, sin depósito).
Es exactamente lo que pasa en una primera entrega: el cliente paga el agua y se lleva un envase que ahora figura en su saldo (RN-CAT-08).
Por qué: confundir recarga con venta de botellón hace que el inventario de envases se desangre sin que nadie lo note.
RN-ENV-04 — El saldo de botellones va por cliente
Sección titulada «RN-ENV-04 — El saldo de botellones va por cliente»Estado: ✅ Confirmada
El sistema sabe cuántos botellones tiene cada cliente en su poder. El saldo es a nivel cliente, no por dirección. Se mueve con cada entrega y cada retorno, nunca a mano.
Por qué: son botellones de Aquazaku que están afuera. Sin este saldo no se puede reclamar, ni cobrar depósito, ni detectar al cliente que acumula envases.
Y alcanza con el nivel cliente porque el botellón es fungible: para reclamar ocho botellones no hace falta saber en cuál de sus tres locales están. Es la misma lógica que hace que no tengan ID (RN-ENV-01).
RN-ENV-06 — Los botellones entran al parque por compra
Sección titulada «RN-ENV-06 — Los botellones entran al parque por compra»Estado: ✅ Confirmada
Aquazaku compra botellones para ampliar o reponer su parque de envases. Esa compra registra un activo retornable nuevo, no una entrada de producto vendible.
Por qué: un botellón comprado no se vende nunca — se suma al total que hay que conservar (RN-ENV-02). Si entrara como producto al stock de bodega, el sistema creería que tiene mercadería que en realidad es un envase.
RN-ENV-05 — Descartar botellones requiere motivo
Sección titulada «RN-ENV-05 — Descartar botellones requiere motivo»Estado: 🟡 Supuesto
Botellones rotos, perdidos o no recuperados se descartan indicando cantidad, motivo, responsable y fecha. Queda registrado como pérdida.
Por qué: la baja silenciosa es la forma más fácil de tapar un faltante.
RN-ENV-09 — Ningún botellón sale del parque sin un responsable
Sección titulada «RN-ENV-09 — Ningún botellón sale del parque sin un responsable»Estado: ✅ Confirmada (27-ago-2026).
Un botellón es de la empresa y vuelve. Si sale sin quedar anotado a nombre de alguien, no hay a quién reclamárselo.
La venta escribe el movimiento, en la misma transacción. Antes eran dos actos separados —vender la recarga, y después acordarse de registrar la entrega en otra pantalla— y ese olvido no dejaba ningún rastro.
Qué se pregunta en el mostrador
Sección titulada «Qué se pregunta en el mostrador»Cuántos se llevan y cuántos se reciben — dos números, no un sí/no (ver RN-VEN-17). La conversación real es «vendí tres recargas, trajo dos vacíos», y eso es un envase que sale y dos que vuelven.
Los defaults son 1-a-1 sobre la cantidad de botellones del carrito: el caso común es el intercambio y no cuesta ningún clic ni mueve el parque. El operador los ajusta si el caso no es intercambio (cliente nuevo que compra sin traer vacíos, cliente que devuelve más de lo que compra, etc.).
No se le cobra nada por llevárselo. El envase queda registrado en su poder, no facturado.
El alcance exacto
Sección titulada «El alcance exacto»| Caso | ¿Exige cliente? |
|---|---|
| Paca de bolsas al mostrador | No — no se lleva ningún retornable |
| Recarga con vacío de vuelta | No — el saldo no cambia, no sale nada |
| Recarga sin vacío de vuelta | Sí |
La regla es «ningún botellón sale sin responsable», no «toda venta necesita cliente». Exigir documento en cada venta llevaría a inventar clientes o —lo que pasa de verdad— a reusar el del anterior, que le cuelga el historial a alguien que no compró nada.
Tampoco se pueden despachar más envases que recargas vendidas. Si hacen falta envases sueltos, eso es una entrega y va por su propio camino, donde queda con su motivo en vez de escondida en una venta.
Registrarlo sin abandonar la venta
Sección titulada «Registrarlo sin abandonar la venta»La regla exige un cliente, y exigirlo a mitad de un cobro tiene un costo que no se ve en el enunciado: había que salir a la pantalla de clientes, llenar el formulario completo y volver con el carrito vacío, porque el mostrador vive en memoria. En la práctica eso empuja a no registrar a nadie.
Por eso el alta se hace desde el mismo mostrador, en un diálogo, con lo mínimo para poder reclamar el envase: nombre, documento y un teléfono. La dirección no se pide ahí —esa persona está en el mostrador, no pidió domicilio— y se completa después desde su ficha.
La anulación revierte los activos físicos
Sección titulada «La anulación revierte los activos físicos»La anulación de una venta con botellones o base inserta movimientos de reversión automáticos (cambio del 20-sep-2026 — antes el operador tenía que hacerlo a mano desde Retornables). Concretamente:
botellonesEntregados > 0→INSERT movimientos_botellon tipo='retorno'con signo opuesto (cliente devuelve lo que recibió).botellonesRecibidos > 0→INSERT movimientos_botellon tipo='entrega'con signo opuesto (la empresa devuelve al cliente lo que él trajo).- Base prestada →
UPDATE bases SET direccionId = NULL+INSERT movimientos_base tipo='retorno', identificados víamovimientos_base WHERE documentoId = ventaId AND tipo = 'prestamo'.
La semántica del tipo espeja el libro contable para que la auditoría lea de
forma coherente quién devuelve qué a quién. Ventas tipo='dano_base' se
excluyen: no tienen movimientos origen que revertir. Ver
RN-VEN-17.
Identificadas una por una. Se entregan en préstamo a una dirección.
RN-BAS-01 — Cada base tiene un identificador único
Sección titulada «RN-BAS-01 — Cada base tiene un identificador único»Estado: ✅ Confirmada
Toda base es una unidad distinguible con ID propio y estable durante toda su vida.
Por qué: se entrega en préstamo a una dirección concreta y hay que poder reclamar esa base a ese lugar.
RN-BAS-02 — La base se presta, nunca se vende
Sección titulada «RN-BAS-02 — La base se presta, nunca se vende»Estado: ✅ Confirmada
La base sigue siendo propiedad de Aquazaku mientras está en poder del cliente. No hay operación de venta de base.
RN-BAS-03 — Una base se asigna a una dirección, no a un cliente
Sección titulada «RN-BAS-03 — Una base se asigna a una dirección, no a un cliente»Estado: ✅ Confirmada
Un cliente puede tener varias bases, cada una en una dirección distinta. La asignación apunta a la dirección, no al cliente.
Cliente "Panadería del Centro"├── Dirección: Sucursal Norte → base #A-0412├── Dirección: Sucursal Sur → base #0913└── Dirección: Depósito → base #B-0027Por qué: si la base se asignara al cliente, no sabrías a cuál de sus tres locales ir a buscarla. La dirección es lo que hace reclamable el préstamo.
La base puede salir CON la venta
Sección titulada «La base puede salir CON la venta»Entregar una base era un segundo acto en otra pantalla: cobrar, y después acordarse de ir a Retornables a registrar el préstamo. El segundo acto es el que se olvida — con la base ya en el auto del cliente, nadie vuelve. Es exactamente el mismo problema que resolvió RN-ENV-09 con los botellones.
Así que el mostrador ofrece llevarse una base, y el préstamo entra en la misma transacción que la venta.
Se identifica por el sticker, no por el id interno: en el mostrador nadie
conoce el UUID de una base, conoce el 0042 pegado encima. Y la dirección se
elige entre las de ese cliente, que se piden recién cuando ya se sabe de
quién — con una sola, viene elegida.
Dónde está cada base lo resuelve un JOIN
Sección titulada «Dónde está cada base lo resuelve un JOIN»La pantalla de Retornables pedía las direcciones de todos los clientes para poder cruzar cuál corresponde a cada base: una petición por cliente. Con los cuarenta de hoy pasa desapercibido; con mil son mil una peticiones cada vez que alguien abre la pantalla, para mostrar como mucho cuarenta direcciones.
GET /bases ahora devuelve la ubicación pegada a cada base. Medido contra la
base de desarrollo: una consulta, 0,8 ms para las 38 bases. Y la carga de la
pantalla pasó a hacer cero peticiones a /clientes.
Primero el tipo, después el número
Sección titulada «Primero el tipo, después el número»api rechaza la base inexistente, la dada de baja, la dañada y la que figura en
otra dirección. Siempre lo hizo. Lo que faltaba era cuándo se entera quien
atiende: el rechazo llegaba al cobrar y tumbaba la venta entera —productos,
medio de pago, descuento— por un dedazo en un campo opcional de cuatro
dígitos, con el cliente enfrente. El costo del error no guardaba ninguna
relación con su tamaño.
La primera respuesta fue un aviso: el campo consultaba al salir del foco y
adelantaba el veredicto de api. Funcionaba, y con un solo tipo de base el
argumento para teclear era bueno — el número está pegado en la base que la
persona tiene en la mano, y cuatro dígitos salen más rápido que buscar en un
desplegable de cuarenta.
RN-BAS-14 lo invalidó. Con dos parques, el cliente pide «un dispensador», no «la 0913», y quien cobra no sabe cuál de las cuarenta lo es. El número dejó de ser suficiente para identificar lo que el negocio pide.
Hoy los dos lugares que prestan una base —el mostrador y Retornables— hacen las preguntas en el orden en que el negocio las hace:
| Paso | Qué se pregunta | Qué se ofrece |
|---|---|---|
| 1 | Qué tipo de base | Solo los tipos que tienen alguna libre en bodega |
| 2 | Cuál base | Solo los números de ese tipo, en bodega y sanos |
Y el dedazo desaparece con el campo. No hay nada que teclear, así que no hay código inexistente, ni dado de baja, ni dañado, ni prestado que avisar: esas opciones no están en la lista. El aviso al salir del foco se fue junto con el problema que resolvía.
Con un solo tipo con stock no se pregunta el tipo. Preguntar entre una opción es una pregunta que no existe — el mismo criterio que usa el desplegable de direcciones con el cliente que tiene una sola.
RN-BAS-04 — Una base está en exactamente un lugar
Sección titulada «RN-BAS-04 — Una base está en exactamente un lugar»Estado: 🟡 Supuesto
En todo momento cada base está en una y solo una de estas situaciones:
┌──────────┐ carga de ruta ┌──────────┐ préstamo ┌───────────────────┐│ BODEGA │ ──────────────▶ │ RUTA │ ───────────▶ │ DIRECCIÓN CLIENTE ││ │ ◀────────────── │ │ ◀─────────── │ │└──────────┘ devolución └──────────┘ retiro └───────────────────┘ │ │ └──────────────── baja (rota / perdida) ◀──────────────────┘ requiere motivoEs el equivalente de RN-ENV-02 para un activo identificado: en vez de cuadrar cantidades, cada unidad tiene exactamente una ubicación.
Por qué: una base que figura en dos lugares —o en ninguno— es un bug de inventario que se descubre cuando vas a reclamarla y no está.
RN-BAS-05 — Toda base tiene historial completo
Sección titulada «RN-BAS-05 — Toda base tiene historial completo»Estado: 🟡 Supuesto
Se puede reconstruir dónde estuvo cada base, desde cuándo y por orden de quién.
Por qué: es lo único que justifica el costo de darle un ID. Si no vas a poder responder “¿dónde estuvo esta base?”, el ID no está pagando su precio.
RN-BAS-06 — Descartar una base requiere motivo
Sección titulada «RN-BAS-06 — Descartar una base requiere motivo»Estado: 🟡 Supuesto
Una base rota, perdida o no recuperada se descarta con motivo, responsable y fecha. No desaparece del historial: cambia de estado.
RN-BAS-07 — La entrega de bases es autónoma: pos decide, basta con cliente verificado
Sección titulada «RN-BAS-07 — La entrega de bases es autónoma: pos decide, basta con cliente verificado»Estado: ✅ Confirmada — cerrá la pregunta #11 de Qué falta preguntar.
Entregar una base es un diferenciador competitivo de Aquazaku, así que la fricción tiene que ser mínima para clientes ya verificados.
Reglas:
| Estado del cliente | ¿Se entrega base? | Comentario |
|---|---|---|
VERIFICADO |
✅ sí, pos decide de forma autónoma |
No hace falta pedir permiso a admin |
PENDIENTE |
❌ no, hasta verificar | — |
pos puede verificar Y entregar la base en una sola operación. Si un cliente
nuevo llega a la planta con su documento, pos lo coteja (acto pos_manual en
RN-CLI-14), marca el cliente como VERIFICADO en el
mismo momento, y entrega la base. Esta es la vía de menor fricción y es
la que se va a ofrecer como onboarding por defecto.
Por qué: cualquier cliente nuevo que pida base ya está dando una señal de
intención seria. Frenar la entrega hasta que un admin valide (que vive en
otra ciudad) perdería la venta. La verificación por pos en el momento es
suficiente — admin_oficial puede llegar después si hace falta afinar algo.
RN-BAS-08 — Daño a la base = recargo automático al cliente, en cualquier momento del ciclo
Sección titulada «RN-BAS-08 — Daño a la base = recargo automático al cliente, en cualquier momento del ciclo»Estado: ✅ Confirmada — cerrá la pregunta #23 de Qué falta preguntar.
Botellones: sin garantía nunca. Se intercambian, no se venden. El sistema solo sabe cuántos tiene el cliente (RN-ENV-04). Sin depósito, sin recargo por daño.
Bases: sin garantía al prestar, pero SÍ recargo si se daña la base en cualquier momento del ciclo de vida del cliente. No solo al darlo de baja — en cualquier visita que el operario lo evidencie.
Mecánica del recargo
Sección titulada «Mecánica del recargo»base = { id_interno: uuid, id_sticker: string, // el ID impreso en el sticker físico estado: "sana" | "danada", // (NUEVO — agregado en RN-BAS-08) danada_por: user_id | null, // (NUEVO) danada_en: timestamp | null, // (NUEVO) recargo_generado_id: venta_id | null, // (NUEVO) asignada_a: direccion_id | null, ...}Cuando se evidencia daño:
posoadminregistra el estadodanadacon motivo y timestamp.- El sistema crea automáticamente una venta con
tipo = "DANO_BASE"ymotivo = "..."por el valor de reposición de la base, que depende del tipo (RN-BAS-14): reponer un dispensador no cuesta lo que reponer una estructura metálica. - La venta se registra con el medio de pago que se acuerde con el cliente (contado o crédito si está habilitado y verificado).
- El cargo va al
cliente.cargos_pendientes(4° saldo de RN-CLI-06).
RN-BAS-09 — Una sola clase de base, sin SKU
Sección titulada «RN-BAS-09 — Una sola clase de base, sin SKU»Estado: ⛔ Derogada el 11-oct-2026 — reemplazada por RN-BAS-14. Aquazaku compró un segundo tipo de base.
Todas las bases de Aquazaku son iguales. No hay tipos, modelos, ni SKUs distintos. Esto simplifica:
- Schema: la tabla
basesno necesita atributotipo_base. - Sticker: el ID del sticker es puramente único, no codifica tipo.
- Reportes: no hay “base tipo X” vs. “tipo Y” — todas son iguales para análisis.
- Evolución: si en el futuro apareciera un segundo modelo, hay que volver a esta conversación — no es un toggle.
RN-BAS-10 — Sticker pegado con ID es el método actual de identificación
Sección titulada «RN-BAS-10 — Sticker pegado con ID es el método actual de identificación»Estado: ✅ Confirmada — cerrá la pregunta #24 de Qué falta preguntar.
Las bases se identifican con un sticker pegado. La asignación base ↔
cliente + dirección se hace manualmente en el sistema cuando el pos
entrega o retira.
base.id_interno = uuid // clave primaria del sistemabase.id_sticker = char(4) // cuatro dígitos: 0001 a 9999El formato son cuatro dígitos con los ceros adelante — 0001, 0040,
0913. Aceptar 913 junto a 0913 crearía dos códigos para la misma base
física, y la unicidad —que es lo único que garantiza saber cuál está dónde—
dejaría de proteger nada.
Comprar bases
Sección titulada «Comprar bases»Cuando entran varias de una vez, se registran con una cantidad y el sistema las numera en orden — igual que la compra de botellones. Llegan sin rotular, y los stickers se imprimen después con los números que el sistema asignó.
O entran todas o no entra ninguna. Una compra a medio registrar deja al operario sin saber cuántas cargó ni desde qué número seguir, y con los stickers ya impresos el hueco quedaría en la caja y no en la pantalla.
Quién es dueño del número
Sección titulada «Quién es dueño del número»El sistema propone, el sticker manda. Los dos caminos existen porque los dos casos son reales:
| Caso | Quién decide |
|---|---|
| Las 40 bases que Aquazaku ya tiene, con el rótulo pegado | El sticker: el operario tipea lo que tiene en la mano |
| Una base nueva sin rotular | El sistema: propone el próximo consecutivo |
| Un sticker ilegible que hay que reemplazar | El operario: pisa la propuesta con el número nuevo |
El tercer caso es el que justifica que la propuesta sea pisable y no impuesta. Está advertido más abajo en esta misma regla, y sin ese camino necesitaría un parche especial.
Flujo del pos al entregar una base:
- Elige cliente + dirección en el sistema.
- Tipea el
id_stickerque está pegado a la base que va a entregar. - El sistema valida que ese
id_stickerexiste y no está ya asignado a otra dirección. - Se crea la asignación
dirección → base.
Futuras mejoras (no MVP): integrar escaneo de QR/barcode desde la cámara del celular para eliminar el tipeo manual.
RN-BAS-11 — Sin tope duro de botellones por cliente; admin aprueba casos atípicos
Sección titulada «RN-BAS-11 — Sin tope duro de botellones por cliente; admin aprueba casos atípicos»Estado: ✅ Confirmada — cerrá la pregunta #26 de Qué falta preguntar.
En la operación actual de Aquazaku, los clientes no suelen acumular
botellones en exceso — el intercambio natural lo previene. Si en algún caso
atípico un cliente acumula muchos, el admin evalúa y aprueba el caso.
cliente.botellones_en_su_poder = number // siempre conocidocliente.botellones_acumulacion_aprobada = { aprobado: bool, aprobado_por: user_id | null, aprobado_en: timestamp | null, motivo: string | null,}- Default: el cliente puede acumular sin límite (es raro que pase).
- Casos atípicos: el
adminregistra la aprobación (informational/auditable, no es un toggle funcional). - El sistema continúa trackeando el saldo real; la aprobación es trazabilidad, no cap.
Por qué no hace falta cap en MVP: el modelo de stock se conserva
(RN-ENV-02). Si un cliente
acumula mucho, el sistema lo sabe — y el pos y admin lo ven. La prevención
es visibilidad, no bloqueo.
RN-BAS-12 — Base y botellones son activos independientes
Sección titulada «RN-BAS-12 — Base y botellones son activos independientes»Estado: ✅ Confirmada — cerrá la pregunta #27 de Qué falta preguntar.
La conjunción base + botellones NO es obligatoria en el sistema. El default para onboarding es que aparezcan juntos (cliente nuevo → base + primer pedido), pero los ciclos de vida son independientes y cualquier combinación es válida después.
| Estado de una dirección | Válido |
|---|---|
| Tiene base + botellones | ✅ (típico post-onboarding) |
| Solo base (sin botellones aún) | ✅ (cliente nuevo) |
| Solo botellones (sin base) | ✅ (compró pacas, o devolvió base) |
| Ninguno | ✅ (no ha comprado nunca) |
Implicaciones de UX:
- Onboarding de cliente nuevo: ofrecer flujo combinado “verificar → entregar base → primer pedido” como atajo sugerido. NO obligatorio.
- Gestión posterior: el sistema trata cada activo por su cuenta. Se puede devolver/devolver base sin tocar botellones, y viceversa.
- Reportes: las direcciones se analizan individualmente — cuántas tienen base, cuántas tienen botellones, cuántas tienen ambos.
RN-BAS-13 — Aviso de compra antes de quedarse sin bases
Sección titulada «RN-BAS-13 — Aviso de compra antes de quedarse sin bases»Estado: ✅ Confirmada (27-ago-2026). Demora del proveedor: 7 días. Desde el 11-oct-2026 el cálculo corre por tipo de base.
Avisa cuando las bases libres y sanas de un tipo son menos que las que se prestaron de ese tipo en los últimos 7 días.
El umbral se calcula, no se configura
Sección titulada «El umbral se calcula, no se configura»La pregunta correcta no es «¿cuál es el mínimo?» sino «¿cuántas se prestan mientras llega el pedido?». Y esa el sistema la sabe: cada préstamo queda con su fecha en el libro de movimientos.
Un umbral fijo habría que inventarlo hoy —sin operación todavía— y quedaría viejo el día que el negocio cambie de tamaño. Este se recalibra solo.
Es la misma disciplina que el valor de reposición de RN-BAS-08, que no se inventó: si el número no está, se pide o se deriva, no se elige.
Los detalles que lo hacen correcto
Sección titulada «Los detalles que lo hacen correcto»- Libres y sanas, no el total del parque. Una base dañada en bodega ocupa lugar y no se puede prestar; contarla haría que el aviso calle justo cuando hace falta.
- Préstamos brutos, no el neto contra retornos. Una base prestada se queda en el local del cliente y los retornos son raros. El neto daría casi cero en operación normal, y el aviso volvería a sonar recién en cero. El bruto sobreestima, y ese es el error correcto: avisar de más cuesta una compra anticipada; avisar de menos cuesta un cliente durante una semana.
- Sin operación no avisa. Al arrancar el ritmo es cero y no hay nada que decir. Un aviso que suena el primer día se aprende a ignorar.
- Cero libres avisa siempre, sin importar el ritmo: no se puede prestar lo que no hay, y ahí el aviso no depende de ninguna estimación.
- Un parque por tipo, no uno solo. Sumar los dos tipos en un número haría que veinte estructuras libres tapen que no queda ningún dispensador. El aviso callaría justo cuando hace falta, que es la falla que esta regla ataca — RN-BAS-14.
Qué muestra
Sección titulada «Qué muestra»Los dos números, no el veredicto, y con el tipo. «Quedan 3 dispensadores. En los últimos 7 días se prestaron 8.» Quien lo lee tiene que decidir cuántos pedir, y sin esos dos datos tendría que ir a buscarlos a otra pantalla antes de poder hacerlo.
Sin el tipo en el cartel el número no alcanza para pedir: no se le compra lo mismo a la misma persona.
Si alcanzan, no hay cartel. El sistema no felicita.
RN-BAS-14 — Dos tipos de base, un solo espacio de IDs
Sección titulada «RN-BAS-14 — Dos tipos de base, un solo espacio de IDs»Estado: ✅ Confirmada — por Aquazaku, 11-oct-2026. Reemplaza a RN-BAS-09.
Aquazaku compró un segundo tipo de base. Desde hoy hay dos:
| Tipo | Qué es |
|---|---|
estructura |
La estructura metálica. Es la única que existía hasta el 11-oct-2026 |
dispensador |
Entrega agua fría y caliente al usuario |
Las dos se prestan y no se venden, sin costo y sin depósito, exactamente igual (RN-BAS-02). El tipo no cambia cómo se entrega: cambia qué se tiene, cuánto vale reponerlo y cuándo hay que comprar más.
El tipo se declara al registrar la base, no al prestarla
Sección titulada «El tipo se declara al registrar la base, no al prestarla»Una base existe en el sistema antes de que un cliente la vea: entra al parque por compra y espera en la bodega. El tipo se declara ahí, en los tres caminos por los que nace una base —el registro de a una, la compra directa, y la línea de una compra a proveedor—. Ninguno queda afuera: el que quedara seguiría creando bases sin tipo.
Por qué no al entregarla, que es lo primero que uno piensa:
- El dato ya se conoce antes. La factura del proveedor dice cuántos dispensadores entraron. Preguntarlo al entregar es volver a derivar de la memoria del operario un hecho que ya estaba documentado.
- Sin tipo en bodega, el aviso de compra queda ciego. Se puede tener veinte estructuras libres y cero dispensadores, y RN-BAS-13 diría que alcanza. Es el fracaso exacto que esa regla existe para evitar.
- El error sería irreversible. El tipo acompaña a la base hasta su descarte (abajo). Un clic equivocado en el formulario de entrega declara una estructura metálica como dispensador para siempre, y solo se descubre yendo a mirarla.
Al entregar, el sistema muestra el tipo; no lo pregunta. El operario tipea
el id_sticker que tiene en la mano y la pantalla responde «0913 —
dispensador». Deja de ser una declaración y pasa a ser una verificación contra
el objeto físico.
El tipo no cambia nunca
Sección titulada «El tipo no cambia nunca»Una base es del tipo con el que se registró hasta que se descarta. No hay conversión: una estructura metálica no se vuelve dispensador porque nadie le instala un sistema de refrigeración en el camino. Son dos objetos distintos.
En la base de datos el tipo es obligatorio y sin valor por omisión. Un
default 'estructura' convertiría en estructura toda base mal registrada —
justo el error que esta regla ordena el flujo para evitar—. Si no se declara, el
registro falla.
Un solo espacio de IDs
Sección titulada «Un solo espacio de IDs»El id_sticker sigue siendo único entre todas las bases, sin importar el
tipo. No hay dos listas arrancando en 0001.
El consecutivo sale del máximo de todas las bases y nunca se recicla, igual
que antes (RN-BAS-10).
Si el parque llega a 0040 y entran tres dispensadores, son 0041, 0042 y
0043.
El ID no codifica el tipo, y eso se decidió a propósito:
- Un prefijo o un rango reservado —los dispensadores del
9000en adelante— sería un segundo lugar donde vive el tipo, y el día que discrepe con la columna nadie sabría cuál manda. - El número identifica; el tipo describe. Son dos trabajos distintos y el sticker solo puede hacer el primero: ya está pegado y el tipo se consulta en pantalla.
Una factura con los dos tipos son dos líneas
Sección titulada «Una factura con los dos tipos son dos líneas»Una línea de compra compra exactamente una cosa y lleva su propio costo unitario (RN-PRO-05). Diez estructuras y cinco dispensadores en la misma factura son dos líneas, cada una con su costo.
No es una limitación: es lo que hace que el sistema sepa qué costó un dispensador de verdad, en vez de un promedio entre dos objetos que no se parecen.
Las bases que ya existían son estructura
Sección titulada «Las bases que ya existían son estructura»Las bases cargadas antes del 11-oct-2026 quedan estructura en la migración.
No es un supuesto: cuando se registraron, el dispensador no existía como
producto de Aquazaku.
Preguntas abiertas
Sección titulada «Preguntas abiertas»(Las preguntas 🟡 de Retornables #23, #24, #25, #26, #27 quedaron todas cerradas en la sesión del 18-ago-2026. Los nuevos RN son BAS-08, BAS-09, BAS-10, BAS-11, BAS-12.)
La compra del dispensador abrió dos, las dos en Qué falta preguntar: el valor de reposición de cada tipo (la 39, que ahora necesita dos respuestas) y si la demora del proveedor es la misma para un dispensador que para una estructura metálica (la 48). La segunda le entra directo al umbral de RN-BAS-13.