Bulletproof Doc

“Did you see this bill you sent me?  $150,000 in freight charges on a $3,200 order??”

Along with unexpected Production downtime and lost data, one of the more frustrating system-based events for an organization is a messed-up output document that somehow has reached its business partner.

In black & white (or perhaps color nowadays) problem documents tend to stand out, and – as Murphy’s Law would dictate – at the worst possible moment.  A mistake in spelling or grammar appears sloppy and unprofessional.  Incorrect pricing can lead to confusion, nonpayment and perhaps a strained relationship.  Improper or missing verbiage, such as a description of freight terms, might result in a costly legal dispute.

How then does one build a bulletproof business document?  Is it even possible?

As both a former practicing lawyer and an active SAP form developer and troubleshooter, I have seen business documents from multiple angles.  One of the biggest lessons I have learned is that form creation is an iterative process.  Planning, development and testing go hand-in-hand, uh, in-hand.  But if I had to choose, I would rank testing as the most critical of these components.  There is no way around it.

For instance, it may seem obvious, but until you’ve seen all relevant fields ‘maxed out’ on your test documents, you won’t really know how they will appear in Production.  Does everything fit?  Is it legible?  Does it make sense?  Does the corporate communications department approve?  Are there any other potential ‘gotchas’?

In constructing scenarios and building test data, it pays to think like an end-user.  They seem to have a knack for finding holes in the tightest woven logic.  To put it more plainly, test each and every exception…to exception…to exception.  Yes, this process can be particularly prolonged and painful when dealing with situations such as the detailed display of pricing information or multi-level items, but no worse than the pain felt by one managing to digest this too-long sentence in its entirety.  And, as I have found with my own work, there likely will be numerous tweaks as a result.  And crises averted.

At the same time, a form itself may be coded perfectly, yet rely on a custom data structure or function module which changes and causes a problem.  Or – as I experienced recently – on a bitmap image which another developer inadvertently overwrites.  Similarly, if a new printer has a different margin setting, information that previously was appearing just fine may suddenly…not.

With so many potential components and dependencies, is it possible to catch everything before a form hits Production?  Is there such a thing as a bulletproof doc?  Perhaps not, but rigorous testing is the best KEVLAR®-like protection available.

This is part 6 of a series of Weblogs on SAP output forms.