Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Luisangelebp/SCO_Autolavados/llms.txt

Use this file to discover all available pages before exploring further.

SCO Autolavados is built for the Venezuelan financial reality: every transaction can be recorded in US Dollars, Bolívares, or a combination of both. The platform uses a two-step payment-then-sale workflow. A payment record is registered first and goes through an optional admin approval gate before a final, immutable sales invoice is generated. This separation allows admins to verify that funds actually landed in the bank account before the transaction is considered complete.

​
Payment Methods

The following payment methods are supported:
MethodNotes
Pago MovilVenezuelan mobile payment system — balance recorded in Bs
EfectivoCash — can be USD or Bs depending on currency received
BinanceCrypto — mountBS must be 0 for Binance payments
Débito / Punto de VentaDebit card — balance recorded in Bs
TransferenciaBank transfer
ZelleUSD transfer — balance recorded in USD
When method is "binance", the mountBS field must be 0. Submitting a non-zero mountBS with a Binance payment will return a validation error: "Los pagos por Binance solo permiten USD (el monto en Bs debe ser 0)".

​
Listing Payments

Retrieve all payment records, ordered by date descending. Each record includes the nested customer object. 
GET /api/payments
Authorization: Bearer <token>
Response (200): Array of Payment objects with customer details. This endpoint requires a valid JWT but is not restricted to Admin-only — any authenticated user can access it.

​
Step 1 — Register a Payment

Create a payment record linked to the customer. For cash payments (Efectivo), a reference is not required. For all other methods, a reference number (bank confirmation, transaction ID, etc.) is mandatory. 
POST /api/payments
Authorization: Bearer <ADMIN_TOKEN>
Content-Type: application/json

{
  "customerId": "<ID_DE_MARIA>",
  "method": "Pago Movil",
  "mountUSD": 7.5,
  "mountBS": 4666.60,
  "reference": "REF-00123456"
}
Response (201): The created Payment object. Payments are created with approved: true when registered through the POS (the money is considered immediately received at the counter).

​
Step 2 — Approve the Payment (Legacy Flow)

For payment workflows where the admin needs to verify the transfer before approval (e.g., bank transfers checked against a statement), use the approval endpoint: 
PATCH /api/payments/:id/approve
Authorization: Bearer <ADMIN_TOKEN>
No request body is needed. The system:
  1. Confirms the payment is not already approved — returns 400 "El pago ya se encuentra aprobado" if it is.
  2. Sets approved: true on the payment record.
  3. Adds mountUSD and mountBS to the corresponding AutoLavado.balanceUsd and AutoLavado.balanceBs fields.

​
Step 3 — Record the Sale

After payment, POST /api/sales creates the immutable sales invoice. This links the payment to the service orders and/or product items that were sold, records the exchange rate at the time of sale, and decrements inventory for any product line items. 
POST /api/sales
Authorization: Bearer <ADMIN_TOKEN>
Content-Type: application/json

{
  "paymentId": "<ID_DEL_PAGO>",
  "tazaUsd": 622.21,
  "totalUsd": 7.5,
  "userId": "<ID_DEL_ADMIN>",
  "details": [
    {
      "cant": 1,
      "UPriceUsd": 5.0,
      "serviceOrderId": "<ID_ORDEN_SERVICIO>"
    },
    {
      "cant": 1,
      "UPriceUsd": 2.5,
      "itemId": "<ID_AMBIENTADOR_PINO>"
    }
  ]
}
Each entry in details must include either serviceOrderId (for wash services) or itemId (for products sold at the counter). Including itemId triggers automatic inventory decrement for the sold quantity.
The tazaUsd field captures the exchange rate at the time of sale (Bs per USD). This snapshot is stored on the Sales record and is never updated retroactively, ensuring historical accuracy even as the exchange rate fluctuates.

​
Complete Business Flow

The following is the full happy-path flow from vehicle arrival to invoice generation:
1

Service Order Created

Receptionist creates the service order when the vehicle arrives at the counter.
POST /api/service-orders
Authorization: Bearer <TOKEN_ADMIN>
2

Service Performed and Finalized

