Skip to Content
Personal Insights

Matching RPA e-invoicing expectations with SAP landscape

Lower your expectations to avoid disappointments by diving into uncomfortable details.

I have read the hype about the high expectation from RPA implementation that can automate out of the box “magically” primary documents registering into SAP system without any user intervention or at least less intervention, which consequently leads to company higher process efficiency.

I studied and practiced on RPA courses to understand the concept and have a hand-on sense of RPA in action. Once in a course forum I stopped and reflected on a question from a participant: “Most of the use cases are API calls from the Bot. For these cases, can you guide advantages of using Bots over coding a script to call the same APIs?” and answer from moderator “Besides calling APIs directly, our RPA tool is an orchestration platform to provide a completed toolset such as repository, monitoring, scheduling, logging, and security. You can extend our prebuilt API bots for instance with additional fields and modify our pre-delivery code to handle the additional fields.” I had the same questions in mind so I decided to share in this blog my opinion about assessment steps and expectations from RPA automation.

With recent courses in mind and hands-on experience from SAP project implementations from SAP R/3 to SAP ECC, I agree that an RPA software is an integrated development environment, flexible and universal. It offers attended bots supervised by the user or unattended bots in the “farm” of virtual machines with schedulers and monitoring dashboards. Things evolved, I can tell it from my own back in time experience. In the early 2000th, in my first SAP R/3 project, I tried to record a transaction using a macro screen recorder but I failed because the software messed up with pixels and finding fields on the screen. Failing with screen recorder and without ABAP knowledge at that time, I developed up a solution to generate batch input script with MS Excel and Word, I published it here. Afterward, I founded similar examples from other enthusiasts. 🙂 Over the time, I had to move from batch input script to robust tools like LSMW with code, ABAP programs, and BAPI for real-time integrations.

Nowadays there are many RPA software players and Gartner expects the RPA software market to look very different three years from now. Large software companies, such as IBM, Microsoft, and SAP, are partnering with or acquiring RPA software providers, which means they are increasing the awareness and traction of RPA software on their sizable customer bases.

I opine on the general capabilities of RPA in the context of actual available artificial intelligence technologies.

RPA tools and SAP native tools provide the same capabilities to automate the creation of documents or other objects. What is the difference then?

There is no out of box automation “magic”. Robotic Process Automation is the result of a fully implemented project with phases resembling ASAP methodology.

Implementation stages: Prepare RPA, Solution Design, Build RPA, Test RPA, Stabilize RPA, Constant improvement. Team roles: Business Analyst, Solution Architect, Developer, System Administrator.

RPA High-Level Architecture comprised of Studio and Orchestrator.

Orchestrator – enterprise architecture server to manage robots, ideal for large deployments of robots covering complex processes, but it can also be deployed in scenarios dealing with short and repetitive processes and fewer robots.

Studio – Automate with highly intuitive tools (note code), process recorders; drag & drop, use templates.

Tool capabilities comparison. RPA offers a standardized registering solution with structured data stored in common CSV or user-friendly Excel. RPA has computer vision capabilities but it lacks of out of box templates for all types of documents or even for invoices mostly presented for automation in demos. Recognition of scanned invoices is an important step of implementation, with sequences developed for each invoice format, with further data processing into the required structure. Thus, once you have structured data it does not matter what tools you use an RPA bot or SAP native tool, the result is the same-posted document. With structured data and mapped external master data to internal master I can assure you that SAP tools already provide that kind of “robotic automation” with centralized native logs for processed transactions and reprocessing of errors in background or dialog mode, with an automatic schedule or manual launching even with SAP R/3, early 2000th.

Considering all the above, I would take the decision of automation based on the landscape and team capabilities I have. I noticed the differences in logs storing. RPA stores logs outside of SAP in the preferred format. Over RPA logs I would prefer, SAP batch input logs with screens and fields scripts with values, easy to reprocess, or debug in dialog mode. I developed complex batch input with checking of data or adding data from SAP tables or other BAPI all integrated into one program. In case of complex validations, over RPA screen scrapping I would prefer a BAPI or developed RFC. RPA has strong integration capabilities to scrap and fill web forms, which could be efficient for B2B integration, for instance, payment orders processing, which lack of third party APIs. In the case of small projects or proof of concept, such integration one can realize using other development tools, Python Selenium (available with docker) and  PyAutoGUI. SAP data can be consumed as web service using  OData RESTful APIs, find an example for ERP here and an example for BW here.

Once again, RPA does provide a robust automation IDE but does not provide a magic solution that cannot be realized with other development kits. I consider that complex bots require the use of developed or native SAP of APIs instead of a long list of screen scraping and dialog posting which is not always as fast as background posting.

The business case study presented in demos.

RPA at work processing invoices in SAP without a purchase order from PDF format.

This scenario covers only a small part of real cases because:

Automation requirements fulfilled. Low complexity and High volume.

Logistic complex business scenario.

RPA at work processing logistic invoices in SAP with reference to purchase order from various printed formats.

  • The logistic invoice with one hundred items of spare parts, matching items from Good Receipt and Invoice Receipt.
  • The company has thousands of vendors, but with only several invoices per month.
  • Each vendor has its own format of an invoice.
  • Invoices printed on paper.
  • The vendor does not provide external codes and descriptions of material; master data B2B mapping missing.

If the vendor does not follow the mapping rules of your company and does not provide a PDF invoice with material codes and material descriptions of your company than the RPA computer vision component is not able to return correct data or any valuable data at all.

Implementation time and costs to develop, and maintain, ongoing internal resources to monitor and improve above complex business scenarios will fairly fall behind the efficiency of professional employees responsible for invoices posting.

Automation requirements are unfulfilled. High complexity and Low volume.

RPA automation of business scenario for logistic invoice postings needs long-term improvement in the company to meet at least requirements: digital invoices in PDF, a unification of invoice format so that for each invoice format to have at least 1000 invoices per day and B2B material master data mapping. Probably at this stage of digitalization, it is more efficient to exchange B2B invoices in XML format.

B2B e-invoicing is a complex process where RPA and Machine Learning are components of an integrated solution like Ariba, Tradeshift, Pagero, or other solutions with stages of processing, validation, posting, confirmation supervised by support teams.

When I think strictly of processes to automate with RPA in SAP for almost every company undoubtedly I think first of all about high qualified employees which spend probably half of the time with processing the same downloaded XLS files and merging data to compose final reports. Developing reports in ABAP is a laborious work, therefore only the most important reports are developed to substitute XLS processing. RPA can be a great tool to automate report generation and broadcasting by email or used even as an extractor for SAP BI reporting by saving data into persistent tables.

What is your opinion about the role and suitability of RPA capabilities in the SAP landscape?

Be the first to leave a comment
You must be Logged on to comment or reply to a post.