Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

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 to orders whose Document Status = ‘Open’ and Allocation Status != ‘Full’.

    • If the allocation process fails system will write the error message to the Allocation_Processing_Error__c field.

    • Classes 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 system will save the error message to the
      Whse_Shipt_Processing_Error__c field.

    • Classes Reference: GF_CreateWhseShipmentBatch

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

    • Schedule the routine to run hourly, run this:

      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 Allocations 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 item Quantity on Hand from the quantity allocated. 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.

  • No labels