2008 May 08 9:54 PM
I am trying to find records in 168 that have been inserted within the time period specified on the PNPCE selection screen like this:
if header-endda eq '99991231' and header-aedtm between pn-begda and pn-endda.
However, when the HEADER-OPER is "I" the value of HEADER-AEDTM is always zeros. I'm confused. Please advise.
Thanks.
2008 May 08 10:01 PM
Generally we dont search records based on AEDTM as it may chnage due to certain other reasons and then wil give false results.
e.g. A record is created on 01/02/2008 but on 01/03/2008, I realize that something is wrongly spelt or just open the record in PA30 and save it without making any change then AEDTM will change to that date.
Instead employees are always selected based their action. Normally we etract employees who are active on that given date for that particular infotype.
Regards,
Amit
2008 May 08 10:10 PM
Thanks, Amit. However, the point of this report is to show any participant who added new coverage or whose coverage changed (i.e., switched plans) within the current month. So I'm looking at PCL4 to tell me this.
For example, if I go from Optional Life - $10K to Optional Life $20K this operation does not delimit the original record but is simply an update - the beg/end dates are the same.
2008 May 08 10:19 PM
Exactly thats what I am saying, if its update the begin and end date of the record then fetch it from there only and not from AEDTM.
Or call any of these FM to get records in the given date -
HR_INFOTYPE_OPERATIONS or
HR_BEN_READ_INSURANCE_PLANS
Regards,
Amit
2008 May 09 12:08 AM
Amit:
PERNR BPLAN BEGDA ENDDA
======= ====== ======== ========
Before 00000013 B101 04/01/2008 12/31/9999
After 00000013 B102 04/01/2008 12/31/9999
Let's say I change this record today (5/8/2008).
When I run my program I want to pull this record as having been changed (the plan changed). I can't go by BEGDA/ENDDA unless the user manually delimits the old one and creates a new one. Assuming they do not do that and they simply change the existing record (as above), I'll have to go to PCL4 and see that there's a "U" record in the HEADER where this row was changed. I understand that it could have been a mistake but I'm checking to see if they made a change in only the BPLAN or PLTYP and if those didn't change I'm skipping it. But I'll need to look at AEDTM for these to see if they were changed in the current month. This is working fine in my program.
For records that were inserted into 168 within the current month I've no idea what the BEGDA is going to be. It could be retroactive from the beginning of the month or even prior or it could be some date in the future like the beginning of the next month. So again I'd check PCL4 to see if there was an inserted record in 168 between within the last month by looking at AEDTM but this date is all zeros on HEADER and thus makes it impossible for me to check it for inclusion in my selection.
I'm only looking at PCL4 to see if there was a change or an insert - not to get the data. Really all I need from PCL4 is to see if the given pernr has a changed/inserted 168 record there and if it is I'll grab the details for my report from the actual infotypes themselves.
Is this making any sense? LOL. I'm new to ABAP/SAP so I appreciate your patience.
2008 May 09 12:47 AM
ok, got your point, now one question....why are we not using the normal rule of data entry ...that is terminating the previous value and putting new value. Since it will be wrong to say that employee is upgraded to new plan but the start date will be the same. In this case there will be no history of the employee. If we want to fetch the old record that will not be available.
This is just for my information.
Regards,
Amit
2008 May 09 1:06 AM
I completely agree with you. I'll need to check with my functional person to see if they're going to make that a rule but I do know that today I went into PA30 (test data) and updated a record in place and SAP didn't delimit the "old" record and create a new one - it just let me update it (INFOTYPE 168) so at least from an SAP perspective you can do this although it doesn't make much sense from a history perspective.
This report is actually a SmartForm that is a letter showing the individuals who changed their plans in a given month period what their new coverage is in order for them to confirm the changes.
So I'm looking at PCL4 for any changed records (U) to 168 where the AEDTM is in the month period and once I find them I'm grabbing some demographic information via the pernr to populate the form letter (name, address, etc.). Like I said, I'm checking specifically to see if what was changed as the BPLAN and/or PLTYP.
For some reason, however, when the HEADER-OPER is 'I' (inserted) the AEDTM is all zeros and that's throwing my selection logic off (participants with a new plan during the month such as new hires, etc. will also need a certificate of coverage sent to them as well).
2008 May 09 1:26 AM
I did try to work out on my system for the same but even the standard reports for the same purpose is not fetching the record. I think you need to look a work around taking this report as a base...RPUAUD00 or check the FM - HR_INFOTYPE_LOG_GET_DETAIL
Regards,
Amit
2008 May 09 1:31 PM
Amit:
I ran this report and noticed that on the record where HEADER-AEDTM was all zeros the actual date was showing up on the report so I investigated and found it was coming from LO-KEY-BDATE (and BTIME). I'm not sure why the HEADER isn't being populated but perhaps the macro I'm using (import_from_pcl4) isn't populating this value???
Anyway, I'm going to use lo-key-bdate to select. What do you think?
2008 Aug 13 7:11 PM
Closing this due to lack of responses/resolution but thanks to all who did!