Skip to main content
Every order in CEDIS Pedidos moves through a defined lifecycle with four distinct states managed by both branch users and administrators.

​
The Four States

Orders progress through these states in sequence:

Borrador

Draft - Initial state when branch creates an order
Visual Indicator:
● Borrador
Badge color: Gray (bg-gray-100 text-gray-700 border-gray-300)Characteristics:
  • Editable by branch user
  • Deletable by branch user
  • Not visible in admin approval queue
  • Auto-saved every 30 seconds
  • Not yet submitted for review
Available Actions:
  • Edit quantities and materials
  • Change delivery date/type
  • Save changes
  • Delete entirely
  • Submit to move to next state

Enviado

Submitted - Order sent for CEDIS review (read-only for branch)
Visual Indicator:
● Enviado
Badge color: Amber (bg-amber-50 text-amber-700 border-amber-300)Characteristics:
  • Read-only for branch users
  • Visible in admin dashboard
  • Timestamp recorded in enviado_at
  • User recorded in enviado_por
  • Awaiting admin approval
Available Actions:
  • Branch: View only, export PDF
  • Admin: Edit, approve, or reject
This is the primary review state. Admins validate quantities and delivery feasibility before approval.

Aprobado

Approved - Admin has validated and approved the order
Visual Indicator:
● Aprobado
Badge color: Emerald (bg-emerald-50 text-emerald-700 border-emerald-300)Characteristics:
  • Admin-approved for fulfillment
  • Ready for warehouse picking
  • Fulfillment format available
  • Read-only for branch users
  • Admin can still edit if needed
Available Actions:
  • Branch: View and export PDF
  • Admin: Print format, mark as printed, edit if critical changes needed

Impreso

Printed - Fulfillment format printed, order in progress
Visual Indicator:
● Impreso
Badge color: Blue (bg-blue-50 text-blue-700 border-blue-300)Characteristics:
  • Warehouse has printed picking list
  • Order fulfillment in progress
  • Final state in the system
  • Historical record complete
Available Actions:
  • Branch: View final details
  • Admin: View, track completion, edit if emergency changes required

​
State Transition Diagram

​
State Constants

From src/lib/constants.ts:49-61: 
export const ESTADO_LABELS: Record<string, string> = {
    borrador: 'Borrador',
    enviado: 'Enviado',
    aprobado: 'Aprobado',
    impreso: 'Impreso',
}

export const ESTADO_COLORS: Record<string, string> = {
    borrador: 'bg-gray-100 text-gray-700 border-gray-300',
    enviado: 'bg-amber-50 text-amber-700 border-amber-300',
    aprobado: 'bg-emerald-50 text-emerald-700 border-emerald-300',
    impreso: 'bg-blue-50 text-blue-700 border-blue-300',
}

​
Permission Matrix

Who can do what in each state:
ActionBranch UserAdmin
View✅ Owner only✅ All
Edit✅ Owner only✅ All
Delete✅ Owner only❌ No
Save✅ Owner only✅ All
Submit✅ Owner only❌ No
Approve❌ No❌ No
Print❌ No❌ No

​
Database Schema

From supabase/schema.sql:45-56, the estado field: 
CREATE TYPE estado_pedido AS ENUM (
  'borrador', 'enviado', 'aprobado', 'impreso'
);

CREATE TABLE pedidos (
  ...
  estado         estado_pedido NOT NULL DEFAULT 'borrador',
  enviado_at     timestamptz,
  enviado_por    uuid REFERENCES users(id)
);
Key fields:
  • estado: Current state (enum, defaults to ‘borrador’)
  • enviado_at: Timestamp when moved to ‘enviado’
  • enviado_por: User ID who submitted the order

​
Row Level Security (RLS)

From supabase/schema.sql:132-137, update permissions:

​
Branch Users

CREATE POLICY "pedidos_update_sucursal" ON pedidos FOR UPDATE USING (
  estado = 'borrador'
  AND sucursal_id = (SELECT sucursal_id FROM users WHERE id = auth.uid())
) WITH CHECK (
  sucursal_id = (SELECT sucursal_id FROM users WHERE id = auth.uid())
);
Branch users can only update orders in borrador state from their own branch.

​
Administrators

CREATE POLICY "pedidos_update_admin" ON pedidos FOR UPDATE USING (
  EXISTS (SELECT 1 FROM users WHERE id = auth.uid() AND rol = 'admin')
);
Admins can update orders in any state without restrictions.

​
Typical Order Lifecycle Timeline

1

Day 1: Creation

9:00 AM - Branch user starts new order (borrador)9:30 AM - User adds materials from catalog10:15 AM - User saves draft, continues later3:00 PM - User finalizes quantities and clicks “Enviar pedido”Estado: borrador → enviado
2

Day 2: Review

8:00 AM - Admin sees order in dashboard “Total Enviados” count8:30 AM - Admin reviews materials against inventory9:00 AM - Admin clicks “Aprobar” buttonEstado: enviado → aprobado
3

Day 3: Fulfillment

7:00 AM - Admin exports PDF fulfillment format7:15 AM - Admin clicks “Imprimir” to mark as printed8:00 AM - Warehouse begins picking materialsEstado: aprobado → impreso
4

Day 4: Delivery

Materials picked, loaded, and delivered to branchOrder remains in “impreso” as historical record

​
Special Cases

​
Editing After Submission

If an admin needs to modify a submitted order:
1

Admin opens order

Navigate to Dashboard, find order in enviado state
2

Click pencil icon

Opens order in edit mode (admins bypass read-only restriction)
3

Make changes

Adjust quantities, dates, or materials
4

Save changes

Click “Guardar cambios” - order remains in current state
5

Continue workflow

Approve when ready - state transitions normally
Communicate any changes to the branch - they see read-only view and won’t know about edits.

​
Deleting Orders

From src/pages/MisPedidos.tsx:34-52: 
const handleDelete = async (pedidoId: string) => {
    // Delete detalles first (foreign key)
    await supabase.from('pedido_detalle').delete().eq('pedido_id', pedidoId)
    await supabase.from('pedidos').delete().eq('id', pedidoId)
}
Only borrador orders show the delete button. Once submitted (enviado), orders cannot be deleted.

​
Best Practices

  • Save frequently as borrador while building orders
  • Review carefully before submitting - you can’t edit after enviado
  • Check weight limits before submission
  • Monitor state changes in Mis Pedidos to track approval progress
  • Review enviado orders daily - don’t let them accumulate
  • Approve promptly to give warehouse adequate prep time
  • Print formats early for next-day deliveries
  • Communicate edits if you modify submitted orders
  • Use filters to manage high-volume periods (filter by estado)
  • Respect RLS policies - don’t bypass security
  • Set enviado_at and enviado_por when transitioning to enviado
  • Validate state transitions - follow the allowed flow
  • Use estado_pedido enum - don’t use string literals

​
Monitoring Order Flow

Admins can track order flow health using dashboard metrics:

High Enviados Count

Problem: Backlog building upAction: Prioritize reviews, add admin capacity

Low Aprobados Count

Status: Healthy flowMeaning: Orders moving through system efficiently

Many Printed Today

Status: Active fulfillmentMeaning: Warehouse busy with current orders

High Weekly Tonnage

Alert: Capacity concernAction: Plan additional truck capacity

Build docs developers (and LLMs) love

Get started for freeTalk to us