Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
Alice_Ying
Product and Topic Expert
Product and Topic Expert
Test automation for APIs involves creating scripts and programs that simulate API requests and verify the responses, allowing for efficient and repeatable testing. The strategy and structure of test automation for APIs involve defining a comprehensive plan and framework to efficiently and effectively validate the API functionalities. 

We want to take this opportunity to shed light on our comprehensive approach to API testing, emphasizing our commitment to delivering reliable and high-quality products of journal entry APIs in General Ledger Accounting. To have an overview of Journal Entry APIs, please visit our blog APIs for Journal Entries – The Collection. 

Automated Testing Strategy and Process 

Our testing methodology revolves around a proactive and systematic approach to ensure the functionality and reliability of our APIs. At the core of our strategy is comprehensive test automation, allowing us to efficiently cover a wide array of use cases while maintaining a high level of accuracy and reliability. 

We leverage cutting-edge automation tools and frameworks to streamline our testing process. Our automation suite is designed to execute test cases rapidly and consistently, minimizing human error and ensuring thorough coverage across various endpoints and payloads. By automating repetitive and critical test scenarios, we ensure the reliability and efficiency of our APIs.  

Coverage and Schedule 

Every API we develop undergoes a rigorous testing process that encompasses various scenarios and use cases. We start by defining clear use cases based on real-world applications, ensuring that our APIs meet the diverse needs of our customers. We validate the core functionality of an API to ensure it performs as expected. 

To maintain a vigilant eye on our testing outcomes, we run daily reports to monitor the results. Below is a snapshot of a sample report: 




  • In the left pane of the report, you can see the daily report of the scenario testing. A detailed snapshot of scenario testing unfolds. In the displayed sample results, two journal entries are visible within the testing system. The green checkmarks alongside each entry signify successful verification by the system. 

  • The right part of the screenshot showcases the manual verification option is available, allowing you to cross-reference the data presented in the report with the corresponding information within the application. This verification step ensures alignment and accuracy between our testing environment and your system. 


Continual Improvement 

Our testing doesn't conclude at the product release; it's an ongoing process. We follow a meticulously planned testing schedule that aligns with our development cycles. Continuous integration and deployment enable us to implement fixes swiftly and seamlessly, ensuring rapid response to any identified issues while maintaining uninterrupted service for our customers. 

Use Cases 

So far, our test automation has been implemented for the following journal entry APIs within General Ledger Accounting, encompassing various critical use scenarios: 
























API 



Use Scenario 




Journal Entry - Post (Synchronous) 

Journal Entry - Post (Asynchronous) 


  • Accounts payable 

  • Accounts receivable 

  • Tax 

  • General Ledger related 

  • Account assignment 

  • Profitability segment 

  • Extensibility fields 


Journal Entry by Ledger – Post (Asynchronous) 

  • Account assignment 

  • Profitability segment 

  • Extensibility fields 


 
Journal Entry – Clearing (Asynchronous) 

  • Accounts payable clearing 

  • Accounts receivable clearing 

  • Clearing G/L accounts 


 
Journal Entry – Change (Asynchronous) 

  • Changes in header 

  • Changes in line items 

  • Changes for accounts payable and receivable 



At present, we've automated testing for over 100 sub-use cases, with the number continuously expanding to incorporate a wider array of scenarios that cater to the diverse needs of our customers 























API  Sub-use Case 


Journal Entry - Post (Synchronous) 

Journal Entry - Post (Asynchronous)
 


  • Supplier invoice: with discount; without input tax; with alternative reconciliation account; with multiple P&L lines for document split; with discount net amount 

  • Supplier down payment (request)  

  • Customer neg: with One-Time account; with/without output tax; with dunning; credit demo 

  • Tax related: with non-deductible tax; Item-by-Item tax; with withholding tax;  

  • With extensibility (custom fields): in coding block, in line item, in COPA 

  • Other journal entry related: with negative posting; with cross company posting; with one true account assignment (WBS element/cost center/revenue relevant); with multiple account assignments; with COPA segment (WBS element/cost center/revenue relevant); with currency adjustment; with cost/profit transfer 


Journal Entry by Ledger – Post (Asynchronous) 

  • Journal entries: with one true account assignment (WBS element/cost center/revenue relevant); with multiple account assignments; with COPA segment (WBS element/cost center/revenue relevant) 

  • With extensibility (custom fields): in coding block, in line item, in COPA 


Journal Entry – Clearing (Asynchronous) 

  • Accounts payable clearing: residual item with non-written off reason code; with distribute difference; with cash discount; with downpayment; with payment difference 

  • Accounts receivable clearing: residual item with non-written off reason code; with cash discount; with downpayment; with payment difference 

  • GL accounts clearing 


 
Journal Entry – Change (Asynchronous) 

  • Header: header text; reference ID; country specific fields 

  • Line item: item text; assignment reference; Item key; payment difference reason; supplying country; state central bank payment reason; reference ID by business partner 

  • AP/AR related fields: invoice reference; invoice reference fiscal year; Invoice item reference; amount in payment currency; last dunning date; dunning blocking reason code; dunning level; dunning key; payment terms; due calculation base date; cash discount days; net payment days; cash discount percent; payment method; payment blocking reason code; fixed cash discount; payment difference reason 

  • extensibility (custom fields): on G/L item; on APAR item 



Sample Payload  

Below you can view the payload for sub-use case Supplier Invoice with Input Tax: 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sfin="http://sap.com/xi/SAPSCORE/SFIN"> 

<soapenv:Header/>

<soapenv:Body>

<sfin:JournalEntryBulkCreateRequest>

<MessageHeader>

<ID>TAOJ_SIWIT</ID>

<!--<ReferenceID></ReferenceID>-->

