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”

2) Assign the new context value to profile option “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:

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.