When I copy an old Sales Quote that was cancelled, selecting Copy To creates a new quote for today’s date (which is what I want), but still has the cancelled box ticked. This is a bug, as new quote should be active.
I disagree. A copy is a copy, with all the same options. The software performs as designed.
I think Clone is pretty strict but Copy to can be more sensible. That’s why we have both Clone and Copy to.
1 Like
That was my thinking exactly. We already have a clone option and I can’t think of a single business use where one would want to copy to a new sales quote and retain the cancelled setting. Even if it was, it would be very much the exception.
So, @dalacor, how would you suggest the program decide which of the many options to leave in place and which to negate? I am not saying your belief that a new quote should not be Cancelled makes no sense for some workflows. But what about discounts, rounding, hidden totals, and themes? I can think of situations where users might want each of those negated, as well as circumstances where they would want them preserved. In fact, I can think of at least one situation where you might want to copy a sales quote and have the new one be Cancelled (catching up on entering transactions at the end of a month, where a quote was given and rejected verbally). No doubt, someone will suggest that all these choices be user-selectable. But that just spirals out of control into more and more complexity.
It seems to me that copying one transaction to another entails an obvious need for careful review. I cannot recall a single instance over the years where either a clone or copy did not require editing.
I was thinking about this and it’s not subjective.
Copy to function copies all attributes except for dates.
Cancelled checkbox is not a date but it is related to date so it should be reset as well. I mean we could as well add date field for when the quote was cancelled and in that case there would be no ambiguity why Cancelled checkbox is unchecked when using Copy to.
I think if we implement Copy to function on Billable Time, new billable time will have date set to today and Status will have to be reset to Uninvoiced because status is related to date.
You make a rational case, @lubos. But this has the potential to be incredibly complex because of the recent ability to copy all sales- and purchase-related transactions to all others.
Cloning was simple, because you ended up with the same transaction type—and therefore all the same fields—as you started with. The only real question was whether the date should be the original or current date. And that was resolved in favor of original, based on definition of a clone.
Switching to copying introduces the problems of new fields that weren’t part of the source transaction, orphaned fields with nowhere to put their content, due dates that may not make sense, customer/suppliers that have to be abandoned, rounding choices that no longer apply, etc. Soon, you realize that there is a complex map of things that carry forward and things that don’t. And it all varies for each combination of source and destination transaction type. But at least currently there is a standard: if there is a home for something, it will appear on the copied transaction with the same value/selection as on the source.
If you make an exception for fields based on dates, where do you stop? I am not saying your logic is flawed. I am just saying that the decision should consider more than a quote-to-quote copy job and the Cancelled checkbox. Otherwise, it will all seem random.
@Tut You are looking at the issue backwards. Instead of trying to work out whether cancelled and other attributes should be enabled/disabled etc, what you should be asking is what are you trying to achieve with the clone and copy to features. What is the end user business purpose of each function?
This is really at the root of the problem. It’s never been made clear what the end user business purpose is for each function when deciding how to implement it.
Your post in a way actually makes my point. We used to have the clone where it updated the date to the current date. Then it changed because a small number of users decided that they needed to have the date identical. This caused a lot of problems for me because I kept forgetting to update the date to today’s date. By focusing on the concept of a clone being identical instead of focusing on the purpose of the clone form from a business point of view, I personally feel that deciding on clone functionality was being looked at the wrong way around.
So I understand to a large extent where you are coming from, but by not looking at the end user business use for the feature, you are in effect creating a flawed feature from day one in that the end user has to remember to enable/disable/update certain things that they would expect the program to handle. I am pleased to have the copy to function as this has solved a major failing of the program for me. It is not a trivial matter to keep forgetting to change the date of a cloned invoice.
However, to directly answer your question - for me the purpose of the copy to for copying an old sales quote to a new one is to re-issue a quote to a client who has requested a quote months ago or to use the same item information in that quote for another client as it’s a very similar spec requirement. In every user case that I would be copying an old sales quote or invoice etc, I want the current today’s date and for it to be active on the basis that I want to use send that quote/invoice to a client Your example of an end of month thing is a very unusual scenario and is more likely to be the exception than the norm. Why create a copy to with settings and attributes that are not applicable to 99% of users and end user business cases?
As you can see, I keep coming back to the root issue. What is the end user business use case? This is what should be considered, not thinking about individual attributes and what is the definition of a clone etc.
I agree with the points made by Lubos in his post although he is looking more at the point that the date and the status are linked - which they are. But I think the focus is wrong. The end user business use case is what matters.
@Tut and @lubos what I propose - which I believe that I have mentioned in another post is the following.
Personally I feel that having a clone and a copy to (where you are copying a quote to a quote or invoice to an invoice) is not desirable because most users would not know what the difference is between a clone and a copy to. It’s not obvious to new users and even long time Manager users. I think the copy to should remain as quote copy to sales order or sales invoice concept, rather than also as a modified version of the clone with updated date.
For me the clone feature is flawed as the only use that I (and probably many others) had for the clone was to re-use old quotes and invoices to create a new quote and invoice. However the insistence of a small minority of people for the date to remain unchanged broke the usefulness of the clone feature requiring a new copy to feature to address this shortcoming. I frequently clone (copy to) old quotes and invoices as a lot of my business is repeated for various clients every year, but I very often kept forgetting to update the date in the clone.
What I would suggest is removing the copy to for “cloning” forms with an updated date. The clone form should be used to copy quote to quote, leaving the copy to function for it’s original use. Then in settings, I would have another settings feature similar to the form default - or maybe even in form defaults and I would enable the end user to set the default attributes for clone functions so that I could say - update date and those users who want the date to be identical to original could keep original date. Then I could say make new form active, not cancelled, whereas you could have the new form default to cancelled.
There is far too much focus on the meaning on the word clone and copy to in terms of deciding what atttributes are enabled/disabled/updated etc. In addition the copy to for the same form is just a confusing variation of the clone feature with just the date updated.
My suggestion would resolve all these issues making the feature work optimally for each business instead of trying to decide what end user business use each company would be using that feature for. We already have form defaults. Why not a defaults settings for cloning?
Which is the flaw in that approach.
Each user will have a different work mix so different frequency of what is usually the same and what usually needs to be changed.
I agree with @Tut, uniformly minimises the softwares learning curve and optimises ease of use across all users.
Personally I think clone should make an identical copy only excluding what must be unique by definition such as serial number and GUID.
If user particular users want something cleared then let them define that in form defaults.
I actually agree with you! Every user has a different work mix so the business use case is basically different for everyone which is why I am recommending a form defaults concept as suggested in my post. My point is that there has been too much focus on what cloning means and less attention paid to what users are trying to achieve with the clone feature.
If you take this post as an example, I see no point in the copy to feature copying the cancelled attribute, but going by your and Tut’s argument of uniformity, one must have the cancelled box ticked otherwise what about the discount box etc? Focusing on the uniformity ignores the business user case for the feature resulting in a situation like the original request in this particular topic.
Hence my suggestion to remove the copy to feature for quote to quote, invoice to invoice and retain that feature as it used to be in the past where you copy quote to invoice etc. Then use form defaults to specify how cloning works for your particular business. This solves everyone’s problem in my opinion and removes the duplication of a clone and copy to which differ only be whether the date changes.
For your needs maybe, but not mine. I have never ever cloned and wanted to keep the original date. Hence my point that the focus on what cloning means defeats the whole purpose of the feature as the focus is not on the business use case.
Anyway, the only way that I can see cloning working for everyone is to allow business to define what is cloned/updated for their particular business. Otherwise we will be having this discussion ten years from now with the same underlying flaw - that what works for you does not work for me and vice versa.
I think Lubos has the right idea.
A Clone is a Clone so everything should be copied across.
Copy To (e.g. Quote to Quote) should copy everything except Date and should reset status.
1 Like
I am looking at potential uses by all users, not just your personal case, which was dominated by your habitually forgetting to change dates on clones. Others have different needs, purposes, etc.
That is exactly the point I made earlier. One almost always has to change something when cloning or copying. Your own later statement reinforces my point, when you say, “…the purpose of the copy to for copying an old sales quote to a new one is to re-issue a quote to a client who has requested a quote months ago or to use the same item information in that quote for another client….” In either situation, you would need to update expiry dates or change customers. In neither would you send out the identical transaction form, even if the cancellation option was removed.
On the contrary, I think it is far more common than you may think for small businesses to fall behind on accounting entries. Many dump a batch of receipts on an outside bookkeeper at the end of the month. Even businesses with large accounting staffs have a processing lag. Think about your own situation, where you have become enamored of importing bank statements. By definition, you are making entries in arrears.
Not to belabour the point, this is why I am proposing a default form settings for the clone function as I have already said that everyone’s user case is different. And you are not looking at all potential uses by all users. The focus has always been on what the definition of a clone is, not what end users want to achieve by cloning something.
The problem I have is that other people’s business needs have imposed a work flow on me that does not work for me when cloning information because it does not update the date. Why not give end users the flexibility to customise this to suit their work flow.
When talking about having to change things in a cloned quote, yes naturally I might need to change the quantities, prices or client etc. But I am expecting to need to change that. It’s not the same as having to remember to change the date or status of a quote when Lubos himself acknowledges. It might sound the same to you, but it’s not the same thing. I am expecting and wanting to change the customer or amount or price. I am not thinking of attributes like cancelled. So your argument is not really about the same thing.
I don’t know about this end of month thing. But regardless - it is the same as the date issue and the status issue. A workflow that does not work for me and no doubt many other people is being imposed on our businesses. Hence my suggestion for a default forms setting to set default workflow for your particular needs.
Anyway. I think the various points have been made and we are all in agreement that every business is different. I have proposed a solution that would work for everyone unless someone has a better idea than my default form idea, I would suggest we go with that.
I agree with you @itmoto, the different workflow requirements are already being met. If a user needs to keep the historic date, use “Clone”. If they need the current date and status items reset, use “Copy To”.
In my opinion having two functions in Manager which do almost the same thing is a bad idea from an ease of use perspective. While it may result in a small time efficiency for power users, in contrast for new or infrequent users it is just random names for subtlety different operations which behave unpredictably.
As for what users would prefer when copying / cloning dates. That will depend on the individuals most common use case.
If accounting software is used when user needs to do the bills, such as around BAS/VAT submission time, or monthly. Bank statement import works well with this use case and data entry is almost always done well after the transaction date. Then when:
-
Creating a later periodic similar transaction. Most efficiently done is the date is copied, and used as a reference to select the next in the sequence.
-
Creating a similar transaction with no clear date relationship. Most efficiently done if the date is cleared, indicating it needs to be set.
Alternately if the accounting software is used in real time as a point of sales terminal, then the current date is mostly equal to the transaction date. For POS terminal use
- When coping or cloning a transaction to assist entering a transaction today, then replacing the prior transaction date with today’s date is the most common requirement.
Both work flows are appropriate for different users. It is for that reason my preference is for the base copy / clone to copy / clone everything (other than data which must be unique by definition). But add user customisation for particular work flows.
It is great that people can use Manager in different ways that suit their needs. This also sometimes gives reason for debate where the use and exceptions to this use are highlighted. As for the “clone” and “copy to new” debate, it may be helpful to first look into its main use. You do not want to create a new item that contains similar information that already was entered in another item. To improve efficiency you want the information copied.
In ICT terms a clone contains the structure of the original database while a copy would contain both the structure and the data. The original clone function of Manager should therefore have been called “copy” because the structure, settings, and data are copied.
Let’s assume for argument’s sake that we rename in Manager the current “clone” to “copy” as that is what it is and keep the “copy to new” and explore what this “new” would refer to. In this case to today’s date as the only change in the data that was copied, So it could have been called copy to today 
The original question then would mean “if it does make sense to copy something to today and not make the canceled sales quote an active one?” This could be considered a best/most use case scenario, which is a requirement to be reviewed here. Manager jargon treats “clone” as copy with the same structure with identical data, and “copy to new” as the same structure with almost identical data except for the date. Therefore you could argue that a most use case scenario also would except the cancel status and can be included in the “copy to new” feature.
Lubos has already indicated that he agrees with the need to reset the status of quotes etc when the date is updated. This is no longer in dispute and will be implemented.
The remaining point under discussion really is about whether it makes sense to have a clone and a copy to (for same forms) as they are basically identical apart from date change. Patch and I argue that for new users or inexperienced users is not very intuitive. In my opinion the copy to (for quote to quote) was only ever implemented to address the shortcoming of the clone option not updating the date for users who wanted the date updated.
I would disregard the discussion on what constitutes a clone vs copy and focus rather on the business case use of these forms and focus attention on how to ensure the forms work for all business that have different business use case. Hence my recommendation to remove the copy to (for quote to quote) and revert back to the original use of Copy to for quote to invoice etc. Then simply fix the clone issue by enabling businesses to define what they want cloned by default in settings.
Neither aspect of that statement is true. Disagreement continues in this thread, and the developer’s comments were not an announcement of commitment to change. He only moved the topic to ideas. The ideas category is not a development roadmap. It is a place for “Discussion about ideas for Manager.”
I have been thinking about the broader issue of copying a transaction of one type to the same type. A small thought experiment illustrates how convoluted things can become.
Imagine that you start with a sales quote. You copy that to a sales order. You copy that to a sales invoice. The customer calls a year later, after your prices have changed, and says they want to buy the same thing. So you copy the old sales invoice to a new sales invoice. @dalacor would not have to worry about forgetting to change the issue date. But these are the other fields that could require editing:
- Due date
- Reference (unless Form Defaults for Sales Invoices is set to automatic)
- Quote number
- Order number
- Unit price
- Inventory location (if you need to ship from a different warehouse)
And, if the Total amount in base currency is checked for a foreign-currency customer, you would need to enter a current exchange rate in Settings.
Maybe during the interim, you actually sent another sales quote, but never turned that into a sales order, because when you sent it the customer declined to buy, so it was cancelled. Or maybe you will now. So you might have multiple quote and order numbers floating around. You could have a due date before the new issue date that will be automatically converted to the issue date. You could have obsolete pricing from a warehouse you have since closed.
What I am trying to emphasize is that no one should ever clone or copy a transaction without examining every single field the new transaction contains. Tales of woe concerning issue dates are overblown compared to other mistakes that could be overlooked. Implementing any of the suggestions proposed in this thread leaves the majority of potential problems unaddressed. And the list of fields requiring review and editing changes with every different transaction type. So why should any energy be expended on whether a sales quote is cancelled, given the other things that can go wrong.
In fact, you could make a strong case that automatically cancelling every copied quote would be preferable. Then users would be forced to review the new quote and make other necessary edits.
Actually all that clone and copy to are is finding ways to help improve the speed in which one can enter data, so not sure why adding a cancel will help. Nothing can be fool proof and if something is terribly wrong it would either end up in suspense for it to be corrected, or at the point of checking balances, P&L, etc come to light. It is indeed important that people check carefully what is entered, but artificially adding a cancel is in my view not a good way forward.