timo, I wouldn't have thought that these dates should be parsed from the text fields. That seems very error prone to me. Wouldn't it make more sense to implement these new fields exactly like the invoice date and due date fields we currently have? I.e. two new date-fields for beginning and end of delivery range in invoice UI.
These two new dates should then also be available as template-variables, like we currently have {date_invoice} and {date_due}.
Let's assume that they will be named {date_of_delivery_1} and {date_of_delivery_2}. That way they could be easily used within the free-text fields, if we wanted.
Finally, these two fields should directly map to BT73/BT74.
That would also make sure that these dates are saved, correct? Because they wouldn't be parsed on the fly.
Of course, I have only addressed the case of BT73/74, i.e. were someone needs a date range. If BT72 (a single date of delivery) is required, we'd have to consider how this would be handled. It would alle come down to mapping the form-fields to the BTxx fields.
One way is to add seperate fields for BT72, 73 and 74. That would make easier to understand how fields are mapped. But that would make the UI more complex.
The other way would be to just have two new date fields. The logic for mapping could be:
- if only the first field is filled out in the UI, assume that this should map to BT72, leaving BT73 and BT74 empty
- if both fields are set in the UI, leave BT72 empty, and set BT73 and BT74 to the date field values.
- if none of the fields are filled out, assume delivery date = invoice date, i.e. use the existing mapping, where the BT72 becomes the invoice field.
I haven't thought about this very much, so maybe there is a logical flaw in my reasoning. But I believe this could cover all cases and would be consistent with your current approach. And it would avoid error prone parsing.