All companies share a common challenge when implementing an ERP system such as SAP ECC. One specific business requirement will be of vital importance for the success for implementation as it triggers incoming cash flow. Of course the blog title gives away which crucial development is of the upmost importance: the output of an invoice. The invoice is a legal document that triggers the enforceable right to receive a financial compensation for the goods or services delivered. But payment by the customer is only mandatory when the output meets all legal requirements. As the majority of sales flows involve billing, it is advised to start the collection of functional requirements for billing output as soon as possible. The devil is in the detail and any exceptional business case could have an immediate impact on the billing document output. That implies that an user acceptance test may be that comprehensive that it takes weeks to complete.
It is practically impossible to apply a 'first time right' when developing the billing output document. Instead it would be better that all parties involved are aware beforehand that proper unit testing triggers many updates in the business requirements. But there is an opportunity to ensure that the initial version of the functional specification for the billing output covers 80% of the business cases. The information below will reduce the lead time for development considerably as it covers issues that will have to be resolved before it is ready for deployment.
The functional specification needs to have the following chapters:
• Chapter 1: Introduction
At first it is always good to identify what would happen when no output will be available at project go-live, as that would highlight how crucial this document will be. No billing output would certainly be a no-go
decision for project management.
Normally you would create one output for all forms of billing. So when a functional specification only refers to an ‘invoice’ then that would be a limitation that would raise eyebrows. Therefore it makes sense to use this chapter to provide a high level assessment of all business processes that would use this billing document output. Business processes that come to mind are:
- Regular sale
- Free of charge sale
- Inter-company sale
- Customer returns
- Financial correction due to incorrect prices or quantities on the invoice
- Financial correction due to incorrect taxes on the invoice
- Stock transfers for which the departure and destination address are located in different countries
Also it would be important to identify whether the functional specification covers both domestic and export goods flows.
• Chapter 2: Business requirements
After listing the business scenarios in chapter 1, the more detailed business requirements are useful in this chapter.
Remember that the content of this chapter must not refer to any specific SAP ECC functionality.
The timing of document output is important to discuss, as in most cases output is only allowed after successfully posting to accounting.
There may be some legal requirements to consider and therefore a high level overview would be useful. For example there may be a restriction not allowing gaps in document numbering (e.g. Italy). Special handling may be required credit notes in order to provide evidence that the cumulative credit value did not exceed the original invoice value (e.g. Poland). An universal legal requirement refers to the printing of original and copies, which makes it necessary to explain whether the automatic archiving of originals is required.
It is valuable to highlight the handling of document references in the billing output as a single billing document could be a combination of multiple deliveries which could be based on multiple sales orders.
Also the ability to print documents in multiple languages is valuable to take into account. Specific output requirements may be triggered by the language used.
Check whether the output is required on pre-printed paper as that could trigger restrictions on displaying addresses on the document. Be specific regarding the size of the expected output (e.g. A4 format for customers in the EU and letter format for customers in USA and Canada). Different document sizes may also trigger specific instructions which tray of a copier needs to be used.
Identify whether an external share services departments have the task for issuing the billing output, as that could trigger additional requirements (e.g. the need to print terms and conditions on the back of each page).
Some customers may want to receive the output also via email as a PDF attachment. It is wise to identify which billing documents have to be sent to which contact persons.
Finally, some format requirements may be useful to highlight. The expected date format and decimal notation differs all over the world.
• Chapter 3: Functional requirements
Whereas the previous chapter provides an over of business requirements, this chapter will dive into more detail on how to implement them in SAP ECC.
Focus on the potential differences in a) the handling of various business scenarios, b) the impact on domestic and export sales and c) the control of legal requirements.
Required SAP ECC configuration needs to be highlighted. usual suspects are output types, output determination procedures as well as the assignment of SAP standard output user exist within those procedures.
It is wise to specify whether SAPScript or SmartForms functionality is used to generate the output.
Text labels need to be printed when the document does not use pre-printed paper. As the output must be able to handle multiple languages, it is advised to use a custom table to control the maintenance of text labels.
List which logos need to be printed and the location of these images on the document. Also highlight whether these logos needs to appear on every page or only on the first or last page.
Some languages require specific character sets to be loaded into the SAP ECC system (e.g. Arabic).
Describe the layout regarding repeating header and footer sections and whether data associated to a single item may be split over two pages.
By default standard SAP function modules need to be used to collect and print address data. Only in exceptional cases you would be allowed to deviate, but this requires strong argumentation.
Although the first three chapters will cover many of the topics that need consideration, each project will adopt a document template that needs to cover even more potential challenges:
- Special attention is required to identify how hard coding can be avoided. So the usage of standard texts, custom tables and function modules need to be mentioned briefly. You get the opportunity to dive into the details in subsequent chapters.
- It would make sense to identify from where the output language is derived from. Preferably the document language is derived from transactional data (e.g. the billing document) instead of master data (e.g. customer master data).
- Many sites decided to use the FI accounting document number on the SD billing output as that would be easier for the FI department for clearing the billing document payments.
- The printing of pricing data is always a struggle. Consultants need to understand the SAP ECC pricing functionality as it allows the storage of subtotals in transactional database table and the control which pricing conditions are in scope for printing on document item or footer level. Be aware that pricing requirements will change pre and post go-live. Any hard coding linked to collecting and displaying pricing data on billing output will eventually cause a major indicent in the production system. So anticipating billing output issues triggered by changes in pricing configuration is strongly advised. Remember, losing the ability to issue billing output has an immediate effect on the company cash flow position.
Famous last words: Most often forgotten but not less essential will be the printing of the bill-to address when the billing document is folded and placed into an envelope with an address window. Some countries have special requirements regarding the location of the envelope window to support the automated processing of letters by the postal services. So make sure you have plenty of envelopes in all sizes used during unit testing. It will save a lot of disappointments during user acceptance testing.
Of course I would anticipate some comments on this post. Any comments or suggestions are more than welcome.
Thanks in advance,
Isard Haasakker.
email:
Isard@NoTieGeneration.eu
web:
www.NoTieGeneration.eu
