Company size report in Dynamics 365

In older versions of Dynamics AX we had a report showing us the size of a company. It wasn’t pretty and it wasn’t fast. But it was nice to have though.

In Dynamics 365 for Operations it’s no longer in the menus; but don’t worry, it’s still there. All you need to do is to utilize how you can access menu items by building your own URLs:

https://<your-environment>aos.cloudax.dynamics.com/?cmp=<company-id>&mi=Output%3ASysCompanySize

That should give you the report:Size report

 

Advertisements

Button grids and controls out of boundaries in the screen layout

When editing screen layouts you drag and drop controls in the (soon to be overhauled by Microsoft) editor. If you end up dragging a bit too aggressively you can actually throw the control off the grid and the visible area.

The funny part is that it’s not easily pulled back in since the editor doesn’t allow you to traverse through the active controls.

Here’s a quick description and fix. First I’ve created a simple layout with a single control:

Simple layout.PNG

Then I drag it outside the black area. Notice, that it is no longer visible but not available on the list to the left:

Dragged outside border.PNG

To get it back export the layout to an XML file:

Export layout.PNG

Edit the file in notepad. In this case the file is pretty simple. In real life you’ll be pretty pleased with the search function in Notepad.

The thing to notice here is that the left value has gone negative, since I dragged my control too much to the left:

Negative left.PNG

Change the value to a positive figure and save the document:

Fixed.PNG

Import the layout in the designer

Import layout.PNG

And now the control is visible again:

Button grid is back.PNG

If you end up with controls out of boundaries, you could close the editor without saving to prevent getting in the above situation.

Retail operations and user rights

In this post I will do a quick explanation of the user rights setup of the retail POS operations.

Operations is referring to the different actions available in the POS. They are listed in Retail and commerce/Channel setup/POS setup/POS/Operations. Each operation has the following information:

Operation id and Operation name identifies the operation.

Permission ID 1 and Permission ID 2: These permissions can be a required level of rights needed for the operation.

Check user access: If not set the operation does not require the user to have the required access.

User operation: If not set you cannot create a button on the POS for that operation. Notice that the form by default has a filter on that field requiring the field to be set true.

Confused? Let’s have a look at an example.

We are going to focus on the void product operation using worker 000120 (Andrew Lan) and 000110 (Dan Park). Dan is allowed to void transactions:

danp-pos-permissions

Andrew is not:

andrewl-pos-permissions

Scenario 1:

Check user rights = true

Permission IDs = 0

Andrew tries to do a void:

void-transaction-not-allowed

Since Andrew has limited rights he cannot void the transaction.

 

Scenario 2:

Check user rights = false

Permission IDs = 0

In this case the POS doesn’t care what about permissions when voiding transactions so it allows Andrew to void:

void-transaction-prompt

 

Scenario 3

Check user rights = false

Permission IDs = 1001 (Allow transaction voiding)

Like in scenario 2 the POS still doesn’t care about user rights so it allows Andrew to void the transaction:

void-transaction-prompt

Scenario 4

Check user rights = true

Permission IDs = 1001 (Allow transaction voiding)

The user rights are validated again and since Andrew isn’t allowed voiding he can’t do the void. But now we have added the feature that Andrew can call in his manager or anyone else with enough rights to allow transaction voiding:

cannot-void

In this case he gets Dan to type in his id and password and this opens up for voiding the transaction:

void-transaction-prompt

 

Running the CRT samples on AX7

The RetailSDK delivered with AX7 includes a lot of great sample code making it easier to get things rolling when learning how to customise the solution.

One of the sample projects is the CommerceRuntimeSamples. Before you are able to run it you need to do a couple of tweaks though. If not it will crash and burn with error messages that do point you in the right direction on how to fix it. This blog post is made to safe you some time and getting it fixed without having to go troubleshooting.

The first error that pops up is this one:

operatinguniterror

A configuration error in the Microsoft.Dynamics.Commerce.Runtime.dll. The reason is that it cannot find the right Operation Unit Id. It is specified in the commerceruntime.config and all you have to do is put in the operating id of the channel you would like to work with. In this case I use Houston, which has the id 039:

operating-unit

Next is this error:

storageerror

A storage exception in the same dll and same piece of code. This time we have to look in the app.config file. In here we have a list of connection strings that all point at database names as they appeared in AX 2012 Retail. In AX7 demo servers all data for all channels is in the AxDB database so the fix is to change the database names in the connection strings to AxDB:

catalog-db-name

Now you are able to run the samples and start debugging to learn.

debugactive