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 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 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 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 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 system

7.1 Go to the S/4 HANA Syste, 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 .

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

• Accounts Payable
• Accounts Receivable
• Sales and Distribution
• Purchase Order
• 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!