Full User Guide — Product Lifecycle, Inventory & Operations
Master data forms the foundation of every product. Before creating any product, these records must be configured in the system. Admins maintain these — they rarely change once set up.
Navigate to Master Data in the left sidebar. You will see 4 sub-sections: Product Types, Material Codes, Design Codes, and Value Addition.
Go to Master Data → select Product Type, Material Code, or Design Code.
Fill in the required fields — the code (short identifier), name, and status.
Only Active records appear as options in Product forms. Draft = not ready, Retired = discontinued.
It immediately becomes available for product creation.
| name | Short code e.g. PSH, PAB | required |
| category | ABAYA, SHAWLS, KURDHA | required |
| requiresPrimaryMaterial | If true, material becomes mandatory on product | bool |
| status | Active / Draft / Retired | required |
| code | Unique design identifier | required |
| design_name | Auto-filled from code prefix | auto |
| photo | Reference image for this design | optional |
| description | Rich text description | optional |
| status | Active / Draft / Retired | required |
Each Preset is a saved configuration for AI image generation. It stores a parameter set (JSON) defining how the AI model renders the image — lighting, background, style, angles. Admins create presets once; product owners select them when requesting AI generation.
Female model references used in AI image generation. Each model has a name, thumbnail photo, and JSON file_data for the AI engine. Product owners select a model when requesting AI images — this determines the model appearance in generated photos.
Each material has its own color code table. Colors are linked to products via material-specific M2M junction tables. The system has over 40 material-specific color collections.
Color codes are organized by material type (e.g., SLK colors for Silk, CTN colors for Cotton). Each material collection has its own list of available color codes. You select colors per material — not from a single global list.
Each color record contains:
When you select a Primary Material on a product, the system shows only that material's color panel. You then select which colors this product comes in.
In the left sidebar, open Color Codes folder → find the specific material collection (e.g., "SLK Colors" for Silk).
Click "+ Create Item". Enter the color code (e.g., "OLV" for Olive) and the full name ("Olive Green").
The new color now appears in the material's color panel on any product form that has that material selected.
The color panel is conditional: it only shows when you have selected a Primary Material. Different materials have different color sets — selecting "Cotton" shows cotton colors, "Silk" shows silk colors, etc.
The Product is the master record. Fill in the mandatory fields first — the system auto-generates codes and creates variations automatically when you save.
These fields are mandatory and drive everything else — the SKU generation, variation creation, image slots, and AI generation all depend on these being set correctly from the start.
| Field | What It Is | Why It Matters | Status |
|---|---|---|---|
| productType | Relation to ProductType (PAB, PSH, PKH…) | Determines which image slots are shown, product category, and whether material is required | required |
| designCode | Relation to DesignCode master | Part of SKU formula — determines the design segment of the product code | required |
| primaryMaterial | Relation to MaterialCode (if type requires it) | Unlocks the correct color panel. Required when ProductType.requiresPrimaryMaterial = true | conditional |
| valueAddition | Embellishment code (BW1, TW1, PR1…) | Last segment of SKU formula. Identifies the type of work on the garment | optional |
| productOwnerUser | The accountable user for this product | All tasks and approvals route to this user. Cannot be left empty | required |
| productCategory | ABAYA, SHAWL, or KURDHA | Used for channel publishing, POS export, and reporting | important |
| sellingPrice | Proposed price (decimal) | Required for pricing approval workflow. Must be set before lifecycle advances | important |
| preset | AI generation preset configuration | Controls how AI images look. Select the right style/background preset | for AI |
| femaleModel | Model reference for AI image | The AI will use this model's appearance in generated images | for AI |
Click "+ Create Item" in the top right corner of the Product list.
Pick from the dropdown (e.g., PAB for Abaya). This immediately changes which image upload slots appear below.
Search for and select the design from master data. The design_name auto-fills based on the code.
If your ProductType requires a material, select it now. This also unlocks the color selection panel for that material.
Choose the embellishment type from the dropdown (BW1, TW1, PR1, etc.).
The material-specific color panel is now visible. Check all colors this product comes in.
Assign the product owner user and enter the proposed selling price.
Choose the AI image preset style and the female model for AI generation.
Upload the physical product images in the appropriate image slots (see Section 6 for details).
On save: the SKU code is generated automatically, and one product variation is created for each selected color.
SKU codes are auto-generated by the system using a formula. Each product has a Product Code (SKU), and each color variation has its own unique Variation SKU and EAN-13 barcode.
Product Code = auto-generated on product creation
The Product Code is stored in skuCode on the Product record and also registered in the SKU registry collection (admin-only, for governance and duplicate prevention).
Each color variation gets its own unique Product SKU
Each product variation automatically gets an EAN-13 barcode generated from the variation SKU. The barcode image (SVG) is stored in the barcode_image field of the variation record.
The system supports bulk barcode label printing via the Print Barcode PDF flow.
The barcode_generated_at timestamp on the Product tracks when barcodes were last generated. If you add new color variations after creation, run the "Bulk Generate Barcode Images" flow on the new variations.
A Product Variation is one color-specific version of a product. Every color the product comes in gets its own variation record with a unique SKU and barcode.
You can also manually add variations at any time using the "Create Color Variations" manual flow (flow #14). Select the product, run the flow, and it creates variations for all currently selected colors that don't already have variations.
| Field | Description | Status |
|---|---|---|
| product_id | Parent product this variation belongs to | required |
| color_code | Color code prefix (BLK, RED, NVY) | required |
| color_name | Full color name (Black, Red, Navy) | required |
| productSku | Auto-generated: COLOR-DESIGN-MATERIAL-TYPE-VALUE | auto |
| barcode | EAN-13 barcode number (auto-generated) | auto |
| barcode_image | Barcode SVG image file | auto |
| image | Color-specific product image (manual upload) | optional |
| ai_variation_image | AI-generated image for this specific color variation | auto/AI |
| is_default | Mark as the default/hero variation for the product | optional |
| status | active / archived | important |
In the Product record, find the "Variations" section (list of all color variations).
Open the variation record by clicking the row. You'll see the variation detail form.
This is the color-specific product photo for this variation (e.g., the product photographed in Black).
If AI variation generation was run, the AI image for this color appears here. Review and approve.
Changes save immediately. WooCommerce sync (if enabled) will pick up the new image.
Always upload the real color photo to image first. The AI variation image is generated automatically based on the parent product's preset and model selection.
The system uses conditional image slots — different image fields appear based on which Product Type you selected. Each type has 5 standard photo angles.
Image slots are conditionally shown — when you select ProductType = PAB, only the Abaya image slots (image6–10) are visible. The other slots are hidden to avoid confusion. Always ensure you select the Product Type before uploading images.
The primary display image for this product. Shown in listings, thumbnails, and as the hero image across all channels.
The selected best AI-generated image. Set during the AI approval process. Gates the lifecycle transition to Publishing.
Small preview image for catalog lists. Auto-derived or manually set.
Five AI-generated model images. Each has a corresponding approval checkbox. All must be individually approved before final AI approval is possible.
Final approval checkbox. Can only be checked after all individual AI images are approved. Triggers lifecycle transition to PricingReview.
Each color variation gets its own AI image (the AI renders the product in that specific color). Stored on the variation record.
The system integrates with an AI engine (via n8n) to auto-generate professional product images and marketing copy. The workflow is tightly controlled with approvals at each step.
5 professional product images with a model, per the selected Preset and FemaleModel. The AI renders the uploaded product images on the model in the selected style/background.
Marketing copy fields auto-filled by the AI engine:
Use the feedback flow to regenerate:
Describe what should be different. Be specific (e.g., "More natural lighting, model should smile more").
This triggers a new AI generation request with your feedback included.
Review the regenerated images and approve.
For each color variation, the AI can also generate a variation-specific image — the product rendered in that specific color on the model.
The aiRequested field is read-only and set by the Flow only. Do not edit it manually. It signals that an AI request is in progress.
Tasks are work items automatically created by the system at key lifecycle transition points. They route to the right user and track what needs to be done before the product can advance.
Created when AI images are delivered back to the system. Assigned to the Product Owner. Requires reviewing and approving all 5 AI images before the product can advance to Pricing Review.
Created when the product reaches PricingReview lifecycle status. Routed to the Global Approver role. Must be completed before ReadyForChannelInit.
Created if there are issues with master data linkage (invalid design code, missing material, etc.). Blocks progression until resolved.
Created when a WooCommerce push, POS export, or other integration fails. Status = "Blocked". Requires investigation and re-trigger.
Created after AI copy (product name, description, care instructions) is generated. Routes to the Product Owner or designated reviewer for content sign-off.
Created if there's a conflict or error in the SKU registry. Admin must resolve the conflict before the product code is finalized.
| Field | Description |
|---|---|
| title | Short description of what needs to be done |
| type | Task classification for routing |
| status | Open → InProgress → Completed/Cancelled |
| priority | Low / Medium / High / Urgent |
| assignedToUser | Primary person responsible |
| ownerUser | Accountability owner (usually Product Owner) |
| linkedProduct | The product this task is about |
| dueDate | SLA deadline for completion |
| resolutionNotes | What was done to resolve it |
Task Status Flow
The Product record shows openTasksCount and hasOpenPricingApprovalTask flags — these are maintained automatically by flows and give you a quick view of whether a product is blocked without opening each task.
Multiple approval gates exist in the product lifecycle. Each approval is handled by a specific role. The system enforces these — a product cannot advance without required approvals.
Important: The lifecycleStatus field is read-only for regular users. Only Flows can transition this status. Do not attempt to manually change lifecycle states — this will bypass required approval steps and corrupt the audit trail.
Pricing has a dedicated approval gate. A product must have an approved price before it can be published to any channel. The approval is strictly controlled — only the Global Approver role can approve prices.
Enter the proposed price in the sellingPrice decimal field. Also set the currency.
After AI approval, the system automatically transitions the product to PricingReview status.
A task is automatically created and assigned to the Global Approver role. The hasOpenPricingApprovalTask flag becomes true on the product.
The approver opens the product, reviews the price, and checks pricingApproved = true. The system records who approved and when.
Once approved, the product automatically advances. The PricingApproval task is marked Completed, and the hasOpenPricingApprovalTask flag resets to false.
| sellingPrice | Proposed price (decimal) |
| currency | Currency code (e.g., LKR, USD) |
| pricingApproved | Approval flag — Global Approver only |
| pricingApprovedBy | Auto-filled: user who approved (readonly) |
| pricingApprovedAt | Auto-filled: timestamp of approval (readonly) |
| hasOpenPricingApprovalTask | System flag: true if pending |
If the price needs to change after approval, the pricingApproved flag must be reset (by an admin) and a new PricingApproval task will be created. This ensures all price changes are traceable.
Every product moves through a defined lifecycle. The lifecycleStatus field controls what actions are possible. Transitions are fully automated by Flows — you trigger them by completing tasks and approvals.
The readyForChannelInitAt timestamp is the key signal for batch POS export flows. Products with this timestamp set and lifecycle = ReadyForChannelInit are eligible for the POS Batch Export flow.
Inventory is tracked per color variation per location. Each variation gets its own inventory record at each active location. Quantities are maintained via an append-only movements ledger.
When a product reaches ReadyForChannelInit, the system automatically creates inventory records for every color variation at every active location with qty_on_hand = 0. This "blank slate" ledger ensures complete coverage before any stock movements begin.
| Field | Description |
|---|---|
| product_variation_id | Link to specific color SKU variation |
| product_id | Link to parent product |
| location_id | Which store/branch/location |
| qty_on_hand | Physical count — READ ONLY, calculated from movements |
| qty_reserved | Reserved for orders (set manually) |
| qty_available | Calculated: on_hand − reserved (read only) |
| low_stock_threshold | Alert when qty falls below this |
| notes | Operational notes |
qty_on_hand is READ ONLY — it is calculated automatically from the sum of all stock_movements for this item. Never try to edit it directly.
To change stock quantity, you must:
Use the "Add Variations to Inventory" manual flow to add product variations to inventory at all active locations. This is useful when new color variations are added to an already-live product.
Find the variations you want to add to inventory (filter by product if needed).
Check the checkbox next to each variation you want to initialize inventory for.
From the action menu (or flows button), select this flow. Confirm the action.
One inventory_item record is created per variation per active location, all starting at qty_on_hand = 0.
Physical retail stores. Have their own inventory. Customers buy directly here.
Branch offices. Can hold stock. Stock transfers happen to/from branches.
Main warehouse/HQ. Primary receiving location. Stock is distributed from here.
Inventory Exceptions (shortage, mismatch, damage) are tracked in the inventory_exceptions collection. When an adjustment is made due to damage or theft, an exception record is also created automatically for governance.
Stock Transfers move inventory from one location to another. The transfer process creates a full audit trail — from planning through execution. Each transfer has a unique auto-generated code.
Transfer created. Lines being added. Not yet submitted.
All lines confirmed. Ready to generate POS export file.
Excel export generated. Send to POS team for execution.
Stock physically moved. Movements created. Inventory updated.
Click "+ Create Item" to start a new transfer.
Pick the source (from_location_id) and destination (to_location_id) from the dropdowns.
Format: TRF-{FROM}-{TO}-{YYYYMMDD-HHMMSS} (e.g., TRF-STORE-NUG-20250615-143022)
In the Lines section, add each product variation with the quantity to transfer.
Select the product variations and run this manual flow. It creates the transfer record, lines, and stock_movements automatically.
When ready, set status to ReadyToExport, generate the Excel file, then confirm execution after POS team completes it.
| transfer_code | Auto-generated (readonly) |
| from_location_id | Source location |
| to_location_id | Destination location |
| status | Draft → ReadyToExport → Exported → Executed |
| requested_by | User who initiated |
| required_by | Optional deadline |
| notes | Transfer notes |
| export_file_id | Generated Excel file |
| transfer_date | When executed |
| lines | Line items (product + qty) |
| transfer_id | Parent transfer |
| product_id | Which product |
| quantity | Number of units to transfer |
All available manual flows you can trigger from within the system, organized by category.
Manual — on Product
Triggers AI image + copy generation via n8n. Requires preset and female model to be selected on product first.
Manual — on Product
Re-triggers AI generation with feedback text. Fill aiFeedbackText before running.
Manual — on Product
Creates variations for all selected colors that don't already have variation records.
Manual — on Product
Generates a PDF with all variation barcode images (16 per page). Auto-prints on label printer.
Manual — on Variations
Select product variations → creates inventory_items at all active locations (qty=0).
Manual — on Variations
Select variations, choose from/to location. Creates transfer, lines, and movements automatically.
Manual — on Variations
Select multiple variations and generate all barcode images in one batch operation.
Manual — on Inventory
Auto-creates personal bookmarks for inventory filtered by each active location.
Select ReadyForChannelInit products → generates XLSX export → marks products as exported.
Select product → pushes to WooCommerce via n8n → sets wooProductId on success.
Update existing WooCommerce products with latest data (price, stock, images).
| Flow | Trigger | What It Does |
|---|---|---|
| Auto-Generate ProductCode | On product create | Generates the skuCode in format CATEGORY-DESIGN-MATERIAL-VALUE-RANDOM |
| Auto-Create Color Variations | On product create | Creates variation records for every selected color |
| Generate Barcode Image | On variation save | Creates EAN-13 barcode SVG and stores as barcode_image |
| Auto-Print Barcode | On barcode_image save | Automatically prints to XP-DT426B label printer |
| Product Variation Inventory Init | On ReadyForChannelInit | Creates inventory_items at all locations for all variations |
| Auto-Transition to AIApproval | When AI images arrive | Changes lifecycle Draft → AIApproval |
| Set AI Images Approval Metadata | On ai_images_final_approved | Records approvedBy user and approvedAt timestamp |
| Update AI Feedback Timestamp | On aiFeedbackText change | Sets aiFeedbackLastUpdatedAt |
| Mark Overdue Tasks | Schedule (hourly) | Marks tasks past overdue threshold as overdue |
| Generate Variation AI Image | On variation create/update | Triggers AI to generate color-specific variation image |
| Inventory Woo Availability Sync | On inventory_item change | Updates WooCommerce stock availability in real-time |
End-to-End Product Journey Summary:
Setup master data → Create product (fill key fields) → Select colors → Save (SKU + variations auto-generated) → Upload physical images → Select AI preset + model → Trigger AI generation → Review & approve 5 AI images → Final AI approval → System transitions to PricingReview → Global Approver approves price → System transitions to ReadyForChannelInit + inventory initialized → POS Batch Export or WooCommerce Publish → Product goes Live
The Customer module is a central repository of all customer information — contact details, measurements, order history, and bespoke order tracking, all tied to a unique phone-number-based ID.
A single source of truth for all customer data. Each customer record holds contact details, delivery addresses, body measurements, and social handles.
Store precise abaya measurements per customer, enabling accurate bespoke order fulfillment without needing to re-measure on every visit.
View the live status of all bespoke (custom-made) orders linked to a customer directly from their profile — no separate lookup needed.
The customer's phone number IS their Customer ID. This design ensures every customer has a naturally unique, universally known identifier that staff can look up instantly at the counter or during a call — no need to search by name or generate a separate ID.
customers collection| Field | Notes |
|---|---|
| phone_number | Primary ID — international format (+94...) |
| whatsapp_number | Can differ from phone — used for order updates |
| Optional — for receipts and promotions | |
| instagram_handle | e.g. @username — for social follow-ups |
| Field | Notes |
|---|---|
| address_line_1 | Street / house number |
| address_line_2 | Apartment / building (optional) |
| city | City or town |
| district | District for courier routing |
| postal_code | Optional |
Measurements are stored per customer and referenced automatically when creating bespoke orders. Staff update these whenever a new measurement is taken.
| Field | Unit |
|---|---|
| height | cm |
| shoulder_width | cm |
| chest | cm |
| waist | cm |
| hip | cm |
| sleeve_length | cm |
| abaya_length | cm — full garment length |
| measurement_notes | Free text — special fitting notes |
Always re-measure and update if the customer hasn't visited in more than 6 months.
From the customer profile you can see a live list of all bespoke orders and their current status — no need to navigate to the orders module separately.
whatsapp_number| Field | Type | Notes |
|---|---|---|
| phone_number | string (PK) | Primary ID — e.g. +94771234567 |
| full_name | string | Customer's full name |
| whatsapp_number | string | For order notifications |
| string | Optional | |
| instagram_handle | string | e.g. @username |
| date_created | timestamp | Auto |
| date_updated | timestamp | Auto |
| Field | Type |
|---|---|
| address_line_1 | string |
| address_line_2 | string (nullable) |
| city | string |
| district | string |
| postal_code | string (nullable) |
| height | decimal (cm) |
| shoulder_width | decimal (cm) |
| chest | decimal (cm) |
| waist | decimal (cm) |
| hip | decimal (cm) |
| sleeve_length | decimal (cm) |
| abaya_length | decimal (cm) |
| measurement_notes | text (nullable) |
| bespoke_orders | O2M → bespoke_orders |
The Work Order system manages the full production lifecycle of garments — from design initiation through artisan assignment, quality control, and payment closure. It supports both readymade and bespoke orders.
Two types exist — Readymade (linked to a production ID from the production system) and Bespoke (linked to a bespoke order ID from the bespoke system).
Each work order has a Fashion Designer (owner & creator) and a Worker (artisan or tailor). The Head of Design acts as approver before the order proceeds to production.
Work orders integrate with the Inventory System (goods issuance), Product Management (finishing queue), and Bespoke Order System (fit-on state).
Every work order progresses through the following states in sequence. Bespoke orders have an additional intermediary state for sampling and fit-on.
Bespoke only — Sampling: Bespoke work orders have an additional intermediary state between Assigned and Completed. In this state the designer obtains approvals from both the Head Designer and the customer before proceeding.
When the worker returns the completed garment, the fashion designer performs a quality check. Based on the outcome, the designer selects the next status.
Automatic Goods Issuance Task: When a fashion designer creates a work order, the Inventory System is automatically triggered and a pending goods issuance task is created, tagged to the respective designer. The inventory team sees this task in their queue and issues the required materials to the designer before work begins.
Based on the Arwa Abaya/Shawls Artisan Handover Sheet. These are the fields recorded in every work order.
| Field | Notes |
|---|---|
| work_order_id | Auto-generated unique ID |
| artisan_name | Worker assigned to this order |
| contact_number | Artisan's contact number |
| order_description | Brief description of work required |
| order_date | Date work order was created |
| delivery_date | Expected completion date |
| fashion_designer | Owner of the work order (M2O → users) |
| work_order_type | Readymade | Bespoke |
| production_id | Linked production ID (readymade only) |
| bespoke_id | Linked bespoke order ID (bespoke only) |
| status | Current workflow state |
| Field | Notes |
|---|---|
| garment_type | Abaya | Shawl | Clutch | Other |
| design_code | Design reference code or number |
| reference_sketch_provided | Yes / No |
| design_placement_instructions | Free text — where to place embellishments |
| techniques_required | Embroidery techniques to be used |
| special_notes | Any special instructions for artisan |
Multiple material lines per work order. Each line contains:
| Material Type | Fields |
|---|---|
| Fabric | Description (Color/Type), Quantity, Unit, Remarks |
| Needles / Frames | Description, Quantity, Unit, Remarks |
| Mirrors / Sequins | Description, Quantity, Unit, Remarks |
| Beads / Stones | Description, Quantity, Unit, Remarks |
| Threads | Description, Quantity, Unit, Remarks |
| Other (Specify) | Custom material type + details |
| Field | Notes |
|---|---|
| date_of_return | When artisan returned the work |
| work_quality_check_by | Designer who performed QC |
| observations_issues | Free text — QC notes and issues found |
| signature_checker | QC checker's signature |
| issued_by_name | Designer/Coordinator who issued |
| issued_by_signature | Issuer signature |
| issued_by_date | Date of issuance |
| received_by_name | Artisan name at receipt |
| received_by_signature | Artisan signature |
| received_by_date | Date artisan received work order |
The Work Order Queue is a view of all active work orders grouped by status. Designers can see their own queue, and the Head Designer can see the full queue across all designers. Orders pending approval are highlighted for Head Designer action. The queue is also where goods issuance tasks appear for the inventory team.
| Field | Type | Notes |
|---|---|---|
| id | uuid (PK) | Auto-generated |
| work_order_type | string | Readymade | Bespoke |
| status | string | Workflow state (see lifecycle) |
| fashion_designer_id | uuid (M2O) | → directus_users |
| artisan_id | uuid (M2O) | → workers |
| garment_type | string | Abaya | Shawl | Clutch | Other |
| design_code | string | Reference to design system |
| order_date | date | Creation date |
| delivery_date | date | Expected completion |
| production_id | uuid (nullable) | Readymade only |
| bespoke_id | uuid (nullable) | Bespoke only |
| Field | Type |
|---|---|
| reference_sketch_provided | boolean |
| design_placement_instructions | text |
| techniques_required | text |
| special_notes | text |
| materials_issued | O2M → work_order_materials |
| date_of_return | date (nullable) |
| qc_checked_by | uuid → directus_users |
| observations_issues | text (nullable) |
| issued_by | uuid → directus_users |
| issued_date | date |
| goods_issuance_id | uuid → inventory issuance |
| date_created | timestamp (auto) |
| date_updated | timestamp (auto) |
The Bespoke Order system manages custom-made garment orders from initial customer enquiry through design, production, fit-on, pricing, invoicing, and delivery. Each order is one item — if a customer orders five abayas, five separate orders are created.
Each bespoke order represents a single garment. If a customer orders multiple items, a separate order record is created for each — enabling individual tracking, production, and delivery per piece.
Bespoke orders link to the Customer System (contact details & measurements), the Work Order System (production queue), and the Costing System (price approval & invoice generation).
Four garment types are supported: Abaya, Shawl, Kurta, and Clutch. Each type has its own specific design fields and form layout.
Phone-number auto-fill: When creating a bespoke order, the user enters the customer's phone number in the Customer ID field. If the customer already exists in the Customer System, all their details — name, contact info, delivery address, and abaya measurements — are automatically populated into the order form. The designer can override or update any measurement directly on the order without affecting the master customer record unless they choose to save it back.
Bespoke orders enter the Work Order queue automatically. When a bespoke order is confirmed, it is pushed into the Work Order System and appears in the work order queue. The work order is linked back to the bespoke order via the bespoke_id field. During production, the bespoke order enters the Fit-on state when the work order QC status is set to Intermediary.
Based on the Arwa Abaya Customer Order Detail Sheet. These fields are recorded for every Abaya bespoke order.
| Field | Notes |
|---|---|
| order_id | Auto-generated unique order ID |
| order_description | Brief description of the order |
| customer_name | Auto-filled from Customer System |
| phone_number | Customer ID — used for lookup |
| designer_name | Assigned fashion designer |
| order_date | Date order was placed |
| delivery_date | Expected delivery date |
| urgency_level | Normal | Urgent | Rush |
| delivery_shipping_address | Auto-filled or entered manually |
| pick_up_place | Collection point if not delivered |
| Field | Notes |
|---|---|
| occasion | Wedding, casual, formal, etc. |
| design_style | Style description or code |
| inspiration_mood | Mood board reference or notes |
| sleeve_design | Sleeve style details |
| neckline_type | Neckline style |
| abaya_length | Full length specification |
| closure_type | Button, zip, hook, etc. |
| pockets | Yes / No / Placement details |
| embellishment | Beadwork / Stones / Lace details |
| hijab_scarf_included | Yes / No |
| fabric_type | Fabric material type |
| color_ref | Color reference code or description |
| fabric_swatch | Attached swatch image or file |
| Measurement Area | Unit |
|---|---|
| height | inches |
| shoulder_width | inches |
| chest_bust | inches |
| waist | inches |
| hip | inches |
| arm_length | inches |
| bicep | inches |
| abaya_length_shoulder_to_floor | inches |
| cuff_length | inches |
| Item | Fields |
|---|---|
| Main Fabric | Description, Quantity, Remarks |
| Lining | Description, Quantity, Remarks |
| Embellishments | Description, Quantity, Remarks |
| Thread Color | Description, Quantity, Remarks |
| Others | Custom item + Description |
| advance_paid | Deposit amount collected upfront |
| balance_due | Remaining balance (auto-calculated) |
| payment_mode | Cash | Card | Transfer |
| final_payment_date | Date full payment is due |
Shawl orders share most fields with Abaya orders but replace body measurements with shawl-specific dimensions and have a different materials breakdown.
| Field | Notes |
|---|---|
| length | Shawl length in inches |
| width | Shawl width in inches |
Two separate material tables for shawls:
| Section | Fields |
|---|---|
| Materials — Embroidery / Embellishments | Item, Description, Quantity, Remarks |
| Fabric | Item, Description, Quantity, Remarks |
| artwork_embellishment | Beadwork / Stones / Lace placement details |
| placement | Where embellishments are placed on the shawl |
Full garment with complete body measurements, design details, sleeve/neckline/closure specs, and fabric summary.
Length and width dimensions, embroidery/embellishment materials, separate fabric table, placement details.
Similar field structure to Abaya — garment-specific measurements and design details adapted for Kurta style.
Dimensions, material and embellishment details, design style, and finishing specifications for clutch bags.
Both the Customer Signature and Designer/Staff Signature with date are captured on the order form at confirmation.
| Field | Type | Notes |
|---|---|---|
| id | uuid (PK) | Auto-generated |
| order_category | string | Abaya | Shawl | Kurta | Clutch |
| customer_id | string (M2O) | → customers (phone_number) |
| designer_id | uuid (M2O) | → directus_users |
| work_order_id | uuid (M2O) | → work_orders |
| status | string | Enquiry → Confirmed → In Production → Fit-on → Ready → Delivered |
| urgency_level | string | Normal | Urgent | Rush |
| order_date | date | Date placed |
| delivery_date | date | Expected delivery |
| delivery_address | text | Shipping address |
| pick_up_place | string (nullable) | Collection point |
| Field | Type |
|---|---|
| occasion | string |
| design_style | string |
| inspiration_mood | text |
| fabric_type | string |
| color_ref | string |
| fabric_swatch | uuid → directus_files |
| measurements | json — garment-specific fields |
| materials | O2M → bespoke_order_materials |
| advance_paid | decimal |
| balance_due | decimal (calculated) |
| payment_mode | string |
| final_payment_date | date |
| final_price | decimal — approved by costing flow |
| invoice_id | uuid → invoices (nullable) |
| customer_signature | uuid → directus_files |
| designer_signature | uuid → directus_files |
| signed_date | date |
| date_created | timestamp (auto) |
| date_updated | timestamp (auto) |
The Design & Pattern System is a centralised repository of Arwa's fashion design assets — including embellishment pattern drawings, sewing patterns, and sewing drawings. It acts as a reference library linked directly to the Work Order System, enabling designers and artisans to reference exact design IDs and pattern IDs when creating and executing work orders.
A single source of truth for all fashion design assets. Every drawing, embellishment pattern, and sewing pattern created at Arwa is catalogued here with a unique design ID for reference across systems.
The DP System is linked to the Work Order System. When creating a work order, the designer or artisan selects a specific Design ID or Pattern ID from this system to specify exactly what is to be made.
Each asset entry pairs a technical drawing with its corresponding real-world photograph (where available), providing artisans with both the construction reference and the finished look.
Technical drawings of embellishment designs (beadwork, stone placement, lace arrangements, embroidery layouts) paired with corresponding photographs of the finished embellishment. Used to instruct artisans on exact placement and technique.
Flat sewing patterns with corresponding photographs where available. These are the construction templates used by tailors and seamstresses. Patterns are stored digitally and linked to the garment type and sizing.
Technical sewing drawings — flat lay sketches, construction views, and detail drawings that guide garment construction. These may or may not have accompanying photographs depending on whether the design has been produced.
Design IDs and Pattern IDs are referenced directly in work orders. When a work order is created for a bespoke or production garment, the designer selects the relevant design and/or pattern from the DP System. This ensures the artisan working on the order has a clear, unambiguous reference for what they are constructing — eliminating verbal or paper-based instruction handoffs.
design_id or pattern_id is linked to the work order| Field | Notes |
|---|---|
| pattern_id | Auto-generated unique pattern code |
| pattern_name | Descriptive name for the embellishment pattern |
| pattern_type | Beadwork | Stonework | Lace | Embroidery | Mixed |
| garment_type | Abaya | Shawl | Kurta | Clutch | Universal |
| placement_area | Where the embellishment is placed on the garment |
| drawing | Technical drawing file (image or PDF) |
| photo | Corresponding real-world photo (nullable) |
| notes | Construction notes or technique instructions |
| status | Draft | Active | Archived |
| Field | Notes |
|---|---|
| design_id | Auto-generated unique design code |
| design_name | Descriptive name for the sewing pattern or drawing |
| asset_type | Sewing Pattern | Sewing Drawing |
| garment_type | Abaya | Shawl | Kurta | Clutch |
| size_range | Size range this pattern covers (XS–XL, custom, etc.) |
| drawing | Technical sewing drawing or pattern file |
| photo | Corresponding finished garment photo (nullable) |
| notes | Construction notes, seam allowances, technique guidance |
| status | Draft | Active | Archived |
| Field | Type | Notes |
|---|---|---|
| id | uuid (PK) | Auto-generated |
| pattern_id | string (unique) | Human-readable code e.g. EP-001 |
| pattern_name | string | Display name |
| pattern_type | string | Enum: Beadwork, Stonework, Lace, Embroidery, Mixed |
| garment_type | string | Target garment |
| placement_area | text | Where applied on the garment |
| drawing | uuid → directus_files | Technical drawing |
| photo | uuid → directus_files (nullable) | Real-world photo |
| notes | text (nullable) | Construction notes |
| status | string | Draft | Active | Archived |
| date_created | timestamp (auto) | |
| date_updated | timestamp (auto) |
| Field | Type | Notes |
|---|---|---|
| id | uuid (PK) | Auto-generated |
| design_id | string (unique) | Human-readable code e.g. SD-001 |
| design_name | string | Display name |
| asset_type | string | Sewing Pattern | Sewing Drawing |
| garment_type | string | Target garment |
| size_range | string (nullable) | Size range |
| drawing | uuid → directus_files | Sewing drawing or pattern file |
| photo | uuid → directus_files (nullable) | Finished garment photo |
| notes | text (nullable) | Construction guidance |
| status | string | Draft | Active | Archived |
| date_created | timestamp (auto) | |
| date_updated | timestamp (auto) |
pattern_id and design_id codes so assets are easy to search (e.g. EP-001 for embellishment patterns, SD-001 for sewing designs)The Material Inventory System tracks all raw materials and supplies used in production — fabrics, beads, sewing supplies, marketing materials, and stationery. It manages incoming stock via GRN (Goods Received Note), outgoing stock via issuance to work orders, and returns from production, giving a real-time view of available quantities and average unit prices across all storeroom locations.
Every stock movement — incoming or outgoing — is recorded as a transaction. Available quantity is calculated from the running total of all GRNs, issuances, and returns, giving a complete audit trail.
All stock issuances and material returns are linked to a specific work order. This ties material consumption directly to production, enabling cost-per-order analysis and preventing untracked stock movement.
Every incoming item is assigned a storeroom rack and position. This makes physical stock retrieval fast and accurate, and ensures the system reflects real shelf locations.
| Type | Description |
|---|---|
| GRN (Goods Received Note) | Standard incoming stock from a vendor purchase. Requires vendor, receipt date, invoice/receipt attachment, quantity, and unit rate per material. |
| Intermediary Returns | Materials returned from an intermediary work order stage (e.g., partially used fabric returned after a fit-on). Linked to the source work order. |
| Type | Description |
|---|---|
| Stock Issuance | Materials issued from the storeroom to a work order. Must reference a specific work order ID. Quantity issued is deducted from available stock. |
| Material Returns | Unused materials returned from a work order back to the storeroom. Linked to the originating work order. Quantity is added back to available stock. |
Every material in the system is assigned a category code. The material code is derived from its category and a sequential number (e.g., FAB-001 for fabrics). The five supported categories are:
All woven, knit, and non-woven textile materials used in garment construction.
Beadwork, stones, crystals, and all embellishment materials used for decorative work.
Packaging, tags, tissue paper, branded bags, and any materials used in customer presentation.
Thread, needles, zips, buttons, hooks, interfacing, and all sewing notions and hardware.
Tracing paper, pattern paper, markers, design tools, and stationery used in the design process.
A GRN (Goods Received Note) is the primary record of incoming stock. Each GRN can include multiple materials in a single entry — you do not need to create a separate GRN per material. The GRN is linked to the vendor and includes a receipt date and an optional invoice/receipt attachment for financial records.
| Field | Notes |
|---|---|
| grn_id | Auto-generated GRN reference number |
| vendor | Supplier name or vendor record |
| receipt_date | Date goods were physically received |
| invoice_receipt | Attached invoice or receipt file (image/PDF) |
| notes | Optional remarks about the delivery |
| received_by | Staff member who received the goods |
| Field | Notes |
|---|---|
| material_code | Selected from material catalogue (category-based code) |
| material_name | Auto-filled from material catalogue on selection |
| category | Fabric | Beads | Marketing Material | Sewing Supplies | Stationery & Design |
| quantity | Quantity received (in the material's unit of measure) |
| unit_rate | Price per unit for this delivery |
| total_price | Auto-calculated: quantity × unit_rate |
| storeroom_rack | Physical rack identifier in the storeroom |
| storeroom_position | Position on the rack (shelf, bin, slot) |
| Field | Notes |
|---|---|
| issuance_id | Auto-generated reference |
| work_order_id | Required — must link to an active work order |
| material_code | Material being issued |
| quantity_issued | Quantity taken from storeroom |
| issued_by | Staff member issuing the material |
| issue_date | Date of issuance |
| notes | Optional remarks |
| Field | Notes |
|---|---|
| return_id | Auto-generated reference |
| work_order_id | Required — links return to the originating work order |
| return_type | Intermediary Return | Material Return |
| material_code | Material being returned |
| quantity_returned | Quantity returned to storeroom |
| storeroom_rack | Rack where returned material is placed |
| storeroom_position | Position where returned material is placed |
| return_date | Date of return |
| notes | Condition of returned material, if relevant |
The inventory view provides a real-time snapshot of all materials. It shows available quantity (GRN total minus issuances plus returns) and the average unit price (calculated across all GRN entries for the same material code). Staff can search and filter by material code, name, category, and location.
| Field | How Calculated |
|---|---|
| material_code | Direct field |
| material_name | Direct field |
| category | Direct field |
| available_quantity | Sum of all GRN + returns − issuances |
| average_unit_price | Weighted average across all GRN entries |
| storeroom_rack | Most recent location record |
| storeroom_position | Most recent position record |
| last_received_date | Date of most recent GRN for this material |
| Field | Type | Notes |
|---|---|---|
| id | uuid (PK) | Auto-generated |
| material_code | string (unique) | e.g. FAB-001, BEA-012 |
| material_name | string | Descriptive name |
| category | string | Fabric | Beads | Marketing Material | Sewing Supplies | Stationery & Design |
| unit_of_measure | string | metres, kg, pcs, rolls, etc. |
| description | text (nullable) | Additional details |
| status | string | Active | Inactive |
| date_created | timestamp (auto) |
| Field | Type | Notes |
|---|---|---|
| id | uuid (PK) | Auto-generated |
| grn_id | string (unique) | Auto-generated reference e.g. GRN-001 |
| vendor | string | Supplier name |
| receipt_date | date | Date goods received |
| invoice_receipt | uuid → directus_files (nullable) | Attached invoice scan |
| received_by | uuid → directus_users | Staff who received |
| notes | text (nullable) | |
| line_items | O2M → grn_items | One or more material lines |
| date_created | timestamp (auto) |
| Field | Type | Notes |
|---|---|---|
| id | uuid (PK) | Auto-generated |
| grn_id | uuid (M2O → grns) | Parent GRN |
| material_id | uuid (M2O → materials) | Selected material |
| quantity | decimal | Quantity received |
| unit_rate | decimal | Price per unit |
| total_price | decimal (calculated) | qty × unit_rate |
| storeroom_rack | string | Physical rack identifier |
| storeroom_position | string | Shelf/bin/slot |
| Field | Type | Notes |
|---|---|---|
| id | uuid (PK) | Auto-generated |
| transaction_type | string | GRN | Intermediary Return | Stock Issuance | Material Return |
| material_id | uuid (M2O → materials) | Material involved |
| work_order_id | uuid (M2O → work_orders, nullable) | Required for issuances and returns |
| quantity | decimal | Positive = in, Negative = out |
| unit_rate | decimal (nullable) | Applicable for GRN |
| storeroom_rack | string (nullable) | For incoming / returns |
| storeroom_position | string (nullable) | For incoming / returns |
| transaction_date | date | Date of transaction |
| created_by | uuid → directus_users | Staff who recorded |
| notes | text (nullable) | |
| date_created | timestamp (auto) |