You run a project that relates to payment processes in SAP. You have registered invoices to pay or made arrangements for manual payments using payment requests. You have run a Payment Program (F110 or F111) and you see the documents posted. You even generated a payment file using any of three methods.
Now you want to test that the payment process will work as expected and that integration with the bank is reliable. There are several steps of testing you should undertake.
Unit testing is usually done in the special Testing client of Development system. You extract the payment medium file to your local computer and validate it against specifications received from the bank or payment bureau. If you find errors, you fix them straight away and validate again.
Once you are happy with the results of your own validation, you can send the file to your bank and ask them to run their own validation. They often have a special tool to test payment files without making actual payments. This may lead to other changes in the file and more test iterations.
If you plan to deliver the files to the bank using some automatic solutions, for example SAP PI, you need to configure and test the connection too. You may run these tests on dummy files, or you can start exchanging SAP-generated payment files already.
System integration testing is done in Quality Assurance system.
In this test, your main topic is to validate the full flow of information from invoice to the bank and back. This is the first time when you need to test the fully automated process as intended to be in Production. No manual workarounds for file generation, for file delivery and so on.
If you plan to use Bank Communication Manager (BCM) in your solution, here you need to validate that bank sends you proper Acknowledgement files for your test payments. Of course, subject to the bank’s ability to provide you test environment with necessary functionality.
User acceptance testing is done in Quality Assurance system, same as SIT that we discussed above. The difference between SIT and UAT is in testers. SIT is done by consultants preparing the solution. UAT is done by a team of users from customer side. Quiet often this is the first time when users see the developed solution, so prepare yourself for additional questions, challenges and work. Training, training and once again training – that is what UAT is about.
Penny value testing is done in Production system. It can have other names: Smoke testing, Small value testing and so on. This time you make real payments with real money from real bank account paying real invoices. To minimize the risk, usually two approaches are used:
[li type=”glyphicon-arrow-right”]Payments are done between your own accounts or at least within your group of companies (intercompany). If not, choose a vendor with good relationships so you can avoid long arguments if something goes wrong.[/li]
[li type=”glyphicon-arrow-right”]Select small invoices to pay. You do not want to risk big money if something goes wrong.[/li]
It is very likely that PVT will be the first time when you see the Bank Statement reflecting your payments made the new way. This means that some changes in the EBS configuration can be required.
Of course, you need to move all your transports into Production system before you start PVT. But you may wish to postpone mass master data change until after the PVT – just a handful of vendors / banks would suffice the PVT purposes. Once you have a confirmation of successful PVT, you may start mass changes of your master data. This is already a part of Cutover activities, which we will discuss separately.
Successful result of PVT is a mandatory requirement before the system go-live.
Remember that badly tested solution is always a big headache for consultants and for the customer. But badly tested payment solution is worse: it may lead to loss of money and spoiled reputation.
Do you have additional questions about the testing of the payment solution in SAP? Ask SAP Expert a question!