How to Map Custom Lot Number Fields via CSV in NetSuite

You open the Lot Numbered Record, and a custom "Manufacturer's Lot Number" field is sitting there blank. The receiving scanner missed it on a few hundred receipts, and now the data lives in spreadsheets. The question that follows is the same one RF-Smart users hit: can a CSV import write directly into that custom field on the Lot Numbered Record, and if so, which Import Type do you pick?

The short answer: not directly. Inventory Number (Lot) records are not exposed as a top-level Import Type in the CSV Import Assistant, and the field you want to update sits on a child record. Oracle's CSV Imports Guide explicitly states that the Inventory Detail subrecord (which holds bin, lot, and serial data) cannot be imported: "Import of this subrecord's data is not currently supported." The practical workaround uses the "Custom Records" import type with the "Item Additional" record, the path Oracle documents for mapping auxiliary lot and serial fields to items.

The Real Problem with Lot Numbered Records

NetSuite stores lot attributes on the Inventory Number record, which is a child of the item. The standard Import Assistant does not list "Inventory Number" as a selectable record type. That is why mass-updating a custom field on the Lot Numbered Record through a typical CSV workflow fails, the import path simply does not exist for that record.

The fields on the Inventory Number record that you can populate during a receipt include the lot number itself, expiration date, and a small set of standard attributes. Anything custom (your "Manufacturer Lot Number," vendor lot number, country of origin, etc.) lives outside that standard set and cannot be addressed through the regular Item or Transaction import paths.

The Lot Numbered Record is a child record, which is why the standard Import Type list skips it entirely. The Inventory Detail subrecord it lives on is documented as non-importable.

The Documented Workaround: Custom Records Import

Oracle's help topic on mapping additional lot or serial fields points to a specific import route. The Import Type is Custom Records, and the Record Type is Item Additional. This import is designed for adding auxiliary lot or serial attributes that link back to the parent item.

Step 1: Confirm the custom field is actually stored on the Item Additional record. Open the custom field definition at Customization > Lists, Records, & Fields > Record Types, locate the record type that backs your lot attributes, and verify the field is present. If the field lives on the Inventory Number record itself rather than the Item Additional record, this import will not touch it.

Step 2: Build a saved search of Inventory Number records that need the update. Use the internal ID field as the join key, filter on items, and add the custom field as a column. Export that search result to CSV, that becomes your template for the import.

Step 3: Run the import. Go to Setup > Import/Export > Saved CSV Imports, then click Import Assistant. Select Custom Records as the Import Type, then Item Additional as the Record Type. Map your CSV columns to the fields, set the Internal ID of the Item Additional record as the key, and run an update-only operation.

When the Field Truly Lives on the Lot Numbered Record

If your customization writes the manufacturer's lot number directly onto the Inventory Number record (not Item Additional), the CSV import route is closed. NetSuite's own CSV Imports Guide confirms it: "Import of this subrecord's data is not currently supported", and the Inventory Detail subrecord is where lot and serial numbers live. There is no supported CSV import for updating custom fields on the Inventory Number record.

The realistic options in that case:

• SuiteScript update. A Map/Reduce or RESTlet script that loads the Inventory Number record by its internal ID, sets the custom field, and saves. This is the path most RF-Smart environments take because the data already flows through a receiving script.
• Workbench / SuiteTalk REST. Pull the Inventory Number records via the inventoryNumber record type, update the custom field value, and push back. Works for under a few thousand records in one job; concurrency limits make bulk SuiteTalk updates slow.
• Re-receive the lot. If the lot is still open on a pending item receipt, the scanner can re-populate the field without re-creating the lot. This is the cleanest fix when the receiving window is still open.

A minimal SuiteScript 2.1 example for the script route:

/**
 * @NApiVersion 2.1
 * @NScriptType Restlet
 */
define(['N/record', 'N/log'], (record, log) => {
    const updateLotField = (context) => {
        const { lotInternalId, mfgLotNumber } = context;
        record.submitFields({
            type: 'inventorynumber',
            id: lotInternalId,
            values: {
                custrecord_mfg_lot_number: mfgLotNumber
            }
        });
        log.audit('Lot updated', `Inventory Number ${lotInternalId} set to ${mfgLotNumber}`);
        return { success: true };
    };
    return { post: updateLotField };
});

Use custrecord_ (not custbody_) for custom fields on record types like Inventory Number, custbody_ is reserved for transaction body fields. You can confirm the field ID at Customization > Lists, Records, & Fields > Item Fields or by inspecting the URL when viewing the field definition.

Step-by-Step: Building the CSV-Style Update with a Script

For teams that want the CSV workflow but cannot use the Import Assistant, the pattern is a saved search feeding a script.

Step 1: Create a saved search on the Inventory Number record. Add filters for lots missing the custom field, expose the internal ID, and expose the target custom field. Save it.

Step 2: Run a Map/Reduce script that loads the saved search via N/search, processes results in 1000-record batches, and calls record.submitFields on each Inventory Number. Use search.load({ id: 'customsearch_lot_update' }) and iterate with run().getRange().

Step 3: Here is the validation step, run the saved search again after the script completes. Filter on lots where the custom field is still empty. A clean run returns zero results. If you see records remaining, the script hit a governance limit or the field ID was wrong; check the execution log.

Common Failure Points

• Wrong import type. Picking "Items" instead of "Custom Records > Item Additional" writes to the parent item, not the lot. The records appear to succeed but nothing changes on the lot. The Items import type only covers the item record types listed in the Record Type dropdown, it does not reach the Inventory Detail subrecord.
• Auto-generated numbering interference. If your Item Additional record uses auto-numbering, you must check the Allow Override box during mapping or the import will reject the External ID key. This is documented at Setup > Company > Auto-Generated Numbers.
• Field on the wrong record. Customizations created in the RF-Smart bundle often store the manufacturer's lot on the Inventory Number record, not Item Additional. Confirm before you build the import map.

What to Check Before You Commit to a Path

Verify the record type that owns the custom field. If it is Item Additional, the CSV import works. If it is Inventory Number, plan a script or a manual re-receipt. For RF-Smart environments, the most sustainable long-term fix is updating the receiving customization to require the manufacturer's lot before allowing the user to save the receipt, that way the CSV rescue job becomes a one-time cleanup rather than a recurring chore.