The vendedor (seller) role in SansiStore owns the full lifecycle of every order — from the moment a buyer checks out to final delivery or cancellation. All seller pages live under theDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/ProcesosAgilesUMSS/sansistore/llms.txt
Use this file to discover all available pages before exploring further.
/seller/* path and are protected by Firebase Auth role checks; any authenticated user without the vendedor role is denied access. The sidebar navigation is driven by sellerNavGroups and sections constants, grouping pages into Pedidos, Registrar, and Operación sections.
Order Lifecycle Overview
Every order in Firestore moves through a strict sequence of statuses defined inOrderStatus:
Exceptions branch off intoCREADO→RESERVADO→EMPAQUETADO→LISTO→ASIGNADO→EN CAMINO→ENTREGADO/PAGADO
NO ENTREGADO, RECHAZADO, or CANCELADO.
Seller Portal Pages
Created Orders
New orders in status
CREADO awaiting seller acceptance. The seller reviews each order and reserves it, transitioning it to RESERVADO.Pending Orders
Orders in the
PENDIENTE state that are currently being processed. Fetched from /api/seller/pending-orders with a bearer token — requires the vendedor role.Reservations
Orders in
RESERVADO status with stock reserved in inventory. The seller confirms stock and prepares items for packaging.Packaged Orders
Orders in
EMPAQUETADO state. The seller verifies the package and marks it Listo to advance the order to the LISTO status.Ready Orders
Orders in
LISTO status, fully packaged and waiting for a courier (mensajero) to be assigned. This page opens the AssignMessengerModal.Failed Orders
Orders in
NO ENTREGADO status. The seller decides to restart the order (back to RESERVADO) or cancel it (to CANCELADO).Undelivered Orders
Also shows orders in
NO ENTREGADO. The useUndeliveredOrderDecision hook exposes restartOrder and cancelOrder actions; restarting re-reserves inventory when stockRestored is true.Rejected Orders
Orders with status
RECHAZADO. These are orders where the seller registered a delivery failure reason via registerDeliveryFailureReason.Order History
A complete, paginated audit log of all orders for the authenticated seller, sorted by
updatedAt descending. Used for reconciliation and dispute resolution.Core Seller Workflow
Receive a Created Order
The buyer places an order; Firestore writes a document to the
orders collection with status: 'CREADO' and sellerId set to the seller’s UID. The seller sees it on /seller/created-orders, powered by subscribeConfirmedOrders.Reserve the Order
The seller clicks Reservar.
reserveConfirmedOrder runs a Firestore transaction that checks status === 'CREADO' and updates it to RESERVADO, stamping reservedAt. Seller activity is logged via registrarActividadVendedor (HU #160).Package the Order
Once items are physically packed, the order transitions to
EMPAQUETADO. The /seller/packaged-orders page (PackagedOrdersPanel) lists all such orders and lets the seller confirm they are ready.Mark Order as Ready
The seller clicks Marcar como listo on a packaged order. The
markOrderReady validates status === 'EMPAQUETADO' inside a transaction then updates it to LISTO.useMarkOrderReady hook wraps this and exposes markAsReady, isLoading, isSuccess, and error to the UI.Assign a Courier
With the order in
LISTO, the seller opens the Assign Messenger Modal on /seller/ready-orders and picks an available mensajero. assignCourierToDelivery runs an atomic transaction: it creates a new document in the deliveries collection and updates the order’s status to ASIGNADO.Courier Delivers the Order
The courier picks up and delivers. On success the order reaches
ENTREGADO or PAGADO. On failure it moves to NO ENTREGADO, surfacing on /seller/failed-orders and /seller/undelivered-orders.Handle Delivery Outcome
For failed/undelivered orders the seller chooses one of two actions via
useFailedOrderDecision or useUndeliveredOrderDecision:- Restart — returns the order to
RESERVADOand re-reserves stock ifstockRestoredistrue. - Cancel — sets status to
CANCELADO, releases reserved inventory, and records the cancellation reason inincidentReason.
Order Detail Page
Each order has a dedicated page at/seller/orders/[id] that shows the full Order object including the items subcollection. The getOrders service (getOredrs) uses onSnapshot to keep the list live and enriches each record with buyer info, location label, and order items:
The
enrichOrdersWithData function batches lookups for buyers (users collection) and locations (locations collection) and reads orderItems subcollections in parallel, minimising round-trips.Firestore Order Schema
Theorders collection document (OrderDoc) has the following fields:
Order type extends OrderDoc with resolved fields:
| Field | Source | Description |
|---|---|---|
buyerName | users/{buyerId}.displayName | Resolved buyer display name |
buyerEmail | users/{buyerId}.email | Buyer email address |
buyerInstitutionalId | users/{buyerId}.institutionalId | UMSS institutional ID |
locationLabel | locations/{locationId}.label | Human-readable delivery location |
locationType | locations/{locationId}.type | Location category |
items | orders/{orderId}/orderItems subcollection | Array of OrderItem |
OrderItem includes itemId, productId, productName, unitPrice, quantity, and subtotal.
Daily Collections
The/seller/daily-collections page (rendered by DailyCollectionsPanel) gives the seller a financial summary of cash-on-delivery payments collected by couriers on a given day. It calls fetchDailyCollections from dailyCollectionsService.ts:
Total cobrado
Total cash collected across all
cash_on_delivery orders for the selected day, formatted in BOB (Bolivianos).Pedidos cobrados
Count of orders with payments registered by couriers on the selected date.
Confirmados
Number of orders where the buyer confirmed reception (
buyerReceptionConfirmed: true).Sidebar Navigation Groups
The seller sidebar is built fromsellerNavGroups defined in src/features/seller/constants/navGroups.ts: