Parties

Parties are the companies vestl interacts with — the clients you produce for, the vendors who supply your raw materials, and the carriers that move freight. Every product, purchase order, and sales order traces back to a party.

Party Types

Client

A company you produce finished goods for. Clients own product lines and products. Their code appears in every SKU they own — MAYB-MAYBELS-FG-0001 belongs to client MAYB.

Common fields:

• Name — the legal company name (e.g. “Maybel’s Spirits Co”).
• Code — a 2-6 character identifier used in SKU generation. Stable forever once set; renaming a client never changes the SKU prefix on existing products.
• Primary contact — the person you talk to about orders. Required to mark the client as “complete” in the setup checklist.
• Billing address — required to mark the client as “complete” and to issue invoices. A separate shipping address is optional.

Vendor

A company that supplies raw materials, ingredients, or packaging. Vendor code appears in raw material SKUs — CASCADE-RM-0001 is sourced from vendor CASCADE.

Vendor-specific defaults (required by the vendor wizard, optional in the schema):

• Default payment terms — e.g. Net 30, 2/10 Net 30. Applied to new POs unless overridden per-order.
• Default lead time (days) — how long this vendor typically takes from PO to receipt. Used by MRP to compute material order-by dates.
• Default ordering UoM — the unit you order in (e.g. kg, case). Conversions to your inventory UoM are handled by /settings/uom.

A vendor is “complete” when it has a contact, a billing/remit address, and all three defaults set.

Carrier

A freight company that moves shipments between you, your vendors, and your clients. Carriers are tracked separately so shipping documents and TTB transit records can reference them. Lighter-weight than clients/vendors — typically just a name, code, and contact.

Internal

Used for Brella-owned entities that need to act like a party in the system (e.g. the HOUSE entity that “owns” house raw materials). Created at setup; you don’t typically add new internal parties.

The Code Field

Every party has a code — a short uppercase identifier that appears in SKUs and shipping documents. The code is set at create time and cannot be changed afterwards because existing SKUs reference it.

The wizard offers a Generate button that derives a default code from the company name (first 4-6 letters, uppercased). You can override it before continuing.

Adding a Party

Use the wizard at Parties → Clients → New Client (or Vendors → New Vendor). The wizard walks you through:

1. Company — name and code.
2. Primary contact — name, role, email, phone.
3. Address — billing/remit (and optionally shipping).
4. Vendor defaults (vendor wizard only) — payment terms, lead time, ordering UoM.

After creation the party shows up in the relevant list (/parties/clients or /parties/vendors). The client detail page shows Product Lines and Standalone Products side by side.

Field reference (party detail page)

These are the fields on a party’s detail page and what each means. Tooltip copy on the page mirrors this section.

Name

The legal or trading name of the company. Used on POs, invoices, and shipping documents. Edit this when the company rebrands; it does not affect SKUs or codes.

Code

The short uppercase identifier used in SKU generation. Set at create time and permanent — every SKU that references this code would have to be re-issued if the code changed, so vestl prevents it. If a client/vendor genuinely needs a new code (e.g. a true acquisition with a new legal entity), create a new party.

Type

Client, Vendor, Carrier, or Internal. Set at create time and permanent. Type drives which downstream surfaces the party appears on (clients show up in sales-order pickers; vendors in PO pickers; carriers in shipment dialogs).

Status

Active parties show up in pickers (sales orders, POs, formulas, lots). Inactive parties are hidden from creation flows but kept for historical lookups. Never delete a party that’s been used in a PO or batch — the audit trail and TTB records reference them.

Notes

Free-text. Use this for the things that don’t fit anywhere else: the warehouse-receiving quirk a specific vendor has, the contract milestone a client is tracking against, the carrier’s account number with you. Visible to anyone who can read the party.

Default payment terms (vendor only)

Applied to new POs created against this vendor unless overridden per-order. Common values: Net 30, Net 45, 2/10 Net 30, Due on receipt. The setup checklist treats a vendor as incomplete until this is set.

Default lead time, days (vendor only)

How long this vendor typically takes from PO to receipt at the dock. MRP uses this to compute material order-by dates: if MRP needs 1000 lbs of malt on May 15 and the vendor’s lead time is 14 days, MRP will flag the PO as needing to ship by May 1.

Default ordering UoM (vendor only)

The unit this vendor ships in (e.g. kg, case, pallet). Used by MRP to convert your inventory consumption rate into a vendor-friendly purchase quantity. Conversions to other units (e.g. kg → lb) are handled by /settings/uom.

Contacts

Each party can have multiple contacts (sales rep, AP contact, ops contact). One contact is marked primary — that’s the one shown on order summaries and the one MRP/exception alerts route to. Add more contacts for AP/ops/quality without losing the primary.

Addresses

Two address types:

• Billing — where invoices go and (for vendors) where payments are remitted. Required to mark a party complete.
• Shipping — where finished goods are shipped (clients) or where pickups happen (vendors). Optional. If you check “Same as billing”, vestl uses the billing address for shipping too.

Both types support country (default US) so cross-border vendors work the same way as domestic.

Product Lines (clients only)

Clients can have product lines (brands) — see Products for the full Client → Product Line → Product hierarchy. Add product lines from the client detail page or create them inline during the product wizard.

Audit Trail

Every change to a party (name, code, status, contact, address, defaults) is audit-logged. View the trail at Compliance → Audit Trail, filtered by entity type party. Audit entries record the user, timestamp, and field-level diff.