SAP ECC6.0 : DEVELOPER_CHECK

Lately I had quite a number of major developments and all of them have to do UAT nearly at the same month and same time. It's heart wrenching if all developments have to be finished because you need to crack your head to organize correctly so all your developments can be finished on time. Well, I did my best for all though there cracks here and there. Okay, back to my latest contribution for this entry.

Have you (developer) ever thought of controlling certain variables, logic or feature that can be turn on by developers only? On one hand, users or functionals will not be able to see it. These kind of controlling is usually to facilitate developers to debug easier and understand problems faster. I'd always wanted one feature that the program can detect the user is a developer so I finally found one function module that can do this. This function module is 'DEVELOPER_CHECK'.

DEVELOPER_CHECK normally is activated and run when a new developer gotten his/hers user id tries to use SE38. At this point, a dialog will pop up to request for developer key. This pop up is given by DEVELOPER_CHECK function module. However, it can be use for other things.

DEVELOPER_CHECK has this parameter SUPPRESS_DIALOG which you can put an 'X' to it so the dialog requesting for Developer Key is not display. Hence, this make it a good function to be put in the program to check if the user is a developer. The effect of a developer encountering this function module is a '0' returning to SY-SUBRC. Else SY-SUBRC not equal to '0'. Hence, this function module can be use by developers to create a method to open up any additional features in customized programs.

DEVELOPER_CHECK can be use in customize reports with update to database or other concepts. This DEVELOPER_CHECK might not be usable when a report is running in background mode because it will not be raise. Another method to trace a process in background is to create Self Trace Log. Self Trace Log concept will be discuss later in another entry.

williamwilstroth... DEVELOPER_CHECK

SAP ECC6.0 : Auto Create SO (with ref Invoice)

A month more ago, I had undertook an assignment to modify a 3rd Party Commission report to be more dynamic and with the help of a functional along the way. That 3rd Party Commission had originally one type of reporting layout only. With the latest change, it has 4 types of reporting layout. One being able to automatic create Sales Order with reference to Invoice. The other 3 types of reporting will be just reporting only.  

What is more important in this entry that I had finally managed to full this assignment is the overall dynamics of automatic create Sales Order (SO) with reference to invoice. In order for this automatic creation of SO to work it requires a few implementation of User Exit, 2 routines (VOFM) and one customized table to control copy to procedure. The reason behind this requirement ie SO created with reference to Invoice must overwrite the Distribution Channel (VTWEG) checking in VA01; during the creation, SOLD-TO partner must be overwrite; line items in SO will be overwrite, MATNR, ARKTX and PSTYV (item category); and clearing the batch.

Therefore, the 3rd Party Commission report having the automatic SO creation is just a catalyst to fire-up a string of events in the process. The 3rd Party Commission's BDC just enter selected data in first screen, copy with reference is clicked, select first line item, and then clicked the save button. As I'd wrote 3rd Party Commission is just a catalyst so we will proceed to deeper discussion on the User Exits and Routines that will further fulfill this requirement.

Customize Table for copy-to-procedure control

Fields to consider control are VKORG, VTWEG, SPART, KUNNR, ICTP, MATNR, PSTYV, FKARV, and AUARN. Take special consideration on ICTP, IC meaning 2000 inter-company customers and TP meaning 1000 3rd party.

Routine : (VOFM-Copying Req-Orders)

In this part, I need to copy requirement Orders, routine 021, to modify the Distribution Channel (VTWEG) checking. Per standard, if SO being created with reference to Invoice have conflicting of VTWEG, it will display an error message. Therefore, routine 21 will be copied over and make the required changes to cater for Distribution Channel (VTWEG) checking. For a start, the customized table will be query against the VBRK's VKORG, VTWEG and SPART.

Routine : (VOFM-Data Transfer-Orders)

In this part, I need to copy requirement Orders, routine 003, to modify and update SOLD TO partners. As partners being copied SOLD TO, the SHIP TO and the rest will be deleted. Therefore, this routine is to control copying of partners of SO. Condition checking is similar Copying requirements of Orders.

User Exit : MV45AFZZ

1. USEREXIT_MOVE_FIELD_TO_VBAK

