Recently I was asked why the items on an order were being assigned a department of 75 when the default department dimension code assigned to them on the item card was 02. This was occurring because the vendor on the order had a default dimension code of 75.

Vendor Card/Dimensions:

Item Card/Dimensions:

Purchase order – header and lines both have been assigned Department 75:

Setting up Default Dimension Priorities can ensure that the items on purchase orders will always be assigned with the department code assigned on the item card.

To do this, search for “Dimension Priorities” and set the Source Code field to the desired Source Code (in this case, “PURCHASES”). Now enter the table IDs for Items (27) and Vendors (23) and assign a priority to each. The lower priority will take precedence, so think of it more as a sequence. If you do not know the table numbers, you can drill down and search by the table names (Items, Vendors, etc.).

Now when a purchase order is created, the header still has the vendor’s assigned department dimension code, but the item has the department that belongs to the item.

To learn more or have any questions answered, please reach out to me or post your questions and comments on the Dynamics Communities discussion board: https://dynamicscommunities.com/community/groups/d365ugbc/forum/

The link between the component and the routing operation ensures that component inventory is only required when the operation is scheduled to start, rather than at the beginning of the production order. This is useful in complex production processes where components are needed at different stages.

The benefits of using routing link codes:

1. Efficient Inventory Management - Reduction of inventory on hand, lowering inventory holding costs

2. Improved Production Scheduling – Components can be scheduled based on when they are needed.

3. Flexibility – If there are changes in the production process or schedule, it is easier to adjust component delivery schedules based on when components will be needed.

4. Traceability – Provides clear traceability of component through the production process, making it easier to manage and troubleshoot production issues.

How to set up Routing Link Codes:

1. Define Routing Link Codes

   1. Search “Routing Links”

   2. Enter new Codes and enter a description for each:

2. Update Routing

   1. Enter a valid routing link code for each operation in your production routing as needed. These codes will later be used to link production components to the routing operations.

      

3. Update Production BOM

   1. Enter a valid routing code for each component as needed. This will complete the link of components to specific routing operations.

      

4. Review the routing link code setups above and ensure that the production routing and BOM both have a certified status.

5. Now when creating a production order, you can review component due dates to see the effect of using routing link codes since BC will automatically link components to operations

Example:

Production order component due dates when NOT using routing link codes – all components have the same due date:

Production order component due dates when using routing link codes – component due dates vary based on when each component is needed:

In this example, all my components are backflushed, therefore, when I go to the Production Journal, I will only see output lines and there is one output line for each routing operation. (The same would be true if using the Output Journal)

I can post output for each operation individually and consumption will occur only for components linked to the operation posted.

When I post output only against operation 10, only components 1110 and 1120 are consumed since they are the only components linked to operation 10.

Here you can see that only the components linked to operation 10 have been consumed.

To learn more or have any questions answered, please reach out to me or post your questions and comments on the Dynamics Communities discussion board: https://dynamicscommunities.com/community/groups/d365ugbc/forum/

You can certainly use effective permissions to check user by user. In the image below, you can see that this user can insert (create), modify, and delete items, customers, vendors, and G/L Accounts (I have set up a filter for these specific tables in this example).

If you know which permission set(s) allow users to perform a specific function, then you can use the Permission Set by User lookup. Search Users then in the ribbon. Now from the Users page select Related > Permissions > Permission Set by User.

A way to get a definitive list of everyone who can create a master record in BC, is to run the permissions and access pages. You will need to know some of the technical information like the following:

Master Record Tables: (there are other tables you can query as necessary)

Table # Table

15 G/L Account

18 Customer

23 Vendor

27 Item

Permissions Tables (*Note: I put commas in the table numbers for readability!)

2,000,000,004 Permission Sets (contains out-of-the-box permission sets)

2,000,000,005 Permissions (contains out-of-the-box permissions)

2,000,000,165 Tenant Permission Sets (contains only your custom permission sets)

2,000,000,166 Tenant Permissions (contains custom permissions)

9002 User Groups

2,000,000,053 Access Control (lists permissions assigned each user)

The next thing you need to know is how to run an object in Business Central or for our purpose, how to run a table object. To run a table object in Business Central, first go to your BC role center page. Now look at the URL (web address) in the address bar of your web browser. It should look something like this:

https://businesscentral.dynamics.com/?company=CRONUS%20USA%2C%20Inc.&dc=0

Notice that the URL contains your BC company name and ends in &dc=0.

If we change the &dc=0 to &table=2000000005, we will run the permissions page (or &table=2000000166 for your tenant (custom) permissions).

https://businesscentral.dynamics.com/?company=CRONUS%20USA%2C%20Inc.&table=2000000005

With the above information and the power of filtering, we are set to learn who can do that.

Suppose we need to know who has permission to create new items. We would perform the following tasks to get our answer:

First run table 2000000005 (Permissions) or table 2000000166 (Tenant Permissions) if you are using custom permissions and filter by:

Object Type = TableData

Object ID = 27 (Item)

Insert = Yes

(**Note: If you do not used out-of-the-box permissions sets and instead use custom permission sets with a specific prefix – something I always recommend – then you can also add a filter for Role ID. In my case, our custom permission sets all begin with a prefix of MFC, so I can filter by ROLE ID= MFC*)

Your result will be a list of all permissions sets that allow INSERT permission for Table 27 (Items). Hopefully, this list only contains one or two permission sets. (My result below has two permission sets, but I know that the first one is obsolete and not assigned to anyone).

Now for each active permission set that we identified (above), we can run the Access Control table (2000000053) and filter by the permission set to see the users who have it assigned.

In the image below, I set a filter for my permission set (ROLE ID = MFC-ITEM CREATE) and my Company Name (MFC-US) since I have a multi-company environment. As a result, I can see a list of ten users who can create new items.

This is a great way to do security reviews or answer questions that come up during an audit. If you know of any other ways to identify who can do that in BC/NAV, please post them to the DynamicsCommunities.com Business Central discussion board.