SAP PaPM Cloud Universal Model (SAP PaPM Cloud UM) Posting Strategy via SOAP Services

[Angelou]

Did you know that you can perform a posting of document to your S/4 HANA On-premise system via SAP PaPM Cloud UM without the use of Remote Function Adapter (RFA)?

Yes, you read it right, even without the Remote Function Adapter, we can achieve posting of document by using the related SOAP Services of the BAPIs that are being used for each RFA type from SAP PaPM Cloud SM and use this SOAP Services to the Connection and in our Writer function.

For your reference about BAPIs, see documentation Remote Function Adapter.

I know you are already excited to see on how it is being done in SAP PaPM Cloud UM. So, let’s start!

Prerequisite:

1. Cloud Connector Setup with HTTP/ HTTPS protocol with S/4 HANA On-premise system. For more information, please refer to Cloud Connector. In addition, you may also refer to blog post: SAP PaPM Cloud Standard and Universal Model Integration with SAP BW via OData Service directing to Creation of Connection in Cloud Connector and SAP BTP: Create Destination sections.
2. UUID Field on an existing environment that will be used as Default key field in Connection.

Finance General Ledger & General Ledger Items

General Ledger makes use of the BAPI BAPI_ACC_DOCUMENT_POST. Since BAPIs are not directly usable in SAP PaPM Cloud UM, we will use the SOAP service JournalEntryBulkLedgerCreation in our created Connection. This SOAP service can perform a general ledger posting to your SAP S/4 HANA On-premise System and can perform multiple accounting documents in one run.

See documentation: Journal Entry by Ledger - Post.

If you would like to verify if this SOAP service is already implemented in your S/4 HANA On-premise System, follow the step-by-step procedure below:

1. Go to the transaction code: SOAMANAGER
   

2.  Search the SOAP Web Service if available.

   1. Go to Web Service Configuration
   2. Search for the SOAP Service, example: JournalEntryBulkLedgerCreation.
   3. Choose the existing service.
      

      If this service is not yet implemented, please contact the administrator of your S/4 HANA System and see reference from: How to setup the Web Service Configuration of Journal Entry API for S/4 HANA On-Premise System

SAP PaPM Cloud Universal Model – Modeling for Finance General Ledger

1.       Creation of Connection in SAP PaPM Cloud UM with the details of Destination created from the pre-requisite.

1. Add Connection ID
2. Add Connection Description
3. Choose the Destination name
4. Press Help button on the Service Path
5. Add the created UUIDME field
6. Searched for the SOAP Service for General Ledger: JournalEntryBulkLedgerCreation
7. Choose the Service
   Save the changes and all models will populate in the Connections screen.
   

2.       Choosing of Models that will be used in Modeling.

Multiple Models will be available once the Connection is created. For the General Ledger scenario, we will be needing only three Models which are:

