Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
geert-janklaps
Active Contributor
27,425

Blog series overview


During this blog series I'll walk you through creating a real transactional sales order Fiori app with draft handling using Fiori Elements and the new ABAP Progamming Model. The final result will be a working proof-of-concept, this will not be a finished product. (although with some additional work it could be)

The end result can very easily be adapted to fit your own requirements. The principles explained throughout the blog series can be applied to other legacy objects as well.

What we'll cover during these blog series:

  • Identifying minimal set of fields required in the actual classic transaction

  • Building the virtual data model using ABAP CDS

  • Building the consumption layer using ABAP CDS and Metadata Extensions

  • Exposing the consumption layer as an oData Service

  • Generating a Fiori Elements App

  • Adding custom determinations

  • Implementing create, change and delete functionality

  • Implementing durable locking


Prerequisites


To follow this guide you'll need:

  • Access to a backend system

  • A working Eclipse setup for ABAP Development

  • Access to a trial (or productive) SAP Web IDE using a SAP Cloud Platform Account

  • A working SAP Cloud Connector setup

  • A destination configured to connect to your backend


Interesting documents


If you should run into issues during this blog series, be sure to check out following documents. These are the ones I used to prepare this proof-of-concept.

Identifying the minimal set of fields


To determine which fields we'll use for our Sales Order App, we'll go through the standard order creation transaction VA01. This example is based on a best practice system. Based on customizing in your system minimal fields for entering a sales order might differ from this example.

In the first screen we can identify some important fields:

  • Order type

  • Sales organization

  • Distribution channel

  • Division

  • Sales office (optional)

  • Sales group (optional)




In the actual order entry screen we can identify following important header fields:

  • Sold-to party

  • Ship-to party

  • Customer reference

  • Net value

  • Currency


On item level following fields are important:

  • Item number

  • Material

  • Item description

  • Order quantity

  • Sales unit of measure

  • Net value

  • Currency




Throughout this blog series we'll add some more informative fields like:

  • Created by

  • Created on

  • Created at

  • Changed on


Desired end result


Our final application will consist out of a list report / object page from which we'll be able to:

  • Search for existing / draft Sales Orders

  • Display, change and delete existing Sales Orders

  • Create new Sales Orders


List report with sales order search, create and delete functionality:



Detail screen for display, change and create functionality (object page layout):



Same detail screen in change / create mode (with draft handling):



Item detail screen:



Now that we've run through the minimal requirements and know how our app should look like, we can continue with the next part of this blog series and build the virtual data model.

 

Quick navigation


5 Comments
Labels in this area