KoratEl sistema de tienda online existe porque quien vende desde un hilo de chat acaba perdiendo un pedido. Lo que lo sustituye es deliberadamente poco vistoso: un catálogo con búsqueda y filtros por categoría, una ficha que enseña el stock antes del toque, un carrito que nunca es ambiguo sobre a qué tienda pertenece, y un pedido que recorre cinco estados con nombre y avisa en cada transición.
La ficha de producto: variantes, stock y descuento antes de tocar
Cada producto lleva fotos, descripción, stock y un precio que puede tener descuento: precio rebajado junto al original tachado con un distintivo de porcentaje, para que el tamaño del descuento se lea en vez de insinuarse. Cuando un producto está agotado, eso se dibuja encima de la foto, no se descubre al pagar. Aquí se aplica una regla de toda la app: lo que cambia lo que hace un toque tiene que verse antes del toque.
Las variantes se generan a partir de atributos en vez de meterse una a una. Quien vende declara los ejes — talla, color, lo que de verdad varía — y las combinaciones se convierten en variantes con su propio stock. Eso mantiene fuera de los datos el fallo habitual: tres fichas escritas por separado para la misma camiseta que nunca se pueden sumar en un informe, y un recuento de stock que solo es correcto para una de ellas.
El carrito pertenece a una tienda
El carrito es de una sola tienda. Añadir un artículo de otro vendedor pregunta antes de vaciar lo que ya había, en vez de construir en silencio una cesta repartida entre cuatro negocios. Es una negativa de diseño, no una función que falte: una cesta multitienda implica un solo pago, un solo cálculo de envío y un solo responsable cuando algo no llega, y nada de eso existe cuando los vendedores son cuatro negocios locales independientes con cuatro acuerdos de reparto.
Una tienda por carrito, a propósito. Cambiar de tienda pide vaciar el carrito. Una cesta repartida entre varios vendedores necesitaría un pago único para ser honesta, y aquí no hay un pago común de mercado: cada pedido es entre una persona y un negocio.
El coste de envío no es un campo que envíe la app. Se lee del registro de la propia tienda en el servidor al hacer el pedido, y solo se aplica a la entrega.
Pago: entrega o recogida, y un coste que el cliente no fija
El pago pregunta lo que un pedido necesita de verdad: entrega o recogida, nombre, teléfono, dirección, una nota y la forma de pago. Elegir recogida elimina el coste de envío por completo en vez de mostrarlo como cero, porque son dos estados distintos y un cero se lee como un error. Las direcciones vienen de una libreta con dirección predeterminada — y es una sola libreta, compartida con el perfil, porque una dirección de perfil y una de entrega son el mismo dato y guardarlo dos veces garantiza que las dos copias acaben discrepando.
El coste va en el servidor. place_shop_order lee businesses.delivery_fee de la base de datos e ignora el valor que envió el cliente, igual que la vía de comer en el local pone cada precio. Un campo del cliente en el que se confía es un descuento que uno se concede solo. Esto no es una política que se pueda desactivar en ajustes: es de dónde sale el número.
Cinco estados de pedido, seguimiento y aviso a las dos partes
Un pedido recorre pendiente, confirmado, empaquetando, enviado y entregado, con cancelado y rechazado como ramas finales. Quien compra ve una barra de progreso en vez de una palabra suelta, así que «empaquetando» se lee como una posición en una secuencia con algo después. En el paso de envío se adjunta un número de seguimiento junto a un transportista elegido de una lista mantenida por la administración que lleva una plantilla de URL de seguimiento: así el número que teclea la tienda se convierte en un enlace que el comprador puede abrir. Una tienda no puede adjuntar un número sin nombrar transportista, porque un número que no se sabe de quién es nunca puede convertirse en un enlace.
Los dos finales llevan motivo. Quien cancela tiene que decir por qué, y la tienda que rechaza también, y el motivo viaja con el pedido en vez de ser un mensaje que se pierde en un chat. Cada transición avisa a ambas partes, porque un flujo de pedidos sin avisos deja a las tiendas perdiéndose pedidos y a quien compra adivinando.
- pendiente — hecho, esperando a la tienda
- confirmado — aceptado, la tienda se compromete
- empaquetando — preparándose
- enviado — de camino, con número de seguimiento y transportista
- entregado — cerrado, y quien compró puede reseñar
El lado de quien vende: TPV, pedidos online y stock
Un negocio de comercio recibe tres módulos en la consola: un punto de venta para vender en persona, una consola de pedidos en línea para lo que llegó por la app, y productos y stock con avisos de existencias bajas. El panel lleva avisos en vivo que se refrescan cada pocos segundos, así que un pedido nuevo se anuncia en vez de esperar a que lo encuentren. Vender en el local y vender por la app escriben en el mismo libro.
Como los dos canales caen en el mismo sitio, los informes cubren todo el negocio y no solo la parte en línea: ingresos, número de pedidos, ticket medio, reparto entre efectivo, PromptPay y otros, los cinco más vendidos, un gráfico de ingresos de siete días y periodos de hoy, siete días, treinta o todo. Los tiques se reimprimen, y del mismo registro sale un tique compartible o un texto de factura. La lista de clientes se construye también desde ese libro, con notas y etiquetas, historial de compras, puntos que se acumulan a una tasa que fija el propio negocio en su moneda, contra un objetivo y una recompensa configurables.
El acceso del personal lo rige una matriz de permisos con roles predefinidos y ajustes por persona, así que a alguien del mostrador se le pueden dar productos y pedidos sin nómina ni informes. La misma matriz existe en la base de datos como has_capability(business_id, capability), que expande los roles en el servidor para las políticas de seguridad a nivel de fila: el servidor nunca acepta la palabra del cliente sobre qué rol tiene alguien.
Dos registros vecinos comparten la misma lógica de inventario. Lo que un negocio tiene sin venderlo — herramienta, maquinaria, mobiliario — vive en el registro de activos, y lo que presta contra una fianza pasa por los alquileres.
Reseñas de producto que solo escribe quien compró
Las reseñas de producto son distintas de la del negocio, y ambas se filtran igual: solo escribe quien la plataforma pueda demostrar que hizo una transacción. La elegibilidad es una vista de la base de datos, y comprar es uno de los tipos que califican, junto a comer en el local, pedir a domicilio, alojarse y usar un servicio. Todos los demás ven una tarjeta con candado que explica por qué no hay botón, en lugar de un botón que falla.
La puntuación en estrellas no es un número guardado que alguien edite. Un disparador de la base de datos la recalcula desde las filas de reseñas — el mismo mecanismo que detalla la página de confianza y seguridad —, así que la nota de la tarjeta y las reseñas de la página no pueden separarse. Quien compra puede editar su última reseña, borrarla o añadir otra en una compra repetida mientras la antigua se queda; la tienda puede responder públicamente.