• JournalEntryCreateRequestBul1 – this Model will serve as a header of the payload for the SOAP service posting.
• JournalEntryCreateRequest – this Model will serve as the body that contains the General Ledger information like Ledger Group, Company Code, etc.
• Item – this Model contains the information the line Item for the General Ledger posting. Like debit / credit code, transaction value and currency.
  2.1 Choose the First Model which is which is JournalEntryCreateRequestBul1 and map the required fields like the image below:
  
  See documentation on how to add fields: SOAP Service.

  2.2 Since we only need specific Models from our connection, users also need to remove the sync relation and only keep the Second Model synced which is JournalEntryCreateRequest.
  
  

  2.3 Moving on to the Second Model, JournalEntryCreateRequest. Here are the fields that is currently mapped on my General Ledger scenario.
  
  

  UUIDME	JournalEntry.OriginalReferenceDocumentLogicalSystem
  MessageHeader.ID.$value	JournalEntry.LedgerGroup
  MessageHeader.CreationDateTime	JournalEntry.DocumentReferenceID
  JournalEntryCreateRequestBulkMessageLedger_Key	JournalEntry.DocumentHeaderText
  JournalEntry.OriginalReferenceDocument	JournalEntry.DocumentDate
  JournalEntry.OriginalReferenceDocumentType	JournalEntry.CreatedByUser
  JournalEntry.AccountingDocumentType	JournalEntry.CompanyCode
  JournalEntry.PostingDate	JournalEntry.BusinessTransactionType

  The fields above are added in my Model for General Ledger posting via SOAP Service. You may only add the mandatory fields based on the documentation: Journal Entry by Ledger - Post.

  We have two (2) keys for this Model as the (1) UUIDME field will serve as primary key of its Model, while (2) JournalEntryCreateRequestBulkMessageLedger_Key is for association field Joining rows from its Parent Model (JournalEntryCreateRequestBul1).  

  Later, I will show you how we are going to use this association field in the Join condition of this Model Entity relations.
  

  2.4 This second Model JournalEntryCreateRequest also has other Model Relations synced. With our current General Ledger scenario, we need to remove the others and only keep the Sync relation on model Item.
  

  2.5 Last Model that we will be mapping is the Item, Here are the fields that are currently mapped on our General Ledger scenario.
  
  

  UUIDME	AssignmentReference
  JournalEntryCreateRequest_Key	AmountInTransactionCurrency.$value
  GLAccount.$value	AmountInTransactionCurrency.attributes.currencyCode
  DocumentItemText	AccountAssignment.CostCenter
  DebitCreditCode

  
  

  On this model, we also have two (2) key fields which are (1) UUIDME, serving as the primary key of this model, while (2) JournalEntryCreateRequestBulkMessageLedger.JournalEntryCreateRequest_Key is for association field joining both rows from its parent model: JournalEntryCreateRequest.
  

  2.6 Since all fields are created and mapped, we can now configure the Join Condition from the first Model JournalEntryCreateRequestBul1. Follow the steps below:

  1. In the created Connection, choose the Model JournalEntryCreateRequestBul1 , by clicking its row.
  2. Scroll down and choose the Model Relation JournalEntryCreateRequest.
  3. Edit the Join condition accordingly to the format below:
     Join Condition: (Model Name + ‘.’ + Association Field) = UUIDME
     

     This step is important as it in SAP PaPM Cloud Universal Model, association fields should be mapped properly to make a successful relation between two (2) models.

2.7 Perform the same steps for second Model JournalEntryCreateRequest. But this time, we are going to use the association field of the Model Item.

a. In the created Connection, choose the Model JournalEntryCreateRequest,
by clicking its row.
b. Scroll down and choose the Model Relation Item.
c. Edit the Join condition accordingly to the format below:
    Join Condition: (Model Name + ‘.’ + Association Field) = UUIDME

2.8 You may now save the changes by following the steps below:
      a. Choose Save
      b. Then Sync Models

Once all are synced and saved.  Synced Model Entities will now appear on our Manage Functions screen in the environment together with the Fields in the Manage Fields screen.

3.       Creation of Local Model Entities equivalent structure of Model Entities from Connection

Since we already have Model Entities where the Writer function can write. Now, we need to have a Local Model entity that has the same structure from the synced Models.

It is also advisable to create a Local field identical to the Added fields from connection. This is to avoid confusion when it comes to mapping.

On this scenario, I have added the prefix “UM” before the name of the original field from connection to have an indicator that it is coming from my Local Model Entities. See image below for example:

3.1 Create the first Local Model Entity with identical fields from Synced Model JournalEntryCreateRequestBul1.

An association field is created as we are going to have the same structure of Model Entities from Synced Models.

3.2 Create the second Local Model Entity with identical fields from Synced Model JournalEntryCreateRequest. 

Related Model entities are only allowed to have one editable data model. Therefore, the restriction of this second local Model entity is ‘Disable Odata draft’.

For more information, see Documentation: Model Entity .
Note: All fields are not just being shown but number and fields should be identical

3.3 Create the third Local Model Entity with identical fields from Synced Model Item.

Similar from step 3.2,  ‘Disable Odata draft’ configuration is relevant for this Model Entity as well.

For more information, see Documentation: Model Entity .

Since the association fields are added for both second and third model, we may now create Relations between the Parents and its related Model.

3.4 Add Relations to the first Parent Local Model Entity by following the steps below:

a. Choose Edit
b. Then press Create.
c. Add Relation ID
d. Add Description of the Relation
e. Choose type Composition of Many’.
f. Choose the second local model MEA02.
g. Save

 3.5 Add Relations to the second Parent Local Model Entity by following the steps below:

a. Choose Edit
b. Then press Create.
c. Add Relation ID
d. Add Description of the Relation
e. Choose type Composition of Many’.
f. Choose the third local model MEA03.
g. Save

