If you are saying the clone has blank fields where the source transaction had them, that is correct behavior since version 19.2.75. At that point in time, everything was cloned. Then the problem of duplicated reference numbers was addressed in 19.5.1 as described above.
To summarize, a clone now exactly duplicates its source transaction except for the Reference field, which follows Form Defaults.
If you are saying something different, please explain.
I have just updated from an earlier version and not expected these changes.
I have ticked the box for automatic reference in Form Defaults and that seems to fix the first issue.
Everyone updating from an earlier version (who had automatic reference numbers compulsary) will find this problem.
Maybe the program should behave differently and default to having this box ticked in form defaults so when the user updates they don’t have to dive into settings and make adjustments to get to where they were before??
Let me explain,
I have a custom field for my Sales Quotes, “Status”, I have ticked “Show custom field as a column”
In Form Defaults I have the custom field box and I have entered “OPEN” and then updated.
When the Sales Quote has been copied to a Sales Invoice I delete the custom field OPEN in the Sales Quote so I can sort the status List to show Open quotes at the top.
When I view an old sales quote (Already copied to Invoice, No OPEN in custom field), then clone it, the status column in Sales Quote list is blank.
It used to use the data from form defaults ( custom field >> OPEN ) so on newly created Sales Quotes I could easily tell were open.
Hope this is slightly clearer?! And also hope that an update hasn’t made Managers usability go backwards!
That would have worked for you, @itmoto, but not for anyone who did not have that setting. The fact is, the option for manual or automatic reference numbers and their interactions with Form Defaults turned out to be more complex than it appears. There was no way to do it without some category of users being surprised or disappointed. Interestingly, though, in the four months since the final implementation was set, you are the first to complain. I think you will find it preferable to the old approach, though. There was also an article in the Newsletter about using Batch Update to correct reference numbers if you were caught out by the change.
Perfectly clear, thanks. In your case, you will need to remember to enter OPEN in the custom field for cloned sales quotes. I can see that for your situation that might be a little extra work. From a bigger perspective, the issues were:
Expectation that a clone would truly be a clone, that is, an exact copy.
Formerly inconsistent behavior of cloning for different transaction types. For example, some would populate with today’s date, some with the source’s date.
Legal requirements in many places for unique sequential numbering, which is what drove treatment of the reference field to be different.
To solve your problem, the program would need to allow field-by-field specification of which form defaults were used in creating new transactions according to the method of creation: regular, copy, or clone. That would get pretty confusing, I think.
The automatic reference number is rectified with the tick box in form default.
A slight inconvenience but I will just have to try and remember to enter open, as well as remembering to change the date, otherwise I’m going to have a lot of converted
quotes in the database than I am meant to have!
That would be one solution or what @dalacor wrote on a similar topic:
“I would perhaps suggest adding functionality to the form defaults and create a cloning defaults options on the form defaults - this would allow users like me to say don’t clone date, whilst allowing others to say - do clone date and same for other fields.”
Either way I think Form Defaults should behave exactly how they are described and not overridden by the clone feature.