Batch Create expense claims doesn't adhere blocked date setting

I’m importing expense claims. At a certain point the date and amount format changed. It’s unclear to me when this happens, but it results in invalid dates.

These rows are still imported (incorrect behavior), and they will be uneditable because they’re before the block-date (correct behavior).

How?

How? Please be specific about what you are referring to.

Please illustrate with screen shots.

Why is the “import” incorrect?

Transactions prior to a lock date (if that is what you mean by “block-date”) can be edited by temporarily deleting the lock date.

It is worth noting that, if you are referring to Batch Create operations, you are directly manipulating the database, which would bypass a lock date restricting operations in the user interface.

How?
Batch Create Expense Claims

Date Lines.Amount Description
19-02-2021 2,99 XXXXXXXXXXX

How? Please be specific about what you are referring to.
My source material was dd-mm-yyyy and xxx,yy (for amounts). Since a certain release it became dd-mm-yyyy and xxx.yy

Please illustrate with screen shots.


I also had instances where the date would be some valid date, but in the future.

Why is the “import” incorrect?
It’s corrupting data.

Transactions prior to a lock date (if that is what you mean by “block-date”) can be edited by temporarily deleting the lock date.
While I understand that, I’d expect that the import would adhere the blockdata.

It is worth noting that, if you are referring to Batch Create operations, you are directly manipulating the database, which would bypass a lock date restricting operations in the user interface.
That really shouldn’t be the case imho. What happens with other fields where data doesn’t match expected structure? That could cause a crash or other unexpected things. (for example joining on NULLS, where there is data, but not properly ‘imported’ data)

There are several other ongoing discussions about date and number format problems with batch operations. I suggest you join them instead of continuing a separate discussion, which will only scatter information through multiple threads. I am closing this topic.

1 Like