3.6 Add the data records to the main Local Model Entity. In case you need to post multiple items in one document, you need to add more data rows in the MEA03. Similar with the image below:

If you may notice, we have two (2) rows in the MEA03 as it contains the Amount transaction components. When putting an Amount Transaction, it is a MUST to be balanced, that is why we have Positive and Negative values in the data records.

With the same row, you will also see that the values for DebitCreditCode are S and H it means:

S –Debit
H- Credit
Refer to the: Documentation from help Portal

Note: These three (3) Local Model Entities can be a single Model Entity / Flat Model Entity. But the data records MUST be aligned with Association field as our Models uses Related Models structure.

Even so, for this example, we just have used the three (3) Local Model Entities to avoid confusion in terms of mapping.

4.       Create a Model View on top of the three (3) Local Model Entities

With the current UI Implementation In Universal Model, users must create a Model View on top of the Local Model Entity that has a relation from other Local Model Entities. This is because we will not be able to see the other fields as it will still be needed to be implemented.

Therefore, I have created the Model View as an example that contains ALL the fields, we have from three (3) Local Model Entities.

Aside from containing all the fields, I have created an extra UUID field to make it as an alias to our association fields from Parent Local Model Entities, this is to avoid confusion for mapping later in the Writer function.

5.       Creation of the Writer function

With all Input and Outputs already created in our Environment. Users may now proceed with the creation of Writer.

5.1 Create the Writer function

Type: Delete and Insert – for an example, we are using Delete and Insert as the Writer is considering the Primary key being used for Writing. (So, if a user executed a writer that uses only Insert type, it might probably cause an error due to primary keys).
Connection – connection that the user have used from previous step.
Input – the Model View created from previous step(Contains all fields required)
Result Model Function – user must choose the Mother Model Entity which is JournalEntryCreateRequestBul1 as it will serve the first Model Entity to be written on following the next Models setup in the Model Relations

5.2 All identical fields should be mapped to each other to ensure that the specific data records will be written to the correct field. See image below for example:

5.3 More importantly, primary key fields (UUIDME) and Association fields from our Local Model Entity should be mapped to the same field from our Synced Model Entities (UUIDME) and secondary keys.

MEA01.UUIDME = JournalEntryCreateRequestBul1.UUIDME
MEA02.UUIDME = JournalEntryCreateRequest
MEA02.MEA01ASSOC = JournalEntryCreateRequest.JECR.Key
MEA03.UUIDME = Item
MEA03.MEA02ASSOC = JournalEntryCreateRequest.Item.Key

6.       Activation and Execution of the Writer function

6.1 Activate the Environment in SAP PaPM Cloud Universal Model to use the latest
changes performed from previous steps.
6.2 Execute now the Writer function.

a. Choose the Writer function by pressing the checkbox.
b. Press Run
c. Notification will show that the Run is finished for the Writer function.

6.3 Check the logs of the Writer function and get the Message ID from Localize message.

a. Choose the Writer function by clicking its row (not checkbox)
b. Choose direct link of Event logs.
c. Select the runFunction event.
d. Copy the message ID.

7.       Search the Message ID in the S/4 HANA On-premise system

7.1 Go to the S/4 HANA On-premise System, search the Tcode SRT_MONI

SRT_MONI – is like an application log for web services that are being requested or accepted to the S/4 HANA system. Since we have sent a SOAP Service to the S/4 HANA system, it will be listed under the SRT_MONI at SOAP service is also a web service.

7.2 Paste the Message ID then press Execute:

7.3 Choose the generated logs and copy all available details that we can use for searching in ACDOCA Table.

7.4 Search for the posted document from the details of the message ID in previous step.

a. Go to SE16
b. Search for ACDOCA table.
c. Add the copied values from previous steps in Message ID.
d. Execute

From here, we can get the Document number, Company Code and Fiscal year that are posted in the ACDOCA table for specific searching of this document in FB03.

7.5 Display the document to verify if it is successfully posted.

a. Go to transaction code FB03.
b. Add the Document number, Company Code and Fiscal year from previous step.
c. Continue
d. See the document posted.

With this example, we achieved the General Ledger posting from SAP PaPM Cloud Universal Model using SOAP Service: JournalEntryBulkLedgerCreation .

Finance Accounts Payable

Accounts Payable also makes use of the BAPI BAPI_ACC_DOCUMENT_POST.  While it uses the SOAP Service: JournalEntryBulkCreationRequest_In.

