Financials Test Runs

The Financials module in Smart provides the ability to test Financials Business Processes within Workday. Financial Test Runs are created in the same way as HCM Business Processes, however there are additional features which are only applicable to Financials Test Runs. In this section we will cover those features, as well as some specifics to consider when testing Workday Financials.

Financials Chains

Smart offers Financials users the ability to 'chain' business processes together, enabling easy execution of end-to-end Financials tests by allowing Test Runs to reference objects created by previous test cases within the same Test Run.

A Financials Chain test run can be constructed by adding the business processes in the correct sequence. At a very basic level, the most simple Financials Chain is the Journal Chain. This consists of the Create Journal business process and the Unpost Journal business process. The Create Journal template is populated with data in the standard format. The Unpost Journal template then needs to be populated with the journal number created as a result of Create Journal.

Smart can do this by using the operator '<FROM_TEST_CASE: XXXXXX>' (where XXXXXX is a Test Case ID) in the Unpost Journal template. When Create Journal runs, Smart keeps a record of the journal number within the test case information. '<FROM_TEST_CASE: XXXXXX>' instructs Smart to take the resulting Journal number from the specified test case and use it in the specified field. This allows the creation and unposting of a journal to be handled with no manual interaction.

From a technical perspective, the '<FROM_TEST_CASE: XXXXXX>' operator fetches the generated Financials data from the specific test case in the same test run (whether it is a purchase order number, supplier number, invoice number) and uses it at the point in which the operator is specified in a template. This means users can for example run Create Journal, then run Integrations for reporting purposes, and finally run Unpost Journal which will still reference the original journal that was created.

See the images below for an example of how a simple Financials Chain would appear in the Create BP/Integration Test screen, as well as how the Create Journal and Unpost Journal templates would look when populated.

Chain Types

At present Smart supports chaining in six different Workday Financials Functional areas. These are illustrated in the image below. As with the simple Financial Accounting chain example provided above, users can run these chains with Integrations or other Business Process tests in the same Test Run, however the structure from top to bottom must not change in relation to the Financials tests.

The steps listed in each of the Chains are not required, allowing users to start at any point in the chain, as well as end at any point. Additionally users can choose not to carry out a particular BP if it is not needed (e.g. go straight from Create Customer to Create Billing Schedule, skipping the Create Customer Contract BP if the tenant configuration allows this).

Complex Chains

The Financial Accounting example provided above is a demonstration of the basic functionality of Financials Chains, chaining one test to another. Smart offers the ability to chain together multiple Financials test cases in one test run, even if these tests are outputting different types of Financial data. This enables users to run large amounts of Financials tests and create complex chains within each workflow.

Using the above Chain Types table as a reference, users can plan what path their test is going to take and then build the templates accordingly using the <FROM_TEST_CASE: XXXXXX> operator in the required fields to reference the required test case.

Additionally, if the Financials test case outputs Financials data that contains multiple lines (e.g. in a Supplier Invoice), the <FROM_TEST_CASE> operator can be used to reference a specific line by referencing its index. For example, if a Supplier Invoice was created containing 3 service lines, if users wish to reference the third line in this Supplier Invoice they could specified <FROM_TEST_CASE: XXXXXX, 3>.

See the image below for a visual representation of a scenario using multiple chains. In this particular scenario, the user has created three Suppliers. Two of these Suppliers are going to be used in order to Create Supplier Invoices. One Supplier is going to be used with Create Ad Hoc Payment, then Create Settlement Run will be executed for all three tests.

The key to referencing the required data in Financials Chains is that the operator is placed in the correct field. For Create Supplier Invoice, the Supplier field is where users would reference a previous test case. Using the example above "<FROM_TEST_CASE: CRTSUP02>" and "<FROM_TEST_CASE:CRTSUP03>" will allow the Create Supplier Invoice template to pick up the correct Supplier number from the initial Create Supplier test. Similarly within the Create Ad Hoc Payment template, the value "<FROM_TEST_CASE: CRTSUP01>" in the Payee field will pick up the correct Supplier created.

Within the Create Settlement Run template, it is simply a case of referencing the Test Case IDs from your Create Ad Hoc Payment/Create Supplier Invoice templates within the relevant field (Supplier Invoice, Expense Report or Ad Hoc Payment).


Smart supports entering standard and customized Worktags for different Financial transactions.

The most common Worktag types will already be in the template. In the Create Journal template below, the Worktag types Cost Center and Spend Category are already included in the template.

Users can enter as many Worktags into their templates as are required by the Financials business process, by inserting a new row and populating it with the relevant Worktag type in the Field Name column. The Worktag value can then be entered into the test data columns. For example. the Create Journal template above has required the entering of Campaign and Position. In the image below, the template has been updated to include these two Worktag types, along with their values.

On occasion the search response time from Workday may not be quick enough at returning the required Worktag value. Whenever this occurs, we recommend that users refer to a Worktag using an Integration ID, for example the Workday ID. For more information on using Integration IDs in Smart, please see the section on Using Integration IDs in Templates.

Worktag Ordering

In certain scenarios, it may be necessary to enter Worktags in a specific order in a Financials business process. Smart allows control over the input order using the 'Worktags Order' field, available for use in any Financials template where Worktags are used.

This field is available on all new blank Financials templates where applicable. It can also be added into existing templates to enable the new functionality.

In the example Create Journal template below, several Worktags have been used, however the Worktags Order field is empty. In this scenario, Smart will attempt to enter the Worktags in a non-specific order, meaning that there is the potential for related Worktags to override ones that have been previously entered.

