What is the SAP Standard Process or suitable process for developing a Report in ABAP ?

[Former Member]

Hi Experts,

I want to know how to approach developing a major or any report in ABAP.

I am familiar with concepts in report programming but would like an experienced perspective as to what to keep in mind before starting, how to plan a roadmap based on requirements?

I have developed many reports up till now but at times find myself fixing issues related to data output , wrong entries based on user requirements.

Sometimes report takes too long to execute and sometimes value does not match with system entries for example Sales register.

So in all I would really appreciate any guidance regarding report development both in S4HANA and without, how much planning is needed, what to look out for beforehand .

Thanks and Regards,

Nida Khan

[Former Member]

Hi Experts,

I want to know how to approach developing a major or any report in ABAP.

I am familiar with concepts in report programming but would like an experienced perspective as to what to keep in mind before starting, how to plan a roadmap based on requirements?

I have developed many reports up till now but at times find myself fixing issues related to data output , wrong entries based on user requirements.

Sometimes report takes too long to execute and sometimes value does not match with system entries for example Sales register.

So in all I would really appreciate any guidance regarding report development both in S4HANA and without, how much planning is needed, what to look out for beforehand .

Thanks and Regards,

Nida Khan

[Florian]

simple answer. It's the same than everywhere else. You have to plan and keep in mind what the goal is. 70% planning, 30% programming. Depends what you want. So no golden guidelines which keep everything fine. Only some borders and failing is part of that too.

[loyd_enochs3]

I agree with Florian's answer completely.

And I would add: get the user request in writing, put your design response in writing, agree on performance expectations in writing, set an agreed upon delivery date in writing and get the sponsor's approval of it all in writing. (If it isn't in writing, it never happened.) Even a single report program should get this treatment. I am always astonished at how large those small, unplanned, "it is just a few lines of code" reports can grow. Remember, inside every large program is a small program struggling to get out.

This will give you ammunition when you push back against unreasonable requests or complaints. (You will push back, won't you?) It will also give you a solid list of what the user requested should that come into question or when development is restarted after a priority change forced a stop. (It is amazing how quickly those notes on the whiteboard get forgotten and features that were shot down during design and approval will creep back into the discussions.)

There WILL be changes - that is the nature of the business - but you'll have a legitimate justification for the time and effort spent by the developer or developers. Plus a development team track record you can point to going forward.

And don't forget to use the same written procedure for change requests, as well.