Lot, bin and railcar allocation for a resin distributor

#The situation

A resin distributor sells material identified by lot and stored by bin, and much of it arrives by railcar. Customers buy a particular lot or grade, and a railcar still in transit is often sold before it arrives. Standard NetSuite commitment reserves a quantity at a location. It cannot tie a specific lot in a specific bin to an order, and it cannot promise stock that has not been received. The team kept those promises in spreadsheets and relied on the warehouse to pick the right lot.

#What we built

Three allocation screens, each a Suitelet with a client script. They share one allocation library and two custom records, an allocation header and its lines.

• From stock. Start from an item, see its lots and bins with what is on hand and what is already promised, and allocate a lot and bin to one or more sales orders.
• From a sales order. Start from the order and choose which lots and bins will fill each line.
• From a purchase order. Start from an open purchase order and allocate its incoming lots, including railcars identified on the PO line, to sales orders before the material is received. The screen checks that the order and its location are set before anyone can allocate.

User Events keep the numbers right. When an allocation line is created, changed or removed, the allocated quantity on the sales order line is recalculated. When every allocation is removed from an order, its commitment, location and lot details are reset. When a receipt arrives against a purchase order with allocations, the item receipt logic moves the allocation onto the received lot numbers, so the promise made against the railcar becomes a promise against real stock. An allocation button on each lot-numbered item opens the stock screen for that item.

#What it does now

Customer service can check from NetSuite whether a lot is still available, and the warehouse fulfils against the lot and bin that was promised. Inbound railcars can be sold ahead of arrival, and NetSuite keeps track of who bought them. The allocation screens show errors on the page in plain language and log them for the administrator.

#Under the hood

• Allocations are custom records with a header and lines, so each one has its own history, separate from the transaction fields.
• The allocated quantity on an order line is summed again from its allocation lines on every change, which keeps it correct after edits and deletes.
• The receipt step turns a purchase-order allocation into a lot allocation at the moment of receipt.
• The three screens share one library, so the rules are the same whichever screen a user starts from.
• Checks on the purchase screen stop an allocation before the data it depends on exists.