Chapter 2 - The Embedded Architecture

Introduction

In this chapter we will start with the planning application. As with any project, it is important to know where we are headed and we will start off with the functional requirements of our application.

Become a Patron!

Functional Requirement

The objective of our planning application is to produce a profitability report. The profitability report must be produced using all the characteristic available for actual volumes. Prices can only be planned on a higher level. For example, we cannot plan prices on material/customer level, only material group/customer. In some instances, we may have prices applying to a material within a material group, while material group and customer specific prices may exist. Planned prices are also valid for a full year and no periodic price planning is required. Planned revenues will be a simple quantity * price calculation and the results will be written to a derived GL account.

We will have the following main characteristics available from actual volumes:

0MATERIAL	Material
0CUSTOMER	Customer No.
0SALESORG	Sales Organization

The only key figure available from actuals is 0QUANTITY, and we will use this key figure to hold planned volumes as well.

Since we want to be able to perform scenario planning, we will use version and value type as well to separate different values. Version/Value Type 0/10 will hold actual information, while version/value types 100/20, 101/20 etc. will hold planned values. In addition, planned volumes and prices must also be captured against 0MATL_GROUP (Material Group). We will derive the value of 0MATL_GROUP from 0MATERIAL and write the value to the database for volumes, but plan against 0MATL_GROUP directly for prices.

Actual volumes from CO-PA will form the basis of our future planned volumes. The average volumes of the past 12 months should be written as planned values for the next 24 months. Initially, volumes must be planned on material level, with a top-down distribution to customer based on a reference historic period.

 We will look at two scenarios to supply actual volumes to our application, which requires the use of virtual objects to avoid data replication and redundancy.

The results of the calculation will be written to a separate aDSO. This DSO will have the same characteristics than the volumes aDSO (TVOL_A20), but we will add an InfoObject for the GL Account (0ACCOUNT) and replace quantity with 0AMOUNT.

The InfoObject that we must use to derive the GL Account is 0ACCNT_ASGN, but it is an attribute of 0CUST_SALES (Sales view of the Customer Master). Further, a mapping form the Customer Account Assignment Group to GL is maintained in a table ZACCDETER with the following values:

0ACCNT_ASGN	SALESORG	GL_ACCOUNT
#	1710	41000000
01	1710	41000000
02	1710	41001000
03	1710	41001500

To summarise, the following objects with their InfoObjects will be created:

	TPRC_A10	TVOL_V00	TVOL_A20	TREV_A10
	Planned Prices	Actual Volumes	Planned Volumes	Planned Revenues
KOZGF	X
0MATERIAL		X	X	X
0MATL_GROUP	X		X	X
0CUSTOMER	X	X	X	X
0SALESORG	X	X	X	X
0VERSION	X	X	X	X
0VTYPE	X	X	X	X
0FISCPER		X	X	X
0FISCPER3		X	X	X
0FISCYEAR	X	X	X	X
0FISCVARNT	X	X	X	X
0AMOUNT	X
0CURRENCY	X			X
0ACCOUNT				X
0CHRT_ACCTS				X
0QUANTITY		X	X
0UNIT		X	X

Become a Patron!