The purpose of this user exit is to update Distribution Channel (VTWEG) and update line item's Item Category (PSTYV). During this process, I looped XVBAP so its' line item's item category can be updated. However, there's one consideration to this point, customized table's KUNNR need to be check against KNA1 so to further validate ICTP field and KNA1's KTOKD. For example, if customized table's ICTP field is 'IC' and KNA1's KTOKD is '2000' meaning, PSTYV and VTWEG can be updated.

The above condition I wrote is only validated if VBAK-AUART and VVBRK-FKART matches customized tables' AUARN and FKARV. More important, I found out that for all this updates to be activated, there's this field called SVBAK-TABIX must be updated with a value '1'.

2. USEREXIT_MOVE_FIELD_TO_VBAP

The purpose of this user exit is to update MATNR, ARKTX, KWMENG, ZMENG, FKIMG, VTWEG_AUFT, and update item's position if Invoice is batch-split, and clear CHARG.

Condition for this user exit is similarly to USEREXIT_MOVE_FIELD_TO_VBAK.

There you have it, an automatic creation of SO with extra conditions in the background process. This implementation requires thorough understanding of SO creation. This is just one big part of the development.

You will need help from an SD functional who knows the whole concept of this implementation because there is a need to configure certain items especially allocation of certain item category that can be only use in this application. Therefore, functional and developer should work close with each other.

williamwilstroth... Invoice to SO in automation

SAP ECC6.0 : Classification of Batch Master

Recently, one of my last assignment to a project requires me to query classifcation batch of material for a WMMBXY outbound IDOC. This query only requires 2 fields for the extended segments. This classifcation batch of material, standard way, you can view it through MSC2N. To query it you need to have 2 function modules to get the value.

FM 01 : CLAP_DDB_UPDATE_CLASSIFICATION

FM 02 : CLFM_SELECT_AUSP

The first function module based on material and batch will produce the object number that identifies the group of characteristic of batch referrring to a material. This identification object number will be use by the second function module will produce lines of items of characteristic in an internal table. This internal table EXP_AUSP will be the result table.

Some of the tables that these two function module uses are KLAB and AUSP. AUSP is your characteristic batch transparent table that you can use it manually (programmatically) in your reporting and enhancements. However, I recommend that you use above two functions. Actually, these two SAP standard function modules are applied in MSC2N standard coding.

williamwilstroth... classification of batch by material

SAP ECC6.0 : Y/C and Cross Stock in IDOC_OUTPUT_ORDERS

Today, I had to debug a function module IDOC_OUTPUT_ORDERS to determine why certain segments and its fields are not appearing especially when it is sending out for its Cross Stocks. In contrast to Y/C stocks, those segments are appearing normally. So I had to make a comparison on the flow of its coding during debugging.

As an initial start of debugging, I need to know what are the missing fields and segments. So I took 2 PO numbers and sent out Y/C and Cross Stock IDOCS. After sent out, execute WE02 to get the two comparison output of the following 2 IDOCS as below:

Figure 1.0 Missing Segments

The Figure 1.0 showed two screens of WE02 of 2 IDOCS of same basic type but sending out Y/C and Cross Stocks. On your right, the IDOC sent out Y/C and the left is Cross Stock. As you see, the Cross Stock (Left Screen) has several missing segments that is in Y/C type IDOC. These are those difference in segments missing. Following figure showed the missing fields in a segment.

Figure 2.0 Missing fields

Similar as above description in Figure 1.0 Missing Segments, Y/C had extra fields that Cross Stock type in IDOC_OUTPUT_ORDERS that is not appearing. These missing fields and segments are due to the following reasons: (The following segments are filled in subroutine fuellen_idoc_inttab)

1.0 E1EDK01 (General Data)

Debug 1.0 General Data

E1EDK01 segments that is supposed to be filled in Cross Stock is not filled due to FLAG_PSTYP_STR not fullfilled. As a result, E1EDP-VSART and E1EDPK01-KZAZU are not filled in Cross Stock for IDOC (Orders).

2.0 E1EDKT1 (Document Text, Third Party)

Debug 2.0 3rd Party Document Text

Segment E1EDKT1 that is supposed to be filled in IDOC for Cross Stock not appearing is due to the coding above which FLAG_PSTYP_STR and SO_COUNTER is not fulfilled as in IDOC for Y/C. However, VBAK had to be fulfilled to in order to get the segment for Cross Stock.

