General ledger Journal Entry not giving error messages

[cricalixwood]

Version

1.11.5

What browsers are you seeing the problem on?

Firefox

What happened?

Select GL/Journal Entry from menu. Enter any txn , leaving date fiels blank (i.e showing yyyy-mm-dd. Hit update. No error message displayed regarding missing date. Similarly if you should enter a debit and credit for one account on the same line, you just get a refreshed screen, with only the Update button. No error message to indicate why.

What should have happened?

I think you should get an error message when the data does not pass validation.

[cricalixwood]

More info: the above is with Separation of Duties=NO

[ehuelsmann]

Not saying this is by design, but it's impossible to block on an unfilled date field: template transactions allow empty date fields.

At the moment, template transactions may be disabled though (not sure).

[cricalixwood]

If I do the same thing in 1.10.25, I get an error saying invalid date....(in so far as I would usually just hit Post).

[ehuelsmann]

Yep. On "Post" that makes sense, but because the transaction is incomplete, you're no longer being offered that button.

I'm contemplating how to proceed on this topic: because the transaction isn't complete, the "button-dealing-code" actually doesn't know there's a "Post" or a "Save" action -- the library which governs the "next steps" doesn't release that information...

With respect to dealing with 2 numbers on a single line, this is something we can provide feedback for in the transaction screen.

Do you have any ideas on what to do with the date field?

[cricalixwood]

Not really. It just seems to me that simply refreshing the page, with no messages, and not proceeding to the next step, is unsatisfactory.

You said that a blank date was acceptable...so why not let it pass validation, and fail on a subsequent Post if the date remains blank?

[ehuelsmann]

Not really. It just seems to me that simply refreshing the page, with no messages, and not proceeding to the next step, is unsatisfactory.

Hmm. From the perspective of the workflow, it is moving to the next step: it's applying the Update action and returning to the INITIAL state. While doing so, it offers all buttons allowable for the inputs that have been provided. Since the transaction date is missing, that excludes the "Post" button. But I do get the point that this may be counter-intuitive.

You said that a blank date was acceptable...so why not let it pass validation, and fail on a subsequent Post if the date remains blank?

The bizarre result of doing it this way is that when opening the transaction screen, you'd have a Post button without anything filled in. Although all the fields are there to make Post a valid operation... Needs more thinking.

[ehuelsmann]

What we need here is a set of criteria when to not to show a button and when to show a button, but prevent its action when the button is triggered.

[cricalixwood]

Agreed. But after the first post, plus New, post is available with just the date filled in...so what's so bad about that? Roger ⁣Get BlueMail for Android ​

…

On 15 Dec 2023, 15:12, at 15:12, Erik Huelsmann ***@***.***> wrote: > Not really. It just seems to me that simply refreshing the page, with no messages, and not proceeding to the next step, is unsatisfactory. Hmm. From the perspective of the workflow, it *is* moving to the next step: it's applying the Update action and returning to the INITIAL state. While doing so, it offers all buttons allowable for the inputs that have been provided. Since the transaction date is missing, that excludes the "Post" button. But I do get the point that this may be counter-intuitive. > You said that a blank date was acceptable...so why not let it pass validation, and fail on a subsequent Post if the date remains blank? The bizarre result of doing it this way is that when opening the transaction screen, you'd have a Post button without anything filled in. Although all the fields are there to make Post a valid operation... Needs more thinking. -- Reply to this email directly or view it on GitHub: #7806 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>