Proposal for Application Engineering Allow SO, Not PO

Proposal Summary 

This proposal outlines a solution that leverages the status of items added to transactions to address situations where customers place orders without accurate part numbers being assigned. 

 

Requirement 

Magwitch’s Application Engineering department is encountering an issue where customers order a custom Pole Shoe before a part number is generated in Netsuite. Design work commences when the PO is received; However, there are numerous times where customers place PO without the accurate part number being assigned. The customer PO needs to be configured by CS before the design is complete to assign an accurate part number. 

 

Deliverables 

We are utilizing the potential of the Status Fields bounded to Item Records, to add validations at transaction levels. Only 4 transactions are considered – Sales Order, Purchase Order, Item Fulfillment and Assembly Built. 

Conditions associated to each status of the item, shown in the matrix below: 

 

 

Custom Record Creation: 

We will create Custom Record named – ITEM STATUS MATRIX which will hold the following fields  

1. NAME – Points the CODE. 
2. OVERRIDE IN SO – In Sales Order records, Allow Item when True; and disallow when False. 
3. OVERRIDE IN PO – In Purchase Order records, Allow Item when True; and disallow when False. 
4. OVERRIDE IN IF – In Item Fulfillment records, Allow Item when True; and disallow when False. 
5. OVERRIDE IN BUILD – In Assembly Build records, Allow Item when True; and disallow when False. 
6. NOTES – To add the description of each status. 

 

We will create entries for each distinct code as per the shared matrix. 

Example: To enable part numbers to be generated for a sales order but not be orderable on a PO. See the table below for use cases:   

Item Status Field & Data Import: 

 

• We will create a new field like the current ITEM STATUS (Field Id: “custitem_mtww_item_status”) field in the item record.  

 

 

• We will name the new field as ITEM STATUS (NEW) and the list will source the custom record entries. 
• We will run an import to update the Item status (new) field values based on the current ITEM STATUS Field in sandbox. 
• In Sandbox, initially in the scripts this new field will be referred for validating the status of the item record. 
• After Confirmation we will change the sourcing of the original field ITEM STATUS with the custom record entries replacing the current custom list “Item Status List”. 
• Then the data lost in old the field due to the field type change, will be restored by another CSV import 

 

Sales Order & Purchase Order 

• We will add validation at the transaction line level, where an alert will be shown each time items are committed to the item sublist. 
• If the status of the item holds FALSE, for the overriding SO it will be restricted on SO and alert will be shown. Similarly for PO.  

More Scenarios: 

1. Alerts will be shown whenever the items are added. This will consider editing and addition or updation of existing item lines in SO and PO. 
2. Since there are limitations in validating and alerting upon addition of line items on using “Add Multiple” Button. We will have one more validation that will work on saving the order, intimating the restricted items. 
3. Also, the alert on line level will work for the orders created manually within Netsuite. But, for validating eligibility of the items on orders created via other systems e.g. EDI, CSV Import, validation on the save will happen and won’t allow the creation of SO/PO with such items. Or do we need to remove and save with the rest of the items? 
4. Will the item status change at in transit states – say if an item is placed in an order and later the status changed to any of the restricted status? So, upon editing and saving the record, every time the validation needs to run? 

 

Assembly Build 

• We will add validation upon saving of the Assembly Build record, an alert will be shown. (items both at the transaction body level and the components will be considered) 
• If the status of the item holds FALSE, for the overriding Build it will be restricted to the assembly build and alert will be shown.  

 

Item Fulfillment 

• An alert will be shown upon save of the Item Fulfillments, based on the selected items in the IF. 
• If the status of the item holds FALSE, for the overriding IF it will be restricted on the assembly build and alert will be shown. 
• Validation will run on each edit or any transition change from pick, pack and ship. 

 

Error Handling: 

Any unexpected errors in the script will be routed to the script owner. 

Assumptions 

• Item Type will be Assembly and Inventory Items. Not kit items, Group items or any other item types will be considered 
• Custom records item status entries should be distinct 
• There won’t be any validations on the custom records. 
• Item Status in item record and the custom record entries won’t have any validations or automation. 
• Item Status is manually selected by the Engineering Team. This status field has no connection with the inventory/stock levels of the item. 
• Orders placed manually (directly in User Interface of Netsuite) are only considered. Hence all other contexts like orders created from bulk processing etc. are ignored.  

 

RISK 

• We will create custom records referring to the internal id order of the item status list only. But, right now some of the statuses on the list are not included in the matrix rules. 

 

 

Otherwise syncing the Item Status field from sales force may break, after changing the sourcing with our custom record. In that case we don’t need to replace the status list with the custom record entries list. Hence, we will check the status and lookup the corresponding custom record matrix.