Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Date fields: current date is autofilled on editing a record
I noticed that a lot of the datefields fill in the current date when editing a record. I would like to block this behaviour al together, the application should never autofill date fields. Is there an easy way I can do this?
try this:
Seems to do the trick, what does the generatedtype mean anyway?
Another thing I've noticed still is that during the creation of a record, date fields are still set to the current date. I really need to stop this behavior since I want to use a field to record when salesorders are fully invoiced (the date that this event first occurs). We use this for financial reporting so we need to be able to rely on this field. This is a custom field, where the generated type is already set to 2, as per this answer (to a question from Joe in 2006!).

Wait, this seems to be related to a workflow I use. The workflow is (on SalesOrders):

- Until the first time a condition is true
- field that is auto calculated by aggregating all related invoices should be 'greater than or equal to' the 'sum_nettotal' field
- Then field should be get_date('today')

I see in the workflow list that this workflow is listed before the 'Update financial fields on every save' workflow. I'll try and reverse their order to see what happens.
Something is weird here, since I can edit these two fields (both custom fields) in createview (but not in editview) while both are set to displaytype 4

I feel like the workflow is launching on a false positive, checking the value of the custom field against the sum_nettotal field when the sum_nettotal field is still 0. Since the custom field that aggregates the invoices starts out at zero as well, the date is filled. When I disable the workflow task, the date field stays empty

So basically, to sum up all the madness:
  • I created two custom fields on salesorders: one aggregates all the invoice net totals, the other is a date field
  • I created a workflow that checks the aggregated field (that holds the sum of all the invoices) against the sum_nettotal field of the salesorder. That workflow works untill the first time a condition is true:
  • The condition is: the aggregated field that holds the sum of all invoice net totals should be equal of bigger than the sum_nettotal value of the salesorder, ergo: the salesorder is completely invoiced
  • At that moment, the second custom field should be filled with today's date
The behavior now is that every new salesorder has that second field set to the creation date of the salesorder, while I would expect it to be empty.

I think I've hacked this by adding a condition: I added the condition that 'Last modified' by can not be empty. This will prevent the date field from being filled in at the first save of the salesorder. I can't really test if it does what I want it to do when the salesorder is actually completely invoiced, since I can't create invoices on a production system without the invoice no.'s increasing (and you need consecutive numbers for the tax guys). I will monitor this and see what happens.
Now this becomes even weirder. I now see new orders popping up created on 20-09 with a date 'totally invoiced' filled on 19-09, while the workflow explicitely says get_date('today'). Also, the invoiced amount does not exceed the total order value.
I think I know why the date was set to 'yesterday'. The salesorder I checked were created at 00:30. But we are in daylight savings time right now, so probably the server (admin user time zone) that did the updating thought it was 23:30 the previous day. About the rest of this thread, we solved that here. Basically workflows weren't checking against the correct module when you created a workflow on module A to check two fields on module B against each other.

Forum Jump:

Users browsing this thread: 1 Guest(s)