The customer Schedule uses a cummulative start date and a cummulative req.  so basically as there was a requirement for it unless you have taken that into account it still thinks you owe them that quantity.  It can also be affected "Use Ship/Plan PCR"

The "Prior Cum Req" represents the total cummulative requiement prior to the "Prior Cum Date"  MRP compares this quantity with the cumulative shipped quantity before determining the net demand. For example, if the total you have shipped against an order is less than the Prior Cum Req value by the Prior Cum Date, this shortfall appears as a demand requirement on MRP, with a due date equal to the Prior Cum Date. However, if you are ahead of demand, the difference is deducted from the schedule release demand.

So you need to adjust this to correct the change.  Normally it is corrected when you get the next schedule from the customer as they should adjust the EDI to reflect that they no longer need this, but sometimes this does not happen and you have to adjust manually

Hi Phill,
Thanks for the quick reply. The person who would be able to carry this out is on holiday for today but back tomorrow. We will try and resolve the issue then. 

Thanks again really appreciate your help.

Hi Phill,
I am still a little confused. As you can see below, for each of the shipment dates shown below, we have shipped a partial quantity (we shipped 3600 instead of 4320), but it seems to think nothing has been shipped and left the whole demand still showing.


When i check the cum's i can see 


That is up to the 16/8/2023. The schduled data (from 1st screen shot) is up to the 18th so that would include the parts we shipped yesterday?? Is that correct? 
Prior day cum shipped 16/8/23 (2nd Screenshot) shows 1,095,240, that is 3600 different to the required ship prior cum req (from 1st screen shot). that is correct because that is the amount we shipped yesterday (17/8/23) 3600.
If we are only 3600 short in total why has it not cleared some of the old dates? Is that because QAD believes we are 720 pcs short for each individual reference??
Sorry if my expaination isnt very clear
Lee

You have cummulative set to no.  Can you print out the MRP results for this part?  

Hi,
you can see demands still required for the amounts we potentially short shipped becuase hte bucket amounts did not match our shipping quantities. Cusomter demand 4320, we shipped 3600 on each occasion leaving 720pcs still open.



Is this the information you wished to see?

Yes, this is what I wanted to see.  It is working as designed.  As you can see MRP is still just working on the balance that you theoretically still owe them (720 per week)  .  If you run the schedule inquiry you will see that the quantity ordered is 4320 and the cumulative would iclude the amount you still owe them.  So my first question is why you allow the customer to order 4320 but you are set to make FOQ's of 3600?.  If you are not going to ship them the backlog then they need to adjust the EDI message to change the cummulative order quantity to exclude this backlog.  If they need them then you need to look at your planning parameters to see why you are shortfalling.  I see that you are creating the WO as firm but increasing the quantity to 7200 (combining 2 at 3600 FOQ) so is FOQ the correct rule.  Perhaps you maty want to set to Ord Mult = 3600, and then use a POQ of 7 days.  Then it will automatically do what you are doing manually.

Hi,
sorry i went silent. we had summer shutdown etc. We anageed to reslve the issue above, however now we have a very simiar issue. As you can see this legacy data will also not delete. I have tried in 7.5.3 Req'd Ship Sched Maint, but it wll not delete. Is this becasue the staus is Q = 2 and Req Det is set to yes (ticked)?

 When i try to delete these demands, the system only adds in another line.  Then i have to change from Q status from F to 1, before deleting it.

Any ideas how i can change the Q & Rqm Det status? 
regards

I had a similar issue many years ago so what I did was to create a new release ID called say "ZERO"
I would then set that as the current release ID. on 7.5.1 and 2 (planning and shipping schedules) then when I ran 7.5.5 it would create the new schedule as an empty one.
I am probably over simplifying this as it was about 5 - 6 years ago