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
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.
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
and the taxonomy reference.
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<N> 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<N>_mgr keys (e.g. j12_mgr for the Sales
manager), with levels 1 = view, 2 = edit, 3 = elevated actions, 4 = delete. The
action column documents the per-action
minimums.
Related #
- The journal_id taxonomy — the one-screen lookup table
- The Sale / Purchase Manager — the UI built on jIDs 3/4/6/9/10/12
- Custom journal type — adding your own
- Quote → SO → Invoice → Payment → Deposit
- PO → Receive → Bill → Pay
