How do I make the program display a message once on the last day of the month?

Question

I am working on the development of a financial program in Windows Forms and a requirement appeared that I am not yet knowing how to do. The requirement is as follows::

On the last day of the month when opening the program for the first time, the same should ask if you want to generate the boletos of all installments to be paid in the following month and if positive, generate these boletos all at once.

The program already has a billet generating mechanism using the Boletonet library. In fact, there is a screen that shows the plots and allows generating the billet for the selected plots. The mechanism is the same, the only difference is that the program would need to take all the installments to be paid the following month and execute the billet generation code on top of them.

So far so good. The problem that exists is the following: how to make the program on the last day of the month show this message only once?

Displaying a message like this on the last day of the month is easy. Simply put a if that checks if today is the last day of the month and if so opens the window with the question and the options yes and no.

The problem is making that message appear only time. And in fact I think it would even be necessary to have an option: "show later" for the message to be shown again after.

Anyway, the problem is that that would require a sense of state of it. But I think making a table in the database just to store whether that month the window was shown or not is nonsense. It doesn’t even make sense, because that kind of window could be used for more things and then there would be a table for each?

What I want to know is, how can I get this window to be shown once?

Editing: In attention to the comments, I will add this edition to explain a little better. The requirement was presented anyway. And to tell you the truth, it’s hard to get any more explanations. In this project several times I tried to get more explanations about the requirements but in general we did not get much clarification.

Back to the requirement itself: the user asked to open once only on the day. Not to open again we would have to have recorded somewhere that that month was already opened. Hence in memory is not enough.

On the other hand, there are other variables and considerations that made me post the question to evaluate the best way to achieve this. First, this type of interaction must occur for other things. For example, the user wants that on the first day of the month the program opens only once a window asking if he wants to send the boletos generated on the last day of the previous month. Hence the same kind of situation.

In addition, there are variables to consider: (1) and if the user wants to be remembered later? (2) would also need a verification of the existence of parcels to generate billet? (3) and if the user creates a new charge on the same day?

It’s just a few questions that make you consider the need to have a sense of state of this. On the other hand, I thought of using a table for all these types of actions, in an abstract way thinking only of the business rule. Something like this: create a table acoes_periodicas with columns id , tipo_acao, data, situacao. The tipo_acao would discriminate against what is done periodically, e.g., geracao_boleto_mes, envio_boletos_mes. The date would contain month information and the situation would contain the information whether it was made or whether it was postponed.

This was just a first idea, but I found it a little strange. The biggest oddity is: the column tipo_acao would have to have only a few default values that would be hardcoded. That is, when to open the boleto window would make a query in the database explicitly by geracao_boleto_mes. I think it works, but I think it’s weird. As the situation is more general and can be used in other situations where a program needs to ask a user always on a day of the month to do something, I found valid the question even for other people and posted.

Answer 1

There are basically two scenarios:

• the system does not work as a network

  I do not agree with Luiz Vieira in comment, I do not think that a simple indication in memory would work in the best way, unless it is guaranteed that someone will enter this day and it would be weird for someone to issue the tickets and then ask you to issue again. This could even be avoided if you check if you have any billet to issue within the normal criterion of the requirement, if you have nothing not ask to issue. I don’t like this solution because you will have to make a potentially expensive consultation to make the decision, but if you attend, you can use it works, credit to Luiz.

  If you want to facilitate can put an indicator in the database that no longer need to issue the boletos, a simple query. This can be in a specific own table or in a general settings and flags existing.

  Although I don’t recommend it, it can also be in the Windows registry, the application configuration file or other means. A more or less acceptable way would be to create a file to record the condition. In fact the file doesn’t even need format, it can have 0 bytes, its simple existence is an indicator. It would be good to check his date, at some point erase, or leave and always use the date to determine if that did already issued. I find these solutions fragile and do not seem very correct.

  The user can tamper with it and bypass the system, even by accident. In the database is a little more secure and it will only do by want, or lose everything and the problem is much worse.

• the system works in network, probable, né?

  I imagine that if a person issued it, no one else can issue it. Controlling on the client becomes difficult to function. It would work only if it is guaranteed that no one on another machine will try, then the system would control by machine whether to show the screen or not. I find it very fragile.

  Whether information will become available system wide has to persist somewhere. In memory it’s bad, unless you can guarantee that the server will always be on. A little fragile. If it’s to be stored somewhere I can’t imagine why it’s absurd to put it in the database, even if you have to create a table just for that.

  You can avoid creating anything in the database if you create a query that checks whether you have billets to be issued in the established criteria and only return to the customer if you have them or not. It is an exchange of a derisory space in the database for a processing that may not be so cheap. I prefer to have an indicator.

The problem has nothing to do with the interface, an encoding in it is necessary to comply with a business rule. If it’s a business rule, the database seems like a more than adequate place. You will not control whether the screen will be displayed or not, will control whether you need to send the boletos on the last day or not, because they have already been issued. The screen is a consequence of the business rule.

But imagine, if nobody goes in that day, what happens? It emits the next day? I guess so, right? The user may not want to issue a anates day because he knows that tomorrow he will not access the system. It needs specific control, it needs to be determined by the database one way or another. Trying to deal with a business rule problem in the UI seems like a mistake.

Do you need the intervention of a human to do this? Can’t the system broadcast itself? Maybe I do, if that’s the case, you need to think about the exceptions, whether it’s going out before or after. It seems to me a fragile requirement that the user will enter the system on the right day and will send for sure.

Nor do I enter into the merit that the requirement may also be wrong, unless it is guaranteed that all conditions of issue of billet are "x days out month, where x is not a few days", since issue day 31 a billet that will expire day 1 does not seem to be right.

With the well-defined and correctly persisted business rule UX is just a detail.

In attention to editing:

The requirement was therefore submitted

The requirement is what you reap and not what you are presented with. If the requirement is not clear to the user it is its function to make the requirement reach a suitable point. If this is not possible the best to do is not to do the project, has good argument at hand. If the best is not possible then any solution serves.

The user must define what he needs and not how the system works.

Unless it is poorly described here the user does not know how to work, and then the best thing to try is to act as a process analyst and try to fix the company before tidying up the system. There are too many holes to be able to do anything that works. Part of the wrong premises, as I said above.

The issue places some points, I put others.

I don’t know if it’s necessary, but it looks like you’re looking to create a workflow system.

You have to be careful with the "you did it or you didn’t". You have to make sure you’re done. And this business of such a day does, is only an initial basis, I have already put up that there may be problems in this criterion and other criteria need to be created to deal with it.

The normal thing is to find strange something never did.

You will not get the solution to a problem that is poorly defined.

Answer 2

If I understand your question, you can save in the user settings if they have already been warned or not:

---

if(UltimoDiaDoMes())
{
    if(!Properties.Settings.Default.AvisouUsuario)
    {
        MessageBox.Show(...);
        Properties.Settings.Default.AvisouUsuario = true;
    }
}
else
{
    Properties.Settings.Default.AvisouUsuario = false;
}