In my A Beautiful Form weblog, I discussed the importance of design considerations when developing output forms.
Yet I can think of an even more critical consideration: tight collaboration among all individuals involved in the form creation process.
Thankfully, the ‘throw it over the wall’ approach seems largely to have faded in the IT world. And I have seen many SAP projects where functional and technical team members worked closely together to ensure a quality work product, delivered on time and on budget.
But – alas – not always when it comes to output forms.
One major problem as I see it: Many functional team members are unaware of the limitations and inner workings of a form tool such as SAPscript, hence their form specifications tend to resemble report specs. Developers that accept such specs and begin working from them right away fall into the same trap I once did (as described in my last weblog).
In a way, a form is like a report, of course. However, the differences far outweigh the similarities. For instance, unlike a stand-alone report, an SAP-generated form is a template launched and fed by an external ABAP print program. In the case of SAPscript, the form is rather passive, relying on the program for most of the heavy lifting; in Smart Forms, the print program handles the initial data gathering and the form does just about everything else, while there is also a separate Smart Style to contend with. In addition, unlike most reports, forms frequently are sent outside the organization and thus must follow certain corporate standards and satisfy various legal requirements; furthermore, there are multiple output mediums and languages to consider.
When a form is treated like a report, typically the developer is given too little direction. For instance, font types and sizes as well as other style elements can be left to his discretion, with inconsistent results. In addition, as every experienced SAP form developer has learned, the formatting of column tabs in SAPscript – and table or template cells in Smart Forms – must be mapped out carefully, often on paper with a pencil and ruler; any subsequent design changes to these columns (“Hmm…on second thought, swap those two, would you?”) can trigger major rework, especially where boxes and lines are involved.
So what can you as a functional team member do (other than hiding the sharp pencils before asking for a column swap)? Here are a few things to try:
1) At the start of any decision to develop a particular SAP form, invite the developer to design meetings.
2) Seek his input on the best form tool to use and which possible standard SAP-delivered form templates and/or print programs to consider as a starting point.
3) When a standard form has been selected as a base, ask him to help (a) identify the default values available in the form, and (b) highlight any relevant differences between a standard SAP transparent table and its derived print structure in the form (e.g. VBRK -> VBDKR).
4) Ask him to explain to you in layman’s terms – and then demonstrate – how the print program and form interact to produce output.
5) Build your spec taking the above into account.
Obviously, this as a two-way street. Here is what you as a developer can do:
1) Explain to your functional counterpart what is easy to do in a form (e.g. dynamic document title based on doc category) and what is not; perhaps that complex requirement causing you to lose sleep at night was merely a ‘nice-to-have’ which will go away once there is an understanding of what it involves technically.
2) Request a form ‘mock-up’ as part of the spec, especially if you do not feel comfortable making design decisions on your own.
3) If you encounter a significant ambiguity in the spec which could open the door to massive changes down the road, either in form logic or design, immediately seek clarification; it is quite possible that this issue was overlooked or invisible from a high-level perspective.
4) Have your counterpart create a set of test data for you to experiment with during development – ideally in a system where you can test immediately without transporting any code.
5) If you are unfamiliar with the functional area in question, ask your counterpart to demonstrate the document creation process so that you can see how the pieces fit together and create your own unit test data.
I could go on but my essential point is this: tight collaboration and ‘cross-training’ among the functional and technical team members can shave time off a form development project, while educating both sides and fostering a positive atmosphere at the same time.
This is part 5 of a series of Weblogs on SAP output forms.