Skip to content
The three decisions that close behind you — transcript

The three decisions that close behind you — transcript

Presentation 1 of 5 in Set up your item master so every module reads it the same way · about 12 minutes · for the whole-system operator — you run the books.

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 is about to create GadgetSphere’s first few thousand items, or has just been asked why an item cannot be corrected. Three fields on the create screen decide things you cannot undo, and the moment they lock is earlier than almost everybody assumes. In about twelve minutes you will know which three, when each closes, why the platform refuses, and what to do with an item that was set up wrong.

Step 1 — Name the three fields before you fill any of them

After this step you will slow down on the right part of a short form. The create screen asks for very little — code, name, type, sub item type, base unit, currency — and three of those are decisions rather than descriptions. The item code is the name every other system will know this product by. The item type decides whether the line moves stock, whether it has a cost, which account it reaches and whether a margin report should count it. The sub item type decides how quantity is tracked: plain quantity, a serial number per unit, a batch, a bin. Everything else on this screen and every tab behind it can be changed later. These three effectively cannot.

Screen: Doc Item Maintenance, Items, Create, the Default tab with the six mandatory fields

Reference: Doc Item Maintenance — Create item

Step 2 — Learn the exact moment the door closes

After this step you will stop believing the comfortable version. The usual explanation is that an item locks once it has been used in a transaction, and that is what a customer is normally told. What actually happens is earlier and less forgiving. The create screen auto-saves as soon as code, name, type, unit and currency are all present. At that instant the item stops being a draft, and the type and tracking controls are disabled from then on — on an item that has never appeared on a document and that nobody has knowingly saved. If you are keying an item and you realise halfway down the form that the type is wrong, you are already too late. Abandon it and start again.

Reference: Doc Item Maintenance — Sub item types

Step 3 — Understand what the lock is protecting

After this step you will be able to explain the refusal instead of apologising for it. Suppose an item has sold two hundred times as a plain quantity and somebody now switches it to serial tracking. The platform would immediately believe that two hundred past sales should each have carried a serial number that was never recorded, that every stock balance behind them was counted the wrong way, and that every reconciliation since is wrong. The work to reconcile that was never written, so the screen refuses instead. The lock is protecting your history, not the item record. That is worth saying out loud to a colleague who thinks it is a missing feature, because it is a deliberate refusal.

Reference: Doc Item Maintenance — Sub item types

Step 4 — Know the permission that unlocks nothing

After this step you will not waste an afternoon on a permission grant. There is a client-side permission on this applet whose name reads exactly like the override you want for the sub item type. It is registered, it is active, an administrator can grant it, and it appears in the permission list next to permissions that do work. No code in the applet reads it. Granting it to a user changes nothing at all: the field stays disabled for them exactly as before. This is the single most asked question about this screen, and the honest answer is that the lock has no key on it. Spend the time on the replacement instead.

Reference: Doc Item Maintenance — Sub item types

Step 5 — Recognise the one door that is not locked

After this step you will treat one routine job with more care. The lock lives in the screen, and nowhere else. No validation on the server refuses a change of item type or tracking mode — the edit template records why, in a comment on the field itself, saying the backend checks were never written and the control was disabled instead. The file import is a different door into the same table. It matches a row on item code among your non-deleted items, updates the one it finds, and writes the item type and sub item type columns from your file without comment. So exporting a catalogue, editing it in a spreadsheet and uploading it again can silently retype live items that the screen would have refused to touch. Treat a re-upload of existing codes as an edit of those items, because that is exactly what it is.

Reference: Doc Item Maintenance — Import is an upsert, not a create

Step 6 — Replace an item properly, and free its code

After this step you can retire a mis-typed item without losing anything. The pattern is replace, not repair. Create a new code with the right type and tracking, move the remaining stock across on an adjustment, and set the old item Inactive so it keeps every document it ever appeared on. One trap sits at the end of that: an item code is unique among everything that is not deleted, so an Inactive or Obsolete item still holds its code, and the listing filtered to Active shows you nothing while the save insists the code exists. Switch the listing filter to All before you conclude the platform is wrong. If you want to reuse the exact code, the old item has to be deleted, and deleting it is a much bigger decision than retiring it.

Reference: Doc Item Maintenance — What it will not do

How the steps fit together

    flowchart TD
  s1["Step 1 — Name the three fields before you fill any of them"]
  s2["Step 2 — Learn the exact moment the door closes"]
  s3["Step 3 — Understand what the lock is protecting"]
  s4["Step 4 — Know the permission that unlocks nothing"]
  s5["Step 5 — Recognise the one door that is not locked"]
  s6["Step 6 — Replace an item properly, and free its code"]
  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.

1. When does the sub item type control actually lock?


2. A user has been granted the permission that names editing the sub item type. What changes?


3. Why does the platform refuse to change how an item tracks quantity?


4. You re-upload last month's catalogue file, expecting the existing codes to be rejected. What happens?


5. Saving a new item fails saying the code already exists, but the listing does not show it. Why?


Answer key
  1. At the create screen's auto-save, as soon as code, name, type, unit and currency are filledDoc Item Maintenance — Sub item types
  2. Nothing — no code in the applet reads that permission, and the field stays disabledDoc Item Maintenance — Sub item types
  3. Because it would make every past document and stock balance for that item wrong, and the work to reconcile that was never writtenDoc Item Maintenance — Sub item types
  4. Each existing code is matched and updated, including its item type and sub item type columnsDoc Item Maintenance — Import is an upsert, not a create
  5. The listing is filtered to Active and the code belongs to an Inactive, Obsolete or draft item, which still hold their codesDoc Item Maintenance — Item listing
This is a self-check. Your answers are marked in your browser and stay there — nothing is sent anywhere, nothing is recorded, and the marking is readable in the page source, so it is not a credential. Open the answer key at any time.

Next: What the item type decides in every other module · Back to the series · Play this as a presentation

Last updated on