Admin assigns laundrer and eventually marks the order as FINALIZADO.
PATCH /api/service-orders/<ID>/start   # assign laundrer
PATCH /api/service-orders/<ID>/finish  # mark complete
3

Customer Pays at Counter

Cashier registers the payment at the POS.
POST /api/payments
# { "customerId": "...", "method": "Pago Movil", "mountUSD": 7.5, "mountBS": 4666.60 }
4

Sale Invoice Generated

Admin posts the final sale linking the payment to the service order (and any items purchased).
POST /api/sales
# { "paymentId": "...", "tazaUsd": 622.21, "totalUsd": 7.5, "userId": "...", "details": [...] }
The Sales record is immutable once created. The payment status is confirmed and inventory is decremented in a single atomic transaction.

​
Customer Orders (Web Portal)

Customers can initiate their own purchase orders directly from the web app without going through the reception counter. This flow supports both service bookings and product purchases.

​
Listing Orders

Admin — all orders: 
GET /api/customer/orders
Authorization: Bearer <ADMIN_TOKEN>
Returns every OrderCustomers record in the system with full details (customer info, payment, and line items). Customer — own orders only: 
GET /api/customer/orders/my
Authorization: Bearer <TOKEN_CUSTOMER>
Returns only the orders belonging to the authenticated customer. This endpoint requires the CUSTOMER role.

​
Create an Order (CUSTOMER role required)

POST /api/customer/orders
Authorization: Bearer <TOKEN_MARIA>
Content-Type: application/json

{
  "carId": "<ID_VEHICULO>",
  "details": [
    {
      "itemId": "<ID_AMBIENTADOR_PINO>",
      "cant": 1
    },
    {
      "serviceId": "<ID_LAVADO_COMPLETO>",
      "cant": 1
    }
  ]
}
Each detail entry must include either itemId or serviceId and a cant (quantity). carId is required when any detail contains a serviceId. Unit prices are resolved server-side from the item/service catalogue — do not send UPriceUsd in the request body. The order is created with status: "PENDING" and inventory is decremented immediately at order creation. If insufficient stock exists, the entire transaction is rolled back with an error.

​
Pay for an Order

POST /api/customer/orders/:id/pay
Authorization: Bearer <TOKEN_MARIA>
Content-Type: application/json

{
  "method": "Pago Movil",
  "mountUSD": 0,
  "mountBS": 1555.25
}
A Payment record is created and linked to the order via paymentId. The order’s status remains PENDING at this stage — it must still be approved by an Admin.

​
Approve an Order (ADMIN only)

Once the admin verifies the payment and confirms the order: 
PATCH /api/customer/orders/:id/approve
Authorization: Bearer <ADMIN_TOKEN>
Content-Type: application/json

{
  "tazaUsd": 622.21,
  "methodPayment": "Pago Movil"
}
This creates a Sales invoice record, updates the order status to APPROVED, and finalizes the transaction. The order must have a paymentId set and must be in PENDING status — attempting to approve an already-approved order returns a 400 error.

​
Reject an Order (ADMIN only)

If the payment is not valid or the order cannot be fulfilled: 
DELETE /api/customer/orders/:id/reject
Authorization: Bearer <ADMIN_TOKEN>
This rolls back the order: inventory decremented at creation is restored, any associated service orders are marked CANCELLED, and the order status is set to REJECTED. The order must be in PENDING status to be rejected.

​
Expenses

Expenses record financial outflows from the business. They deduct the amount from AutoLavado balance and optionally restock inventory: 
POST /api/expenses
Authorization: Bearer <ADMIN_TOKEN>
Content-Type: application/json

{
  "description": "Compra de repuestos internos",
  "amountUSD": 50.5,
  "amountBS": 0,
  "quantity": 10,
  "itemId": "<ID_ITEM_OPCIONAL>"
}
If both itemId and quantity are provided, the expense doubles as a restocking operation — the quantity is added to that item’s inventory automatically.

Payments API Reference

Endpoint reference for payment registration and approval.

Sales API Reference

Endpoint reference for sales invoice creation and history retrieval.

Build docs developers (and LLMs) love

Get started for freeTalk to us