Skip to Content

From Functional to Technical                         From Functional to Technical – Part 3

So if you have read my From Functional to Technical blog then you know the context. This blog is to share a very recent experience. Maybe it will sound simple for experienced ABAPers or even Techno-Functional Consultants but its these small glitches which stretch a beginner.

Background

We have a very old report (most of us have forgotten about it) which used to work (nobody used it much) and now suddenly it is not working. That was the problem statement. Now as a Functional Consultant you start of checking are the conditions (some master data, custom table entries, transaction data) all are fulfilled. Yes everything looks fine and more importantly it works fine in the Development System.

The Hunt Continues

So the challenge was to figure out why the report is not pulling up the receipt (Deployment Purchase Requisitions) elements as expected. Took up the challenge boldly to test my debugging (limited!) skills in the Quality System where the issue is happening. Going through the code (rather than reading the FS) I realised that there is a BAPI call to extract order data which then gets passed through some logical condition before reporting in ALV. Somehoe the BAPI called in the report was not extracting the receipts even when the correct paramaters (Location, Products, Date Range, ATP Category, Planning Version) are all passed. Completely baffled because if I test the BAPI with the Location-Product combination which has the receipt that needs to be reported it works fine.

Well thankfully I have a very good Techno-Functional Consultant in my team. Actually he is my guru in my journey from being a Functional to Techno-Functional. He pointed out to check the RETURN table from the BAPI execution. So in I go into debug mode running the report and continue to the BAPI call. Then go to the RETURN table and yes there is some information there. More than 100 entries – something like that. So what does that mean. Take help of my guru who points out some more stuff in standard code for the BAPI stating each BAPI call can handle a total of 100 entries. Now I remembered the report was throwing up 359 products (assigned to a Transportation Lane) and obviously that is more than the limit to extract order data using the BAPI in one go.

Feeling high finding out the root cause assigned the defect to Application Development team to do the necessary code change. For a change the code fix was completed in 1 hour and after a quick test and checking the code in dev (did not have much data volume) set the transport to move to QA system. It will be done overnight so the defect will remain In-progress 🙂

The Aftermath

Well next morning the first mail in InBox says the defect is actually REOPENED and not FIXED. Good lord what has happened. So back to debugging and soon realised the restriction of 100 entries actually includes all the input entries. Now in the report we were passing 100 products but also Planning Version which constitutes one entry. So back to Application Development for the code change. To be on safe side asked them to code loop for BAPi call at 90 products – don’t want to hit the 100 entries restriction.

This time the report worked sweetly in QA and one major learning on my path to TechnoFunctional.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Matthew Billingham
    I think it is quite difficult to get from functional to technical – not as easy as the other way round.  So I commend you.

    Now, when you were debugging the code, what kinds of things could the developer have put into his code, how could he have structured it so that it would have been easier for you to understand?

    (0) 

Leave a Reply