Skip to main content
Question

Receive into Arrival Location causing issues with Master Scheduling

  • March 12, 2024
  • 4 replies
  • 217 views

Mdangelo
Sidekick (Customer)
Forum|alt.badge.img+8

Hello IFS Experts, hoping someone out there has an solution

We use demand planning and we forecast many of our purchased finished goods items and majority of these are offshore with lead times of 6-8 weeks transit time.

We register arrival once container is on ship in transit to designate ownership of goods.

When we receive this into arrival into non--nettable location, it shows up for Master Scheduling as available on the date of we did the receipt into arrival location.  This is a flow in IFS and was fixed for Cloud Version update, but IFS will not update for APPS10. 

This is causing inaccurate MS proposals and we need the system to have accurate date of receipt for Master Scheduling to generate correct purchase requisitions.  

Is there anyone else experiencing this  issue and have a good solution?

4 replies

AkilaR
Hero (Partner)
Forum|alt.badge.img+11
  • Hero (Partner)
  • March 12, 2024

Hi Michelle,

If the Items are in Inspection status it is not considered for Planning. So if you change the receive case to Receive into Arrival, Inspect at Arrival Receive Case receipt will place the item in Inspection Management, while it is in the Arrival location and the user will have to perform the inspection register before moving to a usable location. However, I’m not sure if this works with MS as I have not tried this with the MS process before. I can confirm this works with other planning functionalities and it does not show in the IPAP as available as well.

I hope this will help.

Regards,

Akila


Mdangelo
Sidekick (Customer)
Forum|alt.badge.img+8
  • Author
  • Sidekick (Customer)
  • March 13, 2024

Akila, thank you for your feedback. The one thing that must happen is that the planned receipt date must be from the IDA and/or PO. If MS still uses the date that it was received into arrival, then it still will plan incorrectly by MS. 

If the solution you gave will prevent items to use the receipt to arrival date by adding an inspect to arrival as well, it may work, but if not, then MS still may not work.

If this is an IFS flaw in APP10 and they fixed for Cloud Version, I wish they would fix in APP10 as well. When your MS or MRP does not work properly, you cannot run your business effectively and it requires outside tools.


Rhillson
Sidekick (Customer)
Forum|alt.badge.img+6
  • Sidekick (Customer)
  • December 18, 2025

@Mdangelo - We too have been looking at ‘Register Arrival’ as a solution for taking ownership of goods at time of shipment from overseas. I believe I’ve isolated the issue down to how IFS treats PURCHASE_ORDER_LINE_SUPPLY (PO lines) differently than ARRIVED_PUR_ORDER_SUPPLY (PO lines after register arrival receipt) as it applies to the ‘date_required’ field displayed in IPAP and used for MRP as well as I’m guessing MS related calculations.

Elements of PURCHASE_ORDER_LINE_SUPPLY plainly use ‘planned_receipt_date’ from the PO line, which end users can edit/maintain (VARIABLY), as the ‘date_required’ , but elements of ARRIVED_PUR_ORDER_SUPPLY use a calculation from Pur_Ord_Date_Calculation_API.Get_Date_Required. This API specifies that date_required can be influenced by, as mentioned above, changing some (FIXED) inspection parameters AND/OR by changing the (FIXED) ‘Internal_Delivery_Leadtime’ by Supplier/Site on the SC Matrix for Supplier. Both modifications via the API are (FIXED) offsets from the ‘Actual_Arrival_Date’ logged at time of the register arrival receipt.

The FIXED nature of the possible adjustments are currently what we are struggling with, as our purchasing team wants to be able to adjust the planned receipt date for delays on-water, at port, etc. when Register Arrival is used in the fashion we are both attempting to use it for. It seemed like the best way for us to manage PO dates for ocean shipments until this API nuance was discovered during our testing.

Would be interested to hear if you found any other workarounds in the last year? Thanks!


Rhillson
Sidekick (Customer)
Forum|alt.badge.img+6
  • Sidekick (Customer)
  • December 18, 2025

