> ## Documentation Index
> Fetch the complete documentation index at: https://docs.garmentflow.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Vendors

> The directory of factories and suppliers your team places orders with — typed as garment factories, fabric mills, or accessory suppliers — with the currency, payment terms, and contact defaults every downstream document pre-fills from.

A **vendor** is the canonical record for one outside party your workspace places
orders with — a garment factory, a fabric mill, or an accessory supplier —
together with the currency the vendor invoices you in, the payment terms you
have agreed, and the contact your team works with. Every
<Tooltip tip="The outsourcing document (委外) covering work sent to a factory; one factory order can span several orders and styles.">[factory order](/reference/glossary#factory-order)</Tooltip>,
<Tooltip tip="A purchase order (採購) sent to a supplier for fabric or trims.">[purchase order](/reference/glossary#po-purchase-order)</Tooltip>,
subcontract,
<Tooltip tip="The canonical record for one fabric, with its vendor, category, unit, and lead time.">[fabric master](/reference/glossary#fabric-master)</Tooltip>,
and
<Tooltip tip="The canonical record for one trim or accessory, with its vendor, category, unit, and lead time.">[accessory master](/reference/glossary#accessory-master)</Tooltip>
picks a vendor from this directory — set the record up once and the right
defaults flow into every document raised against it.

## What it is

A vendor record holds the identity of one outside party you do business with —
name, country, contact, and the commercial defaults the platform pre-fills onto
documents raised against the vendor. Each vendor is **typed** — see
[Vendor types](#vendor-types) — and the type pins where the vendor is selected
downstream.

The same record covers every relationship you have with that party. One factory
you outsource cut-make-trim to, place fabric orders against, and pay invoices
from is one vendor row in the directory, not three.

## Why it exists

An OEM business works with three kinds of outside party at once: the factories
that cut, make, and trim finished garments; the mills that supply fabric; and
the suppliers that supply trims and accessories. Each comes with its own
invoicing currency, its own payment terms, and its own contact. Without a
shared directory, every team enters the same vendor's details on every
document, and the details drift the moment a phone number changes.

The vendor record consolidates one party into one row. Set it up once, pick it
on every document, change a contact once and every future document reads the
new value. The currency and payment-terms defaults travel with the record into
the factory orders, purchase orders, and subcontracts you raise against the
vendor, so the commercial basis stays consistent across the lifecycle.

## When it is used

* **At onboarding**, before you load any material masters — a fabric or
  accessory record can only name a vendor that already exists.
* **Setting up a material master**, where the fabric mill or accessory supplier
  is picked from this directory.
* **Raising a factory order**, where the garment factory is picked from the
  directory. The factory order's contract currency reads off the vendor's
  `Currency`, and the factory order's payment terms pre-fill from the vendor's
  `Payment terms`.
* **Raising a purchase order**, where the material supplier is picked from
  the directory.
* **Raising a subcontract**, where the vendor doing the outsourced operation
  (embroidery, printing, washing) is picked from the directory.

You find the directory in the sidebar under **Vendors**.

## Dependencies

* A workspace with its **tenant base currency** set during provisioning — every
  vendor's invoice currency sits against that base for AP reporting and
  FX conversion. See [Currency](#currency).

There are no upstream master records a vendor depends on; the vendor record is
itself one of the entry points of the master-data layer. Vendors load **before**
fabric and accessory masters — see the
[setup sequence](/admin/setting-up-your-tenant#configuring-master-catalogs).

## What depends on it

* Each **fabric master** carries one vendor (the mill that supplies the fabric)
  — see [Master catalogs](/admin/master-catalogs#fabrics).
* Each **accessory master** carries one vendor (the accessory supplier) — see
  [Master catalogs](/admin/master-catalogs#accessories).
* Each **factory order** is raised against one garment-factory vendor, and its
  contract currency and payment terms read off the vendor's record — see
  [Production](/modules/production).
* Each **purchase order** is raised against one material-supplier vendor — see
  [Production](/modules/production).
* Each **subcontract** is raised against one vendor.
* Each
  <Tooltip tip="The workspace's record of a trim sample being sent out for sign-off and the outcome that came back.">[trim submission](/reference/glossary#trim-submission)</Tooltip>
  names the vendor it was sent to — typically the
  accessory supplier who would be filling the bulk trim purchase. See
  [Trim Submissions](/modules/trim-submissions).
* Each **vendor invoice** is keyed to one vendor; the **outstanding payables**
  view on the vendor detail and the AP figures across orders and Finance read
  from this list — see [Finance](/modules/finance).

A vendor referenced by any of the above stays referenced by it forever, even
after the vendor is deactivated. See [Effect of changes](#effect-of-changes).

## Fields

The vendor record groups by identity, type, contact, commercial defaults, and
status.

### Identity

* `Vendor name` — the party's business name. Required, up to 200 characters.
  Shown on every downstream document the vendor appears on.
* `Vendor code` — your workspace's short code for the vendor. Optional, free
  text. Shown on the list card next to the name and on the detail-view
  identity block, so a teammate scanning the directory can recognise the
  vendor by the code your team already uses.
* `Country` — the country the vendor operates in. Optional, free text.

### Type

* `Type` — one of **Garment Factory**, **Fabric Mill**, or **Accessory
  Supplier**. Required. Set when the vendor is created and **not editable**
  after. The type determines where the vendor is picked downstream — see
  [Vendor types](#vendor-types).

### Contact

* `Contact name` — your primary contact at the vendor. Optional.
* `Contact phone` — the contact's phone. Optional.
* `Contact email` — the contact's email. Optional.
* `Address` — the vendor's postal address. Optional, free text.

### Commercial defaults

* `Currency` — the currency the vendor invoices you in. Required. Defaults to
  `USD` on a new record. Set when the vendor is created and **not editable**
  after; see [Currency](#currency).
* `Payment terms` — your default payment terms with this vendor, written in
  your own words (for example, `Net 30`, `T/T 60 days`). Optional, free text.
  Pre-fills onto factory orders and purchase orders raised against the vendor;
  the document carries its own payment-terms field, so you can still adjust it
  per document.

### Status

* `Active` / `Inactive` — every vendor record carries an active/inactive
  state, mirrored on the list and at the top of the detail page. An inactive
  vendor stays linked to documents that already named it but is hidden from
  new picks.

## Vendor types

The three vendor types pin where the vendor is selected downstream and what
the vendor is chosen for.

* **Garment Factory** — the factory that runs cut-make-trim on finished
  garments. Picked on the
  <Tooltip tip="The outsourcing document (委外) covering work sent to a factory; one factory order can span several orders and styles.">[factory order](/reference/glossary#factory-order)</Tooltip>
  (委外單); the factory order's contract currency reads off the vendor's
  `Currency`, and the contract's payment terms pre-fill from the vendor's
  `Payment terms`. A subcontract for a garment-side operation is also raised
  against a Garment Factory vendor.
* **Fabric Mill** — the mill that supplies fabric. Picked on a fabric
  [purchase order](/modules/production) and named as the vendor on every
  [fabric master](/admin/master-catalogs#fabrics) you create.
* **Accessory Supplier** — the supplier that supplies trims and accessories.
  Picked on a trim purchase order, named as the vendor on every
  [accessory master](/admin/master-catalogs#accessories), and selected as the
  recipient of a [trim submission](/modules/trim-submissions).

A vendor is one type. To re-type a vendor after the fact, deactivate the
existing record and create a new one of the right type — every document that
already references the original keeps the original on file.

## The factory-supplied sentinel vendor

Every workspace also carries one **factory-supplied** sentinel vendor that
the platform seeds for you. It exists so a BOM line whose material is supplied
by the garment factory itself — not bought from a separate mill or accessory
supplier — has a vendor to name. The platform displays it as **Factory** (in
Traditional Chinese, **工廠**; in Simplified Chinese, **工厂**) on every list
card, detail view, and document it appears on, regardless of the raw name the
record was seeded with.

The sentinel is read-only — you do not edit, deactivate, or delete it, and it
is not offered as a regular `Garment Factory` pick on a factory order. You
work with it indirectly, by marking a BOM line as factory-supplied; the
platform routes those lines to this sentinel for you. See [BOM](/modules/bom)
for the BOM-line side of the rule.

## Currency

Every vendor carries its own `Currency` — the currency the vendor invoices you
in. The values offered on the dropdown come from the
[Currencies catalog](/admin/master-catalogs#currencies) — the workspace ships
with `USD`, `TWD`, `EUR`, `CNY`, and `JPY`, and the default on a new record is
`USD`.

The vendor's currency carries forward onto every document raised against the
vendor:

* The **factory order's** contract currency is the vendor's `Currency` — the
  per-style factory FOB and the payment-progress bar read in that currency.
* A **purchase order** raised against the vendor reads the line prices in the
  vendor's currency.
* The **vendor's invoices** are denominated in the vendor's currency.

Your workspace also carries a separate **tenant base currency**, provisioned
when your account is set up. The AP, cost analysis, and FX views convert each
vendor's currency back to base at the saved FX rate when they roll figures up
across vendors. The vendor record itself sits in its own currency; the
consolidated view sits in base. The full AP and FX behaviour lives on the
[Finance](/modules/finance) page.

## Business rules

1. **`Type` and `Currency` are set at create and not editable.** Both pin the
   commercial basis the downstream documents read; changing either after the
   vendor has been used would silently shift every document raised against
   the vendor. To change either, deactivate the record and create a new one.
2. **A vendor must be of an appropriate type for the document it's picked
   on.** Factory orders pick Garment Factories; fabric purchase orders and
   fabric masters pick Fabric Mills; trim purchase orders and accessory
   masters pick Accessory Suppliers.
3. **An inactive vendor stays linked to existing references.** Documents,
   masters, and invoices that already named the vendor keep the vendor on
   file; only new picks are hidden.
4. **The vendor record is the source for `Vendor name`, `Country`, `Contact`,
   and `Payment terms` on every new document raised against it.** Updates to
   those fields flow into documents raised **afterwards**; documents already
   raised keep the values they captured at the time. See
   [Effect of changes](#effect-of-changes).

## Validations

| When            | Check                                     | What happens if it fails                                           |
| --------------- | ----------------------------------------- | ------------------------------------------------------------------ |
| Create a vendor | `Vendor name` is filled in                | The "Create vendor" button stays disabled until a name is entered. |
| Create a vendor | `Type` is one of the three accepted types | The save is rejected.                                              |
| Create a vendor | `Currency` is one of the supported values | The save is rejected.                                              |

## Active and inactive

The active/inactive state is a soft lifecycle for the vendor record:

* An **active** vendor is offered on every downstream picker — fabric and
  accessory master forms, factory-order and purchase-order create, subcontract
  create.
* An **inactive** vendor is hidden from new picks. Documents and master
  records that already named the vendor keep the vendor on file and stay
  fully functional — open them and the vendor still reads through. The
  vendor's name still shows on its existing factory orders, purchase
  orders, subcontracts, invoices, and material masters.

Both the list view and the detail-page header show an **Inactive** badge on
an inactive vendor.

## Effect of changes

* **Edit `Vendor name`, `Country`, `Contact`, or `Payment terms`.** The
  updated values are read by every document raised against the vendor
  **from that point on**. Documents already raised — the open factory
  orders, purchase orders, and subcontracts you created before — keep the
  values they captured when they were raised. The AP and subcontract
  history on the vendor detail re-reads the current `Vendor name` on the
  next view.
* **Deactivate a vendor.** Future pickers hide the vendor. Existing
  references — fabric and accessory masters, open factory orders, open
  purchase orders, subcontracts, and open vendor invoices — are unaffected,
  and the vendor's detail page stays reachable through them.
* **Reactivate a vendor.** The vendor returns to every picker on the next
  read; nothing on the existing references changes.

The platform does not let you reassign a fabric or accessory master, factory
order, or invoice from one vendor to another after the fact. If you raised a
document against the wrong vendor, fix the document — not the vendor.

## The vendor detail view

The vendor detail page reads as the record from the directory plus the
activity that already references it.

The page header shows the vendor's `Vendor name`, the `Type` and `Country`
together as a subtitle, and an **Inactive** badge if applicable.

Three summary cards sit below the header:

* **Outstanding payables** — a quick-glance total of what you owe this
  vendor today, drawn from the vendor's unpaid invoices. This is an overview
  number, not the place to record a payment — the AP detail, the invoice
  list, and the payment record live on [Finance](/modules/finance).
* **Subcontracts** — a count of the subcontracts the vendor is on.
* **Currency** — the vendor's `Currency`, with the `Payment terms`
  underneath as a reminder of the commercial defaults.

A **Contact info** section below the cards carries the country, the contact
(name, phone, email), and the payment terms in one read-only block, with an
**Edit** action that opens the same block as a form. The `Vendor name` is
also editable here. `Type` and `Currency` are not editable on the detail —
both are set at create and not changed afterwards (see
[Business rules](#business-rules)).

A **Subcontract history** table at the foot of the page lists every
subcontract the vendor is on, with the subcontract's number, type, delivery
date, quantity, amount, and current state. Open a row to drill into the
subcontract — the lifecycle and the document mechanics live on the
subcontract itself, not on the vendor page.

## Best practices

* **Load your vendors before your material masters.** A fabric or accessory
  record requires a vendor, so the directory has to be in place first. The
  [Data Import wizard](/admin/importing-master-data) handles bulk-load.
* **Pick `Type` and `Currency` carefully — they aren't editable.** Both pin
  the commercial basis that every downstream document reads. If you make
  the wrong choice, deactivate the record and re-create.
* **Use one vendor record per real outside party.** Duplicating the same
  factory under different rows splits the outstanding-payables view and
  the subcontract history across the duplicates, and silently halves the
  picture finance has of the relationship.
* **Write payment terms in plain words your team uses.** The field is free
  text and pre-fills onto documents as you wrote it; consistent wording
  (e.g. `Net 30`, `T/T 30 days`) reads better on the documents themselves.
* **Deactivate rather than try to retire a vendor by deletion.** An
  inactive vendor stays attached to the documents that already named it,
  which is the right outcome for the audit trail.

## Related pages

* [Setting up your tenant](/admin/setting-up-your-tenant)
* [Master catalogs](/admin/master-catalogs)
* [Importing master data](/admin/importing-master-data)
* [BOM](/modules/bom)
* [Cost Sheet](/modules/cost-sheet)
* [Production](/modules/production)
* [Trim Submissions](/modules/trim-submissions)
* [Finance](/modules/finance)