Worktags Order allows control over the exact order in which the Worktags are entered into Workday.

Using the Worktags Order field, simply specify the Worktags in the order in which they are to be entered, separating each Worktag with the '|' character.

This functionality works for any number of Worktags and in any order. If there are Worktags for which the order they are entered does not matter, they can simply be excluded from the Worktags Order field, where Smart will enter them in a non-specific order after all listed Worktags in Worktags Order.

Accounting Validation

Smart supports Accounting Validation for the business processes (listed below). This feature enables users to validate the integrity of operational journals created by Workday as part of a Smart test.

Business Processes WD Functional Area
Issue Asset Business Asset
Dispose Asset Business Asset
Capital Project Workbench Business Asset
Create Expenses Report Expenses
Create Expense Report for Worker Expenses
Supplier Invoice workbench Procurement
Create Prepaid Spend Amortization for Instalment  Procurement
Create Supplier Invoice Supplier Accounts
Create Supplier Invoice Adjustment Supplier Accounts
Customer Invoice for Billing Installment
Revenue Management
Create Customer Invoice Revenue Management
Create Revenue Recognition Accoutning Revenue Management
Record Customer Payment
Revenue Management

The purpose of Smart Accounting Validation is to enable users to test the Workday Financials specific rules, which govern how transactions post in accordance with your tenant configuration and how these rules dictate the content of an operation transaction. Some common use cases include:

  1. Account Posting Rules
  2. Currency Rules
  3. Revenue Recognition Rules
  4. Tax
  5. Intercompany
  6. Alternate Account Mapping Rules

Test Case Creation

For the purposes of the User Guide, we will look at the Create Supplier Invoice and Create Customer Invoice Business Processes as examples. Like all tests in Smart Accounting Validation tests are data driven, let’s look at two example scenarios:

1. Testing Account Posting Rules

In order to test account posting rules we need to create a transaction which contains the correct dimensions to trigger the rule. Take the below rule as an example.

This rule should cause journals to post to the “6800: Travel & Entertainment” ledger account provided the company on the Supplier Invoice is “WEN Wayne Enterprises Inc” and at least one item on the invoice has a Spend Category of “Travel and “Entertainment”.

To test this, we will simply create a standard Smart Business Process test and populate the Company in the test template with “WEN Wayne Enterprises Inc”

and the Spend category with “Travel & Entertainment”.

Otherwise the test template will to contain the typical fields (per your tenant configuration) to initiate and complete the business process.


2. Testing Tax

In order to test Tax rules, we need to create a transaction which contains the correct dimensions to trigger the appropriate Tax rule/s. Take the below rule as an example.

The above tax rate will calculate tax at 20% and based on the below posting rule, the tax amount should post to ledger account “2210:VAT Payable”.

To test this, once again we will simply create a standard Smart Business Process test and populate the Tax Applicability field with “Input VAT” and the Tax Code as “UK Input VAT (20%)” in the test template as shown below.

We will also set the invoice line item amount to £15,000 in the test template (so the expected result is tax will be calculated as £3,000, and posted to the “2210:VAT Payable” ledger account).

Otherwise the test template will to contain the typical fields (per your tenant configuration) to initiate and complete the business process.

As you will see from the above both test cases are data driven and the process of creating a Smart Accounting Validation test is the same as a Business Process Test.

Once the test templates have been uploaded to Smart and the tests have been successfully executed you will see a new tab within the test case details page called “Accounting”, this shows the content of the journal created as part of the most recent execution in the section highlighted as "Current". Once your test has executed you should ensure the test result is as expected, this can be done by either reviewing the journal entry as shown below.

The table at the top of the tab (highlighted below) represents the header information at the top of all operation journal entries.

Below this you will a see a series of secondary tabs which represent the same tabs which would also be present on the journal entry in Workday. You can navigate between these in the Smart UI to review the journal data as it would be displayed on the respective tabs in Workday.

Alternatively you can review the journal entries directly in Workday using the “View accounting Details” link in Smart to link directly the operational journal in Workday (this is within the “Steps” tab).

Once you have reviewed the journal and confirmed the results are as expected you can set the baseline results in Smart (which tells Smart that on each test execution we expect the journal to post exactly the same as the baseline). To set the baseline all you need to do is set the test to passed (as shown below)

When the test is then re-executed Smart will compare each field on journal from the current execution with the baseline, if any value is different Smart will fail the test and show a status of Non Match in the results next to "Accounting Validation Comparison", to understand exactly what is different between the baseline and current execution click on the highlighted below for "view accounting".

This will take you directly to the Accounting tab and display a clear side by side comparison of the baseline journal and current execution. In the example below you can see in the baseline journal (left) Workday posted to the 6300: Office & Administrative ledger account however in the current execution (right) Workday posted to the 6200: Marketing account.

Any variation from baseline journals and the current execution will always be highlighted as per the below.

Note:Generally Smart compares ALL fields across ALL tabs on the baseline operational journal to operational journal from the current execution however some fields like “date” are excluded from the comparison but they are output to the “Accounting” tab.

For more information on Accounting Validation, please contact a member of the Kainos Smart Customer Support team.

Chains View

When viewing a Financials Test Run that contains chained tests, users can select the Chains View tab (highlighted below) to enter the Chains View. In this view, Smart will display (in order) the various chains that exist in any given test run in an easy to read format.

If a test case in the pack is not included in any chains, it will be under its own individual heading with no further test cases.