<CreationDateTime>{{$isoTimestamp}}</CreationDateTime>

</MessageHeader>

<!--1 or more repetitions:-->

<JournalEntryCreateRequest>

<MessageHeader>

<ID>TAOJ_SIWIT_1</ID>

<!--<ReferenceID></ReferenceID>-->

<CreationDateTime>{{$isoTimestamp}}</CreationDateTime>

</MessageHeader>

<JournalEntry>

<OriginalReferenceDocumentType>BKPFF</OriginalReferenceDocumentType>

<OriginalReferenceDocument/>

<OriginalReferenceDocumentLogicalSystem/>

<BusinessTransactionType>RFBU</BusinessTransactionType>

<AccountingDocumentType>KR</AccountingDocumentType>

<DocumentReferenceID>123</DocumentReferenceID>

<DocumentHeaderText>Postman:Supplier Invoice</DocumentHeaderText>

<CreatedByUser>_SAPUSERNAME</CreatedByUser>

<CompanyCode>{{companyCode}}</CompanyCode>

<DocumentDate>{{currentDate}}</DocumentDate>

<PostingDate>{{currentDate}}</PostingDate>

<Reference1InDocumentHeader>ap-invoice-w-tax</Reference1InDocumentHeader>

<TaxDeterminationDate>{{currentDate}}</TaxDeterminationDate>

<Item>

<GLAccount>0063001000</GLAccount>

<AmountInTransactionCurrency currencyCode="EUR">100</AmountInTransactionCurrency>

<Tax>

<TaxCode>V1</TaxCode>

</Tax>

<DebitCreditCode>H</DebitCreditCode>

<AccountAssignment>

<!--Optional:-->

<CostCenter>0010101201</CostCenter>

</AccountAssignment>

</Item>

<CreditorItem>

<ReferenceDocumentItem>2</ReferenceDocumentItem>

<Creditor>S1030001</Creditor>

<AmountInTransactionCurrency currencyCode="EUR">-119</AmountInTransactionCurrency>

<DebitCreditCode>S</DebitCreditCode>

</CreditorItem>

<ProductTaxItem>

<!--Optional:-->

<ReferenceDocumentItem>3</ReferenceDocumentItem>

<TaxCode>V1</TaxCode>

<DebitCreditCode>H</DebitCreditCode>

<ConditionType>MWVS</ConditionType>

<AmountInTransactionCurrency currencyCode="EUR">19</AmountInTransactionCurrency>

<TaxBaseAmountInTransCrcy currencyCode="EUR">100</TaxBaseAmountInTransCrcy>

</ProductTaxItem>

</JournalEntry>

</JournalEntryCreateRequest>

<JournalEntryCreateRequest>

<MessageHeader>

<ID>TAOJ_SIWIT_2</ID>

<!--<ReferenceID></ReferenceID>-->

<CreationDateTime>{{$isoTimestamp}}</CreationDateTime>

</MessageHeader>

<JournalEntry>

<OriginalReferenceDocumentType>BKPFF</OriginalReferenceDocumentType>

<OriginalReferenceDocument/>

<OriginalReferenceDocumentLogicalSystem/>

<BusinessTransactionType>RFBU</BusinessTransactionType>

<AccountingDocumentType>KR</AccountingDocumentType>

<DocumentReferenceID>123</DocumentReferenceID>

<DocumentHeaderText>Postman:Supplier Invoice</DocumentHeaderText>

<CreatedByUser>_SAPI069526</CreatedByUser>

<CompanyCode>{{companyCode}}</CompanyCode>

<DocumentDate>{{currentDate}}</DocumentDate>

<PostingDate>{{currentDate}}</PostingDate>

<Reference1InDocumentHeader>ap-invoice-w-tax</Reference1InDocumentHeader>

<TaxDeterminationDate>{{currentDate}}</TaxDeterminationDate>

<Item>

<GLAccount>0063001000</GLAccount>

<AmountInTransactionCurrency currencyCode="EUR">200</AmountInTransactionCurrency>

<Tax>

<TaxCode>V1</TaxCode>

</Tax>

<DebitCreditCode>H</DebitCreditCode>

<AccountAssignment>

<!--Optional:-->

<CostCenter>10101040</CostCenter>

</AccountAssignment>

</Item>

<CreditorItem>

<ReferenceDocumentItem>2</ReferenceDocumentItem>

<Creditor>S1030005</Creditor>

<AmountInTransactionCurrency currencyCode="EUR">-238</AmountInTransactionCurrency>

<DebitCreditCode>S</DebitCreditCode>

</CreditorItem>

<ProductTaxItem>

<!--Optional:-->

<ReferenceDocumentItem>3</ReferenceDocumentItem>

<TaxCode>V1</TaxCode>

<DebitCreditCode>H</DebitCreditCode>

<ConditionType>MWVS</ConditionType>

<AmountInTransactionCurrency currencyCode="EUR">38</AmountInTransactionCurrency>

<TaxBaseAmountInTransCrcy currencyCode="EUR">200</TaxBaseAmountInTransCrcy>

</ProductTaxItem>

</JournalEntry>

</JournalEntryCreateRequest>

</sfin:JournalEntryBulkCreateRequest>

</soapenv:Body>

</soapenv:Envelope>

 

Your feedback is very valuable to us, and we genuinely appreciate your patience and understanding as we diligently address issues and strive to maintain the high standards you expect from SAP. If you come across any test scenarios that you believe are important but might be missing from our current suite, we welcome and appreciate your effort in helping us enhance and enrich our test scenarios for a more comprehensive coverage.  

For further information regarding APIs in general and the SAP Business Accelerator Hub, we encourage you to explore the documentation available on the SAP Help Portal: