Corfu Navision 2016, Data, Development Tips, Dimension, Excel, Functional Tips, How To, Information, Tip & Tricks

How to attach additional 6 Shortcut Dimensions to Dimension Set when copy data to Journal from Excel

 

In my previous post I explained how we can copy data to-and-fro between Excel and Navision. Also we saw the limitation of additional 6 Shortcut Dimensions neither can be exported nor imported back.

Today we will see solution to this limitation, as it is required from several customers and we keep getting request for same. The same reader for whom I have posted my previous post have requested similar need.

If you missed my previous post you can find here : Copying data to-and-fro between Excel & Navision

Let us see how we can get this part working, yes it will require a small customization to get this working. Below I explain the steps we require to achieve this.

My example refers to Table 81 & Page 39. You can do same with other Journals too.

We will Add Custom Fields for these additional 6 Shortcut Dimensions.

 

ExcelToNavJnl-8

Add the Fields and write the above code to OnValidate trigger and set the Property accordingly for all of the 6 Shortcut Dimension Fields.

ExcelToNavJnl-9

Similarly add a piece of code to OnInsert trigger of the Table.

ExcelToNavJnl-10

Add our newly created Fields to Page too.

Now Let us check if it works as expected.

ExcelToNavJnl-11

 

Perform the operation as in previous post, this time add the newly created fields for Dimensions as shown in above screen.

If you missed my previous post you can find here : Copying data to-and-fro between Excel & Navision

Export and Import back by adding value to these additional Dimensions 1 &2 is Global 3-6 is my additional Shortcut Dimensions, 7-8 I have not included as not setup in my database.

After importing back check the Dimensions and you will find due to above customization my all the Shortcut Dimensions are attached to Dimension Set Entry.
ExcelToNavJnl-12

Yes we are done.

I will come up with more information in my upcoming posts. Till then keep exploring and Learning.

 

 

Advertisement
Data Model, Development Tips, Excel, How To, PowerPivot

Set Data Categories for fields in PowerPivot

In order for Power View to dynamically create reports based on underlying data, such as location, fields that contain such data must be properly categorized.

Open the Excel Workbook we created in our earlier post. Create a Power View report

For the Olympics data, let’s specify the categories for a few fields.

  • In Power Pivot, select Hosts. Select the NOC_CountryRegion field. From Advanced -> Reporting Properties -> Data Category: click the arrow and select Country/Region from the list of available data categories, as shown in the following screen.

ExcelData-37

  • Return to Excel, and select the Power View sheet. Expand the Medals table in Power View Fields, and notice that the NOC_CountryRegion field now has a small globe icon beside it. The globe indicates that NOC_CountryRegion contains a geographic location, as shown in the following screen.

ExcelData-38

We’ll use that geographic location in an upcoming post. It’s time to save your work, review what you’ve learned, and then get ready to dive into the next post.

I will come up with more details in my next post. Till then Stay Tuned, Keep Learning & Practicing.

Data Model, Development Tips, Excel, How To, Power View, PowerPivot

Set Table Behaviour in PowerPivot

You can set the default table behaviour, which Power View uses to automatically create report labels for the table.

This becomes useful when you create visualizations from the same table, perhaps for many different reports.

Open the Excel Workbook we created in our earlier post. Create a Power View report

We use default table behaviour in the next few steps, so let’s set it now.

Open Medals Table in Data Model, select Advanced > Reporting Properties > Table Behaviour. A window appears where you can specify table behaviour.
ExcelData-33

  • In the Table Behavior window, the Row Identifier is the column that contains only unique keys and no blank values. This is often the table’s primary key, but not compulsory to be any other field which satisfy this property. You have to select a Row Identifier before making other selections in the window. Select MedalKey as the Row Identifier.
  • In the Keep Unique Rows section, select AthleteID.

Fields you select here have row values that should be unique, and should not be aggregated when creating Pivot Tables or Power View reports.
Note: If you have trouble with reports that don’t aggregate how you want them, make sure that the field you want to aggregate is not selected in the Keep Unique Rows fields.

  • For Default Label, select a key that should be used as a default report label. Select Sport.
  • For Default Image, leave the selection as [No Column Selected], since you haven’t added images yet. The Table Behavior window looks like the following screen.

ExcelData-34

  • On the Power View sheet in Excel, select the table you created in the previous post Set field defaults in PowerPivot
  • From the ribbon, select DESIGN -> Table -> Card.

ExcelData-35

  • The table you created changes into a collection of Cards; the data is the same, but the visualization of the data has changed. The table now looks like the following screen.

ExcelData-36

Notice that the Sport field is larger than the rest, and appears as a heading for each card. That’s because we set Sport as the Default Label in the Table Behavior window when we were in Power Pivot.

I will come up with more details in my upcoming posts. Till then Stay Tuned, Keep Learning & Practicing.

Data Model, Development Tips, Excel, How To, Power View, PowerPivot

Set field defaults in PowerPivot

When you set a default field set for a table, you can simply click that table in Power View, and the default set of fields is automatically added to a new report.

Open the Excel Workbook we created in our earlier post. Create a Power View report

In today’s post, we will learn how to set defaults for our workbook that will save our time when creating reports.

Steps to Create the Default Field Set for a table

  • Select the Medals table in Data View Mode from PowerPivot Manager.
  • From the Advanced tab, select Reporting Properties > Default Field Set. A window appears that lets you specify default fields for tables created using client tools such as Power View.
  • Select Sport, Event, EditionID, Athlete, and Medal in the left pane, and click Add -> to make them the default fields.

ExcelData-31

To see how this works, switch to the Power View sheet in Excel.

  • Click anywhere on the blank report canvas, to make sure you don’t have an existing visualization selected. Your Power View sheet currently only has one visualization, which is the map you created earlier in previous post. Create a Power View report
  • In the Power View Fields list, click the Medals table name. Power View creates a table and automatically adds the five default fields from the Medals table, in the order you specified, as shown in the following screen. Make sure you don’t click on the triangle beside Medals, if you do so the table simply expands, rather than adding a new table with default fields.

ExcelData-32

I will come up with more details on this topic in my upcoming posts. Till then Stay Tuned, Keep Learning and Practicing.

Development Tips, How To

How to: Set .NET Framework Types to Run on the Microsoft Dynamics NAV Windows Client or Microsoft Dynamics NAV Server Computers

Here is the brief description for how to set .NET Framework objects that are instantiated by DotNet variables to target either the Microsoft Dynamics NAV Windows client or Microsoft Dynamics NAV Server.

By default, a type is set to target Microsoft Dynamics NAV Server. However, you can set the type to target the Microsoft Dynamics NAV Windows client.

Setting the .NET Framework Type to Target the Microsoft Dynamics NAV Windows Client

To set a .NET Framework type instance to target the Microsoft Dynamics NAV Windows client, you must complete the following tasks:

  • Set the DotNet variable for the .NET Framework type to target the Microsoft Dynamics NAV Windows client.
  • Copy the .NET Framework assembly to the computer that is running the Microsoft Dynamics NAV Windows client.

You must copy the assembly to each computer that is running the Microsoft Dynamics NAV Windows client. If the assembly is included in the global assembly cache, then you do not have to do this task.

For the Microsoft Dynamics NAV Web client, you cannot implement Microsoft .NET Framework interoperability objects that target the client.

To set the .NET Framework type to target the Microsoft Dynamics NAV Windows client

  • In Object Designer, open the C/AL code of the Microsoft Dynamics NAV object that uses .NET Framework interoperability.
  • Do one of the following steps:
    • For a global variable, on the View menu, choose C/AL Globals.
    • For a local variable, select the trigger that uses the variable, and then on the View menu, choose C/AL Locals.
    • On the Variables tab, select the DotNet variable, and then on the View menu, choose Properties.
    • In the Properties window, set the RunOnClient property to Yes

To copy a .NET Framework assembly to a computer that is running the Microsoft Dynamics NAV Windows client

    • On the computer that is running the Microsoft Dynamics NAV Windows client, copy the.NET Framework assembly to the Add-ins folder of the Microsoft Dynamics NAV Windows client installation.

By default, the path of this folder is C:\Program Files\Microsoft Dynamics NAV\80\RoleTailored Client\Add-ins or C:\Program Files (x86)\Microsoft Dynamics NAV\80\RoleTailored Client\Add-ins.

You can also put assemblies in a subfolder of the Add-ins folder. This can be useful when you have multiple versions of the same assemblies and dependencies.

Setting the .NET Framework Type to Target Microsoft Dynamics NAV Server

