workOrders Core Collection (Folha de Obra) #34
Labels
No labels
CI/CD
MongoDB
PostgreSQL
api
authentication
bug
documentation
duplicate
enhancement
example issue
fix
good first issue
help wanted
high-level requirement
infrastructure
invalid
low-level requirement
medium-level requirement
question
security
test
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
AndreFerreira5/starranja#34
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is the core collection for the application, tracking the entire lifecycle of a repair job. It must support multiple functional and business requirements by aggregating data from clients, vehicles, and items.
We will use a single document per work order, embedding line items (parts and labor) for performance and atomicity.
Requirements Covered
Tasks
workOrderNumber,status,entryDate,completionDate).clientIdandvehicleIdreferences to link to the other collections.quotesub-document (for diagnostics, totals, andclientApprovedstatus).itemsarray of embedded documents for parts and labor, ensuring all required fields are present (type: 'Part'|'Labor',description,reference,quantity,unitPriceWithoutIVA,ivaRate,totalWithIVA).statusfield enum (e.g.,AwaitingApproval,InProgress,AwaitingParts,Completed) to manage the workflow and trigger notifications (RB07).vehicleIdwherestatusis not 'Completed' or 'Invoiced').Document Management Timestamps
createdAt- When the WO was createdupdatedAt- Updated on EVERY modificationWorkflow Timestamps
entryDate- Vehicle check-indiagnosisRegisteredAt- Diagnosis registeredquoteApprovedAt- Customer approvalexecutionStartedAt- Optional, but good for measuring performancecompletedAt- Work completednotificationSentAt- Notification sentdeliveredAt- Vehicle deliveredmechanicsIdsarray to link to the user system (see Issue #37 ).The scheme is looking like this for now, we have to Define how to address RB02. And module the items array.

Added the items array.
It can be "Part" or "Labor", for example:
"items": [
{
"type": "Part", // 'Part' ou 'Labor'
"description": "Amortecedor Bilstein B4",
"reference": "BLS-22-1111", // (RB03)
"quantity": Decimal128("2.0"), // (RB03)
"unitPriceWithoutIVA": Decimal128("85.00"), // (RB03, RF06)
"ivaRate": Decimal128("0.23"),
"totalPriceWithoutIVA": Decimal128("170.00"),
"totalPriceWithIVA": Decimal128("209.10") // (RF06)
},
{
"type": "Labor",
"description": "Substituição amortecedores",
"reference": "MO-005", // (RB03)
"quantity": Decimal128("1.5"), // (RB03)
"unitPriceWithoutIVA": Decimal128("50.00"), // (RB03, RF06)
"ivaRate": Decimal128("0.23"),
"totalPriceWithoutIVA": Decimal128("75.00"),
"totalPriceWithIVA": Decimal128("92.25") // (RF06)
}
],
To address RB02 it will be necessary to create an index.
// --- Index for RB02 ---
// Ensures that a vehicle can only have ONE active worOrder.
db.workOrders.createIndex(
{ vehicleId: 1 },
{
unique: true,
partialFilterExpression: {
status: { $nin: ["Completed", "Invoiced", "Delivered"] }
}
}
);