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...