To set a .NET Framework type instance to target Microsoft Dynamics NAV Server, you must complete the following tasks:

  • Set the variable for the NET Framework type to target Microsoft Dynamics NAV Server.
  • Copy the .NET Framework assembly to the computer that is running Microsoft Dynamics NAV Server.

If the assembly is included in the global assembly cache of the computer that is running Microsoft Dynamics NAV Server, then you do not have to do this task.

To set the .NET Framework type to target Microsoft Dynamics NAV Server

  • In the development environment, in Object Designer, open the object that uses the .NET Framework variable.
  • Do one of the following steps:
    • For a global variable, on the View menu, choose C/AL Globals.
    • For a local variable, in the C/AL Editor, select the trigger that uses the DotNet variable, and then on the View menu, choose C/AL Locals.
    • On the Variables tab, select the NET Framework variable type, and then on the View menu, choose Properties.
    • In the Properties window, set the RunOnClient property to No

To copy a .NET Framework assembly to the computer that is running Microsoft Dynamics NAV Server

    • On the computer that is running Microsoft Dynamics NAV Server, copy the.NET Framework assembly to the Add-ins folder of the Microsoft Dynamics NAV Server installation folder.

By default, the path of the Microsoft Dynamics NAV Server installation folder is C:\Program Files\Microsoft Dynamics NAV\80\Service\Add-ins.

You can also put assemblies in a subfolder of the Add-ins folder. This can be useful when you have multiple assemblies and dependencies.

If you are working in the development environment, to compile and test Microsoft Dynamics NAV objects, you must also copy the assembly to the Add-ins folder of the Microsoft Dynamics NAV Windows client installation on the computer that is running the development environment. By default, the path of this folder is C:\Program Files\Microsoft Dynamics NAV\80\RoleTailored Client\Add-ins or C:\Program Files (x86)\Microsoft Dynamics NAV\80\RoleTailored Client\Add-ins.

Development Tips

AccessByPermission Property – in Navision 2015

Sets a value for a table field or UI element that determines the permission mask for an object that a user must have to see and access the related page fields or UI element in the client. The UI element will be removed at runtime if the user does not have permissions to a certain object as specified in the Access by Permission window.

AccessByPermission-1
AccessByPermission-2
AccessByPermission-3

Depending on the setting in the UI Elements Removal field in the Microsoft Dynamics NAV Server Administration tool, only user interface (UI) elements on objects in the license or on objects that the user has permissions to will appear in the user interface.

AccessByPermission-4

To make full use of the LicenseFileAndUserPermissions option in the UI Elements Removal field, it is recommended that you assign the special permission set, FOUNDATION, along with the relevant permission sets that define which application objects the user will access.

AccessByPermission-5

The majority of the permission sets that are provided with the CRONUS demonstration database cannot be combined with the FOUNDATION permission set to fully use the UI Elements Removal feature. You must first create or edit the relevant permission sets to avoid that the user is blocked from performing the involved tasks. You must first create or edit the relevant permission sets to avoid that the user is blocked from performing the involved tasks.

If you only use the LicenseFile option in the UI Elements Removal field, then you do not have to edit any permission sets as they will not affect which UI elements are removed.

To specify when UI elements are removed
  1. Open the Microsoft Dynamics NAV Server Administration
  2. In the UI Elements Removal field, choose the relevant option as described in the following table.
Option Description
None All UI elements are displayed, even if the license file does not include the related object and the user does not have permissions to the related object.
LicenseFile A UI element is removed if the related object is not included in the license file.
LicenseFileAndUserPermissions A UI element is removed if the related object is not included in the license file and the user does not have permissions to the object as defined in the AccessByPermission property for the related UI element.

By default, this option is selected.

AccessByPermission-6

When you configure user interfaces in Microsoft Dynamics NAV, you should make sure that the UI Elements Removal field is set to its default, LicenseFileAndUserPermissions, so that you only see the relevant UI elements in the Customize window.

When you develop in Microsoft Dynamics NAV, you should make sure that the UI Elements Removal field is set to its default, None, to make sure that all UI elements are visible when you review your development in the UI.

All types of UI elements will be removed if they relate to objects that are not included in the license or the user does not have the required permission to the objects:

  • Fields
  • Actions
  • Page parts

UI elements that are directly related to an object through the TableRelation or the CalcFormula property can be removed automatically according to the license file and/or user permissions.

For UI elements that are not directly related to an object, you can use the AccessByPermission property to remove the element according to the user’s permission to a related object

All types of UI elements will be removed if they relate to an object to which the user does not have the required permissions:

Fields on pages, including FactBoxes

Actions on pages, including toolbars and navigation panes

Page parts, such as Lines FastTabs

Note

To use this property, the UI Elements Removal field in the Microsoft Dynamics NAV Server Administration tool must be set to LicenseFile or LicenseFileAndUserPermissions.

This Property Applies To

Fields in tables (affecting all related fields on pages)

Fields on pages

Actions on pages

MenuSuite items

Page parts, such as a Lines FastTab

Property Value

When you choose the AssistEdit button, the Access By Permission window opens. Fill the fields as described in the following table.

Field Description
Object Type Specify the type of object to which permission is required to display the UI element.
Object ID Specify the object to which permission is required to display the UI element.
Read Specify if Read permission is required to display the UI element.
or Insert Specify if Insert permission is required to display the UI element.
or Modify Specify if Modify permission is required to display the UI element.
or Delete Specify if Delete permission is required to display the UI element.
or Execute Specify if Execute permission is required to display the UI element.

AccessByPermission-7

Note

If multiple permissions are selected, then one or the other applies.

Example: Remove the Unit Price field if the user does not have permission to the Sales Price table

Open table 27, Item Card, with the Table Designer.

View the properties of field 18, Unit Price.

For the AccessByPermission property, choose the AssistEdit button in the Value field.

In the Access By Permission window, fill the fields as described in the following table.

Field Description
Object Type TableData
Object ID Sales Price
Read Select
Insert Select
Modify Leave blank
Delete Leave blank
Execute Leave blank

Close the Access By Permission window and save the changes on table 27.

All instances of the Unit Price field on pages are now removed if the user does have Read or Insert permission to the Sales Price table.

AccessByPermission-8

Important

If you defined the property for a table field, then all instances of the field on pages are removed. To override the property on an individual page field, delete the permission value after the = sign in the Value field. Do NOT delete the whole string as that will be replicated on the property of the table field.

Note

To use the LicenseFileAndUserPermissions option in the UI Elements Removal field, you must assign the special FOUNDATION permission set to the user along with the relevant application permission sets that define which application objects the user will access. Unlike the BASIC permission set, the FOUNDATION permission set only grants access to application setup and system tables and requires that other assigned permission sets define which specific application objects can be accessed.

Not all of the 167 default permission sets that are provided with Microsoft Dynamics NAV are ready to support the FOUNDATION permission set to remove UI elements according to user permissions. You must therefore edit the relevant permission sets as explained in the following procedures.

To experience how UI elements are removed for a user performing the task to create and edit a new customer, you can create a sample user interface based on default permission sets provided with Microsoft Dynamics NAV.

Special Permission Sets

The following permission sets have special definitions that you should be aware of as you implement permissions and security for Microsoft Dynamics NAV users.

Permission set Definition
SUPER Can read, use, update, and delete all data and all application objects in the scope of your license. Microsoft Dynamics NAV requires that at least one user be assigned this permission set in each database.

You cannot modify permissions for the SUPER permission set.

SUPER (DATA) Can read, use, update, and delete all data. You typically assign this permission set to an accounting manager who needs to work with all data but does not need to change Microsoft Dynamics NAV.

This permission set does not give access to the Object Designer.

SECURITY Can create new users and assign them the same permission sets. Must be able to access the User, User Property, Permission Set, and Access Control tables.

For example, you can create a SECURITY permission set that includes the four required tables and any additional permissions that you want to include. You can then assign this permission set to a user who is a department administrator. This user can then administer permissions for other users in their department.

Only a user who has the SUPER permission set can create and modify a SECURITY permission set. Users who have this permission set can assign the same permissions to other users, but they cannot assign themselves the SUPER permission set.

BASIC Grants Read access to almost all application tables and all system tables.

The main purpose of this permission set is to enable the client to open and show all pages.

When you create a new database, you must import the BASIC permission set from an XML file.

FOUNDATION A prerequisite for all other permission sets. The FOUNDATION permission set grants access to system tables and application setup tables that are required for most application features to work.

Note

This permission set is recommended when using the UI Elements Removal feature to automatically remove UI elements according to user permissions.