The WO numbers should not be random. When you generate planned orders you are creating provisional purchase, transfer, sales or work orders in MRP. These are generally created using the next key number configured in your system for the document type, but need to be unique and so take into account the sequence numbers used by manual, EDI or other interfaces. That means if you create planned work orders in the morning, the next day the numbers might be different because you created work orders through your manufacturing processes throughout the previous day. The numbers are sequential but they are tracked internally and are not user configurable.

Unless you are using an add-on like E2B to automate the MRP calculations, the problem you describe is at least partially self-inflicted. Each time you initialize a MRP version, you remove any planned orders created under that version. If you generate planned orders then remove the unfirmed orders, you are again deleting the provisional orders that were not created into actual orders. Whenever you create orders in MRP you are using these sequential keys, which are integers. They are not generally reused, but you will only have a problem if you start getting close to 2.1 billion (positive integer value maximum is 2,147,483,647 in SQL, which is the same as Long variable type in VB6).

If the process you are following is manual, you may need to begin organizing your MRP processes with different versions, filter criteria, options, review and planning processes. That could potentially include the inventory, warehouse, vendor, routing and MRP configurations in the system. You generally create orders after reviewing the forecast for the items in your plan. You can reuse MRP versions without initializing if your filter, initialization criteria, selection and planning options do not change. Some of those can be modified without the need to reinitialize the plan but it depends on your configuration and requirements.

The Planned Orders tab first sorts by item, but if you want to change the order, click the column header. For example, if you click the "Order No" header the grid will sort by the number, either ascending or descending. The grid sort feature here works the same as it does in much of Sage 500.

thanks for your response.  Using your example your first planned WO 920 for 1005 pc.  What we see is when we run MPR the next day that WO number cycles to a new number (something like 1204) unless that planned WO is Firmed in the system which we do not like to do.  So I loose my index for that WO that is critical for other reports and analysis.  Other than firming the planned WO is there a way to keep the WO number from cycling?  We run MRP every day.

Thanks, DT  

You might want to reread my response from yesterday since those questions are answered there.

I am not an planner but a program manager.  So it wasn't obvious that your response had the answer.  Simply stated is there a process for maintaining the planned work order number besides firming the order in the system?

If you initialize data each day, the keys are going to increment according to your MRP and WO activity and there is no method in the native functionality to change that other than a source code modification. That applies to all companies you have in the system as well since they all use these key values. If you don't create actual orders and initialize the MRP version, the system removes the previous data associated with that version and recalculates it accordingly.

MRP is primarily a forecasting engine for demand fulfillment of your materials, sub-assemblies and finished goods. The method of fulfillment depends on your configuration and usage of the functionality but this logic centers around the items and not the orders. You can use the native features to build your forecasting models, as well as creating and scheduling work orders but it is always going to be item-centric, and the native MRP features and reports revolve around item fulfillment.

Given that, if you have the need to retain more order-centric data, you are going to need to adjust your MRP processes and usage scenarios, or have a developer build a modification to suit your needs. As I noted, you do not need to initialize the data each time you calculate demand, but it depends on how you have configured the MRP functionality, and there are hundreds of different ways to use it.

If you don't want to adjust your procedures or finance a modification, your only choice is to change those reports and analyses to organize planning data by item, not work order, because each time you initialize a MRP version, that previous data is going to be removed.

again, thanks for the response.  I think we are going to work with our developer to see if we can capture the association between the SO and the WO.  Obviously the MRP system knows that relationship because it creates it but there does not seem to be a record or index recorded that we can use.  Otherwise, I'll take your advice and look at some of the other ways we define our system and processes, such as how often we run MRP etc.

Thanks, DT

That can be a little tricky. The relationship between a WO and SO can be established using the Customer PO entered on the SO as well as the WO (you can create a WO from SO), or it can be established using an Estimate or with Product Configurator. These last features are a roundabout way to get to the routing and/or WOs though.

If you are looking strictly at MRP, a SO contributes to the demand forecast for an item, but that might be aggregated into the total demand for the item which I seem to recall is related to the settings you use. If there is a relationship between the MRP version and the sales order, it is going to be based in the tmfMRPDetail_HAI table.