Sasha Nazarov's Remarks

Relational operator 'like'

2008-08-20T14:53:00Z

After having 5+ years of X++ experience, I finally realized that the relational operator 'like' might equally well be used outside of select-statements, just like this:

static void testLike(Args _args)

{

str someString;

;

someString = "Johnny";

if (someString like "Joh?ny" || someString like "*ny")

{

info("Dammit, I should have known this before!");

}

It looks very much like I don't need Global::strStartsWith() and Global::strEndsWith() methods anymore...

QuickSort

2008-05-20T14:54:00Z

I have just written a simple class that implements QuickSort algorithm and allows sorting of some "keys" by their "values".

And this is how it may be used:

static void exampleQuickSort(Args _args)

{

QuickSort quickSort;

ListEnumerator itemEnumerator;

str itemId;

Qty qty;

;

quickSort = QuickSort::construct(Types::String, Types::Real);

quickSort.add('Item1', 10.00);

quickSort.add('Item2', 12.00);

quickSort.add('Item3', 9.00);

itemEnumerator = quickSort.getEnumerator();

while (itemEnumerator.moveNext())

{

[itemId, qty] = itemEnumerator.current();

print itemId, ' ', qty;

}

pause;

}

The output will look like this:

Item3 9,00
Item1 10,00
Item2 12,00

You may find the class in the attachment.

By the way...

2008-05-02T10:32:00Z

...the class that I mentioned in my previous post has been implemented in Dynamics AX 2009 as SysFormEnumComboBox.

Be aware, that Vanya Kashperuk has published another version of this class, valid for both 4.0 and 2009.

How to exclude some enum values from a combobox?

2007-10-04T15:57:00Z

Imagine a combobox based on an enum. By default it contains a list of items that correspond to the values of the enum.

Quite often people wonder whether there is a simple way to limit this list to a set of allowed values. Maybe there is a solution posted somewhere in the net - please let me know if you met one. As I has not found anything like that, I propose the following.

1. Create a class, named, say, SysCustomizedEnumComboBox. In the class declaration, write:

class SysCustomizedEnumComboBox

{

FormRun formRun;

int comboBoxControlId;

EnumId enumId;

Set allowedEnumValuesSet;

Map enumValue2ComboBoxItemMap;

SysDictEnum sysDictEnum;

}

2. Create parm-methods for each of the first 4 variables, and a constructor method without input parameters.

3. Now, create init() method (thanks to Palle Agermark who proposed a way to build comboboxes at run-time):

protected void init()

{

#define.List(1)

FormComboBoxControl formComboBoxControl;

SetEnumerator allowedEnumValueEnumerator;

int comboBoxItemNumber;

int allowedEnumValue;

;

sysDictEnum = new SysDictEnum(enumId);

formComboBoxControl = formRun.form().design().control(comboBoxControlId);

formComboBoxControl.enumType(0); // don't assign any enum type

formComboBoxControl.label(sysDictEnum.label());

formComboBoxControl.helpText(sysDictEnum.help());

formComboBoxControl.comboType(#List);

formComboBoxControl.items(allowedEnumValuesSet.elements());

enumValue2ComboBoxItemMap = new Map(Types::Integer, Types::Integer);

comboBoxItemNumber = 1;

allowedEnumValueEnumerator = allowedEnumValuesSet.getEnumerator();

while (allowedEnumValueEnumerator.moveNext())

{

allowedEnumValue = allowedEnumValueEnumerator.current();

formComboBoxControl.item(comboBoxItemNumber);

formComboBoxControl.text(sysDictEnum.value2Name(allowedEnumValue));

enumValue2ComboBoxItemMap.insert(allowedEnumValue, comboBoxItemNumber);

comboBoxItemNumber++;

}

4. Create a method that will construct the class and initialize it:

public static SysCustomizedEnumComboBox newParameters(

FormRun _formRun,

int _comboBoxControlId,

EnumId _enumId,

Set _allowedEnumValuesSet)

{

SysCustomizedEnumComboBox sysCustomizedEnumComboBox =

SysCustomizedEnumComboBox::construct();

;

sysCustomizedEnumComboBox.parmFormRun(_formRun);

sysCustomizedEnumComboBox.parmComboBoxControlId(_comboBoxControlId);

sysCustomizedEnumComboBox.parmEnumId(_enumId);

sysCustomizedEnumComboBox.parmAllowedEnumValuesSet(_allowedEnumValuesSet);

sysCustomizedEnumComboBox.init();

return sysCustomizedEnumComboBox;

}

5. And finally, add a couple of methods that will manipulate the combobox:

public void select(int _enumValue)

{

FormComboBoxControl formComboBoxControl;

;

if (!enumValue2ComboBoxItemMap.exists(_enumValue))

throw error(Error::wrongUseOfFunction(funcName()));

formComboBoxControl = formRun.control(comboBoxControlId);

formComboBoxControl.selection(enumValue2ComboBoxItemMap.lookup(_enumValue) - 1);

}

public int selection()

{

FormComboBoxControl formComboBoxControl;

int ret;

;

formComboBoxControl = formRun.control(comboBoxControlId);

ret = sysDictEnum.name2Value(

formComboBoxControl.getText(formComboBoxControl.selection()));

return ret;

}

6. That's it.

Now, you may use the class in a form. For example, you have a form named ReserveTickets. It is used for booking airplain tickets for employees. There are 2 classes that represent employees and managers, and Manager class extends Employee. The booking form may be called by either of the classes. Depending on what class is the caller, the types of the tickets are different, so that employees may book only economy seats, while managers - economy and business seats. Let's say we have an enum SeatType representing both seat types.

So, first of all we have to add a method to Employee class, and override it in the sub-class:

// Employee class method

public Set allowedSeatTypeValuesSet()

{

Set allowedSeatTypeValuesSet;

;

allowedSeatTypeValuesSet = new Set(Types::Enum);

allowedSeatTypeValuesSet.add(SeatType::Economy);

return allowedSeatTypeValuesSet;

}

// Manager class method

public Set allowedSeatTypeValuesSet()

{

Set allowedSeatTypeValuesSet;

;

allowedSeatTypeValuesSet = super();

allowedSeatTypeValuesSet.add(SeatType::Business);

return allowedSeatTypeValuesSet;

}

And finally, let's correct the form ReserveTickets (assuming that it has a combobox named SeatTypeComboBox). Declare sysCustomizedEnumComboBox member-variable in the form class declaration. Then override init() method of the form as follows:

public void init()

{

Employee caller = this.args().caller();

;

sysCustomizedEnumComboBox = SysCustomizedEnumComboBox::newParameters(

element,

control::SeatTypeComboBox,

enumNum(SeatType),

caller.allowedSeatTypeValuesSet());

super();

}

Done. From now on, whenever this form is called by Employee class - only economy tickets will be selectable, and when called by Manager - then both economy and business tickets will.

We don't actually use select() and selection() methods of SysCustomizedEnumComboBox in this form example. These methods would become handy if there was another class behind the form, and the form was used as a user interface for this class member-variable SeatType. I don't provide the example here, but I know - you understand the concept.

Looking for help documentation

2007-06-21T15:51:00Z

There is a simple way to programmatically fetch help documentation for system functions based on what text is stored in the xpo-files.
If you run this:
-----------------------------------------------
static void getSystemDocumentation_Job(Args _args)
{
;
info(Web::stripHTML(TreeNode::findNode(@"\System Documentation\Functions\abs").AOTgetSource(), true, true));
}
-----------------------------------------------
then an infolog will appear:
-----------------------------------------------
Information:

Abs
[HEADER]

Returns the absolute value of arg.

Examples
Abs(-100.0) returns the value '100.0'.

Abs(30.56) returns the value '30.56'.
static void Job_Examples_22885_1_abs(Args _args)
{
real r1;
real r2;
;

r1 = abs(-3.14);
r2 = abs(3.14);
if (r1 == r2)
{
print "abs of values are the same";
pause;
}
}

-----------------------------------------------

Unfortunately, special symbols like ‘>’ are converted to something like ‘&lt’, but still this is a way to understand what the kernel function does.

The way to read weighty books

2007-06-04T13:37:00Z

I am a lazy guy. And some time ago it was very difficult for me to brace up and read a good thick technical book from cover to cover.
For example, "Code Complete, 2nd Edition" is 960 pages thick. I knew, that this one was a "must read" for every developer. I had been trying to read it for a year or something. But its thickness was awesome. And each time I thought "well, I'll better continue tomorrow....". And the "tomorrow" came rather seldom.

But the day has come, when I found a way to fix this problem - Microsoft Office Project. So, I took "Code Complete" and split the remaining 660 pages into 33 groups of 20 pages each, and then I assigned a business day to each of the groups. According to the plan, I should have read the rest of the book in about 1,5 months. The last day has become tangible - I knew the exact date, when the book would be read. More then that, I promised myself, that I would burn a 100 DKK bill (about 20 USD) whenever I spend an evening without reading the planned 20 pages. The plan was printed and put onto the wall. I crossed one small blue "task" rectangle with a green marker every time I was done with another bunch of pages.

And, you know, I have burnt no money. Instead, the Day has come, when I read the last sentense and closed the book. I can't describe what I felt at the moment. It was a mixture of two feelings - impression by the book and impression by the fact. The plan has done its job, and I have become a better developer!

Several other books have been read since then, mostly recommended by Steve McConnell for a developer "reading plan". Each book was split and planned. 20 pages a day. Very little daily effort, but huge yearly improvement. It is not a big deal to read 2 books in parallel, 20+20 pages a day, but one book is still fine.

The funny thing is, that my wife has also decided to use this approach while preparing for her last Danish exam: she is reading 2 pages of grammar and processes 2 pages of exercises, every day. She did not promise to herself that she would burn anything if the plan is not followed, still she follows it since the beginning. Our plans hang on the wall - side by side.

There is definitely a sort of magic in a printed Gannt chart. No doubt about that. Try it out.

Import of dimension set rules

2007-03-05T22:05:00Z

A couple of days ago I had a question. One guy had to generate dimension set rules for ledger accounts, based on information from an Excel file. The file contained 3 columns: the first one for ledger accounts, the second one for values of the first dimension (say, Departments), and the third column for values of the second dimension (say, Cost Centers):

'10510', '49', '0'
'10511', '49', '3'
'10600', '49', '0'
'10600', '49', '6'
'10600', '50', '0'
'10651', '49', '0'
'10651', '50', '0'
'10800', '49', '0'
'10811', '49', '0'
'10900', '49', '0'

and so on. As can be seen from the sample:

only department 49 and cost center 0 are valid for the account 10510;
only departments 49 and 50 are valid for 10600, while cost centers 0 and 6 are valid for department 49, and cost center 0 is valid for department 50;
the accounts 10800, 10811 and 10900 have department 49 and cost center 0 as the only valid values

etc.

I have written a sample job that generates dimension set rules based on this information.

Pre-conditions for the job:

“Dept-cc” dimension set is created, composed of Department and Cost Center dimensions.
The dimension set has neither hierarchies nor rules created.
All mentioned ledger accounts exist in the chart of accounts.

As a result of the job execution:

Several dimensions set hierarchies will be generated. The number of hierarchies will be less than number of accounts, because some accounts have similar validation rules.
The hierarchies will be updated and approved.
There will be a dimension set rule collection created for “Dept-cc” dimension set.
There will be several dimension set rules created – one per ledger account. The rules will be assigned to the rule collection.

The job may be found in the attachment.

Facts and Fallacies of Software Engineering

2007-02-13T23:51:00Z

I have just finished reading "Facts and Fallacies of Software Engineering", by Robert L. Glass.

Quite a funny book, very easy to read. Highly recommended! Here are some of the facts he mentions and elaborates on:

Fact 2 - "The best programmers are up to 28 times better than the worst programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field."
Fact 7 - "Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none."
Fact 23 - "One of the two most common causes of runaway projects is unstable requirements."
Fact 37 - "Rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run."
Fact 45 - "Better software engineering development leads to more maintenance, not less."

And here is a couple of the fallacies:

Fallacy 8 - "Given enough eyeballs, all bugs are shallow."
Fallacy 10 - "You teach people how to program by showing them how to write programs."

(...damn, all these books make me more and more sober-minded!..)

Default dimension set hierarchy

2007-02-09T14:49:00Z

On the General tab-page of "Dimension sets" form there is a field, named "Default hierarchy".

By default, if a ledger account, journal or table collection has no explicitely defined dimension set rule, than it will not be controlled by dimension sets and any dimension combinations will be valid. But if a dimension set has a hierarchy selected as "default", than everything that has no rules will be controlled by this default hierarchy.

Parent dimension sets

2007-02-08T17:20:00Z

So far, I have been explaining everything based on one dimension set, consisting of Department and Cost Center dimensions. We created a hierarchy and rules for some ledger accounts and free text invoice.

Now we control combinations “Department - Cost Center”, and don’t care about Purposes – any purpose is valid in any situation. Still, if we wanted to control Purpose without dependency on any other dimension, we would have to create another dimension set, specify Purpose as its one and the only component, then create a one-level hierarchy and all needed rules. Our dimension sets would not intersect in this case, so whenever we validate Purpose – one dimension set would be used, and when we validate Department or Cost Center – than another one would work.

But let’s imagine that the Purpose dimension should also depend on another dimension, say, Cost Center. And although Cost Center is already controlled by DepCC dimension set, we may create another dimension set (that will consist of Cost Center and Purpose dimensions), create a hierarchy and eventually a rule that will control ledger accounts, journals etc.

So, open the Dimension Sets form and create another record in the upper grid, setting “Set” field to “CCPurp”, and “Description” to “Cost Center and Purpose ”. Then, open Dimension tab-page. As you can see, only one dimension is available to select from (because the other two are already used in another set). Move Purpose from the “Available dimensions” list to “Selected dimensions”. Good. But we need Cost Center dimension as well. So, open Parent tab-page. We have to tell the system, what dimension set we would like to share a dimension with. Here, we select “DepCC” dimension set, then mark Cost Center in the appeared list of dimensions, and finally press Ctrl+S to save the record. After you press Yes in a confirmation dialog, the dimension set is saved, having Cost Center as the first priority dimension, and Purpose as the second priority:

From now on, the Cost Center dimension is controlled by two sets!

So, if we had a rule for a ledger account in each of the two sets, then only Cost Centers valid for both rules would be available for entry.

Let’s check this behavior. As you may see in my first post about dimension sets, the “110180 - Petty cash” ledger account has a rule for “Department – Cost Center” dimension set, and according to this rule the dimension entry for this account is controlled with DepCC1 dimension set hierarchy. Let’s imagine that we would like to apply new restriction onto this account:

· Only Cost Centers 1020 and 3010 are valid;

· For Cost Center 1020 - only Purpose M010 is valid, and for Cost Center 3010 – only Purposes starting with ‘P’ are valid.

So, we have to create a dimension set hierarchy for “CCPurp” set. In the Designer, it should eventually look like this:

Now, mark Check checkbox and then mark Simulate checkbox.

The hierarchy has no duplicate errors. Press the enabled Update button and close the designer. On the “Dimension sets” form, mark the hierarchy as Approved and then open the “Dimension Set Rules” form.

Now, in the “Dimension Set Rules” form create a Collection named “Accounts”, and select the just created hierarchy:

And finally, create a record in the lowest grid, setting a dimension set rule for the Petty Cash ledger account:

(As you might notice, the Hierarchy value is automatically substituted – it is just copied from the collection setup. You may select another hierarchy for a detailed rule, if you wish.)

So, the ledger account 110180 has two rules now – one per dimension set.

Let’s create a new General journal and create a journal line, setting Account to 110180. If you consequently opened lookup form for each of the Dimensions now, you would see 2 values for Department, 2 for Cost Center and 6 for Purpose. But, set Cost Center to 3010 and check the lookups again. You can see the difference: only one department is valid from now on.

And only purposes starting with ‘P’ are selectable.

This is the result of intersection of the two rules: all the 3 dimensions are validated together for the ledger account 110180.

Of course, it is also possible to create one dimension set consisting of all the 3 dimensions, and then create a 3-level hierarchy. But if there were dozens or even hundreds of dimension values in the system, then the number of valid combination would be so huge, that the hierarchy simulation would take several hours (if not days!). It is much more convenient to have several small sets (linked together through shared dimension) and several small hierarchies for these sets.

And this is it about the parent dimension sets.

Prefixes and dimension set rules

2007-02-06T17:20:00Z

When setting up dimension set rules, sometimes it is necessary to limit the range of valid dimension combinations even more.

Find my first post about Dimension Set Hierarchies functionality, and look at the use case: there are only 2 departments and several cost centers valid for “110180 - Petty cash” ledger account. But let’s imagine that we have another account “120210 - Bonds”, and we want to restrict the valid combinations down to “department 10 - cost center 1010”.

The hierarchy DepCC1 contains this combination already. So, we select this hierarchy when setting up a rule for bonds account, and then we specify a prefix for this rule, narrowing the range of combinations inside the hierarchy down to one:

Now, create a General journal line and select the account 120210. As you can see, only department 10 and cost center 1010 are selectable in the appropriate dimension lookup forms. And if you tried to enter a cost center other than 1010 (say – 1020), than you would eventually get a validation error “Dimension set value 10 - 1020 on set DepCC is not authorized on hierarchy DepCC1 with prefix 10 - 1010”.

When setting up prefixes, you may leave them blank (filled with ‘?’s) – then the whole hierarchy will do. Or you may specify one or more dimension values in the prefix and make the hierarchy more “narrow” for a particular rule. So, if we specified a rule for a Free Text Invoice like this (fixing the cost center selection with 1020, which is valid for both departments in our hierarchy):

Then, when creating a free text invoice (Account Receivable > Free text invoice), we might be able to select any of the two departments, but only one cost center:

We might equally well create new hierarchies for the second and the third rule and don't use prefixes, but prefixes allow us use only one hierarchy in our case.

Inside Microsoft Dynamics AX 4.0

2007-02-02T14:31:00Z

I have finished reading the book a couple of days ago, and it was real pleasure!

Some sentences have kind of opened my eyes; others were quite cognitive, even if not related to my immediate tasks. And if you asked me, what were my favourite chapters, I would name four of them: Performance, The Data Layer and 2 small funny chapters named Advanced MorphX Forms and Reflection.

If you code in X++ and still hesitate whether you need "Inside Microsoft Dynamics AX 4.0" on your bookshelf - stop thinking. Just order it, read it, and then put onto your ... no, not "shelf". You will definitely need it onto your desktop - to reference from time to time.

Rapid Development, by Steve McConnell

2007-01-29T22:15:00Z

Mfp mentions two books in one of his posts: "Code Complete" and "Rapid Development" by Steve McConnell. He expresses exactly what I felt after having read them both. The only thing that I would add to that, is that Rapid Development is a "must read" not only for leads and management, but for private developers as well, because Steve describes all possible mistakes that would lead a developer to not having complete his tasks in time. Moreover, Steve gives recommendations on how to prevent these mistakes, and this knowledge is invaluable. By the way, the developer who has that knowledge, will definitely help his PMs and testers be more productive. So even if a manager has never read this book, but all his developers have - the team will succeed anyway, unless the manager hastily ignores his developers' arguments at team meetings.

Dimension Set Hierarchies

2007-01-27T19:56:00Z

This post is supposed to help people understand how Dimension Set Hierarchies functionality should be used in Microsoft Dynamics AX 4.0 (earlier known as Axapta).

As far as I know, there is still no official whitepaper. Help texts exist, but don’t reflect the logic of the feature. I will try to fill this gap.

So, first of all: why do we need this feature? Sometimes we have to control dimensions entry to a transaction, e. g. along with Department A we may enter either Cost Center 1000 or Cost Center 1001, but prohibit Cost Center 2000. Sometimes we want such control to be applied on a particular ledger account, sometimes – on a particular journal. And we may also need to control dimensions entry for a group of related tables. This is what Dimension Hierarchies are used for.

Note: the examples below are based on a demo company, provided with the installation CD.

Let's set up the feature from scratch.

Use case:
There is a ledger account “110180 - Petty Cash”. We want to make sure, that whenever we use this account for posting, it is controlled by the following rules:

· either General or Finance department may be selected, and all the rest are not valid;

· whenever General department is selected – any cost center is allowed, but if Finance department is used – only cost centers 2010 and those starting with 1* are allowed.

OK, now we have to set up the system so that these rules are followed. This is very simple: we have to set up 3 things one after another: a dimension set, a dimension set hierarchy and finally a dimension set rule.

1. Before we begin, make sure that one of the parameters is set up: open “General Ledger > Setup > Parameters” and go to “Number sequences” tab-page. There is a reference named “Dimension priority ID”. If it is empty, then set it up by selecting any number sequence from the lookup. You will not find the generated values anywhere in the user interface because they are used internally, so just set this parameter up and close the Parameters form.

2. Then, we have to create a dimension set. A dimension set defines that one dimension depends on another one (note, that particular dimension values are not mentioned at this stage). In our case Cost Centers depend on Departments, therefore we have to create a dimension set, where Department dimension has the first priority, and Cost Center goes after. Open “General ledger > Setup > Dimensions > Dimension sets” menu item. You will see a form with two grids. In the upper grid, create a new record, setting “Set” field to “DepCC”, and “Description” to “Department and Cost Center”. Then open Dimension tab-page, move Department from the “Available dimensions” list to “Selected dimensions”, then move Cost center and finally press Ctrl+S to save the record. After you press Yes in a confirmation dialog, the dimension set is saved:

3. After we have specified what dimension depends on what, we have to create a dimension set hierarchy. We have just saved the dimension set, so the “Dimension set hierarchy” grid in the lower part of the form has become available for edition.
Create a new record in the grid, setting “Hierarchy” field value to “DepCC1” and “Description” to “Hierarchy 1”. After that, press “Structure designer” button. You will see the designer form, with a tree structure in the left part, and a grid in the right. This is where we specify valid dimension values. As you remember, the only departments we would like to be valid for our account are General and Finance. Drag these departments one by one from the grid and drop them onto the “Company” node in the tree:

The first priority dimensions are defined.
As we remember, any cost center is allowed for the first department; therefore we will not add any sub-nodes to “10 - General”.
So, select “90 - Finance” tree node and press “Create” action button in the left part of the form. Now the designer is in the node creation mode. Set “Row name” to “CCsForFinance”, and “Row description” to “Cost centers valid for Finance”:

Then go to “Setup” tab-page of the same tab, change “Topic” field to “Cost center”, set “Value” to “2010, 1*” and press Ctrl+S. You can see that the Finance department has a sub-node now:

The hierarchy is constructed.
But still we have to make it available for future use in the dimension set rules. In order to do that, we have to simulate the hierarchy, to see all the valid combinations “department – cost center”. But, before we simulate the hierarchy, we mark “Check” checkbox, so that any duplicate combinations will be found (if any), and only after that we mark “Simulate” checkbox, to run the simulation process. As a result, we see another structure:

The nodes with ”yellow scroll” icon represent valid dimension combinations (“blank list” nodes are not meaningful here so don’t pay attention to them). Well, we have generated all valid combinations – then we have to save them to make the hierarchy available for use. Press “Update” button in the right part of the designer (it becomes enabled as soon as we have the hierarchy simulated and there are no duplicates in the structure). After that the “Last updated” field in the form header is automatically set to the system date, and “Updated” checkbox is marked. The hierarchy is updated.
Close the designer form. You can see, that on "Dimension sets" form one of the checkmarks in front of the hierarchy name is marked now:

The hierarchy is updated, but we have to approve it, so mark the second checkbox:

The hierarchy is updated and approved. Now we can proceed with the final step.

4. We have created the dimension set and the dimension set hierarchy. After that, we have to create a dimension set rule - to attach our validation rules to the ledger account.
Find “Dimension set rules” button on the “Dimension sets” form, and press it to open “Dimension set rules” form. You can see three grids in the form. The second grid represents dimension set rule collections, attached to the current dimension set (we may group dimension set rules to virtual collections and give these collections names). So, create a record in the collections grid and set its “Code” to “AccRules” and “Description” to “Rules for ledger accounts”:

The collection is created, now we may create dimension set rules, attached to this collection. Create a new record in the third grid, which actually represents dimension set rules. Set “Object type” to “Ledger account”, “Identification” to “110180”, and “Hierarchy” to “DepCC1”, and save the record.

We have just created the dimension set rule for the “Petty cash” ledger account. You may close both the “Dimension set rules” and “Dimension sets” forms now.

5. The validation rule is ready, but the system will not use it until we set up the final parameter: open “General ledger > Setup > Parameters” form and set “Activate sets” parameter to “At update and posting”.

Congratulations! You have just made the dimension sets feature up and running!

6. Would you like to see the effect? Then open “General ledger > Journals > General journal” form and create a new journal, then press “Lines”.
In the journal lines form, create a new line (but don’t modify any fields for now!) and press the lookup button of the Department dimension:

You can see, that the lookup form has changed – now it has 3 tabs, and the first tab “Selectable” contains all departments. Any department may be selected at this point. But don’t select any department; instead, set “Account” field of the journal line to 110180:

And press the Department lookup button again:

As we can see, only two departments are selectable now. Select the Finance department. The department dimension is set up. Press the lookup button of the Cost center dimension:

These four cost centers are indeed the only cost centers valid for Finance department. The dimension set rule works as expected! We may select one of these values, say, 1010 Building, and our Department and Cost center dimensions are set up.
By the way, if you opened the lookup form of the Purpose dimension, all purposes would be selectable, because we don’t have any dimension set rules controlling purposes.
Now, we may proceed with the journal lines edition, validation and posting.