Editing an Item

Editing an item nobody has put on a document yet is easy. Editing one that is on three years of invoices is a different job, and that is what this page is about: what you can change, what you cannot, what a change quietly affects, and how to retire something without breaking history.

Meet GadgetSphere

GadgetSphere Sdn Bhd is discontinuing a smartphone model, repricing a range of accessories, and has just discovered that one item has carried the wrong tax code since March. Three edits, three different levels of care.

Four kinds of edit, at a glance

1. A label (name, description, alias, EAN code, remarks): change it whenever it is wrong (What you can change freely).
2. A tax code, e-invoice classification, category, price or UOM ratio: think first. A new tax code or price leaves documents already raised as they were; moving a category moves the item in and out of price-book rules; a wrong UOM ratio is a data problem, not a field to correct (What you can change, but should think about first).
3. The code, type or sub item type of an item that has been used: this screen cannot fix it. Set the item to Obsolete, after checking open orders, bundles and price sets, and create a replacement; do not force the type through the import (Retiring an item).
4. Hundreds of items: Export Item, edit the file, Import Item, leaving the type columns as exported (Changing many items at once).

What the edit screen will not let you change

If the code, type or sub item type is wrong on an item that has been used, the item cannot be fixed on this screen. Set it to Obsolete and replace it. See Retiring an item below, and do the replacement properly rather than living with the wrong one.

Do not go looking for a permission for Sub Item Type. There is one with a promising name, your administrator can grant it, and the field stays grey — nothing in the item screen reads it. The lock is not about who you are; it is about what the change would mean. Switching an item from plain quantity tracking to serial numbers, after stock has moved and documents have posted, would have to invent a serial number for every unit already counted and every line already sold. BigLedger will not guess, so the field closes the first time you save. Get it right on the create screen, or create a new item.

The import is the one route around the lock, and it is not a repair tool. Import Item matches each row to an existing item by code and writes the row’s type and sub item type over the item’s, with none of the checks this screen’s lock stands in for — so an item can end up claiming serial tracking for stock that was counted without serials, or the reverse. The same row also rewrites the item’s name, base UOM and status, and every other column you filled in, and for a Basic Item the inventory record follows. It is built for bulk maintenance; the only type correction it is safe for is an item nothing has used yet.

If you have already asked for the permission and been given it, you have not done anything wrong — it is a real permission that simply does nothing today, and the field will still be locked.

What you can change freely

Item name, description, remarks, abbreviation, alias, EAN code, product manager, default supplier, comments, and the delivery and production checkboxes. These are labels. Change them whenever they are wrong.

What you can change, but should think about first

These four ripple outwards.

Tax codes. Changing the output tax code changes what is charged on every document raised from now on. It does not touch documents already posted. So if an item has carried the wrong code since March, fixing the item is only half the job — the posted documents need their own correction, and that is a conversation with your accountant, not a field edit.

The e-Invoice classification. Nearly the same shape, with one wrinkle worth knowing. What goes to LHDN is the classification on the document line; a line that was saved without one takes the item’s classification at the moment of submission. So a correction to the item does nothing to what has already gone to LHDN — but it can reach a document raised before the change and submitted after it, if its lines carried no classification of their own.

Categories. Price-book rules match on an item’s categories. Move an item between categories and you move it into and out of every promotion keyed on them — usually silently, and usually noticed at the till.

Pricing scheme prices. The new price applies to lines added after the change. Documents already raised keep the price they were raised at, which is correct and occasionally surprising.

Multi UOM ratios. A document line stores its own copy of the ratio and the base quantity it produced, so changing the ratio on the item does not re-base history — stock and old lines stay exactly as they were counted. That is the problem: if the ratio was wrong, every base quantity already written from it is wrong too, and correcting the item fixes only the lines you enter from now on. Treat a wrong ratio as a data problem to investigate line by line, not a field to correct and forget.

Changing many items at once

Editing one item at a time is fine for three and a mistake for three hundred.

• Export Item → edit the CSV → Import Item. The safe pattern for any bulk change: you can see what you are changing before you change it, and you have the before state on disk. Leave the type and sub item type columns as exported: the import writes them over the item without checking anything (see What the edit screen will not let you change).
• Item Price Change is not a bulk editor: it is a read-only report of recorded price changes, old beside new. Move prices in bulk through export and re-import.
• Entity Pricing Import for prices agreed with a particular supplier — purchase price, order quantity bands and lead time, which replenishment reads when it raises a purchase order. The same screen will accept a sales price per customer and nothing on the selling side ever reads it, so do not use it to give a customer a special price. Use a price book price set targeting that customer’s category instead.
• Item Image File Import for images.
• On the inventory side, Min-Max Quantity Import File for reorder levels across locations — and the Export button on the item listing, which is the only bulk read of min and max levels anywhere in the product.

Retiring an item

Items are not really deleted: you change their status. The statuses, what Delete checks and the message it shows, and what Inactive does on the inventory side are explained once, on Retiring an item. For an edit, the rule that matters is the next one.

For anything that has ever been on a document, use Inactive or Obsolete. Reports, audits and warranty lookups all depend on the record still being there.

Before you retire an item, check three things: no open sales or purchase orders reference it; it is not a child of a live bundle or grouped item; and it is not named in a live price set.

What success looks like

Two minutes after any edit:

1. Raise a draft document line for the item. It behaves the way your change intended — the new price, the new tax, the new category’s discount.
2. Open a posted document from before the change. It is unchanged, which is correct.
3. For a retirement: search for the item when raising a new document. It is not offered — and it is still visible on the old documents that used it.

Discard the drafts.

Common mistakes

Related documentation