SAP R/3 : Update ALV FieldCat... must check Layout Management

Morning reach office and had the most wonderful headache ever. I added a new field to an ALV report but it was not showing the new field during run time.

Last time i had this similar issue with the grids. However it was so solve with clearing the ALV buffer (table GT_LTDXKEY and shared buffer EUINFO). By using this method, i still couldn't see my latest changes to the ALV report. So the best way would be Google around first. Hey, human invented Google right? In fact, everyday we Google. Why not Yahoo? Anyway, after some 15 minutes, i dropped off everything. I went for a break and think again of my coding. 'What went wrong?', i asked.

Well, my dear readers, the only thing that you must always remember to do when you change your FIELDCATS in ALV, you must ensure that the layout management is not holding any old layout from your tester, your functional or your previous ABAPer. I was brought to this resolution in SDN when Rich Heilman wrote in Raj Chinni's similar problem. Raj had the same problem like mine.

So, it was the layout management that was dissappearing my new changes...

is sky the limit... clear your layout management when you make changes to FieldCat...

SAP R/3 : TRIAD Vendor on Flexible Spending Account (FSA)

One of the many things that i got to know about coding a program to download data on flexible spending account onto a specified file format are the following items:

1. Infotype 0170 - Flexible Spending Account
2. Function module 'CU_READ_RGDIR'
3. Function module 'PYXX_READ_PAYROLL_RESULT'
4. Infotype Payroll, Payroll Results, Payroll Results Table
5. Infotype 0000, 0002, 0041
6. Tables PCL2 to use Payroll clusters and functions
7. Transaction Code PC_PAYRESULT to see payroll result (Payroll result cannot be seen using PA30)

Given an employee number (PERNR), you will need to decide whether he or she is valid for the FSA file extract. In 0170 there will be a BEGDA and ENDDA, you need to compare against the payroll year for selection and the date selection in the program. Comparing against the payroll result, for period (begin date and end date) is a must so you will get the exact record.

To get the payroll result, you will need the function module called 'CU_READ_RGDIR'. This will give you the as you see in pc_payresult transaction code. The paydate, for-period, in-period, begin date, end date and so forth. Now to obtain the result table of a certain for-period record, you need to use the PYXX_READ_PAYROLL_RESULT. This function will return you the RT result table.

Using PYXX_READ_PAYROLL_RESULT, reader must take note that it returns table in structure, preferably use a field type to hold the result. Don't use internal table, you won't be able to see the result when you debug this function module. A better way to see how the result is work out, you can trace PC_PAYRESULT

Employee with health plan DCAP (dependent healthcare) and MCRP (employee healthcare) will be selected into the file. The program will calculate the effective date for the both benefit plan, the deductions and the stop date and annual contribution. The stop date is pretty unique here is that it require the programmer to do plus one record checking.

(Note : In VSP, PPO and TRIAD, all requires plus one record checking. Its just not only in TRIAD that require this feature)

Plus one record checking meaning you check the existent or availability of the next (future) plan from the existing current plan.

At the end of the result, the file should have all the valid employees entitled for FSA via legitimate DCAP and MCRP benefit plan. In contrast to VSP and PPO file that i had done last time, TRIAD file does not require row of records of dependent after employee record. However, TRIAD will not retrieve employees who are retired or terminated.

This program is my last program which was handed over to Mitchelle Yeoh for future maintenance. So far this is the best program i ever written cos all of it are include program and many subroutines for easy handling and maintenance.

is sky the limit... payroll result and result table for FSA

SAP R/3 : How to Create Dunning Proposal

In order to create a Dunning and also see its result you need the following transaction code:

1. FPVA - Dunning Proposal
2. FPM3 - Dunning History Display
3. FPL9 - Account Display List

Let me explain a little bit about Dunning. Dunning is a method developed to insure collection of accounts receivable. So now what the hell is accounts receivable. It means the money owed to the company for providing their services to customers. Therefore, Dunning is a way to insure that any amount of money not paid by customers are made known (in other words, a gentler reminder to pay back money)

Dunning procedure in SAP are automated and you can configure the Dunning procedure in SAP.

However, this entry is not about configuring client's Dunning procedure. Its about how you can propose a Dunning to a contract account and displaying its history.

1. FPVA - program to propose an account contract for Dunning. You can do this by copying a past DATE ID and Identification related to a contract account and put it as the latest date for processing. However, you will need to reverse the past Dunned item in order to process.

- Once you have copy a previous contract account for Dunning, click the 'Save' button.
- Then click the 'Schedule for Processing' button. You will be ask whether to run now or later. You can click tick 'Process Immediately' option and click 'OK'.
- Your contract account will be processed. Remember to click 'Refresh' to see the result.

2. FPM3 - depending whether your Dunning proposal's contract account allowed you to Dun, it will be shown in FPM3. FPM3, a program that display either available contract account eligible for Dunning or for reversal. You can reversed a Dunning item here. To reverse Dunning, look for the thick red arrow pointing to the right.

3. FPL9 - to display all your contract accounts with items that has Dunning reversed and overall items that is debited and credited. You can checked in detail by double clicking the line items. In my assignment, an item is Dunned according to the following rules:

1. if clearing state is 8 and credit posting is less than zero and total balance is greater than zero, then it is Dunned.

2. if clearing state is 8 and credit posting is less than zero and total balance equals zero then no Dunning carried out.

3. if clearing state is 8 and debit posting is greater than zero and total balance greater than zero, then no Dunning carried out too.

Personal note : FFI_EVENT_1708 standard function module was modified to cater the changes mention above. Client wanted Dunning to vary according to the 3 rules above.


is sky the limit... Dunning procedure