Activity Stream

2 days ago
new user registration
Parasuraman Vaidyanathan joined our community! Welcome!

More than a week ago
new download
Kandasamy Nagappan downloaded Aging 4 buckets


new user registration
Kandasamy Nagappan joined our community! Welcome!

new user registration
Zakeer Shaik joined our community! Welcome!

More than 2 weeks ago
new user registration
Narasinga Chennuri joined our community! Welcome!

new download
Marek Skulski downloaded Aging 4 buckets

Create your own workspace - Set an Accounting Methods Builder context
( 2 Votes )
Financials for R12 - Subledger Accounting & FAH
Written by Sven van Leemput   
Monday, 12 January 2009 20:51
Using the AMB (Accounting Methods Builder) context functionality you can create a dedicated work area which allows you to copy over an AAD (Application Accounting Definition) from the default context into your personal context, make changes to this AAD and, when satisfied, copy back the AAD to the default context.

The following is intended as a quick tutorial on how to use the AMB context functionality.

1) Define a new context value under subledger accounting lookup “XLA_AMB_CONTEXT_TYPE”

Define new AMB context

2) Assign the new context value to profile option “SLA: Accounting Methods Builder Context”

SLA:
Accounting Methods Builder Context

Note: to avoid mistakes the tidiest thing to do would be creating a new application responsibility and assigning your context at the responsibility level of this dedicated responsibility. This allows you to quickly switch between contexts just by switching application responsibility. Alternatively, you could of course also choose to switch the profile option back and forth.

Now that you have activated your new context, the Application Accounting Definition and all the underlying components striped with an AMB context will show the context value in their respective windows:

ADR with context

So at all times you can see under which context you are working.

You can now use concurrent requests “Import Application Accounting Definitions” and “Export Application Accounting Definitions” to export your AAD from the default context and import it into your custom context. You can make the wildest changes you can imagine in your custom context because if things go wrong you can always revert back to your default context (kind of like a mini backup). But if you like your experiments and they turn out to be successful you can copy the new AAD from your custom context into the default context.

When exporting an AAD a ldt file is written on your file system, in the destination path specified when submitting the request. The import program then picks up this file. But you can of course pick up the physical file yourself and apply it to other instances just as well. So when you have built a custom AAD (e.g. you have made modifications to a seeded AAD in order to fulfill country x’ statutory requirements) then you should export this AAD and slip it into your consulting briefcase because you might be able to reuse this AAD at your next project.



Comments

avatar chickey
0
 
 
Sven,

It looks like you can't migrate an ADD into a new instance with out doing some setup such as Events and Sources. Is there any documentation on what needs to be set up first in order to import an ADD into a new instance?

Thanks,

-Chris
avatar Sven van Leemput
0
 
 
Hi Chris,
The Subledger Application components (which are not part of the AAD, and therefore not included in the AAD loader) are listed in section 7 of the FAH implementation guide, and can be loaded through fndload.

Regards,
Sven
avatar tim
0
 
 
Hi Sven

Our client is wanting to make use of AAD Loader to migrate accounting rules from one environment to another and also to make use of it as a sort of version and change control.
I can successfully run the exports and, using the overwrite option, imports. We then run query to verify the import was successful and to verify what needs to be deleted from the destination (as the loader does not handle these deletions).
Perhaps you are able to assist me in this, from the documentation, i understand the standard, leapfrog and supersede exports however am having the following issues:
1. When performing a standard export I receive the error: XXX is based on a version earlier than the current version in the destination context. Please indicate if the account derivation rule should leapfrog the current version. Where XXX can be account derivation rules, application accounting definitions, mapping sets etc.
How am I able to get these items to the latest version in order to perform a Standard export? This leads to the next question...
2. When I perform an import using a file created from a Supersede or Leapfrog export my account derivation rule names change. The code remains the same however the name is updated to reflect something such as "(Name) Name" when the original was purely "Name".

Any help would be appreciated or at least a nudge in the rite direction.

Thanks
Tim
Please login to post comments or replies.