Making PO Line Creation (Aggregation) More Granular

Acumatica ERP provides great flexibility for use while also working to streamline purchase activities with suppliers. On the demand side, a Sales Order and related SO Shipments can be created with many lines for the same item, and those lines can be broken down further into “splits” to capture Lot/Serial information. However, once the demand in a sales order flows to the PO for purchase, demand is aggregated to simplify the order with the supplier. As that material is received, it becomes available to fulfillment of the existing demand.

While aggregating demand into streamlined purchase orders sounds great for supply chain management, “aggregate” turns to “aggravate” when those PO lines need to be broken down into more granular pieces than allowed in standard code. While heavy handed modification is undesirable, sometimes it is necessary. Keep in mind that such heavy handed modification adds work to every subsequent upgrade because we must check the new source code against our modified version and apply any changes to standard code back to our copied/modified code. In this case, we need to replace the CreatePOOrders method and import the private static method CreateSplitDemand to overcome accessibility issues since it is defined as private in the source code. While not shown here, also note that the POCreateFilter_RowSelected event handler must be overriden to call our copy of the CreatePOOrders method. As it does not relate to the topic, the code to update the PO line cost from Bob’s customization is also excluded. However, it is important to note that a customization is required to override the cost in this case. Otherwise, standard vendor prices are used by the PO creation.

In this scenario, our purchasing clerk, Bob, needs to place purchase orders for outsourced customization of stocked materials to ship to a customer. The customizations have different costs from the supplier, and the cost of each customization must be tracked individually on the purchase order. The supplier has identified the cost to modify each unit. Unfortunately, all demand is merged into a single PO line by default with a single cost, so Bob must manually enter each line item on the purchase order and attach each line to its respective sales order line. Since Bob has a tool to track the customizations and supplier price alongside the customer’s sales order, Bob has asked that an enhancement be created to allow the standard Create Purchase Orders screen to process his demand into purchase orders, splitting by his key values that drive the distinct pricing.

Before making the enhancement, it is important to understand how the POCreate graph (used by the Create Purchase Orders screen) aggregates PO lines. Using a FieldLookup, the fields are defined for aggregation. Once the search is executed, if no match was found then a new PO line is created. Unfortunately for Bob, this did not include his extra “slice” of data. By adding MyField to INItemPlan from Bob’s product customization tool, the demand has a connection to the exact product customization record in the custom tool created in Acumatica ERP for his custom sales. Splitting PO lines at creation based on MyField means we need to inject that field into the FieldLookup search. To make matters easier, we add MyField to the PO Line in a DAC extension to store the reference to Bob’s custom tool and simplify our search.

The following code samples show only enough original code to help locate the additions as well as all the code added to complete the task. We can see how the INItemPlan (and DAC Extension) are found for the demand and added to the FieldLookup. Then once the PO line has been created, we store that value in the PO line’s DAC extension to aid with the FieldLookup on the next demand record processed. This has the added benefit that the PO line can be given a link back to Bob’s custom tool with ease!

The full code added the Graph Extension for Acumatica ERP 2021 R1 shows the original source code copied from POCreate with the additions embedded.

Now that the enhancement has been implemented, Bob’s workload has dropped significantly because the standard Create Purchase Orders screen automatically creates PO lines for each unit in the demand with its different costs.

It is worth noting that subitems may have worked in “Bob’s scenario” in which the purchase order would have split lines by subitem However, not all use cases fit subitems. The real scenario that drove this enhancement involved restoring identical stock items of varying conditions to specific quality specifications. Acumatica ERP facilitates the restoration service performed by a host of vendors with unique specialties. The product received on the Purchase Order should have identical specifications, so subitems would not be practical.

Happy Coding!

Leave a Reply