SAP Place

If you've done a bit of substitutions or validations, tocdes GBB1 and GBB0, respectively, then you might've encountered a case where you need to retrieve another object's details, e.g. get parent's WBS element's cost center. You might think that you'll only need to get the object's ID or number and work from there, but remember that the details may not have been committed to the database yet.

There are a couple of direct ways to achieve this:
1. Use matrix parameter
Set this feature when you define your exit in your custom copy of RGGBR000/RGGBS000. There is an example to capture this in the sample programs already, but basically it is to capture the FI document items (single BKPF entry & multiple BSEG entries).

2. Use SAP standard function modules to read from the buffer
SAP standard function modules related to the objects in validations/substitutions generally have a function module that will enable you to read from the buffer, instead from the database.

The first tips are usually the most obvious, but they can also be the most overlooked. To save yourself and your supervisors hours of reworking & re-reviewing, here are some tips:

1. Thorough, intuitive unit testing
Unit testing is the start of it all. If you manage to cut down the problems at this stage, it's like weeding out wild grass at its root, you'll save a great deal of time, both for yourself and for your supervisors.

Thorough means that you systematically test your unit, from the very beginning, and step-by-step work your way towards the end. Don't skip out on any parts, unless you're very, very sure that they can be done so. MOST importantly, you will need to make sure that your unit works correctly. That means, verifying the source data, the process, and the outcome of data. Are the calculations correct? Are there any duplicate entries in the output?

It is extremely easy to say that you've tested one unit just because the output is... well, tidy, or pretty (or the outcome didn't shortdump). But that doesn't mean that it is correct. Verify input, process, and output!

It is also easy to just focus on the main functionality of your unit. For example, remember that your unit may work correctly for, say, its functionality to display a nice, tidy, and correct ALV report, but it may be completely incorrect and/or messy when it comes to outputting it to, say, a form or a local file. Test each piece of the functionality, and before you say you've tested it, make sure you've actually done it and the results are OK.

Intuitive means don't just test what the scenarios written in the functional design told you to test. Think outside the box. Position yourself as if you are the user. Would you be satisfied with your own work? The functional designer may not explicitly say to test one thing, but if you, as a user, would be annoyed or confused at the approach you take when coding the unit, then it is logical to either improve or reconsider that approach.

2. Assume only when it is safe, not just when it is convenient to do so (i.e. avoid assumptions!)
It might be convenient to assume one thing when you're developing, but a wrong assumption may lead to extensive rework, or, on the contrary, may lead to extensive development when it is not required (or even must not exist).

There are some things that can be directly assumed, such as, your unit will work if the server is not somehow hit by lightning or an earthquake, but if it is not unambiguously written, then do confirm. And when you confirm, make sure you have evidence that the other party has confirmed.

3. Get a pair of extra eyes
It can be generally said that developers know more (at least technically) about his/her own units than other people. While this is expected and it's natural, this could lead to the "alpha-tester syndrome" (yes, I made the term up), which means that the developers may subconsciously assume things or may overlook things because he/she was the one who developed it.

Ask a colleague or your supervisor, if they're not busy, to come and give a look about your unit's results. See if they notice something that may be useful for you to either detect a bug and fix it, or change a part of the code to improve the unit.

4. Learn outside the scope
Your scope may be in development, but don't let that stop you from learning about the functionality and your unit's place inside the "big picture", i.e. what your unit contributes to the overall business process.

Knowing about the background of your unit will enable to get a sense of what the users will expect of your unit, so you could anticipate those by implementing things that may improve the user experience with your unit. You may even see an "invisible" hole that might've been overlooked by the functional designer, or even suggest a better approach.

Well, that's it for part 1. If I ever have the urge for part 2, I'll post it here. Hopefully the above will help you in doing your assignments and improve our overall quality.

Here's the case. I've added some fields in ANLU table and I want to make them as part of dynamic selection on reports such as s_alr_87011990.

Update !

BDC Mode is now available in global class. Below are the attributes :

C_BDC_DISMODE_E : BDC Processing mode, Display error
C_BDC_DISMODE_N : BDC Processing mode, No Display - if break point sy-subrc
C_BDC_DISMODE_A : BDC Processing mode, Display all screen
C_BDC_DISMODE_P : BDC Processing mode,No Display - if break point debug

C_BDC_UPMODE_S : BDC Update mode, Synchronous
C_BDC_UPMODE_A : BDC Update mode, Asynchronous
C_BDC_UPMODE_L : BDC Update mode, Local update

There are two ways to implement traffic lights (lamp icon) in your ALV Grid:

1.For any icon (including traffic lights)
Define a field in the internal table LIKE ICON-ID
For example...
DATA: BEGIN OF ITAB...
icon_field LIKE ICON-ID,
... END OF ITAB.
Then fill the field icon, for example...
itab-icon_field = @0A@ "Red light
Preparing the fieldcatalog...
wa_fieldcat-tabname = 'ITAB'.
wa_fieldcat-fieldname = 'ICON_FIELD'.
wa_fieldcat-icon = 'X'.

2.For traffic lights only
icon_field(1) TYPE C.
itab-icon_field = '1'. "Red
itab-icon_field = '2'. "Yellow
itab-icon_field = '3'. "Green
wa_layout-lights_tabname = 'ITAB'.
wa_layout-lights_fieldname = 'ICON_FIELD'.

Instead of recreating the text symbol 'Select-Option'(001) each time the program displays message 255(ZM), just use ZCL_ZCA_COMMON=>C_SELECT_OPTION. Same as for PARAMETER.

Just follow the link for tutorial how to send email from SAP using CL_BCS class.

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/789