Cycle Count question regarding last PI date (MARD-DLINL)
Dear SAP Expert,
We would like to start Cycle count Next month , 95 % of our product is need to be count once a year . We expect to have the Physical inventory to be created spreads accross the year.
The problem is the date stamp on Mard-DLINL still blank, if we run MICN right now all Physical inventory document will be fall on beginning of this year . Do you have any experiance on this. I would like to go ahead to update date on Mard-Dlinl to spread the physical inventory accross the year, but I looking at elegant way. creating PI inventory is not solution because we have 200 branch and each branch has 10000 material nr.
Any suggestion appreciated.
The problem is the date stamp on Mard-DLINL still blank, if we run MICN right now all Physical inventory document will be fall on beginning of this year .
I dont think so, usually the next count date is determined by last count date plus the days specified for the class. If no last count date exist, then last goods receipt date is taken.
Further you should ABCD classify your materials to help SAP to create spreads accross the year. A items should be counted more often than B items, which should be counted more often than C items .....
The selection screen for MICN allows you to do further selections like storage location and material type and planned count date.
It will create more work while creating the documents but selection variants can help you to organize it.
If it is to much to count all material due to be counted in one day then you need to manual organize the count.
Like storage location from aaaa to cccc in week one, dddd to gggg in week two......
or
material type ROH in week one, FERT in week two, HAWA in week 3.....
or
by date, select only materials due to be counted in week one of a month and so on....
I am sorry I mean if we run right now all will be created beginning next year.
It is very hard to manually organize the way you describe , user need to manually sort 100 material every day as those is the same storage location and the same material type.
But thanks for you suggestion
I am sorry I mean if we run right now all will be created beginning next year.
I do not fully agree with your assumption. This would only be the case if you have all materials in one ABCD category and all stock have the same GR date.
Can you give a bit more insight? Maybe cycle count might not be that what you are looking for.
If you run it today, why would you have to count everything beginning of next year then?
What makes you think that it will happen this way, what seletion would you use.
Thanks for your patience,
We do have ABC , A need to be count 12 times a year, B is for 6 times a year , C is once a year.
All the C product never been count before and the normally for C item they have not many movement ( the last GR is initial balance ). so all the C item has last PI date blank (One things that I am not agree is, I don't think last good receipt date will be taken as based on SAP notes its clearly said system will takes from last PI date, if last PI date not there it will taken from material master creation date )
As the last PI date is blank and the all material created in the same day so all the PI for C item will fall in one day.
We run MICN report in background for the whole plant and setup the planned count date as today date . So system only create the PI for everyday job.
So the If for one particular day planned count fall exactly one year after creation of all C items , all PI for C items will be created. that the things we don't want .
That's why we expect to manipulate the Last PI inventory date.
I hope that explaint the whole pussle.
Okay, now I agree with you. Under these circumstances it will happen as you described.
Thank you for pointing me to the OSS note outlining the calculation. I will post the part below. I did not know that system is looking for material master creation date from table MSTA. All our stocks are batch managed, means system looks at MCHB table, whose entry is created when doing the goods receipt in our case, thats why I said last GR date.
You only have two options to avoid the described situation.
Option 1: Creating an ABAP which fills the 'date of the last physical inventory', means updates the existing MARD records.
Option 2: Smooth your count manually with additional manual created counts. Todays situation is that you only get very few materials to count almost only A items. Means you have still time enough to count more than the system proposes. Unfortunatly this means that you have to create PIDs by yourself, using the selection parameters as described in my first reply.
OSS note 518418
In principle, the program calculates the planned date of physical
inventory according to the following formula:
planned date = base date + Interval (Trans.OMCO/Tab.XT159C-ININV)
Usually, the base date is the 'date of the last physical inventory'.
Depending on the type of the stock or the batch management
requirement, this date is read from one of the following table
fields:
MARD-DLINL (Normal materials)
MCHB-CHDLL (Batch materials, separately valuated materials)
If no physical inventory has been carried out yet and if this date
field is therefore empty, the system uses the creation date of the
material as basis date. The basis date then comes from one of the
following table fields:
MSTA-ERSDA (Normal materials)
MCHB-ERSDA (Batch materials, separately valuated materials)
Since the cycle counting physical inventory always runs for the
current fiscal year, the earliest possible physical inventory date
is the 01.01. and the latest possible physical inventory date is the
31.12 of the current year.
Thanks,
I thought so , I already have the program to update the date of last PI in MARD, but have you tried this method ( update the MARD table ) before in live system..?
I just wondering must be some one have the some problem like me and already tried that method in live system.
I have done some table updates in a LiveSystem, but of course with extensive testing in developement and test system before. But I didn't do it for this discussed case.
We used the alternative approach I mentioned in my earlier reply.
I am curious about what others have done, too.
Iam even wondering that there is no OSS note about that issue, anybody must have the same issue when implementing CC
Well,
I already made a choice and go ahead on those table directly , as I have 200 branch and need to change last physical Item for almost ten thousand product for each branch.
So far I don't see any problem.
cheers