3.0 E1EDP02 (3rd Party Order)

Debug 3.0 (A)

Segment E1EDP02 that is supposed to appear in IDOC for Cross Stock had been skipped because EKPO-PSTYP does not equal PSTYP-STRE. This is the first checking that initiates the rest of filling of segment E1EDP02.

Debug 3.0 (B)

After the Debug 3.0 (A) had initiate, this is the portion Debug 3.0 (B) that will fill E1EDP02 in Cross Stock. However, this only occur in IDOC for Y/C.

4.0 E1EDPT1 (Text for 3rd Party Order)

Debug 4.0 Text for 3rd Party Order

This is the last segment that is supposed to be filled in IDOC for Cross Stock but not appear at all. Similar to previous filling of segment's condition, SO_COUNTER and EKPO-PSTYP must also matched PSTYP-STRE before this segment be fill into IDOC for Cross Stock.

This is the analysis as the reason IDOC (IDOC_OUTPUT_ORDERS) not appearing for Cross Stocks. Functional should be make understand this findings and hopefully they will do the necessary adjustment or configurations to enable Cross Stock have those missing fields and segments be filled up during publication from ME21N or ME22N. Another options, there might be a possible enhancement to this IDOC. Each segments has a BADI or USER EXIT that allow you to make the necessary enhancement to fulfill your business requirement.

williamwilstroth... IDOC_OUTPUT_ORDERS, missing segments...

SAP SRM550 : Shopping Cart Assessing PO...

I had initially wanted to write about my experience in accessing a PO from EBP to ECC6 system about a year ago but ECC6 rollout project had tied up all my time. So here it is. EBP is totally whole different environment. Table wise, transparent tables like EKKO and EKPO are not available. Most data accessed by EBP are extract via BBP RFC function modules from ECC6 (standard system).

Therefore, EBP (SRM) development revolves largely around BBP's BAPI and RFC functions modules*. It is quite an interesting system on the overall and it is worthwhile exploring and expanding your SAP universe. It is not just ECC6 alone because there are other several industry specific system spawn out from ECC6.

Coming back to my Shopping Cart Report, there are several function modules that you can use to extract data from ECC6:
1. FM : BBP_PROCDOC_GETLIST
2. FM : BBP_PD_PO_GETDETAIL
3. FM : META_PO_GETDETAIL

Each of this function module in EBP has a different and important role in reporting or process development.

1.BBP_PROCDOC_GETLIST has a parameter that allows you to obtain shopping cart no and several other SC item information.

2.BBP_PD_PO_GETDETAIL obtains PO No and information from PO Header. This ties to the SC.

3.META_PO_GETDETAIL refers to information extract of PO line items. This can be a query resultant of second function module BBP_PD_PO_GETDETAIL. However, one can try to query out this FM from the first function BBP_PROCDOC_GETLIST.

* BAPI is an encapsulated function module with a layer of RFC and published in the Business Object Repository


williamwilstroth... SRM, EBP...

SAP ECC6.0 : My thoughts to other developers...

Of my 6 years as a developer, I'd met a lot of good, inspired and even bad programmers. Everyone of them has a different way of doing their programming. Some are so organized right down to one line of data declaration it is neat and clean. These types of programmers gives good programs and will have less errors and ensure good enhancements in the future. Now, there are those who care less about coding management and gives you less desirable result. These programmers gives you lots of errors after roll out plus nightmarish future enhancements. It's not that they are not experience but resultant of the attitude they carried in their development.

There may be many factors as why one programmer does not pay any attention to coding management and I can give you some examples. First, it is just programming and as long as it works and get the results. This is a grossly injustifiable attitude in programming, the person just want the program to work only. This behavior will always result a messy piece of coding. Future maintenance will be very terrible to maintain. A messy code usually make enhancement difficult when original flow is thwarted from working normally. Second, seasoned programmers who had to make a change to learn new programming language. This behavior is a result of their mindset which was so fixed to their old programming language's behavior that they could not find a way to accept the new programming language's behavior. This kind of scenario is similarly to a management changing their company's direction and many of their staffs finds it difficult to adapt to new challenges. So, it is the same when a programmer changes to new programming language.

