Is it possible to correct the date of a posted statement and it's lines

Support User
1

Hello,

I made a mistake :frowning:

Two days ago I prepared bank statements for the end of 2023, and didn’t see that some dates were wrong: they got sent to 2024.

For the first one, the statement date is correct, but the lines are in 12/2024.

For the second statement, both the statement and line dates are in 12/2024.

Of course I posted them, then noticed that something was wrong…

Is there any way to correct those ?

Thanks

2

Not from the UI.
Indeed you should correct by cancelling the wrong moves and create new one with correct values.

Of course you could also update the date in the database but at your own risk as you may break the validity of the data.

3

By the way I filled Add warning when posting statement with lines in the future (#12951) · Issues · Tryton / Tryton · GitLab to try to avoid such mistake.

4

for my problem, I ended up restoring the last daily backup of the db and redo the few things I had done in between.

For the date problem, I noticed that I often encode wrong dates when the month change, because I type only the day number then [tab]. Tryton then defaults to the current month (and year in my statement little adventure).

For accounting documents, shouldn’t it default to previous month and year when the current month or year would make that date in the future ?

I mean, if it’s the 05/01/2024 and I type 23[tab], it should default to 23/12/2023 instead of 23/01/2024.

There’s no point to default to a future date for accounting documents like statements, invoices, moves… or is there ?

5

The client can not know what you want to type. Sometimes it may fit in the future sometimes in the past.
For me it shows just that it is a bad habit to type only days.

6

IT is supposed to simplify our lives, and Human beings are creatures of habits :slight_smile:

The client already makes an assumption about what the user wants to type. I just noticed that in some cases (accounting documents with a resulting date in the future), that assumption turns out to be wrong. And that most of those cases are preventable.

Instead of filling an incomplete date with current year or current month+year, fill it with nearest corresponding date in the past. Even nearest straight corresponding date should catch most errors: there’s a good chance that someone encoding 25[TAB] in early X month means 25/X-1, and not 25/X.

7

You also can use the m and M key in the date widget, to increase/decrease the month. Same with w, W eek, y, Y ear, d, D ay.

1 Like