Help images should render inside articlesDone
Screenshots now live in the user-doc assets folder and render through /docs/assets/.
Add role-based starting pagesDraft
Help now includes start pages for Sales, Online Orders, Accounting, Shipping, and Marketing.
Missing catalog SKU silently falls back to non-taxable generic QBO itemOpen
Confirmed on 2025TOTV (invoice 223818/INV-1074) and 1743 (invoice 223837): when a SKU has no matching real QBO Item, HubSpot native sync maps the line to the generic "HubSpot Custom Line Item" fallback (QBO id 244), which is Type: Service and so never taxed by _activate_tax_on_lines(), regardless of the item's real taxability. Confirmed via MOM's own ITEMS.NONTAX flag that both are genuinely taxable in practice -- root cause is the missing catalog mapping, effect is silently-dropped tax on that line. AP Trial 3's catalog is deliberately truncated (243 of 392 real SKUs) so expect this to recur on any invoice touching a pruned SKU.
Service-typed QBO items are always marked non-taxable, but MOM taxes some of themOpen
invoice/qbo/data/biz.py::_activate_tax_on_lines() treats item.type == "Service" as always non-taxable (TaxCodeRef: NON). Confirmed against real MOM order history (ITEMS.NONTAX) this is wrong for at least 2 real, correctly-catalog-mapped items: 2025TOTV and 1730P (A P/Teens: Families in Action Kit, QBO item id 39) -- both STOCK.NONPRODUCT=true yet taxed on 100% and 10/10 sampled real MOM orders respectively. A sample of other Service-typed items (3852K, 3889K, 3805A) correctly came back non-taxable, matching today's rule -- so the rule is right most of the time but confirmed wrong on a real, non-trivial subset. Needs a taxability signal distinct from the Service/Inventory type classification; not yet designed.
A product sheet missing some columns used to fabricate values in QuickBooks and HubSpotFixed
Until 2026-09-11, importing a product spreadsheet that left out certain columns did not leave those fields alone: a missing Sales Price or Unit Cost was pushed to QuickBooks as 0, a missing Service Item made every row a stocked product (which QuickBooks rejects for services), and a missing Item Name renamed the HubSpot product to 'Line Item' -- the source of the 'Line Item' products seen on portals in July. Fixed: a column that is not in the sheet, or a blank cell, now means 'leave it as it is' on both sides. The three account-number columns still have to be present for QuickBooks to accept an update, and the Items page keeps them in every download and refuses a sheet without them.
Manually-entered recipient address is silently overwritten by revision, no warningOpen
Real user feedback (Shawnda Smith / Comprehend Inc, INV-1074): typed a billing address manually on invoice creation because HubSpot showed none pre-filled, then Revise Invoice Now silently replaced it with the associated Contact's own stored address, no warning shown. Root cause: invoice/hs/data/biz.py::_ensure_recipient_billing_address() (built for issue 27, to auto-fill invoices with no address at all) unconditionally prefers the Contact record's address whenever it differs from the invoice's current value -- it never distinguishes "nothing filled in yet" from "user already entered something else." By design for its original purpose, but a real UX gap now that it can silently discard a manual correction. Needs a product decision: should a manually-entered address, once set, be preserved on later revisions?
Revise-button status message can say stuck after the revision already succeededOpen
Confirmed live on INV-1074 (2026-08-04): the actual server-side revision completed successfully in ~32 seconds, but the UI still showed "Revision is taking longer than usual" after 5 minutes of polling, because the status poll itself (invoice-revise-status.js -> GET /api/flows/<id>) was silently failing 401 (a separate, since-fixed missing HubSpot secret from the 2026-08-03 API-auth rollout). Design gap independent of that specific cause: the poll loop treats any non-ok poll response identically to "still processing" rather than surfacing a real poll-level error distinctly from genuine processing delay, so a broken status check and a truly slow revision look identical to the user. Worth distinguishing so this exact confusing message can't recur for a different root cause later.
Shipping & handling fee doesn't yet follow the full published fee scheduleIn Progress
Run Shipping currently charges a flat 10% shipping & handling fee (minimum $10.95) on every order, regardless of where it's shipping to. It does not yet apply the Alaska/Hawaii/territories rate (15%, $15 minimum) or the international rate (25%, $40 minimum), and it does not yet exclude training, Online Classes, or electronic downloads from the charge the way the published fee schedule says it should. These rules are documented and being worked through, but not all of them are live yet -- see Start Here for Shipping for the current confirmed/unconfirmed and implemented/not-implemented breakdown.
The placeholder item for unmatched invoice lines is badly named and its income account cannot be chosenDraft
When an invoice line has no matching product, both HubSpot's sync and this app's own sync book it against a placeholder QuickBooks item currently named 'HubSpot Custom Line Item' with the SKU '--'. It should be called something plain such as 'Unmatched Items', and accounting needs to be able to choose which income account it posts to. That choice belongs on its own page, reachable from both the Items and Accounts pages.
A product sheet overwrites changes made after it was downloaded, including inventory countsOpen
When you apply a product sheet, every column in the sheet is written as-is. If something changed in QuickBooks or HubSpot after you downloaded the sheet (an order shipped and lowered a count, a colleague edited a name), the sheet's value replaces it. The review before Apply warns when a column you did not edit would put an older value back, but it does not yet warn when you edited a cell that also changed on the other side, and it does not stop a stale inventory count. This is accepted behaviour for names, prices and the like: the sheet is the intent and it wins. It matters only for inventory counts, which are transactional. Counts are off by default (the 'Allow inventory count updates' setting) and should only be turned on for a deliberate stocktake, exporting right before and applying right after. Two candidate fixes are recorded: a conflict warning when both sides changed, and a hard block on count drift that asks for a fresh export.
"Partial bundles" -- some bundle/breakout components shouldn't block the whole order from shippingDraft
Today, if any item in a bundle or breakout kit is backordered, the whole kit is held back from shipping until every component is available. For small included items (a magnet, for example) that shouldn't be true -- the rest of the order should ship without waiting on them. We're adding a way to flag specific items as "non-blocking" so they don't hold up shipping. Not built yet.
Reserved SKUs are excluded from the product CSV by a fixed list, not a setting you can changeDraft
Some SKUs must never travel through the product spreadsheet no matter which system they turn up in. Today the only one is the two-dash placeholder item QuickBooks uses for invoice lines that have no catalog product. The app now drops these rows from every export and every import, but the list lives in code. The intended shape is a policy you can see and add to in the app: 'wherever we see this SKU, it goes away.' Until then, ask for additions.
Item type overrides (this SKU is a service, regardless of the warehouse system) have no place in the appDraft
The app carries a small fixed map that overrides what the warehouse system says an item is, for example forcing a SKU to be a service item so QuickBooks accepts it. Like the reserved-SKU list, this is policy that belongs in the app where you can see it and change it, not in code. Nothing is broken; this records that the override exists and needs a home.
How to track outstanding invoices originating from MOMDraft
A user asked how to see which MOM-originated invoices are still outstanding -- unpaid or only partly paid -- and there isn't a documented way to do it today. This is an open question rather than a known defect: we haven't yet decided where that view should live (a report, something in QuickBooks, or something in HubSpot), or exactly what "outstanding" should mean for an order that started in MOM. Raised 2026-08-26; no work started.
Discontinued products stay in QuickBooks after a catalog refreshDraft
The product list in QuickBooks only ever grows. When we refresh the catalog from the warehouse system, products that are no longer carried are left alone rather than removed, so QuickBooks -- and the product spreadsheet exported from it -- still lists items that were discontinued some time ago. This is working the way it was designed to: the refresh deliberately only adds and updates, and never deletes anything, so a product can't disappear by accident just because it went missing from the source. The exported spreadsheet is an accurate picture of what QuickBooks currently holds; QuickBooks is simply holding more than the current active list. Clearing the extras is a separate, deliberate step -- marking them inactive -- which hasn't been scheduled yet. Until then, expect the exported product list to run somewhat longer than the active product count, and don't treat the extra rows as an error.