For more information, see Journal Entry - Post (Asynchronous).

1.       Choose the Models that will be used in the Modeling.

Similar from the previous Remote Function Adapter types, these are the Models that are needed for Accounts Payable scenario. In my scenario, here are the four(4) models that I have used:

• JournalEntry CreateRequestBul40– this Model will serve as a header of the payload for the SOAP service posting.
• JournalEntryCreateRequest51– this Model will serve as the body that contains the General Ledger information like Ledger Group, Company Code, etc.
• JournalEntryCreateRequest62 – this Model contains the information the line Item like debit / credit code, transaction value and code.
• CreditorItem – this model has the Field Creditor that is relevant for Accounts Payable posting.

1.1 Choose the First Model which is which is JournalEntryCreateRequestBul40 and map the required fields like the image below:

 1.2 Since we only need specific Models from our connection, users also need to remove the sync relation and only keep the Second Model synced which is JournalEntryCreateRequestBul51.

1.3 Moving on to the Second Model, JournalEntryCreateRequestBul51. Here are the fields that is currently mapped on my Accounts Payable scenario. 

UUIDME	JournalEntry.AccountingDocumentType
JournalEntry.BusinessTransactionType	JournalEntry.PostingDate
MessageHeader.ID.$value	JournalEntry.OriginalReferenceDocumentLogicalSystem
MessageHeader.CreationDateTime	JournalEntry.DocumentReferenceID
JournalEntryCreateRequestBulkMessage_Key	JournalEntry.DocumentHeaderText
JournalEntry.OriginalReferenceDocument	JournalEntry.DocumentDate
JournalEntry.OriginalReferenceDocumentType	JournalEntry.CreatedByUser
JournalEntry.CompanyCode

1.4 We only need specific Models from our connection, users also need to remove the sync relation and only keep the Second Model synced which is JournalEntryCreateRequestBul62 and CreditorItem.

1.5 On the Third Model, JournalEntryCreateRequestBul62. Here are the fields that is currently mapped on my Accounts Receivable scenario. 

UUIDME	GLAccount.$value
Tax.TaxCode.$value	DocumentItemText
Tax.TaxExpenseAmountInCoCodeCrcy.$value	AmountInTransactionCurrency.$value
Tax.TaxExpenseAmountInCoCodeCrcy.attributes.currencyCode	AmountInTransactionCurrency.attributes.currencyCode
JournalEntryCreateRequestBulkMessage.JournalEntryCreateRequest_Key

 1.6 Our Fourth Model is the CreditorItem. Here are the current fields that are mapped on my Accounts Payable Scenario.

UUIDME	DebitCreditCode
ReferenceDocumentItem	AmountInTransactionCurrency.$value
JournalEntryCreateRequestBulkMessage.JournalEntryCreateRequest_Key	AmountInTransactionCurrency.attributes.currencyCode
Creditor

With the Synced Model entities from connections, in our Local Environment, we should have the same structure of local Model entities same from Finance General Ledger above. The Creditor field must be field up with valid accounts from your S/4 HANA On-premise.

See sample data:

With the creation of Model View on top of the four (4) Local Model Entities, we can use this Model View as input to the Writer function same from Finance General Ledger.

Once setup, execution of writer will also provide a message ID that can be used for searching the document in the S/4 HANA On-premise system.

Mandatory fields are still the same from previous RFA types for similar models, please see documentation, CreditorItem.

Finance Accounts Receivable

Accounts Receivable also makes use of the BAPI BAPI_ACC_DOCUMENT_POST.  While it also uses the SOAP Service: JournalEntryBulkCreationRequest_In same from Accounts Payable.

1.       Choose the Models that will be used in the Modeling.

Since Accounts Receivable uses the same service from Accounts Receivable, we are going to use the same first three(3) models which are JournalEntryCreateRequestBul40, JournalEntryCreateRequest51 and JournalEntryCreateRequest62.

But on this scenario, we will need the Model DebtorItem instead of CreditorItem

• JournalEntryCreateRequestBul40– this Model will serve as a header of the payload for the SOAP service posting.
• JournalEntryCreateRequest51– this Model will serve as the body that contains the General Ledger information like Ledger Group, Company Code, etc.
• JournalEntryCreateRequest62 – this Model contains the information the line Item like debit / credit code, transaction value and code.
• DebtorItem – this model has the Field Debtor that is relevant for Accounts Receivable posting.