If you just program a program for the sake of "I-am-force" to use a new programming language I am very sure you will find that programming new languages dull and eventually you will dread coming to work and see that language every day. I was a C programmer when I started working. Then I'd change to working with Visual Basic until I saw it became Visual Basic .NET. Finally, I settled with ABAP for SAP. With all these languages I come to understand that each of them requires different understanding to be able to use it. I am not saying ABAP is a good programming language or C is difficult language to use but each of them has it own unique feature that require your time to understand them. In my years of doing ABAP, I see many ABAPers, especially the new ones, complained why it doesn't work like web programming languages or like Visual Basic. I can only say one thing, they are trying, with some degree of difficulty, to accept the language's behavior and its way of usage.

It is normal and one definitely need a lot of patience and practice. It's like a programmer who has been so use to programming Visual Basic suddenly change to C++ and he needs to grasp the language so he could start programming for his assignment. At this level, one need to find time to understand and learn to accept the new language's behavior. I have a colleague who thinks that all languages are just getting data, processing data and displaying data and one should not focus on just one programming languages. That is good in my opinion as one need to diversify in order to survive otherwise when one language is consider obsolete you will have less opportunity to work in projects. Yet, this colleague of mine will less likely to accept the difference of behavior in each language he uses. One language can do such function with one routine but that does not mean the other language can also perform back similar routine. Most of the time, it requires a different approach. ABAP is a good example, it does not work like any other web languages. It is a proprietary language cater for business reporting and customization of SAP. That point itself it is always overlook by many new ABAPers when they start to compare with other languages.

On one hand I totally disagree with my colleague's atttitude towards all programming languages too because he has taken to a level to think that all programming languages are just getting data, process data and displaying data. I believe my days will be just as dark as the charcoal you get from the coal field. Why? This explanation gives me an impression my job is bored and dull and there's no excitement in doing programming and customization. However, if you regard your programming language as a tool to solve unique problems then I can give you one beneficial possibilities that your working life as a programmer will not be as dull as it is like any mundane routine. I like programmers has the fire or passion in their work. In every work, you need to have understanding and a degree of passion in it. Otherwise, there will be no more creativity to solve problems.

"Programming is an art or skill that requires passion, understanding and patience so it can be a masterpiece" - William Wilstroth

william wilstroth... programming is an art

SAP ECC6.0 : Roll Out

Editor : Just in case, you are wondering what happened to my old technical blog. Here's the link isskythelimit-technical. I had it revised and migrated to this new blog. All my old entries still remains in the old blog. Thanks!

It had been almost half a year since I participated in ECC6.0 roll out at the end of 2008 for EU, the Americas, and Asia Pacific. I was in a team responsible for Asia Pacific region and Germany being the leading team started the roll out at December 2008 with a blast. Things were getting excited and my team had faced a number of challenges but had it solved before the go-live. It was a challenging but wonderful journey. Some of the things I'd learned from the roll out, I list it down as below:

1. Unicode translation need to be taken care of because ECC6 is unicode enabled system. It means all custom reports had to be flagged for UC. It's not all that easy because you need to identified all programs that is not UC enabled prior to 4.6c.

2. Codings in existing customized program, forms, function modules, batches, Idocs and other customized include programs had to be check out for obsolete coding and to be replaced with newer ones especially strings and certain standard function modules.

3. A lot of testing were carried out by our functionals to ensure that all processes and customizations are working fine accordingly as in the old system after stages of migration as in ECC6.0.

4. There was a UC team specifically to handle unicode and language translation on various countries like EU, China and Japan. It was a gruesome task especially tables are language dependent. SUMG is a good TCODE to maintain your translation objects.

5. Migration of development system, quality system and production system are taken stage by stage to ensure, I should say, a smooth upgrade that does not impact the business process or users.

6. Then come after the roll out, the warranty of supporting all users so any unfound errors left in the upgrade process can be iron out. So this is another last wave of support. There after, its back to normal support and development routine.

Six month upgrade project that I had gone through with the team. A good deal of fine functionals and a four person development to support only Asia Pacific region.

Some reference for everyone who is undergoing ECC6 Unicode Enabled Upgrades:

1.http://help.sap.com/saphelp_nw04/Helpdata/EN/79/c55458b3dc11d5993800508b6b8b11/content.htm

2.TCODE : UCCHECK - Unicode Check program

Welcome to my new technical blog!

williamwilstroth... ecc6.0 roll out...