Option field type vs. State Management

I do not like to use the Option field type for two reasons:

  • If you want to use, or replicate, the same field in others tables, you must remember where you have the same field because if you make a change you must replicate this change to all other tables.
  • If you add a new option, you must add it to the end to avoid that all your code point to a wrong option. To avoid it, you can do two things. The first is to save all your code in text format, add the option, load the text code, fix it and compile it. The second is to use numeric values instead the text options, like IF myTable.Status = 4 THEN instead of IF myTable.Status = myTable.Status::Sent THEN

The above mentioned has given me more than one headache in situations where I had the same field in multiple tables and I have had to add one or several options, because most likely all code compiles and does not give any error, but really is not correct.

State Management. The Basis

Due to this, I have been using a homemade functionality that I have called “State Control”. The “State Control” not only allows me to prevent against the annoying effects of add a new state to the flow control but it permits to the end user to change them (as long as it has not effect in the logic). Furthermore we can add a little of workflow behaviour, how we will see later.

The “State Control” prevents against the annoying effects of add a new state to the flow control

It is very simple. We start with two tables, one table to define the flow of state, and other for to control of the “current” state of something. Let us see it with an example.

table1

We are going to use the fixed description (with the hope that it is not going to change) in the code, and we could use the free description to paint it on the page or factbox.

table2

The state control table has relation of 1:1 with any other table of the system. The state control code can be the primary key of the related table. Although could also be a code auto-generated and linked with the table to control its states.

code1

This is an example of how we can write code similar to the Option field type.

Later, if someone want to add some state to the flow it is such easy as add a register into State Flow table, like follow.

table3

And, of course, your code has remained intact.
Now, you can add the code for the new state.

code2

Furthermore, the same state flow can be reused as many times as you want.

State Management. Adding more functionality

To make the “State Control” more useful we are going to add some columns in the State Flow table.

table4

First of all, we need add some code to the table we want to control the state.

code3

table5

And, optionally, we can move to backward and forward.

code4

table6

Even we can offer to user, across a standard dialog page, for he choose one.

code5

table7

And put it to the state appropriate.

code6

table8

We can also ask the “State Control” for the states we can move, using the “States Admitted”.

code7

Also, we can have a Codeunit subscribed to State Control Management CU for to program the business logic needed.

code8

In this example, something or someone wanted to change the state of a Ticket to Solved and a business rule has prevented it and send it to Cancelled state, because the customer had overdue balance.

table9

Finally we need a Factbox to display information about the state of control. Something like this.

state-control

State Management. To finish

A lot of new things can be make over the “State Control” functionality. Here I put a few of them.

Expirations
When a register of the State Control table has no changes for more than an established period of time, established in State Flow table, a background process can automatically change its state to another state like waiting state or something like that.

Notifications
In the State Flow table we could add a check to indicate that someone (the owner, the customer, the manager, etc.) should be notified, and of course, point out where this person can be found.

By this way, when the State Control Management CU make a change of state, automatically will send a notification to whom corresponds or raise an event.

Approvals
From the previous feature, or similar to the previous feature, we could force that a third people must approve a register of the State Control table for allow the change of the state.

Log
Every time a register of the State Control changes, we could write in a State Control Log table and we could write down who and when the change of the state was realized.

Times
From the State Control Log table we could determine how long a State Control has stayed in a determinate state, or who has less things in a determinate state, for example.

Progress
A panel that shows the percentage of completion with two lists, one that shows the stages completed and other that show stages pending.

 

NOTE: This is my first post written in English. I am apology for the mistakes.

Anuncios

One thought on “Option field type vs. State Management

  1. I agree Option Lists are not the best solution but if you need a list and expect *some* growth, you can make provision by using extra commas to make space ready. I.e. If your option list is ” ,A,,,D” you have options A = 1, D = 4. B and C can be added later as options 2 and 3. The drop-down list in NAV will ignore the empty options.

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s