Architecture

You don't need this page to add a field. You need it to understand why the rest of this section works the way it does, and to make good decisions when a customization gets complicated.

The three layers

GarmentFlow is a Frappe app. It sits on top of two things:

GarmentFlow          garment manufacturing: tech packs, cutting, batches, QC, maintenance
ERPNext              generic business: items, stock, purchasing, selling, accounting, assets
Frappe Framework     the platform: DocTypes, permissions, REST API, printing, reports, jobs

Each layer can use everything below it, never above. That is why GarmentFlow's machines are ERPNext Assets and its subcontract bills are ERPNext Purchase Invoices — reusing the layer below means the accounting already works, and your accountant's reports already include it.

It also means anything true of Frappe is true of GarmentFlow. Every technique in this section is a standard Frappe technique, so Frappe's own documentation and community answers apply directly.

Everything is a DocType

A DocType is Frappe's unit of everything. Define one and you automatically get:

• a database table,
• a form to edit records,
• a list view with search, filters and sorting,
• permissions by role,
• a REST API endpoint,
• print formats, reports, notifications, comments, attachments, and a full change history.

Production Order, Tech Pack, Work Center and Cutting Order are DocTypes. So are User, Print Format and DocType itself.

This is why adding a new kind of record (Creating DocTypes) needs no programming: you describe the fields, and the framework builds everything else.

Kinds of DocType

Submittable matters when you extend. Once a document is submitted, its fields are frozen unless they are explicitly marked Allow on Submit. If your custom field needs to change after submit, you must tick that when you create it.

How records connect

Two field types do the joining, and knowing which is which explains most of the data model:

• A Link field stores the name of another record. Production Order.tech_pack is a Link to Tech Pack.
• A Table field holds child rows. Production Order.operation_plan is a Table of Production Order Operation rows.

The main chain through the product:

Tech Pack ──> Production Order ──> Production Batch ──> Operation Ledger Entry
    │               │                     │
    │               └──> Cutting Order    └──> Batch Operation Step ──> cost
    └──> Tech Registry (variant × size ──> Item)

Three of those are worth knowing before you customize anything nearby:

• Tech Registry is the only link between a style's variant/size and a stock Item. If you need to find the item code for "Navy, size M" of a style, that is where it comes from.
• Operation Ledger Entry is the movement record. Quantities on batches and units are derived from the ledger, not stored independently — so never write a quantity field directly and expect it to hold.
• Batch Operation Step carries the per-operation cost. It is where an operation's production unit, cost source and actual cost live.

Why your customizations survive updates

GarmentFlow's own definitions ship as files in the app. Yours are stored as records in your database:

An update replaces app files. It does not touch your records. The two are merged at runtime, every time a form is loaded — which is why your custom field appears on a GarmentFlow form that GarmentFlow knows nothing about.

Edit an app file directly and you are on the wrong side of that line: the next update overwrites it.

Desk, apps and the API

Three front ends read the same data:

• Desk — the back office at /app. Forms, lists, reports, workspaces.
• The floor apps — separate mobile apps at /garmentflow/… (production, cutting, packing, design, logistics, quality, supplier, recruitment). They are ordinary web applications that call the same server.
• Anything you build — see API & integrations.

None of them has private access. The floor apps call whitelisted server methods over HTTP with the user's session, exactly as an external integration would with an API key. Permissions are enforced on the server, so a user who cannot see a Production Order in Desk cannot fetch it through the API either.

That is worth internalising before you integrate: you don't secure your integration by hiding a screen. You secure it by giving its user the right roles.

Where GarmentFlow's own code lives

Useful for reading, not editing:

garments_manufacturing/
  garments_manufacturing/
    doctype/        one folder per DocType: .json definition, .py server logic, .js form script
    report/         script and query reports
    page/           full-screen Desk pages (Floor Monitor, Cutting Control, …)
    api/            whitelisted endpoints the apps and dashboards call
    print_format/   the standard printed layouts
  public/js/        form scripts loaded into Desk
  hooks.py          how the app plugs into Frappe: events, scheduled jobs, overrides
  www/              server-rendered public pages and the app entry points

If you want to see how something is done before you copy it, that is where to look — the standard print formats and reports are especially useful as starting points, and both can be duplicated from the interface without touching the files.

What to do next

Start with Extending forms, or Creating DocTypes if you already know you need a new kind of record.