If ever you need to add currencies into Words and have to include their Decimals (i.e. Cents), this query below demonstrates that using to TO_CHAR(TO_DATE(X, 'J'), 'JSP') trick:
SELECT AMOUNT_SIGN||AMOUNT_IN_WORDS COMPLETE_AMOUNT_IN_WORDS
FROM (SELECT AMOUNT
, CASEWHEN SIGN_AMT isnotnullthen SIGN_AMT||' 'END AMOUNT_SIGN
, CASEWHEN DOLLAR_AMT ISNOTNULLAND CENT_AMT ISNOTNULLTHEN
DOLLAR_AMT||' AND '||CENT_AMT
WHEN DOLLAR_AMT ISNULLAND CENT_AMT ISNOTNULLTHEN
CENT_AMT
WHEN DOLLAR_AMT ISNOTNULLAND CENT_AMT ISNULLTHEN
DOLLAR_AMT
END AMOUNT_IN_WORDS
FROM (select AMOUNT
, CASEWHEN INSTR(AMOUNT, '-') >0THEN'NEGATIVE'END SIGN_AMT
, CASEWHENABS(amount) >=1THEN-- ONLY THE ONES WITH WHOLE NUMBERS
to_char( to_date(TRUNC(ABS(amount)), 'J'), 'JSP') ||' BAHT'END DOLLAR_AMT
, CASEWHEN INSTR(AMOUNT, '.') >0THEN-- ONLY THE ONES WITH DECIMALS
TO_CHAR(to_date(RPAD(SUBSTR(AMOUNT, INSTR(AMOUNT, '.') +1), 2, '0'), 'J'), 'JSP') ||' SATANG'END CENT_AMT
from (select30 amount from dual
unionselect30.500 amount from dual
unionselect0.501 amount from dual
unionselect-30 amount from dual
unionselect-30.500 amount from dual
unionselect-0.501 amount from dual
)
)
);
As you create a control, you can create a test plan for it. Completed as part of a control assessment, it test whether the control is effective in alleviating the related risks.
Risk Management is a great tool for Auditors to address risks in the Organization. Risk, in this context, is an adverse material or financial impact to the organization. The Risk Management Module is composed of two divisions: Financial Reporting Compliance and Advanced Controls Management.
Financial Reporting Compliance is the part that Documents all the Business Processes, while Advanced Controls Managementis used to test Financial Transactions (specifically Payables and Expense Reports), Segregation of Duties and User Security. Advanced Controls Management is further broken down into two: Advanced Financial Controls and Advanced Access Controls. Goals of Risk Management
Update/Maintain Documentation for Business Processes and Adverse Impact
Evaluate/Review Risks to Business Processes
Resolve Issues
Distribute/Print Results
To work with a risk is to:
Name the risk
Describe the risk
Relate the risk to the controls meant to minimize it
You may also attach documents to the risk to provide more detail about it and select perspective values for the risk to characterize it.
Risk Management Cycle
Add risks and controls to the object library
Review and approve risks and controls
Create Assessment templates and plans and initiate assessments
Assess Objects
Create and Address Issues identified during assessments
Re-assess Risks and Controls
Review assessment result Reports
Predefined Job roles for Risk Management
Application
Job Role Name
Financial Reporting Compliance
Enterprise Risk and Control Manager
Financial Reporting Compliance
Compliance Manager
Advanced Financial Controls
Application Control Manager
Advanced Access Controls
Application Access Manager
Important Duty Roles in Risk Management
Enterprise Risk & Control Manager
Compliance Manager
The above-mentioned roles is recommended to be copied and customized because it is way too powerful to assign to business users. You would need to run specific background programs after the customization have been carried out.
How does Financial Reporting Compliance and Advanced Controls Management work together?
Financial Reporting Compliance and Advanced Controls Management both use Control as the way to identify the Risks in the Enterprise.
Scheduled Jobs in Risk Management
Three predefined processes run the first time you start Risk Management:
User and Role Security Synchronization
Worklist Security Synchronization
Report Synchronization
Common Terminologies in Risk Management Cloud
Some common terminologies for Risk Management:
Object is the generic term for any of the components one may include in a module. Objects are independent of other objects in other modules.
A Module is a set of objects that relate to one another in a way that defines governance, risk and compliance environment.
Process is the focus of governance, risk, and compliance efforts, representing business processes for which users identify risks and create controls to alleviate those risks.
Financial Reporting Compliance
Process Object
Risk Object - A risk defines circumstances that may adversely affect a business process.
Control Object - A control defines measures to address a risk.
Test Plan - For each control, you can create test plans. Test plans document steps to be followed in determining whether the control is effective.
Issue - An issue is a defect or deficiency detected for a risk or control, or an activity connected with one of these objects, such as an assessment.
Remediation Plan
Assessment - An Assessment is the review of a risk or control to ensure that it is defined correctly and remains effective over time.
Survey is a set of questions that may be associated with assessments or distributed independently of assessments
Automatically, the system will create one header level object and one line level transaction object. Those transaction objects have been utilized to generate the sources. Then the sources are also automatically generated based on the transaction objects and are assigned to the corresponding accounting event classes. These sources will always be used as a value when you design your accounting rules.
What is stored at the header transaction object level? Header transaction objects are used to store one row with header source values for each transaction that comes from the source system. This header object will always get populated with the transaction information that is coming from the source system. So for every transaction that comes from the source system, we need one header level record.
Each transaction is identified by its unique transaction number. And each transaction is also automatically assigned with an event as well. The transaction details whose values do not vary by transaction line or distribution should normally be stored in the header transaction objects only. So if you do not have line level details for bifurcating that value that you're capturing at the other level, so only header level information is enough to create the accounting entry.
What is stored at the line transaction object level? If you have a requirement where one header may have multiple lines, then apart from populating the data into the header level object, we need to populate the data into the line level objects also. So line transaction objects will store the details of transactions that vary based on transaction attributes.
For example, a mortgage transaction for loan origination may have multiple amounts, each related to different components of the loan, such as a loan origination amount, closing cost amount, and escrow amount, and you want to charge them to separate accounts. So each of these amounts could be captured as separate lines, along with an indication of the amount type. One row per distribution is linked to the associated transaction by transaction number. So at the header level, you will have the transaction number. And same transaction number will be referenced at the line level also. Because against that header, we want to have three different lines.
Each row is also automatically assigned with a line number. Because for the line level transaction object, line number is a required field. Transaction details whose values will vary by transaction line or distribution are normally stored in the transaction object column, for example, the loan number for a loan payment.
If there is no breakdown for the amount, it's OK to capture that at the header level itself. Otherwise, then you must populate the values at the line level transaction object as well.
Sources
Each and every column that is part of your transaction object will be converted into a source. So you must assign an update value, certain look-up type assignments whenever appropriate sources can have lookup types or value sets assigned to them.
Assigning a value set or lookup type enables you to pre-define valid values for the sources that is used to create accounting rules. So basically, when the transaction object has been registered, you can look into the sources that system has generated against that transaction object. And against each of these columns that are part of the transaction object, you can associate them to a lookup code also so that whenever that will be used as a source while designing the accounting rules, you can pull the values from those lookup codes.
Accounting Attribute
Accounting attribute is a piece of journal entry. The mapping of the sources to accounting attribute specifies how the Create Accounting process will get its values for each of the piece within the journal entry. For example, the Entered Currency attribute is used to map the source values to the Entered Currency field for the subledger journal entry lines.
You have also got an option to add and update the source assignments to accounting attributes as per your requirement.
Go to the Functional Setup Manager (also known as the Setup and Maintenance work area)
Click on the Task Panel and choose Search
Search for a task called Create Subledger Application Setups in Spreadsheet
When you get to that task page, you will see a button on that page called "Download Setup Template" When you click on that button, a pop-up message will appear to open the spreadsheet template. Open it, and then you can start populating the data.
Once you're done populating the spreadsheet. Validate the information and correct any errors.
If there are no errors left, click on generate ZIP and it would generate a Zip file containing the spreadsheet information.
Go back to the task page and click on Upload setup data and choose the generated Zip file and click OK.
Once upload is complete, you may verify the created subledger application by going to the Manage Subledger Application task.
The first sheet on the template describes the instructions that you should follow to enter the data for registering your source system. The spreadsheet template will always have three worksheets:
Source system
Transaction Information
Line Information
Source system. This is where you will provide all the basic information, such as the name of the source system, event class name, event type information, and so on. This sheet has two sections: The Source System Transaction section and the Transaction Type Section:
In the source system transaction section and transaction type sections, you will provide the following:
Column Name
Max Length
Data Type
NAME
25
Character
SHORT_NAME
25
Character
The information that you provide in the source system transaction section is used for registering the source system name and the event class name, as well as to register the journal source name.
Meanwhile, the information that you provide in the transaction type section is used to represents an event in the lifecycle of a transaction that will always have accounting entries. The entries you've put in the transaction type section is grouped under the event class you've defined from the source system transaction section.
Transaction Information. After naming the source system, event class, and the event types, the next thing we need to figure out is what transaction attributes we are going to bring in from the source system.
The transaction information worksheet lists the sources that are used for setting up accounting rules. The system will create a transaction object using these details and each entry in that transaction object will be converted into a source, that will be used when you're designing the accounting model. You would have to define the below fields:
Column
Name
Max
Length
Remarks
NAME
80
SHORT_NAME
TYPE
Indicates
what Data Type the Source will have
JOURNAL
DISPLAY?
3
indicates
whether this source will be is shown on reports
and in inquiries along with the journal.
Values are Yes/No
The Transaction Information spreadsheet has three mandatory fields:
Transaction Date is, by default, used as the accounting date.
Transaction Number links the transaction information and the line information together. Use a unique transaction number so that the source system segregates each transaction differently.
Ledger Name is the reporting entity for which journal entries are booked in the GL application.
Apart from the three mandatory sources, you can add more sources as required. For Example, it may be relevant fields such as a loan schedule payment date, loan maturity date, loan type, loan amount, etc.
These additional fields are also known as User Transaction Identifiers. You can have up to 10 rows that can be used as user transaction identifiers. They constitute the user-oriented key of the underlying subledger transactions. These identifiers are primarily used in accounting events when you perform inquiries or you run accounting event-specific reports. The transaction data that identifies the transaction varies by subledger application. And accounting event reports and inquiries will display the transaction identifiers and their labels as appropriate for the corresponding event class.
Line Information. This sheet lists the type of transaction information that can have more than one value per transaction. There is a possibility that one transaction may have multiple lines. If that is the case, then you must provide those line level fields in this particular sheet.
The worksheet includes three predefined required sources:
Transaction number field links the transaction header with the line information. For example, if I have one transaction and it has got three lines, we need to ensure that the transaction number that we have given at the header level, the same transaction number should be given for all the lines so that system knows that all these three lines pertains to one header.
Default amount holds the transaction amount values that will be used when generating accounting entries
Default currency holds the entered currency value that you will be using in the accounting process.
Additional line sources can be added if multiple and different values are required for use in the same source attribute. The same details for the Transaction information spreadsheet applies to the Line Information spreadsheet. You must populate the Name, Short Name and Type fields.
The "Chart Of Account Value?" column indicates whether that source can be used to derive an account or not. There is a possibility that you might be using one of the fields to derive the chart of account values. For example, the salesperson name or maybe loan type. Acceptable values for this field is Yes or No and only text type sources can be used in segment rules.
An example of a source that would typically be used to derive general account could be Account, Cost Center, or Company. They could also be predefined values, so rather than using them as a derivation factor, you can directly pick up a field here called account value. So whenever the system will generate the accounting entry, if you have mapped it to this source, system will use that as a default value for the segment values under your chart of accounts.
Verifying and Uploading the Spreadsheet Data
Once the data has been populated into each of the three sheets, you will have to ensure that you have submitted the validation process. To verify whether the data that you have entered is accurate or not, you will need to click the Validation button in the Source System sheet.
If an error is generated, you will receive the error message and the system will also generate a validation report as a separate worksheet. You must open the validation report worksheet to review the errors. Then you must correct the error and validate the content again.
Once there are no more errors, then you can generate the zip file by clicking on the "Generate Zip" button in the Source System sheet and save the zip file. You will also receive a notification that the zip file was created and saved in the same local folder as the download spreadsheet template.
Once the file has been saved, the next step will be to upload the setup zip file. Go back to the application page and in the Create Subledger Application Setups in Spreadsheet task, there is another button available called "Upload Setup File". When you click on that, you will get an option to browse the file from your local machine. Choose the file that you generated and then choose "Select Import".
If errors exists during the upload process, you will be prompted with an error message. You must correct the error in the spreadsheet in the fields that have been notified in the error message box. If there are no errors, you will be able to successfully register the source system along with the underlying components like transaction objects, event models, and so on. The files uploaded will basically create the subledger setups in a single step. You don't have to do anything.
Editing the Uploaded Subledger Setups
Sometimes there is a possibility that you may be interested in overriding the uploaded source system information. In that case, you can re-upload the spreadsheet template for the same source system if you have not created any accounting rules under that source system.
You can download the template again, make changes, and load the data one more time. Once the data has been successfully uploaded, you can go to that particular source system from within the Setup and Maintenance work area and verify whether everything has been loaded successfully or not.
You can also update the uploaded setups from the user interface. For example, You can add new event types if you think that the event types that have been loaded are not enough for your requirement.
Also, if you want to make the changes to the source name the system has created to suit your business requirement, you can edit them so that they are easily understood when configuring accounting rules. It should be a user-friendly name, which every user who is involved in designing your accounting rules should be able to recognize them.
You can also add new sources from the user interface. The download of a new transaction data template will include this newly-added source as well. Then you can also complete the accounting attribute assignment, though when you upload the data, accounting attribute assignment happens automatically.
Post-Upload Process
Once the upload has successfully processed, Transaction objects (including Transaction Attributes) will get created automatically and can now be used to configure accounting rules through the Subledger Accounting user interface. Also, a Journal Source, Process Category and Event Class has also been automatically created using the name of the Source System.
Below is a quick step-by-step video demonstration of Creating Custom Subledger Application Setups in Spreadsheet:
The build phase is where you will actually register the source systems for Accounting Hub Cloud. You have the flexibility to register source systems with the help of predefined spreadsheet templates. The source system is the place where you will get all the information about the transactions that you want to bring into the Accounting Hub.
Before you start bringing the transactions, you must register the source systems and their underlying event models. And for that, you will use the Excel templates to populate the values for the source system name and columns that will be used for registering your transaction objects used to store the transactional data from the source systems.
Underneath the source system, you will establish an event model that will carry your process categories, event classes, and event types. This will also carry all the column details that are required for storing the values at the header-level values and line level values. This means when you use this template, you will specify the entire event model and the other attributes that are required for generating your accounting entries.
When the data is uploaded using that spreadsheet template, it will register a transaction object. A transaction object is a database table which is used to store the header-level data and the line-level data. You will have to analyze what attributes you want to bring from the source system. And you need to have a column for each one of those attributes in your transaction object.
For example, in the source system, you have many important fields like such as customer name, customer number, loan number, loan reference number, sales person, currency amount, etc. To bring this information into Accounting Hub, these fields need to be populated in the rapid implementation spreadsheets. When the data is loaded into the application through the upload mechanism, the system will register a transaction object and build the respective columns. Whatever fields you will specify on your spreadsheet templates, each one of those fields will be considered as the sources. And they will become part of your transaction object.
You can use these sources for the purpose of designing your description rules, account rules. Use those sources when you are defining your journal line rules to identify what is your debit line, what is your credit line as well.
And then you must verify the source system information. When the source system has been created, you will have to figure out the accounting attributes that are associated with those sources or with those objects. And you must figure out the source assignments as well. So that is going to be your first step.
Accounting Hub always works based on a three-model definition. The three models are called the data model, the event model, and the accounting model.
Data Model.The data model will be generated based on the source system registration process. In the spreadsheet template, provide the source system name, the transaction objects and specify the fields that will be used as columns. When you load the spreadsheet into the system, system will establish a data model.
Event Model.Simultaneous with the Data Model creation, the system will also establish an event model. When you provide the information on the spreadsheet template, you will also specify the event class and the respective event types that will be part of your event model. This process of registering source systems will help you in creating a data model and an event model.
Accounting Model.Creating the Accounting Model is the time when you will actually configure your accounting rules. Here, you will manage the information based on the transaction object data that has been created as part of the data model and the event model.
And finally, once your three models are in place, then you can start bringing the transactional data from the source system and upload that into the application either by using the spreadsheet templates or by automating the process using the predefined web services.
How can you Register a Source System?
The spreadsheet integration upload process accelerates the time from implementation and testing to production. It's a faster way of registering your source systems and helps us in registering our source systems by generating the transaction objects to the spreadsheet upload process.
After completing the source system transactional flow analysis, Go to the Setup and Maintenance work area, you will search for a task called Create Subledger Application Setups in Spreadsheet. When you go to that task page, you will get a button on that page called Download Setup Template. When you click on that button, a pop-up message will appear to open the spreadsheet template. Open it, and then you can start populating the data.
Populate the data into the spreadsheet template with the following guide questions to establish your data and event models:
What is the name of the source system?
What is the event class name?
What are the event types that you want to use?
What are the columns that will be used to store the data at the header level?
What are the columns that will be used to store the data at the line level?
Then you must validate the spreadsheet content once the data has been populated in each of those fields. You will generate the zip files. And then you will upload the zip files into the application. And finally, once the process gets over, you will verify whether your source system has been created or not.
Under each Source System, you need to establish your event model. An event model helps you map the transaction types from your source systems. Under each event model, we can then map accounting events which represent the transactions that may have financial significance. For example, issuing a loan and disposing of an asset is a transaction that we book in the source system.
For each one of these transactions, we need to manage and record their accounting entries by submitting the Create Accounting process for the Accounting Hub application. When you define accounting events, you must determine, from a business perspective, which activities or transactions that occur in your source system may create a financial impact. And accordingly, you will have to build an event model.
An Event Model contains three components:
Process category is just a grouping for event classes. For example, you can create a grouping for invoices and payments. Under each of these process categories are event classes and event types defined. The process category's name is taken from the source system name,
Event Class. An event class is used to group the related transaction information and attributes within a source system. An event class is created by using the registered source system name. From the above example, "Loans" is the source system name and will be the event class and process category name, and under that, multiple event types can be defined. Accounting Hub Cloud supports only one event class per source system application. But you can have as many unique event types for segregating your transaction types under that event class.
Event Types are basically represents the transaction types of your source system. In the current example, the event types could be loan chargeoff, loan interest accrual, loan interest accrual reversal, and so on. Events with significantly different fiscal or operational implications are classified into different accounting event types. Accounting definitions in the Accounting Hub Cloud are based on an event class and event type combination. And an event type must be unique within an application.
Whenever you are planning to establish your event model, visualize the hierarchy. You will have a source system. The source system, you will have process categories. Under process categories, you will have an event class. And under an event class, you can have multiple event types. And these event types are actually reflecting your transaction types from the source system.
This article provides an Overview of the Analyze Phase in the Accounting Transformation Implementation in Accounting Hub Cloud.
Analyze and Identify the Transaction Lifecycle of Source Systems
First, the number of custom subledgers to be created should be determined. In our example, we have separate third-party systems for commercial and individual loans, and a billing application. Depending on how your organization uses these third-party systems, we may want to register them as separate subledgers or just one subledger. Below is a quick comparison between the two:
Unified Subledger
Separate Subledgers
Share subledger accounting rules
Provides more security across
applications
Lets you report across all data
easily
less data in each processor,
performance will be much faster
accounting process can be run
simultaneously for different applications
much less likely to contend for
database resources
For example, If the commercial and individual loan systems will be registered as a single, unified subledger, data for processing will be huge and this might impact system performance. On the other hand, this actually saves time, because we can re-utilize the subledger accounting rules. So considering these points, you will have to figure out whether it is a wise decision to go with separate or unified subledgers.
Another point that we have to keep in mind is that, we need to determine what source data is required to create subledger journal entries. You should not bring each and every transaction from the source system into Accounting Hub, rather, only transactions which need to be accounted for. You need to analyze the source systems and determine what transaction types to capture and what transaction types should be considered for accounting purposes.
In the loan system example, we have the following activities in your source system:
loan origination
loan interest approval
loan interest accrual reversals
loan scheduled payments
loan late payments
loan charge-offs
Some of the mentioned transactions will attract accounting entries, and some of them will not. Only the transaction types that needs accounting entries must be established as part of your event model under the source system that you're registering within the Accounting Hub Cloud. These transactions must be distinctly identified and registered as transaction types.
A transaction type and it's associated transaction data typically relates to a single document or transaction in the source system. Transaction types will become accounting events in the Accounting Hub Cloud, and for each of those accounting events, we must generate the accounting entries.
Next point that we need to keep in mind is to figure out how frequent do you want the data to come from the source system. This will depend on the immediacy and volumes of accounting requirements in your company. It should not be scheduled during the day when your database resources are being consumed at a high level.
Also, you will have to evaluate if you will bring each and every individual customer transaction from the source system, or just the summarized activity for a customer that you have managed throughout the day.
Analyze the Accounting, Reporting, Auditing, and Reconciliation Requirements for Transaction Types
This analysis should, at a minimum, answer a couple of questions, such as: Under what condition does each of the subledger journal entry lines get created? Is it upon the loan approval or when the loan has been entered in the source system? You need to identify the event when the transaction should be picked from the source system. What is the line type of each subledger journal entry line, debit or credit? You need to figure out if a transaction will use a debit line or the credit line. For example, the transaction "Loan Origination" will have a debit line for loan receivable account and a credit line for cash or bank account.
What description should be used for the subledger journal entry? This determines the description the subledger journal entry will have for each transaction type. This will be useful for reconciling the subledger journal entry to the source system.
How are the accounts derived for the entry? This determines how are the account segment values for each of the segment in your chart of account will be retrieved. What logic is needed to be applied to identify the account segment values of each transaction type.
What additional information may be useful for reconciling the subledger journal entry to the source system? You would need to identify what additional information needs to be captured that will be useful for reconciling the subledger journal entry to the source system.
Aside from identifying the accounting transactions in your source system, you should also determine which attributes you need to include in journal entry creation. There are 10 attributes, called transaction identifiers, that you can use to capture transactional information from your source systems.
These transaction identifiers can help you easily reconcile journal entries. Specify which fields you want to map against those 10 transaction identifiers to, and when the accounting entries are generated, the system will populate the values of those transaction identifiers at the journal entry level. These transaction identifiers can be utilized for designing either the description rules or the account rules. Example transaction attributes may include:
Amounts (including entered and accounted amounts)
Dates (such as accounting date and transaction date)
Descriptions
Journal Ledger accounts
Customer Information
Transaction Type Information
Product Information
Salesperson
Loan Type
Carefully analyze, plan and model the custom subledger by visualizing the accounted journal entries. and identify the transaction attributes from the source system that can be used for accounting and reporting purposes, and model the source system to meet your business requirement in the Accounting Hub Cloud.
Transaction Identifier Example
From the above loan source system example, the transaction "Loan origination" is the debit line, and Cash is the credit line.
Observe that the Account column shows different values. Analyze whether the entire combination or each of the individual segments will follow a specific rule to retrieve the values. Those values could be based on the transaction attributes that were brought from the source system. This can be achieved with a mechanism called mapping sets.
For example, the value for the Line of Business segment (segment 2) can be based on the salesperson who is tied to that transaction line. Below, If the transaction was tied to Mr John Doe, the Line of Business Segment is 10. Additionally, the cost center segment can be dependent on the loan type. If the loan type is an adjustable rate, the value for the cost center would be "0000" and if the loan type is fixed rate, the cost center value is "2120".
When you have listed all the transaction attributes that are required to obtain the appropriate accounting entries from the Accounting Hub Cloud and visualized all these details, you will be able to retrieve the values for your chart of account segment and map them into the application. And based on that, the journal entry will be created.
Accounting Attributes
Next, we need to figure out, what are the accounting attributes that we need to assign for our source system. So the Create Accounting process basically utilizes the values of the sources assigned to accounting attributes and accounting rules to create subledger journal entries.
Each accounting attribute is associated with a level when you create the subledger journal entries. It could be the header level definition, or it may be the line level definition. Below are the mandatory accounting attributes and source assignments, these must be used whenever you are registering your source systems.
Accounting Attribute
Predefined Source Assignment
Accounting Date
Transaction Date
Distribution Type
Accounting Event Type Code
Entered Amount
Default Amount
Entered Currency Code
Default Currency
First Distribution Identifier
Line Number
Accounting Hub Cloud basically pre-defines transaction dates as accounting date. So whatever is your transaction date, that is identified by Accounting Hub as accounting date. The Create Accounting process will use this to derive the accounting date of the journal entries. There is another option that we have to keep in mind as far as accounting date is concerned, that is called accrual reversal accounting date source. This attribute is relevant to applications that must perform automatic reversal on accrual journal entries at a specified date or period. You can assign application and standard date sources to the accrual reversal accounting date on the Accounting Attribute Assignment page.
The First Distribution Identifier information is equivalent to the line number in the predefined source assignment. This basically links the subledger transaction distributions to their corresponding journal entry lines.
So these are the accounting attributes that we should always keep in mind, and they will always be associated to a predefined source assignment.
