Close accounting periods

[TonyIT]

Hi Maxime

It would be very useful to have a lock when you are trying to enter a date that falls within a period that is considered closed.
In other words, if I consider that the balances of my accounts are perfect on a certain date, it must become impossible to receive new transactions or make changes to old operations that affect the period before that date. The balances are "cemented" and protected.

I am thinking of a setting like this:
[ In ALL accounts of this ledger, consider close the period before: [yyyy-mm] ]
in the [Properties] pane of the xhb file you have opened.
To override this block, you can simply change that date, act your changes, and re-set the date.

All the ERPs work in this way: you cannot touch or enter anything new that could change the numbers that fall within a closed period. You would be shot! :)

Grazie,
TonyIT

[Maxime DOYEN (mdoyen)]

this is VERY similar to how the lock reconciled switch works together with reconciled transaction
it does not protect adding new txn, but prevent any chnage to existing (and reconciled) ones
close the account to prevent to add new txn

[TonyIT (nc8430)]

Thanks for the answer

I can accept that the reconciliation is on the right way but it leaves huge holes because you can modify the date of an existing txn, add new txn with a wrong date or import something wrong.

And there are no reasons to close an account: the account MY_WALLET (e.g.) will never be closed. For this topic, you need to close a period, not an account.

Closing of an account is done for other reasons.

TonyIT

[Maxime DOYEN (mdoyen)]

"you can modify the date of an existing txn"
>if you can it is a bug, please provide a use case

>indeed at present reconciled txn are freezes but you can still make other changes

So far I did not see any such feature in other software, except the reconciled process with the last reconciled date maybe. Is it the use case you have in mind ?

I mean after any reconciliation with a statement, the date is freezes, and you ask that no change is done before this date ? (If I understand you right, my mind is not very clear this morning :D)

[TonyIT (nc8430)]

Hi Maxime!
sorry for you mind! ;D A good Expresso can do miracles, it's on me!

Put it in this way:
1. You have you a correct balance for (e.g.) 2017. Well cemented and with the right numbers.
2. Your colleague creates a new tnx, and for just a mistake (we are soooo human btw ;) ) he/she writes "3 Apr 2017"
3. Go out to and have a nice w.e.
4. Come back and start worrying (and getting angry) about why the balance is now wrong!

Just that. A simple check on the date of:
- new transactions
- when editing transactions
- imported transactions

BTW, your sw is great even as it is

[Maxime DOYEN (mdoyen)]

humm, as you mention 2017 (past)
Isn't it a lock this account would suit ?
this will work similarly to closed account (technically = only visible account)

[TonyIT (nc8430)]

Numble Numble... (the sound of my mind...)

So you suggest to create at least two account for (e.g.) banks?

Bank_1_on_the_rocks (open)
and
Bank_1_old_but_good (to be close ASAP)

and

Bank_2_on_the_rocks_again
and
Bank_2_old_but_good_as_the_other

and move all the damn 2017 (and before) to the "oldies"?
and after the moving, close them?

it's a way.
it's a _not_so_elegant_ way,
but it's a way

https://docs.oracle.com/cd/A60725_05/html/comnls/us/gl/openper.htm
:)

[Maxime DOYEN (mdoyen)]

not at all, I was suggesting an account property, but I thinks I missed the account was still to be used :D

so the 'last reconciled date' method should be the one to go, it should be implemented with #1099033 wish: Account reconciliation dialog/workflow for Bank Accounts

the principle is each time you reconcile, you cannot do any changes prior the last reconciled date of the account, so probably what you wish. there is already a last reconciled date which is the date of the highest reconciled txn. #1099033 is also to have an additional dialog to focus on the reconcile process.

[TonyIT (nc8430)]

Hi Maxime!
Yes, this fits perfectly.

Thanks a lot!