What is e-Way bill (definition from https://cleartax.in ) :

E-Way Bill is an Electronic Way bill for movement of goods to be generated on the e-Way Bill Portal. A GST registered person cannot transport goods in a vehicle whose value exceeds Rs. 50,000 (Single Invoice/bill/delivery challan) without an e-way bill that is generated on ewaybillgst.gov.in.

Alternatively, e-way bill can also be generated or cancelled through SMS, Android App and by site-to-site integration through API.

When an e-way bill is generated, a unique e-way Bill Number (EBN) is allocated and is available to the supplier, recipient, and the transporter.

How to implement into SAP:

There are three possible choices in order to comply with India government requirement:

In the remaining part of this post, we will only focus on the option 2, with some extra step to fully automate the process end to end.

GSP: GSP stands for GST Suvidha Provider. A GSP enables a GST taxpayer to comply with all the procedural provisions of the GST law through its web platform.

Pre-requisites:

At the time I am writing this blog post, below SAP Notes were available for the Indian e-Way Bill. Some will not be relevant based on the solution you are choosing. Please have a look carefully and follow the SAP guideline for each Notes.

2631687 - SAP solution for e-Way Bill India

2624167 - GST India_PART-B Information Capture for generating e-Way Bill

2619222 - SAP solution for e-Way Bill India - prerequisite for SAP Note 2618988

2647971 - eWay Bill India: Utilities (Mass Update Part-B and Contingency Mode )

2624358 - SAP solution for e-Way Bill India - Proxy Generation

2618988 - SAP solution for e-Way Bill India - Basic Enablement

2631746 - SAP solution for e-Way Bill India - prerequisite note for SAP Note 2618468

2638630 - e-Way Bill India : UDO report for Missing DDIC objects for nonDCS customers

2618468 - SAP solution for eWay Bill India - Mapping

2482854 - GST: Invoice Form

2668293 - India eDocument Plant Level Authorization Prerequisite Note for 2672373

2672373 - India eDocument Bill Plant Level Authorization in eDocument Cockpit

2711279 - eWayBill India: Support for eWay Bill API 1.03 and Get eWay Bill Features Pre Requisite for 2689088

2689088 - eWayBill India: Support for eWay Bill API 1.03 and Get eWay Bill Features

2722226 - Bug fixes for EDOINEWBCONFIGV view, Contingency Mode, Get API and 1.03 API changes

Purpose and Views to be maintained and its purpose is given in attachment “2631687 - eWay bill_Installation_Configuration.pdf

2458714 - eDocument India: Pre-requisites for Note 2443144

2502952 - GST IN: Corrections in MIRO/FB60/FB70 (II)

2598300 - GST India: E-way Bill Solution

2883712 - eDocument India: Enabling eInvoice and eWayBill Solution - DDIC Prerequisite note for 2883713

2883713 - eDocument India: Enabling eInvoice and eWayBill Solution

3016198 - GST India: Correction in eInvoice solution to avoid Invalid File Data error

2472623 - GST India: Official Document Numbering

2490565 - GST India 2017: Official Document Numbering for REFX

2526295 - GST India: ODN no. is not getting updated correctly in Invoice no. for REFX

2896060 - GST India: Error 'No data found for given input' while uploading the response JSON in transaction code - J1IGIRN

2902336 - GST India: eInvoicing relevant validations to ODN Solution

2904222 - GST India: eWay bill information capture from JSON response version 1.01 in IRN Report - J1IGIRN

2941538 - GST India: Corrections to Note 2904222

2948482 - GST India : DDIC Activities for IRN Capture in Supplier Invoices

0002958243 - GST India : IRN Development for MIRO/FB60/FB65

0002972270 - GST India : Solution for eInvoice/IRN Contingency Process

0002973308 - GST India : eInvoicing cancellation manual solution

High Level process:

Once the process is completed, the additional data can be added on the invoice (including the QR Code), and the documents can be provided to the Freight forwarder and final customer.

In this automation case, only step 1 and 5 need to be automated. The other steps are under the responsibility of the GSP provider.

The step 1 will highly depend on your GSP provider and their capabilities. The one we are use to work with accept an encrypted json file that contains all the relevant data. For that we basically generate EDOC that we transform in json and send to the GSP provider.

J1IGIRN & J1IGEBILL

The two main transactions are J1IGIRN and J1IGEBILL.

J1IGIRN is mainly used to import the signed QR Code and IRN number, while J1IGEBILL is used to complete information with Date and Time for validity of the e-way bill.

The main point of the automation is to be able to perform the step 5, describes above, without any human intervention. At the date I am writing, there is no BAPI available for that, therefore we need to explore other options.

Option 1: Web Browser automation

If your SAP is exposed thru HTTP/HTTPS, then this option might seemed to be an easy one. Unfortunately we faced the situation that the JSON upload can’t be perform from a shared drive / mount. This needs to come from the local device, and therefore the virtual file system (Z folder) of the browser.

For the one familiar with the Virtual browser file system approach, you are probably aware of the pain to upload document and make them available for SAP. After couple of tests, we found out the process complex, not stable and error prone. Therefore, this option has been discarded for a productive automation.

Option 2 : Create a Z transaction

The second option that came to mind was the creation of a Z transaction, based on the original SAP transaction, with some modification to overcome above limitation.

At RPFACT, we are not pro Z transaction. Any update from SAP would require to re-create and re-test the Z transaction, too complex and time consuming.

Option 3: SAP GUI Scripting

SAP Gui scripting is an extraordinary capability provided by SAP when it comes to automation. Therefore option 3 was to take the option of the SAP GUI Scripting.

All went well until two specifics action. With the transaction J1IGIRN, after uploading the document from your GSP provider, you will get a prompt indicating the success of the upload:

Unfortunately the green check mark is not accessible thru the SAP Gui Scripting. Therefore you can’t validate above message box. Good news, the data is uploaded and stored, despite the fact you do not validate above message box. So, not completing above step is not a big deal, just not clean.

Then come the second issue. After inserting the date and time in the transaction J1IGEBILL, the system need to link e-Way Bill to Document number. For that, the line is selected and button “Link E-way Bill to Document Number” is press. If no error, the system issue below message box:

Unfortunately, this message box is also not accessible by SAP Gui Scripting, therefore it’s not possible to press/select ‘Yes’. Unlike the previous issue, clicking on ‘Yes’ is mandatory in order to save the data. So with the SAP Gui scripting, the full process can be performed, except the last step, very frustrating.

Then I thought about clicking the bouton based on screen position, but that requires a screen (Windows limitation), and therefore required someone to be connected via remote desktop at minima.

Going back top option 2 and creating a Z transaction could give the opportunity to fix that, but we have discarded that option.

Option 4 – SAP Java Gui

The main constraint in the option 3 was the screen. Then we decided to leverage the virtual screen capability of Linux based platform to overcome the limitation of Option 3.

Going that route also bring some challenge, especially when you need to click on area for the text, the speed of the keyboard that sometimes is too fast and so on. But the big advantage is that you can test each screen against validating picture to ensure that the process is progressing as expected, and if not trigger action to remediate. And of course, now the full step 5 of the process is fully automated, and people can do thing that have a bigger added value for the company.

If you are interested by that Robot, please let me know. I can’t share publicly the full solution as it include proprietary technology.

Edit - 18.10.2021

We are receiving questions and comments about the e-way bill process and automation described above. The two recurring ones are: Do you have some stats to share? How do you handle peak activities?

Regarding the stats: We have looked at the execution stats, and we are finding an average of 500 invoices per customer per month being processed by our bots. You can then extrapolate the human time savings based on the time you think people need to complete the e-way bill tasks manually.

If we estimate an average of 5 min per invoice, it means that our bots are shifting 40 human hours of work per month per customer to robots work. The equivalent robot execution time represent 8.5 hours per month per customer. And then this 40 hours can be reused for more added value's activities.

Regarding scalability: We will discuss and compare in a next post the micro-bot approach Vs the process-bot approach. We are preparing stats to compare both approach in the case of e-way bill, to see which one is faster, which one can handle more activity, ...