Ir al contenido

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.

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.


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 registrados

Esta 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 lleno
BODEGA 12 40
RUTA:3 5 8
CLIENTES — 63 ← siempre llenos al entregar

El 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 y se aplica la política de envase prestado o en depósito.

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.


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 #A-0913
└── Dirección: Depósito → base #B-0027

Por 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.


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 motivo

Es 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.


  • ¿Se cobra depósito o garantía por la base prestada? ¿Y por el botellón no devuelto?
  • ¿Cómo se identifica físicamente una base — grabado, etiqueta, código de barras, QR? Define si el seller puede escanearla desde la app.
  • ¿Hay tipos o modelos distintos de base?
  • ¿Hay un límite de botellones que un cliente puede tener en su poder?
  • ¿Puede haber una dirección con base pero sin botellones, o viceversa?
  • ¿Quién autoriza el préstamo de una base — solo admin, o el seller puede dejar una base nueva en la calle?