Fields that are needed for three(3) first models in Accounts Receivable scenario are the same from Accounts Payable. Therefore, I will show to you the fields that I have used for DebtorItem model.

On our DebtorItem. Here are the current fields that are mapped on my Accounts Receivable Scenario.

UUIDME	DebitCreditCode
ReferenceDocumentItem	AmountInTransactionCurrency.$value
JournalEntryCreateRequestBulkMessage.JournalEntryCreateRequest_Key	AmountInTransactionCurrency.attributes.currencyCode
Debtor

Once we have mapped and synced all the Models, data records from equivalent Model Entities are still needed. See sample data below:

Upon execution of the Writer function, it will provide the Message ID that contains that can be search also in S/4 HANA On-premise system and use for searching the document.

See sample document below:

Purchase Order

Purchase order make use of BAPI BAPI_PO_CREATE1. For SOAP Service, we can make use of PurchaseOrderRequest_In.

1.       Choose the Models that will be used in the Modeling.

Models that are needed and contains the required components for Purchase Order posting are listed below:

• Purchase Order Message - this Model will serve as a header of the payload for the SOAP service posting. In addition, it has the fields for Purchase Group, Organization, Supplier and other components that are being used for Purchase Order posting.
• Purchase Order Item – this model contains the fields that pertaining to Item prices, materials, star and end date and plant.
• Price Condition – this model contains the fields for the Condition of the purchase order posting.
• Account Assignment Line – this model contains the Order ID and Cost center that are also being used for Purchase Order posting.

Since you already have an Idea how Model Relations setup from previous SOAP Services scenarios, Here are the simple examples of Model Relations I have setup for the Purchase Order.

2.        Model Relations:

Purchase Order Message => Purchase Order Item

Purchase Order Item => Price Condition & Account Assignment Line

3.       Fields used:

Purchase Order Message

UUIDME	PurchaseOrder.PurchasingGroup
PurchaseOrder.SupplierParty.Supplier	PurchaseOrder.DocumentType
PurchaseOrder.PurchaseOrderExternalReferenceID	PurchaseOrder.CompanyCode
PurchaseOrder.DocumentCurrency	MessageHeader.SenderBusinessSystemID
PurchaseOrder.ActionCode	MessageHeader.ID.$value
PurchaseOrder.PurchasingOrganization	MessageHeader.CreationDateTime

Purchase Order Item

UUIDME	PurchaseOrderMessage_Key
RequestedQuantity.$value	ItemPrice.BaseQuantity.$value
PurchaseOrderItemExternalRefID	ItemPrice.Amount.$value
Plant	ItemPrice.Amount.attributes.currencyCode
PerformancePeriod.StartDate	ActionCode
PerformancePeriod.EndDate	AccountAssignment.AccountAssignmentCategory
Material

Price Condition

UUIDME	PurchaseOrderMessage_Key
RequestedQuantity.$value	ItemPrice.BaseQuantity.$value
PurchaseOrderItemExternalRefID	ItemPrice.Amount.$value
Plant	ItemPrice.Amount.attributes.currencyCode
PerformancePeriod.StartDate	ActionCode
PerformancePeriod.EndDate	AccountAssignment.AccountAssignmentCategory
Material

Account Assignment Line

UUIDME	OrderID
PurchaseOrderMessage.PurchaseOrder.PurchaseOrderItem_Key	CostCenter

With the Synced Model entities from connections, in our Local Environment, we have the same structure of local Model entities. These local Model entities will be filled up with the valid data records coming from our S/4 HANA. See sample image below for filled up Purchase Order document type, Purchasing Group that are mandatory fields for Purchase Order posting.

Successful execution of the Writer function also provides the Message ID in the message log that the user can search in the SRT_MONI of the S/4 HANA On-premise. Searching the posted value in ME23N transaction code will show the Purchase Order posted.

Mandatory fields are still the same from previous RFA types for similar models, please see documentation, Purchase Order (MM-PUR)

We are still preparing how to achieve the posting for these RFA Adapters below using the SOAP Services:

• Sales and Distribution
• Post Journal Entries for Group Reporting

Once these are prepared, I will update this blog post with additional SOAP Services that you can use for other Remote Function Adapter scenarios.

Hopefully to see you again, in next integration blog post!