I recently completed a two-month project to build a till solution in SAP. In summary, it went really well. The effort estimate and timeline were approved without much debate and we delivered accordingly. There was no PM, just a small team of senior SAP consultants and a business analyst from the customer who no doubt had a few meetings with the budget owner but we didn’t notice as there were no concerns worth discussing. I know full well that for decades people have reeled against writing bespoke software, but here we have proven that there is a way to deliver bespoke software well, affordably and reliably whilst delighting the users. We didn’t have a specification signed in blood, in fact, we didn’t use any Word documents at all. But I’ll come to that.
A bit of background
Our client has several shops that sell both products off the shelve but also a lot of products that are stocked in a warehouse and require cutting/sawing/drilling etc… as part of the sales process.
The shops were using an off-the-shelve till system, not integrated with the SAP system nor with the payment terminals. The till operator had the error-prone task of keying everything in and the back office was forever trying to reconcile the cash book and the bank statements to the financial accounts.
But my client had S4/HANA and Fiori. Hence the obvious question was to integrate the till and the payment terminals with SAP. Something like this:
The design phase
We started with a simple question from the client: “Can we capture the payments directly in SAP? Basically, a button in the order entry screen? And can you send the payment instruction to the payment terminal from SAP so we don’t have to key it in manually?” The client had formed an idea of the effort involved.
We had a conversation with Worldline who confirmed that integration of the payment terminals via an API was indeed possible, providing we let them validate our solution.
From increasingly detailed corridor-style conversations, I formed an idea of what a till screen should look like and I did a mock-up in pptx to prepare for the design thinking session. During that session, whilst people were discussing requirements, I refined the pptx. By the end of the session, the design was agreed based on the mock-up. Quite a few new requirements came to light.
I then proceeded to make an xlsx list of all build components that were required. I then estimated each line in the xlsx including testing time, go-live cutover, documentation, etc. I broke the build down to enough detail to ensure that no single item on the list was more than a few days effort. When I added the detailed estimates together, I came out 40% higher than what the client had had in mind, but this was acceptable given the additional features we had agreed upon.
And with that, the design phase was over. It was time to start building.
1) An ABAP report (from the area of dinosaurs, I know) with a dynpro screen (idem) to represent the till, a transaction code to call the report and a Fiori tile to call the transaction code. ABAP dynpro is very well known, easy to use and lots of consultants can find their way around it. Fiori Apps are a whole different cattle of complicated fish especially if you want to deviate from the standard screen layout templates which was inevitable in this case.
2) New database tables: to hold the shops, the payment terminals, the customers, the link between the orders and the till, the payments and the link between payments and orders.
3) ABAP classes to represent the business entities: a till, a customer, a cashbook, a till ticket, an order, a payment and a payment terminal.
4) ABAP classes for reporting (model/view pairs): customers, orders, order line details, payments, terminals and payments of orders. These classes provide quick ways to report on the new database tables. The view classes are subclasses of a generic view class that hides the complexities of the standard CL_GUI_ALV_GRID. The model classes are subclasses of a generic model class, each implementing their own data selection. The model and view classes are automatically picked up by a reporting framework that makes it possible to place several reports on the screen simultaneously.
5) Proxy objects generated from WSDL files for real-time synchronous integration with Worldline via CPI. Integration flows in CPI that pass data back and forth between the SAP backend and the Worldline server.
6) A Fiori catalog and group containing the till tile. Two user roles per shop: one for reporting and one for the till itself.
The integration with Worldline went very smoothly thanks to the available expertise in the team, and the successful validation was a confidence booster knowing our solution was solid from the word go.
The build phase
The build consisted of a step by step implementation of the build elements listed in the xlsx. Every now and then, I consulted the other consultants and demo’ed the till screen to gather more detailed feedback. The fact that the client could follow the progress created the confidence needed for me to work without much supervision. The deadline was reasonably crazy and I worked through several weekends. But I knew it wasn’t for very long, so…
The ABAP code is clean
Clean code is a big deal. And I am a strong believer. So…. This is my personal interpretation which I applied rigorously.
No code block is longer than 50 lines. (I hate scrolling and 50 lines of code fits on my monitor). There are no static classes and hardly any static methods. The class methods each perform one single function and the name of each method is carefully chosen to be unambiguous. The largest number of parameters passed to any method is 3 (mostly it is 1) making it obvious what a method does. The view classes do not have any attributes, the model classes have only the report filters as attributes. The other classes usually have 1 or 2 attributes, no more. The method names are short and contain maximum one verb and sometimes a noun. All these elements make for very readable and maintainable code. The only non-object oriented element was the 29 line ABAP report (see below). putting logic in classes like I did makes codes maximally reusable, testable and consistent.
This solution should pose no upgrade issues. Only a few enhancements were added to pass data from the till screen to the sales order entry program (where there was no standard way of achieving that). But these are very simple and can be easily validated during an upgrade project.
The single till screen contains many functions:
- A list of customers currently in the shop (ALV). The user can select one customer to process further
- A list of orders currently processed in the shop (ALV).
- Address, invoice details and credit status of the currently selected customer
- Buttons to 'welcome' a customer and to let a customer 'depart'
- Buttons to start order entry (3 different types of orders)
- Buttons to capture two types of payments
- Buttons to produce and print the till ticket / invoice (depending on the customer profile)
- Buttons to look for pre-existing orders, created outside of the till
- A button to create a new customer profile
- A button to search for a customer profile
- A button to check the payment status (with Worldline - only in case of temporary comms issues)
- The due amount and the amount of change (in case of cash payment)
- A popup to select the payment terminal and optionally overwrite the payment amount
I choose well established technologies (you may argue it’s the stuff of dinosaurs but it works!) which made the build easy to estimate, the solution technically simple and thus easy to maintain. Everything was built in SAP GUI, no need for Eclipse or any other build environment or software.
The users enjoy using the till because the screen behaves exactly as they expect it to, using their terminology and only providing them with options that are relevant to the situation at each point in time. I believe building custom intuitive screens is a major contributor to any successful SAP implementation.
