--- title: Journals (the journal_id reference) description: "**Audience:** bookkeeper, admin, developer · **Last updated:** 2026-06-07 · [Edit on GitHub](https://github.com/phreesoft/bizuno/edit/main/docs/04-modules-in-depth/01-phreebooks/02-journals.md) # Journals (the `journal_id` reference) Every transaction in Bizuno is a row in **`journal_main`**, tagged with an integer `journal_id` that says *what kind* it is. This page is…" url: "https://www.bizuno.com/docs/journals/" updated: "2026-06-18" category: PhreeBooks --- # Journals (the journal_id reference) **Audience:** bookkeeper, admin, developer · **Last updated:** 2026-06-07 · [Edit on GitHub](https://github.com/phreesoft/bizuno/edit/main/docs/04-modules-in-depth/01-phreebooks/02-journals.md) # Journals (the `journal_id` reference) Every transaction in Bizuno is a row in **`journal_main`**, tagged with an integer `journal_id` that says *what kind* it is. This page is the per-journal narrative: for each ID, what it does, what it posts to the General Ledger, the fields that matter, its lifecycle, and the pitfalls. > **If you want the one-screen lookup table** (every jID, its name, its class > file) read [The journal_id taxonomy](/docs/journal-id-taxonomy/) > first. This page is the long-form companion to it. > > > > **If you want the UI** that drives jIDs 3/4/6/9/10/12 — the Save menu, the > action column, the entry fields — see [The Sale / Purchase > Manager](/docs-category/modules-order-manager/). --- ## How to read each entry Each journal class lives at `controllers/phreebooks/journals/jNN.php` and extends the shared base `common.php` (`jCommon`). The class's `Post()` method is the authority on what the journal does; `unPost()` reverses it. A posted transaction is one `journal_main` row plus several `journal_item` rows. Each item row carries a **`gl_type`** code that says what kind of leg it is: | `gl_type` | Meaning | | --- | --- | | `itm` | A line item (a SKU or a charge the user entered) | | `ttl` | A GL distribution leg generated by a totals plugin (AR, tax, freight, the offsetting account) | | `cog` | A cost-of-goods leg, generated automatically from inventory cost | | `pmt` | A payment leg (on the payment journals) | | `adj` | An inventory adjustment leg | | `asy` | An assembly (build) leg | | `xfr` | A store-transfer leg | The **GL postings** shown below are the net debits/credits a normal transaction produces. Bizuno is strict double-entry: every post balances to zero. Two lifecycle flags recur throughout: - **`waiting`** — an interim state (order confirmed but not shipped; goods received but not yet billed). - **`closed`** — the terminal state (order fully filled; invoice fully paid). A closed record can't be Saved-As / Moved-To. --- # Trading documents The eight journals that move goods and money with a contact. They come in two mirrored families — **vendor** (purchasing) and **customer** (selling) — and progress Quote → Order → Invoice → Credit. --- ## jID 3 — Request For Quote `j03.php` **What it is.** An outbound request to a vendor for pricing. **No GL impact, no inventory impact.** A record-keeping document. **Where in the UI.** *Vendors → Purchases → (RFQ)* — the order manager pointed at journal 3. **Key fields.** Bill-to vendor (`contact_id_b`, required), line items, expiration date (the `terminal_date` field, relabeled "Expiration Date"). **Lifecycle.** Sits open until you fill it into a PO (jID=4) or let it expire. Convert via the grid's *Fill → Purchase* action or the form's *Save As ▸ / Move To ▸*. **Pitfalls.** It's not a commitment to buy — nothing is reserved or accrued. --- ## jID 4 — Purchase Order `j04.php` **What it is.** A commitment to buy from a vendor. **No GL posting**, but it **increments `qty_po`** on the inventory record (quantity on order), which the reorder logic and stock-status views read. **Where in the UI.** *Vendors → Purchase Orders*. **Key fields.** Vendor (required), line items with quantities, expected ship date ("Expected Ship"). Supports the per-line **delivery dates** editor. **Lifecycle.** `waiting`/confirmed → filled into a Purchase (jID=6). When the bill is posted, Bizuno **auto-closes the PO if fully received**, or leaves it open if partially received (see jID 6's pre/post-flight handling). Supports the prepay shortcut (deposit to vendor via Pay Bills). **Pitfalls.** The `qty_po` it adds is backed out when the PO is filled or deleted; if a PO is force-closed while partially filled, the balance is reconciled on re-post so on-order quantities don't drift. --- ## jID 9 — Sales Quote `j09.php` **What it is.** An outbound quote to a customer. **No GL impact, no inventory impact.** The customer-side mirror of jID 3. **Where in the UI.** *Customers → Sales Quotes*. **Key fields.** Customer (required), line items, expiration date. **Lifecycle.** Open until filled into an SO (jID=10) or invoice (jID=12), or it expires. **Pitfalls.** Inventory is **not** reserved by a quote — only an SO reserves (`qty_so`). --- ## jID 10 — Sales Order `j10.php` **What it is.** A confirmed order from a customer. **No GL posting**, but it **increments `qty_so`** (quantity committed/reserved) on inventory. **Where in the UI.** *Customers → Sales Orders*. **Key fields.** Customer (required), line items with quantities, expected ship date. Supports delivery dates, **recurring** schedules, and the customer-deposit prepay shortcut (via Cash Receipt). **Lifecycle.** `waiting`/confirmed → filled into a Sale (jID=12). Auto-closes when fully shipped/invoiced; stays open when partially filled. Can spawn a drop-ship PO (grid *Create PO* action). **Pitfalls.** The `qty_so` reservation is what makes stock look unavailable elsewhere; deleting or filling the SO releases it. --- ## jID 6 — Purchase (vendor bill) `j06.php` **What it is.** A vendor invoice / bill. This is the **posting** purchase document. **Where in the UI.** *Vendors → Purchases (Bills)*. **GL postings.** ``` Dr Inventory / Expense (per line item's GL account) Dr Freight / Tax / Fees (per totals plugins) Cr Accounts Payable (the order total) ``` For tracked inventory, the line debits the inventory asset account and updates `qty_stock` and weighted-average cost; for expense purchases it debits the expense account. **Key fields.** Vendor (required); **reference number** (the vendor's invoice #) — *may be left blank only if Waiting is checked*; line items; due date. **Lifecycle.** `waiting` = goods received, paper invoice not yet entered (use the grid's *Set invoice #* action when it arrives). Settle via *Save & Pay* / the *Payment* action → Pay Bills (jID=20). Can spawn a Vendor Credit (jID=7). `closed` = fully paid. **Pitfalls.** Editing a posted bill triggers a **re-post chain** — dependent payments and COGS are recalculated. Receiving against a PO reconciles that PO's on-order quantity automatically. --- ## jID 7 — Vendor Credit `j07.php` **What it is.** A credit received from a vendor — a return or billing correction. Reverses a Purchase. **GL postings.** The reverse of jID 6: `Dr Accounts Payable`, `Cr Inventory / Expense` (and reverses inventory/COGS for returned stock). **Where in the UI.** Spawned from a Purchase via the grid's *Create credit* action, or directly under Vendors. **Lifecycle.** Settled via Vendor Refund (jID=17) if the vendor refunds cash, or applied against open bills at pay time. `closed` = fully applied/refunded. --- ## jID 12 — Sales (customer invoice) `j12.php` **What it is.** A customer invoice — the **posting** sale document and the most important journal in the system. **Where in the UI.** *Customers → Sales (Invoices)*. **GL postings.** ``` Dr Accounts Receivable (invoice total) Cr Revenue (per line item's GL account) Cr Sales Tax Payable (tax totals plugin) Cr Freight income / Fees (totals plugins) Dr Cost of Goods Sold (cog legs, from inventory cost) Cr Inventory asset (cog legs) ``` The COGS legs (`gl_type='cog'`) are generated automatically from the item cost — you don't enter them. `qty_stock` is decremented; `qty_so` is released if the sale was filled from an SO. **Key fields.** Customer (required); reference (invoice #, blank = auto-assign); line items; ship date. **Lifecycle.** `waiting` = unshipped. Settle via *Save & Pay* / *Payment* → Cash Receipt (jID=18). Can spawn a Credit Memo (jID=13) or an RMA (grid *Create return*). `closed` = fully paid. **Pitfalls.** Editing a posted invoice (price, qty, cost) sets off the **re-post chain** (`getRepostData` covers jIDs 6, 7, 12, 13, 14, 15, 16, 19, 21) so COGS and applied payments stay consistent — expect dependent entries to recompute. Reconciled payment legs are protected. --- ## jID 13 — Credit Memo `j13.php` **What it is.** A customer return / credit. Reverses a Sale. **GL postings.** The reverse of jID 12: `Cr Accounts Receivable`, `Dr Revenue` (and reverses tax); returned stock is added back (`Dr Inventory`, `Cr COGS`). **Where in the UI.** Spawned from a Sale via *Create credit*, or directly. **Lifecycle.** Refunded via Customer Refund (jID=22), or applied to open invoices. `closed` = fully applied/refunded. --- # Payment & refund journals These settle the trading documents. Their grids carry a slim action column (Print, Edit, Set reference, Delete) and their status column reads **Reconciled**. --- ## jID 18 — Cash Receipt `j18.php` **What it is.** A customer payment received against AR. **GL postings.** `Dr Cash / Undeposited Funds`, `Cr Accounts Receivable`. The payment legs carry `gl_type='pmt'` and link to the invoice(s) they pay. **Where in the UI.** Reached from a Sale's *Save & Pay* / *Payment* action, or *Customers → Receipts*. Can be entered against a deposit (SO prepay). **Pitfalls.** If you use Undeposited Funds, the bank deposit is a separate step (General Journal / bank deposit). Don't post the receipt straight to the bank account if your workflow batches deposits. --- ## jID 20 — Pay Bills `j20.php` **What it is.** A vendor payment. **GL postings.** `Dr Accounts Payable`, `Cr Cash`. Payment legs `gl_type='pmt'` link to the bills paid. **Where in the UI.** Reached from a Purchase's *Save & Pay* / *Payment* action, or the dedicated **Pay Bills** screen, which supports **paying many vendors at once by due date** (bulk) and **ACH/NACHA** check runs. The reference (check #) increments per check via the `next_ref_j20` counter. **Pitfalls.** ACH transactions overwrite the posting GL account with the ACH clearing account — the bulk routine preserves the user-selected account for non-ACH checks. Bulk runs increment the check number only for printed (non-ACH) checks. --- ## jID 17 — Vendor Refund `j17.php` **What it is.** Cash refunded *to you* by a vendor (settles a Vendor Credit). `Dr Cash`, `Cr Accounts Payable`. Reached from a Vendor Credit's *Payment* action. ## jID 22 — Customer Refund `j22.php` **What it is.** Cash refunded *to a customer* (settles a Credit Memo). `Dr Accounts Receivable`, `Cr Cash`. Reached from a Credit Memo's *Payment* action. Like jID 20, it maintains an incrementing reference counter. --- # Point-of-sale journals Immediate cash transactions that combine the invoice and the payment in one post. ## jID 19 — Point Of Sale `j19.php` **What it is.** A walk-up sale: invoice + payment in a single entry. `Dr Cash`, `Cr Revenue + Tax`, plus the COGS/inventory legs of a normal sale. Driven by the POS controller rather than the standard order manager. Processed through the payment machinery at post time (hard to reverse — posted last). ## jID 21 — Point Of Purchase `j21.php` **What it is.** A walk-up/petty-cash purchase: bill + payment in one entry. `Dr Inventory / Expense`, `Cr Cash`. --- # Inventory journals These move stock without a contact. Their grids hide the contact and total columns; the "document" is the inventory movement itself. ## jID 14 — Assembly `j14.php` **What it is.** An inventory build — consume components, produce a finished assembly. Pulls the bill-of-materials components (decrementing their stock and COGS) and adds the assembled SKU at rolled-up cost (`asy` legs). The GL effect nets within inventory/COGS accounts. Linked to Work Orders (jID=32) when a job drives the build. **Pitfalls.** A build short on a COGS-tracked component is blocked; non-stock components pass through. ## jID 15 — Store Transfers `j15.php` **What it is.** Move inventory between stores/locations (`xfr` legs). Decrements the source store's stock, increments the destination's. The `so_po_ref_id` column carries the destination store. Cost moves with the goods. ## jID 16 — Adjustment `j16.php` **What it is.** An inventory adjustment — physical-count correction, shrinkage, write-up/down (`adj` legs). `Dr/Cr Inventory` against the adjustment/COGS account. Use it to reconcile book quantity to a physical count. --- # General & system journals ## jID 2 — General Journal `j02.php` **What it is.** A manual GL entry — the escape hatch for anything the structured journals don't cover (accruals, depreciation, opening balances, bank deposits of undeposited funds, corrections). You enter the debit/credit legs directly; the totals must balance to zero. **Where in the UI.** *Banking/GL → General Journal*. The entry screen is a stripped-down version of the order manager (Save As → New is its only Save-As option; no contact required). **Pitfalls.** It's the right tool for true GL adjustments and the *wrong* tool for anything that has a structured journal — posting a "sale" via the General Journal skips inventory, COGS, AR aging, and tax, and will quietly desync your subsidiary ledgers. Reach for it only when no trading journal fits. ## jID 0 — Search Journal `j00.php` **Not a transaction type.** The base used by the cross-journal *Search* manager, which joins `journal_main` to `journal_item` to let you search every journal at once. You'll never post a jID=0 record. --- ## Extension journals (30+) Modules outside PhreeBooks use `journal_id` ≥ 30 (Quality tickets 30, audits 31, Work Orders 32, training 34, maintenance 35). They live in `journal_main` for the shared lifecycle/audit structure but most **don't post to the GL** — they're saved by their own controllers, not the `jNN.php` classes. If you're building your own, use **40+**. See [Custom journal type](/docs/custom-journal-type/) and the [taxonomy reference](/docs/journal-id-taxonomy/#reference-table--extension-journals-30). --- # Cross-cutting behaviors ### The re-post chain Editing a posted transaction whose costs feed others triggers an automatic **re-post** of the dependents. `getRepostData()` on the posting journals returns the affected jIDs (6, 7, 12, 13, 14, 15, 16, 19, 21) so inventory cost, COGS, and applied payments stay correct after the edit. This is why a small edit to one invoice can touch several entries — it's by design, not a bug. ### Recurring transactions (`recur_id`) Sales Orders, invoices, bills, and POs can recur. The **Recur** toolbar button sets a frequency (Weekly, Bi-weekly, Monthly, Quarterly); on save Bizuno posts the series, advancing post date, due date, and reference number for each copy. All copies share one `recur_id`. A record in a recurring series **can't be Saved-As / Moved-To** (it's a linked record). ### Order → invoice linking (`so_po_ref_id`) When an order is filled into its invoice, the invoice carries `so_po_ref_id` pointing back at the order. Posting the invoice runs pre/post-flight checks that release the order's reserved quantity and **close the order if fully filled** (or leave it open if partially filled). ### Next-reference counters Each journal's next document number is stored as a `next_ref_j` meta value (e.g. `next_ref_j20` for the next check number). Leaving a reference blank on save pulls and increments this counter. ### Security keys Access is gated per journal by `j_mgr` keys (e.g. `j12_mgr` for the Sales manager), with levels 1 = view, 2 = edit, 3 = elevated actions, 4 = delete. The [action column](/docs/action-column/) documents the per-action minimums. --- ## Related - [The journal_id taxonomy](/docs/journal-id-taxonomy/) — the one-screen lookup table - [The Sale / Purchase Manager](/docs-category/modules-order-manager/) — the UI built on jIDs 3/4/6/9/10/12 - [Custom journal type](/docs/custom-journal-type/) — adding your own - [Quote → SO → Invoice → Payment → Deposit](/docs/quote-so-invoice-payment-deposit/) - [PO → Receive → Bill → Pay](/docs/po-receive-bill-pay/)