Skip to Content
Technical Articles

Creating a draft enabled Sales Order Fiori App using the new ABAP Programming Model – Part 1: Overview

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

2 Comments
You must be Logged on to comment or reply to a post.