Sources are created by registering your Transaction Objects and clicking the Create and Assign Sources button in the Accounting Event Class Options window (see this article). We call these Standard Sources.
Next to that you can also create Custom Sources under Subledger Accounting Setups > Accounting Methods Builder > Sources > Custom Sources
As the name implies, these are Sources which aren’t standard, so which aren’t inherited directly from the Transaction Objects.
When you define a Custom Source, you enter a PL/SQL function and optionally one or more input parameters. The Custom Source will then be available within the list of Standard Sources. So you can use the Custom Source wherever you like and it will return the output from your PL/SQL function.
Incredibly powerful, isn’t it? Yes, but power often also has a sharp edge...
Let’s say my Transaction Object contains a column Contract Type and a column Product Number, while the business rule is that the combination of contract type and product number determines the product code used for accounting.
To derive this product code value, I make use of a Mapping Set. So I need a combination of two Sources (contract type and product number) to serve as input for my Mapping Set.
The wrong approach:
I can define a Custom Source in which I use the two input parameters, and my PL/SQL function will then return the combination of both Sources into a single string. This Custom Source serves as input for my Mapping Set to derive the product code.
What’s bad about this solution is that when I run Create Accounting, my PL/SQL will be executed for every single accounting entry line that’s generated. This negatively impacts performance.
The right approach:
Instead I should add a separate column to my Transaction Object view in which I join Contract Type and Product Number into a single string. This additional column (i.e. Source) I can then use as direct input for my Mapping Set. The Accounting Program will fetch the values from the Transaction Objects in bulk, which is why this solution outperforms the Custom Sources approach.
Conclusion: never use a Custom Source when implementing FAH (Financials Accounting Hub), as you can simply alter your Transaction Objects to directly include any values you need.
When you’re a regular SLA (Subledger Accounting) customer though, you are not allowed to make changes to the seeded Transaction Objects. Custom Source functionality can then be used in case the seeded Standard Sources are insufficient.
Tip: If you can't find the Custom Source, then the first thing to check is if the Standard Source(s) which are used as input parameter(s) in your Custom Source belong to the same Event Class as the Event Class under which you are trying to use the Custom Source.
Note 790945.1 [Frequently Asked Questions about Custom Sources] contains further information and examples on Custom Sources. But remember: as a FAH customer, you shouldn’t even be using Custom Sources.
|
Comments
Your approach is valid if your application is a custom application. If it is a standard Oracle application (Payables, Receivabales etc.) then you should not amend the tranasaction objects as Oracle owns these and they could (and have) been amended by patches from Oracle.
I recommend that you develop custom sources using a single parameter that is a the unique identifier for an object/table available in a transaction object (either a key or a foreign key).
To improve performance ensure that the PL/SQL caches the unique identifier and the result every time it runs. The PL/SQL should check the UID parameter and if it is still the same as in the cache it should then retreive the value from the cache rather than the database.
I have taken this even further. Where I had several custom sources all using the same unique identifier (e.g. Bill To ID) but returning different atrributes (e.g. Party Type, Sales Person default account etc.) I cache all the return values (one database hit) and each custom source always retrieves from the cache if it can.
I can provide a template for the PL/SQL if would like that.
Nic
Good to see you here! :-)
Agree with your comment. That’s also what I was hinting at when stating regular SLA customers are not allowed to change the seeded Transaction Objects.
Regarding your recommendation: please do feel free to publish an article on here (preferably containing an example), or alternatively you can upload the template on the site. I’m sure it would be appreciated.
Regards,
Sven
It was good to read your blog.
Infact we have a requirement where we need to create a custom source. We are not sucessful in custom source creation.
If you have any custom source example, please share.
My email id is This e-mail address is being protected from spambots. You need JavaScript enabled to view it
- Have you looked at the examples contained in Note 790945.1?
- What / where exactly is it going wrong for you?
Regards,
Sven
I have a requirement to replace segment2 and segment3 of ccid based on item categories and lookup values.
If this fails, I need to not replace segment2 and 3 and let it be as default.
Please let me know if we can handle this
This article is about 2 years old or so but still very good, thanks. BTW - I've noticed, mainly in SLA in Payables, that not all the sources will work if you use them in conditions.
For some reason, Supplier Site Name is ignored when defining a JLT for Invoices (Item Expense).
Do you know a way to determine which source will actually work with the type of transaction without trial and error?
-Scott