How MOM actually works

This page is confirmed facts about MOM (Mail Order Manager) itself — what its database actually contains and how an order really becomes an invoice and a packing slip today. It is not about this app or the sync — the point is to get everyone on the same page about MOM's real behavior before rollout, independent of any new system.

Everything below was checked directly against real MOM data, not assumed from documentation or how the screens look.

How an order becomes an invoice

Each order has one invoice header row (INVOICE), which records the customer being billed, the date, and a COGS dollar figure for that specific invoice — this figure is calculated and frozen the moment the invoice is created, not when it ships or gets paid. Summing that one column across a month lines up exactly with the real monthly accounting entry ($8,905.39 across 201 invoices in June 2026, matched to the penny).

Inventory is drawn down at that same moment — invoice/order creation — not at shipping. Confirmed directly: real orders exist where SHIP_DATE is still blank but the inventory-depletion transactions are already posted, dated the same day as the invoice.

The packing slip is a separate record entirely (see below) — it is not just a reprint of the invoice.

Companies aren't a real table — they're a shared field on customer rows

MOM has no separate company record. Its customer table (CUST) holds a COMPANY field on the exact same row as a person's name, address, and email. A "business" in MOM is really just a cluster of otherwise-unrelated customer rows that happen to share the same COMPANY text — nothing formally links them together unless someone has separately set up a customer-relationship pointer (BELONGNUM) between specific rows, and a lot of same-company customers never get that pointer set at all.

Real example, live and confirmed, from one of the demo orders (#225616): customer #270355 (Rene Pacheco, 1477 W Commerce Ct, Tucson) and customer #269665 (Deeann Arroyo, 85 W Franklin St, Tucson) are both full, independent, top-level customer rows in MOM — neither one is a sub-record of the other. The only thing tying them together at all is that both rows have COMPANY = "Pima Prevention Partnership". If you searched MOM for "the Pima Prevention Partnership account," these are two of the rows that would turn up, with no explicit record connecting them.

Addresses: a different contact, not a field on the same one

MOM has no shipping-address field on a customer record — no "billing address" / "shipping address" pair on one row. When an order needs to go somewhere other than the billing customer's own address, MOM handles it one of two ways, and both amount to a genuinely separate contact record, not an alternate address on the same one:

A second customer row, explicitly linked back to the first via BELONGNUM. This is the fingerprint: CUSTTYPE = 'P', ORDERREC = 0, NET = 0 — a row that exists purely to hold an address, has never itself placed an order, and points at a real customer as its parent. (Real, confirmed pairs: customer #158313 is a clean sub-account of #139869 this way; #164332 is a clean sub-account of #164331.)
A per-order shipping record (SHIPTOT), one row per order, holding the actual recipient's name, address, email, and phone for that specific shipment — completely separate from the INVOICE/CUST billing chain, and not required to be BELONGNUM-linked to anything.

The same real order above (#225616) is the clean example of the second mechanism. The invoice bills customer #270355 (Rene Pacheco). But the order's actual SHIPTOT row names a completely different person as the recipient — Deeann Arroyo, at 85 W Franklin St — and that recipient is herself a full, independent customer row (#269665, the same one from the company example above), not an address field hanging off Rene's record. Two full contacts, one company name, one order.

Bundles: dummy inventory and zero-cost entries

MOM tracks a bundle "root" SKU (e.g. a Guide/Workbook combo) alongside its real component SKUs, but the root's on-hand quantity is always exactly zero — it's never a real, physical thing sitting on a shelf. Its cost field, though, comes in two different flavors depending on the SKU:

Some roots carry a real, accurate cost that is the honest sum of their components' costs (confirmed: one root's stored cost is exactly its two components' costs added together, to five decimal places).
Others carry a literal $0 cost — genuinely "dummy inventory with no cost of goods," which is exactly how it was described by staff and exactly what the raw data shows.

Either way, the root SKU always nets to zero dollars in the ledger every month — confirmed across every active bundle root with real activity in a sample month (22 of them), all landing at exactly $0 net, to the penny. This works because MOM posts a matching pair of transactions on the root — one that "creates" units, one that "consumes" the same units at the same cost — that cancel out completely. All of the real, non-canceling dollar movement happens on the leaf components, never on the bundle SKU itself.

Separately: MOM's cost basis in general is last-cost, not FIFO or a weighted average. The moment a new purchase order lands with a new unit cost, every subsequent sale uses that exact number, flat, until the next purchase order changes it again — confirmed across 360 consecutive sales of one real SKU throughout 2026, all using the identical unit cost.

Why this matters before rollout

None of this is a MOM bug or a quirk to route around quietly — it's what the real numbers already do today, and any new system needs to either match it or make a deliberate, understood decision to do something different. Specifically worth carrying forward: COGS is a per-invoice fact fixed at creation time (not shipping), a "company" is only ever as real as a shared name string, and an alternate delivery address always means a second real contact record in MOM, never a field on the first one.