Sales Order Allocation

Owned by Waseem Khan
Last updated: Sept 11, 2024 by Scott Zhuo
2 min read

Overview

AdMagic receives orders from various channels, such as EDI and Shopify Store integration. All these orders are brought in by automatic routines. Once the order is in the GFERP, users will need to manually allocate and create shipments for those orders. However, due to the volume of orders, manual allocation and creating warehouse shipments is not feasible for AdMagic. Therefore, an automatic/scheduled process needs to be implemented.

Process

  • Step 1: The system will automatically allocate inventory for orders where Document Status = ‘Open’ and Allocation Status != ‘Full’.

    • If the allocation process fails, the system will write the error message to the Allocation Processing Error field.

    • Class Reference: GF_SalesOrderAllocationBatch

  • Step 2: The system will automatically create warehouse shipments for orders with Document Status = ‘Open’ and Allocation Status = ‘Full’.

    • If the creation of the warehouse shipment fails, the system will save the error message to the
      Whse. Shipt. Processing Error field.

    • Class Reference: GF_CreateWhseShipmentBatch

  • The above processes are scheduled to run hourly and are controlled by the scheduler class GF_SOAllocationAndWhseShiptCreationSched

    • To Schedule the routine to run hourly, use the following command:

      String cron = '0 0 0/1 1/1 * ? *'; //hourly  GF_SOAllocationAndWhseShiptCreationSched sched = new_GF_SOAllocationAndWhseShiptCreationSched();  String jobId = System.schedule('Sales Order Allocation and Whse. Shipt. Creation Job', cron, sched); 

Sales Order Allocation Challenge

Issue:

AdMagic states that they will have more than 50,000 order lines with the same item in the same warehouse open at any given time, especially for those Kickstarter items. This will cause the out-of-the-box GFERP allocation routine to fail because the routine calculates the item quantity available by subtracting the quantity allocated from the item Quantity on Hand. The system accomplishes this by looping through all allocation lines, which will trigger a 'too many query rows' error, a limitation imposed by Salesforce governor limits. Salesforce restricts querying up to 50,000 rows per transaction.

Solution:

  • A new object “Item Allocation Summary(GFERP__Table02__c)" is created to store summarized item allocation by Warehouse, Item, and Unit of Measure.

  • Trigger "GF_ItemAllocationTrigger" is added to detect Insert, Update, and Delete operations against the GFERP's Item Allocation object. The system will increase or decrease the quantity count in the summarized table based on the operation type/or the quantity change detected by the trigger.

  • A nightly job routine(GF_SummarizeItemAllocationSched) is scheduled to recalculate the allocated quantity in the summarized table. The night job will run the batches in the following order:

    • 1. Empty the summarized table - GF_DeleteSummarizedItemAllocationBatch

    • 2. Prepare the item allocation table - GF_UpdateItemAllocationBatch

    • 3. Generate summarized item allocation records - GF_SummarizeItemAllocationBatch

  • Custom Allocation Management class(GF_AllocationMgmt) is created to handle item allocation, utilizing the data in the new ‘Item Allocation Summary’ object.

    • This custom allocation management class is only used by 'GF_SalesOrderAllocationBatch'.
      Auto allocation when entering an order manually is still handled by the out-of-the-box GFERP allocation logic.