@majose You were able to help us out with a function change impacting MRP Action Proposals for 25R1, which we’ve now realized during our recent upgrade. (Thank you!)

Any chance you would look at an improvement to Pur_Ord_Date_Calculation_API.Get_Date_Required as well? 😁 The proposed improvement would allow the user-editable PO line ‘planned_receipt_date’ to still VARIABLY impact ‘date_required’ throughout IFS, at least under certain circumstances, after receipt to arrival?

While our team is hesitant to MOD at all during our implementation, we are considering a change like below to restore some VARIABILITY to the process. I’m sure there is something much more elegant you and the team could come up with that also maintains the ability to use the FIXED inspection parameters and/or the internal delivery leadtime if the user desires:


--Pur_Ord_Date_Calculation_API Proposed Modification

-- @IgnoreMissingSysinit
FUNCTION Get_Date_Required(
  order_no_                 IN VARCHAR2,
  line_no_                  IN VARCHAR2,
  release_no_               IN VARCHAR2,
  contract_                 IN VARCHAR2,
  part_no_                  IN VARCHAR2,
  ship_via_code_            IN VARCHAR2 DEFAULT NULL,
  internal_control_time_    IN VARCHAR2 DEFAULT NULL) RETURN DATE
IS
  internal_control_time_temp_   NUMBER;
  ship_via_code_temp_           VARCHAR2(3);
  internal_delivery_leadtime_   NUMBER;
  calendar_id_                  VARCHAR2(10);
  date_required_                DATE;
  date_start_inspection_        DATE;
  pur_order_rec_                Purchase_Order_API.Public_Rec;
  planned_receipt_date_         DATE;
BEGIN
  pur_order_rec_ := Purchase_Order_API.Get(order_no_);

   ship_via_code_temp_ := NVL(ship_via_code_, Purchase_Order_Line_Part_API.Get_Ship_Via_Code(order_no_, line_no_, release_no_));

   calendar_id_ := Site_API.Get_Dist_Calendar_Id(contract_);

   internal_control_time_temp_ := NVL(internal_control_time_, Purchase_Order_Line_Part_API.Get_Internal_Control_Time(order_no_, line_no_, release_no_));
  internal_delivery_leadtime_ := Pur_Order_Leadtime_Util_API.Get_Internal_Delivery_Leadtime(
                                    pur_order_rec_.vendor_no,
                                    Purchase_Order_API.Get_Addr_No(order_no_),
                                    ship_via_code_temp_,
                                    contract_,
                                    part_no_);

   -- Add Internal Time prior to inspection
  date_start_inspection_ := Receipt_Info_API.Get_Latest_Arriv_Date_By_Srce(order_no_, line_no_, release_no_, NULL, Logistics_Source_Ref_Type_API.DB_PURCHASE_ORDER, NULL);

   --Do not use our procedure Fetch_Calendar_End_Date here, it can raise an error and this function is used in a view.
  date_required_ := Work_Time_Calendar_API.Get_End_Date(calendar_id_, date_start_inspection_, internal_delivery_leadtime_);

   -- If inspection time is > 0, it should be added in working days
  IF (internal_control_time_temp_ > 0) THEN
     -- Do not use our procedure Fetch_Calendar_End_Date here, it can raise an error, and this function is used in a view.
     date_required_ := Work_Time_Calendar_API.Get_End_Date(calendar_id_, date_required_, internal_control_time_temp_);
  END IF;

  -- Get planned receipt date
  planned_receipt_date_ := Purchase_Order_Line_Part_API.Get_Planned_Receipt_Date(order_no_, line_no_, release_no_);

   -- If date_required is different from planned_receipt_date, use planned_receipt_date
  IF date_required_ != planned_receipt_date_ THEN
     date_required_ := planned_receipt_date_;
  END IF;

   RETURN date_required_;
END Get_Date_Required;

Thanks again for putting together a great product!

-Roger