What the item type decides in every other module — transcript
Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.
This lesson is for whoever decides what type each of GadgetSphere’s items gets, and for whoever has to explain a report that looks wrong afterwards. The item type is a single drop-down on a create screen, and it quietly settles how five other modules will treat that item forever. In about thirteen minutes you will be able to predict the downstream behaviour from the type alone.
Step 1 — Read the type as a set of consequences, not a label
After this step you will read the drop-down differently. The item type is not a category for tidiness. It is the switch that decides, at the moment somebody puts this item on a document, whether inventory moves, whether there is a cost to subtract, which account the money lands in, whether the line reaches a tax authority, and whether a margin report should count it. It also decides which tabs you get on the edit screen: a Stock Card exists only for a Basic Item, because no other type produces inventory transaction lines to show. When a colleague asks why an item has no stock card, that is the answer, and it is not a fault.
Reference: Doc Item Maintenance — Item types
Step 2 — Know which types your kind of business actually uses
After this step you will stop treating a long list as twenty equal choices. Across the ninety live tenants, three types carry almost everything: Basic Item for physical goods, Account Code for non-stock charges, and Service for labour, installation and delivery. Warranty, Bundle, Grouped Item and Voucher are real but narrower. Below that, several types are held by three tenants or fewer, which tells you they exist for a specific customer’s workflow rather than for you. For a retail group like GadgetSphere the honest short list is Basic Item for everything on a shelf, Service for fitting and delivery, and Account Code for deposits and claims. Choose from those three unless you can say precisely why not.
Reference: Doc Item Maintenance — Item types
Step 3 — Understand the item that has no stock twin on purpose
After this step you will stop trying to make an invoice line countable. Not every item has an inventory record behind it, and that is the point of the split rather than a gap in your data: around eighty-two thousand active items across eighty tenants have no inventory link at all. Those are the services, the delivery charges, the deposits and the account-code lines — things that belong on an invoice and can never be on a shelf. If you find yourself wanting a stock figure for a screen-protector fitting service, the type is telling you something true. Conversely, an item you expect to count that has no inventory code on its Main tab is a genuine fault, and the place to look is the auto-creation job rather than the item.
Reference: Doc Item Maintenance — Doc item or inventory item — which record are you editing?
Step 4 — Explain the deposit invoice that shows a hundred per cent margin
After this step you can answer a question your finance manager will eventually ask. An Account Code item exists to post a charge straight to a nominated account: a customer deposit, a progressive claim, a retention. It has no inventory behind it, so it has no moving-average cost — its cost is zero and correctly so. The sales report, though, computes margin as net amount minus moving-average cost for every goods-and-services line, and does not exclude these. A deposit invoice therefore arrives in the report as pure profit, and a month with several of them reads as though GadgetSphere sold at a hundred per cent margin. The number is not lying about the arithmetic; it is counting a balance-sheet movement as revenue. The per-document gross profit screen does not have this problem, because it works through the inventory link these items do not have — so those two screens disagree for a reason you can now state.
Reference: Doc Item Maintenance — Item types
Step 5 — Give a bundle’s children the one type the check can see
After this step you will set up a bundle that can actually be sold. A bundle sells several stand-alone items for one price, and stock moves on the children rather than on the parent. When somebody finalises a document carrying a bundle, the platform asks how many whole bundles that location can supply, by looking at each child’s stock at that location. It counts only children whose inventory record is a Basic Item, and only children that have a stock-balance row there. A child of any other type is not counted, and neither is one that has never been received at that shop. If the answer comes back short, the error names the parent bundle — never the child that ran out — so the counter sees a document refusing to go final on an item that is visibly in stock. Check the children one at a time, at that location.
Reference: Doc Item Maintenance — Other tabs
Step 6 — Spot a migrated item whose type matches nothing
After this step you will have a first move for an item that behaves strangely everywhere. The type is stored as plain text and compared against exact values, so an item whose type is spelled anything other than one of the values the create screen offers matches none of the comparisons and falls through to whatever the default branch does. Across the ninety tenants there are five such spellings in the wild, carried in by migrations and file imports rather than typed by anyone. The symptom is an item that behaves as though it has no type: no stock card, no cost, odd treatment on documents, and nothing on the screen saying why. When items from an old system misbehave as a group, check the stored type against the offered list before you look anywhere else.
Reference: Doc Item Maintenance — Item types
How the steps fit together
flowchart TD
s1["Step 1 — Read the type as a set of consequences, not a label"]
s2["Step 2 — Know which types your kind of business actually uses"]
s3["Step 3 — Understand the item that has no stock twin on purpose"]
s4["Step 4 — Explain the deposit invoice that shows a hundred per cent margin"]
s5["Step 5 — Give a bundle's children the one type the check can see"]
s6["Step 6 — Spot a migrated item whose type matches nothing"]
s1 --> s2
s2 --> s3
s3 --> s4
s4 --> s5
s5 --> s6
Check yourself
Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.
Answer key
- Only a Basic Item produces inventory transaction lines, and the Stock Card shows those — Doc Item Maintenance — Other tabs
- The line is an Account Code item, which has no inventory cost, and the report subtracts moving-average cost without excluding that type — Doc Item Maintenance — Item types
- Each child's type and its stock at that line's own location — the check counts only Basic Item children there, and names the parent when it fails — Doc Item Maintenance — Other tabs
- Their stored item type against the exact values the create screen offers — the column is plain text and an unmatched spelling falls through every comparison — Doc Item Maintenance — Item types
- When it is a service, a charge, a deposit or an account-code line — around 82,000 active items across the base have no inventory twin by design — Doc Item Maintenance — Doc item or inventory item — which record are you editing?
Next: The two GL codes on an item, and which one your journal used · Back to the series · Play this as a presentation