When setting up data access sets (DAS) and business units (BU) in the Financials module Functional Setup Manager (FSM), the name used for each can affect performance more than one may realize. Not only is the name chosen for each important for users to be able to identify which BU or DAS to use for transactions and such, but it is also important because some roles and duties can be affected. Using a naming convention for each client is best practice, but it is also vital to know that these two setups cannot share the same name.
The IT Leader's Guide to Multicloud Readiness
This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.
This is important for two reasons:
- There are some cases where the user must select either a data access set OR a business unit, and if they have the same name it can be impossible for the user to know which one to use.
- In both R10 and R11, my team has caught that some roles were affected. The best example I can give is when a user goes to create a transaction in AR, the LOV for the business unit, transaction source, transaction type, etc. are missing – no data is available at all.
If your team has already configured a module with both the DAS and BU of the same name, don’t worry, there is a work-around. You don’t want to change the name of either if transactions have already been entered into the instance. This will cause mapping issues and errors that can cause more of a mess than one could imagine. Instead, you want to play around with the roles and mapping of the roles to solve the problem.
In regard to the example I gave of AR transactions not functioning, there is a simple fix, which I will go into more detail about next week. The main takeaway here is to not use the same naming convention for the business units and the data access sets to avoid unnecessary transaction issues. Hope this helps with future configurations!