Wednesday, June 15, 2016

My Daily WTF?! moment: Negative reservation

Still trying to get my head around this one. Serious MS? Negative reservation? Too many downtown Seattle microbrews during lunch hour?


In the inventory transactions I find the line that causes this. It is a physical reservation for qty –1 and it is linked to a sales order.

The sales order has only one line for the item. It has an output order on it, with a reservation of +1 on a different location than above.

With reference to my article about the inventTrans and the rule of never deleting lines from there, that’s exactly what I’m going to do. But I mean….WTF?

The theory of negative reservations

Now gather ‘round, boys and girls and imagine what the world would look like if negative reservations would exist. What would they be like?

I imagine it would be like a place holder on a location. Don’t put anything on this shelf, because I am expecting a returned item from a customer to be placed in this position soon. That’s what it would say whenever someone tries to issue a put away to that location.

It would be like the numbered markers they give you at MacDonalds. You place them on your table instead of the Big Mac that you ordered and by the time your fries are cold, a waitress will come and replace the marker with a freshly assembled burger.

Quantum physical approach of negative inventory

Or maybe it is even more conceptual. String theory enthusiasts, pay attention. This might bring you one step closer to the Theory of Everything.

If a positive reservation is a marker on an item in inventory. Then a negative reservation is a marker on an item that is not in inventory. Basically you are saying that you will fulfill your requirement (e.g. sales order line) using any item that is not in your inventory,

Imagine the collection of all items. This collection has two subsets by definition. [Items that are in your inventory], and [items that are not in your inventory]. Each of these subsets has at least one other subset. [Items that at some time will be in your inventory] and [items that at some time will not be in your inventory] (if you run your business right than the majority of your inventory will be part of the latter. But consider the set [Items that are not in your inventory[Items that at some time will be in your inventory]]. We already know that these items, will be in inventory at some time in the future. If we consider time as another inventory dimension (and in a quantum physical world there is no reason that we shouldn’t), then we must be able to make reservations on this location that has inventory in dimension time x (where x is a time somewhere in the future).

Because that means we are putting a marking on an item that is not in our inventory, we are creating a negative reservation.

When you think about it, it makes perfect sense.

Friday, June 10, 2016

Security (part 1)

…and then you find yourself responsible for setting up a security and authorization policy in AX, or worse…you inherit somebody else’s twisted logic.

Up to version 6, Dynamics AX has always been lacking a solid authorization framework. In 2012 Redmond decided to make up for this, and boy did they make up. They didn’t just come up with a security system that actually works, they made it so that even the brightest minds will have a hard time coming up with a working solution that will satisfy all parties involved.

Badges? Badges? We don’t need no stinking badges!

So who needs authorization?


First and foremost, a good authorization system will benefit your users. AX is big bad and complicated. By shielding your users from stuff they don’t need, it becomes many times more user friendly. Your users may even become more friendly towards you.

Don’t look at it as restricting users. Although there are certain no-go areas in the system, I do believe that a good hiring policy and proper training are much more effective than restrictive ERP systems. However, limiting a user’s privileges to areas that are actually used in his role helps to lay out the boundaries of a user’s functional process.


Auditors don’t just want authorization (for users), they demand it. Segregation of duties, eyes only, SarbOx, you name it. Users should have appropriate clearance for any area of your system and if not, they have no business there. Furthermore it is important to have some kind of traceability. Who did what when and why? And that includes you and your nerd friends on the fourth floor, Brother Technicolor.

The Law

In some cases, and in countries with a legislation that has evolved past the one from Belarus, you are actually required by law to restrict access to certain system areas. Think privacy sensitive data in HR or financial data in GL. Take a little time to investigate the requirements in your neck of the woods or in the woods that you control. Better yet, convince your CEO to have the company legal councilor spend some quality time on the subject.

Your boss

So bosses and/or customers come up with some crazy shit and it’s not always easy to disagree.

Example from the past: “Sales people are only allowed to see customers form their own district. We don’t want them running off to the competition with our entire customer database!”

Sure, but…but..

So I built it.


No you don’t. Life is easier without having to worry about who is allowed to do what or people nagging about missing privileges. If you can get away with setting up a system without security, I say go for it. But if you don’t (or won’t), you do it right off the bat. The longer you postpone, the harder it will be.

You again

As long as you’re at it, ask yourself if you really need that administrator privilege for everything you do all the time.

Back in the days when ERP systems ran on UNIX systems and were administered from a console (the way the Lord intended it), I routinely logged myself out with the kill –a command (which kills any and all processes running under your account). Unfortunately I also got in the habit to routinely log in as root. Inevitably came the day when I killed all my processes as root and I slowly watched the system die while waiting for the phones to ring.

In other words, damage control. Limit yourself to what you really need on a daily basis. It only takes a minute to grant yourself sysadmin rights when needed.

Three General rules

1. Keep it in proportion.

Unless you are guarding the Coca Cola formula, the gold reserve of Pharrell Williams or the memoires of Dick Cheney, your security should be to scale.

2. Keep it simple.

Or at least as simple as possible. Remember, you are the one who has to maintain this crap and you are not going to want to do that for ever so the next guy should be able to understand it as well.

Keep it as simple as possible (but not simpler than that).

3. Don’t be a villain.

(gotta keep chillin’). The sense of absolute power can easily go to your head. Users will have to come beg and crawl for you to grant them access to sessions that they require to perform their daily tasks. Bribes have never smelt so sweet (I will do almost anything for home-made cookies) and who knows how far the new girl in Accounts Payable will go to see all vendor invoices?

But perhaps it is better for your karma to not be too restrictive.

To be continued…

Thursday, June 9, 2016

My Daily WTF?!

Haven’t had a WTF?! moment in quite some time now, but the planets have aligned, the moon is in the second house, and the spirits have woken.

Check this out. I still haven’t solved the mystery. According to the debugger HCMWorker.personnelId contains a totally different value from reality. Where does it get its information from? Some secret data cache? Another dimension? Just some lucky guess?

(click on the image to enlarge)