If you are interested in learning more about planning organizational hierarchy with Microsoft Dynamics 365 for Finance, contact us here to find out how we can help you grow your business. You can also email us at info@loganconsulting.com or call (312) 345-8817.
Planning Organizational Hierarchy for Pharmaceutical Companies with Dynamics 365 Finance
Posted on: July 6, 2022 | By: Guy Logan | Microsoft Dynamics AX/365, Microsoft Dynamics Manufacturing
Within a pharmaceutical company, a team of scientists, technicians, researchers, as well as business management executives, lawyers, engineers, and various other professions work together. All the jobs and departments are responsible for the success of the organization. With a variety of different roles collaborating under a single roof, a strong organizational structure is imperative to ensure that the pharmaceutical company runs smoothly. With Microsoft Dynamics 365, planning organizational hierarchy is easy. Continue reading this blog to get an overview of how to plan the organizational hierarchy using Dynamics 365 for Finance.
In Microsoft Dynamics 365, internal organizations can be defined by the following types: legal entities, operating units, and teams.
Decide whether to model internal organizations as legal entities or operating units
You must have at least one legal entity to represent your business. A legal entity can enter legal contracts and is required to prepare financial statements that report on its performance.
Legal entities can be used for transactional business or for consolidation. This means that a legal entity in finance and supply chain management does not necessarily represent a real entity in your business. Internal organizations in your business, such as regional offices, can be represented as additional legal entities, or as operating units of the main legal entity. An operating unit is not required to be a legally defined organization. Operating units are used to control economic resources and operational processes in the business.
Understanding how organizational status affects functionalities in D365
Now we will discuss how some functionalities will work differently depending on whether the organization is a legal entity or an operating unit:
Master data
If the organization is modeled as a legal entity
Some master data, such as customers, payment terms, tax authorities, and site-specific stock ordering, must be set up for each legal entity. Some master data, such as users, products, and most human resources data, is shared among all legal entities.
If the organization is modeled as an operating unit
Master data is shared among operating units.
Module parameters
If the organization is modeled as a legal entity
Parameters for modules, such as Accounts receivable parameters, Accounts payable parameters, and Cash and bank management parameters, must be set per legal entity. Because the module setup for legal entities is separate, each subsidiary can comply with local statutory requirements and business practices. For example, a professional services legal entity and a manufacturing legal entity can have different module parameters even though they report to the same parent company.
If the organization is modeled as an operating unit
Module parameters are shared among operating units.
Data security
If the organization is modeled as a legal entity
Most data is automatically secured by company ID. A company ID is a unique identifier for the data that is associated with a legal entity. A company can be associated with only one legal entity, and a legal entity can be associated with only one company. Users can access data only for the companies that they have access to. You do not need to customize to secure data by company ID.
If the organization is modeled as an operating unit
Data can be secured per operating unit by creating customized data security policies. Data security policies are used to limit access to data. For example, assume that a user is allowed to create purchase orders only in a particular operating unit. Data security policies can be created to prevent the user from accessing purchase order data from any other operating unit. The volume of transactions and the number of security policies can affect performance. When you design security policies, keep performance in mind.
Ledgers
If the organization is modeled as a legal entity
Each legal entity requires a ledger that provides a chart of accounts, accounting currency, reporting currency, and fiscal calendar. A balance sheet can be created only for a legal entity. Main accounts, dimensions, account structures, charts of accounts, and account rules can be used by more than one legal entity.
If the organization is modeled as an operating unit
An operating unit can’t have its own ledger information. If your internal organizations do not require unique ledgers, you can model them as operating units. Ledger information will be set up for the parent legal entity in the hierarchy. Income statements can be created for operating units within a legal entity or for the parent legal entity.
Fiscal calendars
If the organization is modeled as a legal entity
Each legal entity has its own fiscal calendar. If your internal organizations use different fiscal years and fiscal calendars, you must model the organizations as legal entities.
If the organization is modeled as an operating unit
Operating units must share a fiscal calendar. If your internal organizations can use the same fiscal years and fiscal calendars, you can model the organizations as operating units.
If your company needs more help with establishing whether your organization is a legal entity or an operating unit, and how that affects certain functionalities in Dynamics 365, let Logan Consulting help you with that.
Best practices for modeling organizations and hierarchies
Consider the following best practices when you implement an organization hierarchy:
- Create a department to model the intersection between a legal entity and a business unit. You can then roll up data from a department to a legal entity for statutory reporting, and from a department to a business unit for internal reporting. Departments can serve as profit centers. If you use departments, you do not have to use legal entities and business units as dimensions in the account structure. You can use just departments as a dimension. However, you must use both cost centers and departments as dimensions in the account structure if cost centers are used only as cost accumulators, and departments are used for revenue recognition.
- Model multiple hierarchies for operating units if you have complex requirements for reporting profit and loss.
- In a single legal entity, do not model multiple hierarchies for the same hierarchy purpose.
- Do not create a hierarchy for every purpose. Usually, you can use one hierarchy for multiple purposes. For example, one hierarchy of operating units can be assigned to all policy-related purposes.
- Create balanced hierarchies. In a hierarchy, all nodes that are the same distance from the root node are defined as a level. In a balanced hierarchy, only one type of operating unit can occur at each level, and the distance from the root node to each level is consistent. If there are intermediate levels between a department and a legal entity or a business unit, placeholder organizations may be required to create a balanced hierarchy.
- Do not model a separate hierarchy of operating units if the structure for legal entities is also your operating structure. A mixed hierarchy of legal entities and operating units may serve both purposes.
- Before you model major restructuring scenarios, use the hierarchy’s effective dates to perform an impact analysis and a validation test.
- Use draft mode to change a hierarchy before you publish a new version in a production environment.
- Limit the number of people who have permissions to add or remove organizations from a hierarchy in a production environment. A smaller number reduces the chance that costly mistakes can occur and corrections must be made.