Cloning A/R receipts changed

This is not true. Other information is also cloned.

I think this needs to be in the bugs category for inconsistency. The clone button should clone the same details across all transaction types. It seems silly that on one transaction it would move the date to current and on others it does not.

It’s not a bug when it does what it is programmed to do. Wishing it was programmed to do something else is a different issue.

Two things don’t make sense:

  1. The inconsistency of the cloning behavior across various transaction types, as brought out by Austin Walters; and

  2. The fact that the cloning function would be purposely programmed (or changed in its programming) to create MORE keystroke steps when using it. [By definition a clone of a transaction, like any macro, is designed to save keystrokes.]

This recent change in the function causes the user to have to edit the same number of fields as if they’re entering an entirely new transaction altogether, except if — by some remote chance— they are entering the same exact check number for the same exact customer, but on a different date.

This change also seems to have occurred right after an update was done in cloning for a different transaction type. (I remember reading the update, but it was for a module that I rarely use, I think, and now I can’t recall what it was.) But either way, one could certainly say it is a bug in the cloning function when you can clone an invoice and have the date carry forward in the clone, but NOT have the date carry forward for a payment or receipt. If you don’t want to call it a bug, then we can revert back to my original post and call it a change in cloning behavior that is inconsistent, frustrating, and ultimately useless for user-friendliness and saving of time and keystrokes.

Tut: can you describe a situation in your typical workload where cloning every field except the date is saving you keystrokes? I ask in sincerity— I can’t picture when that is useful for payments & receipts.

See my above post.

You often speak to the consistency of the program, yet here you don’t seem to care about consistency or maybe I am not explaining it properly.

Cloning a receipt CHANGES the date of the transaction while cloning an invoice KEEPS the original date.

Cloning an invoice RETAINS the custom theme setting while cloning a receipt CHANGES the custom theme to the form default.

This is not consistent and is going to cause data to be entered incorrectly. We shouldn’t have to guess what cloning will do, it should be the same across the board. I really couldn’t care less WHAT it keeps, but it does need to be the same.

Not necessarily. It can also be used to replicate information without re-entry, reducing the possibility for error. The reference number is a small part of many cloned transactions. Spelling of names, duplication of notes, replication of account numbers, accuracy of multiple line items, consistency of account posting—all those could also be reasons for cloning, even if reference numbers are not used. In fact, by comparison with some of these other common reasons, reference numbers and dates might be considered small irritations.

Not true. I care very much about consistency and share some of your concerns. In fact, I had previously communicated privately with @lubos on this exact subject, but do not have an answer yet. So I cannot give you justifications for the differences. I’m not sure there are any, other than modules having been developed at different times with different behaviors coded in.

I was also surprised by the change @ElizP mentioned to start this thread. It has impacted my personal workflow in a negative way.

the clone function is used by majority of the users to duplicate the entries of a transaction which excludes the transaction date and reference.

unless the user is a regular back-logger, cloning the date would be a trouble and a waste of valuable time.

while I want the program to have consistency across all tabs, i would not want cloning the date and reference fields. the date should always be current and should not be carried forward from the transaction being cloned.

users who enter backlog data may simply change the system date, reopen Manager and make their entries.

While that would certainly work, I would not advocate that as a regular practice. Entering of accounting transactions from prior dates could easily be interrupted by other work, where incorrect system dates would be troublesome. And many users in a multi-user environment will have no access to such system settings.

I agree with the consistency portion of this, but the date could go either way. Our use-case for cloning transaction is for recurring transactions or repeat transactions. For example every month we pay for our e-mail service, it’s always the same price and is not an invoice / payment, but an auto-charge on our credit card. I find the date changing to the current date helpful.

The latest version (19.2.74) is making cloning consistent across the entire program. That is every field is being copied across. This includes Reference field too which is probably not ideal as reference numbers are meant to be unique. I will be thinking about this.

Perhaps reference field being copied is not a problem if the program makes it obvious there are two transactions with the same reference so it’s easy to spot and easy to fix.

It is not consistent. I have forward the results of my tests on all tabs by private message.

I agree with Tut. Cloning is not consistent.

The cloning works in what I consider to be a proper way, when used in the Invoicing module. The date clones, and other pertinent info clones.

Cloning is inconsistent within the Payments & Receipts module. I still do believe it should work the way the Invoice cloning behaves: dates—definitely yes.

I am more than a little surprised that the need to enter “backlogged work” (as you have called it) is not considered on this forum to be more of a ”norm” in the accounting and bookkeeping fields. I don’t know of any accountants who work in the present. There is always a month that has just ended, a quarter to reconcile, a tax year that we are working on— none of which are TODAY’S date.

Do all of you really get all the day’s work from your clients on such a timely basis that the deposits (receipts) from today are being entered today?? I am thoroughly impressed!! I even have clients who delay getting their documents to me by many months. Others are on either a monthly basis or a weekly basis. NONE will get their deposits and sales invoices to me daily.

But please— don’t change the cloning behavior in the Invoicing module so that the date won’t clone!! I will have to stop using cloning altogether if you do. The date carrying forward has been such a time-saver when cloning in the past. Now, not so much.

Most users of Manager are not accountants doing books for clients. Most are small business people doing their own.

Can you check the latest version 19.2.75? It should be consistent now. Version 19.2.74 was not.

Thank you, yes cloning is behaving “properly,” in that it is now consistent across all modules in Version 19.2.75.

Others who stressed that they didn’t want the date to clone should be cautious, as ALL information is now cloning across the board.

I will have to personally deal with the cloned REFERENCE on my own. But that is a slight amount of disruption to my workflow, compared with the date.

I will have to watch out for when I get up and leave my desk in the middle of entering. I used to be able to know that I had just cloned a transaction, because the reference field was empty. I will now make it a point to ONLY get up to refill my coffee mug after I have pressed CREATE, and the created transaction is visible on the screen…then I’ll definitely remember where I left off. :0)

Tut: I was unaware that most users of this program are small business owners keeping their own books. There are so many excellent features for accountants with multiple clients within the program, such as the multiple business feature, and the ability to assign rights to multiple users, across any or all businesses. I am thoroughly impressed with this program, and the fantastic customer service and attention to user needs. Glad I found Manager!

Thanks again Lubos.

In the Sales Invoice tab (as an example), is there any way that the Clone program could be set up so that if the auto numbering default is set to Automatic in the form default, the reference field would be blank in the created clone, so that the reference field would auto number when the Create button is clicked? Could this be applied to the Purchase Invoice as well?


I have just updated Manager as I was experiencing the problem where cloning invoices was copying the original invoice number across instead of using automatic So thank you for fixing that.

You are probably aware, but when I clone an invoice that has quote reference number and PO Reference Number, these are being cloned as well. I cannot see any circumstance when quote and PO reference numbers need to be cloned as the purpose of cloning is to copy the transaction items if you are issuing identical invoices.

I will also add to the feedback about dates being cloned. In every case when I have cloned something I want the date to be today’s date not the original date.Or if I do want a date that is different, it will never be the date of the original being cloned.

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.

I can’t recall a single instance where I have ever wanted to clone the date - today’s date is far more relevant to me as most of the time I am cloning sales invoices which I wish to issue today.

You seem to contradict yourself, @dalacor. If you want an identical invoice, why would you not want the reference numbers cloned? You can always change them, of course, but not cloning those fields would defeat the point of cloning.

Cloning behavior is now consistent across the entire program. All fields are duplicated from parent to clone, with one exception. The transaction reference number is not cloned, thereby allowing a default, automatic sequence number to be assigned. This accommodates common requirements for unique sequencing.

That is certainly a valid point of view, and might be shared by many users. It breaks down, however, as soon as you try to enter a bunch of cloned transactions two days after the fact. You set up the first, but would need to change the date on every subsequent clone. So the convention adopted was to produce literal clones (with the one exception for sequence numbers mentioned above). I was initially in your camp, as most of my transactions are entered contemporaneously and many of them are cloned. But after only a week or so, I came to strongly prefer the current approach. Now, I don’t need to remember what is duplicated, what is updated, or what is blank. When I asked for a clone, I get a clone.

I would have thought it was blindingly obvious why one would not want to clone client purchase order and quote reference numbers from the original invoice to a new invoice!

This is self explanatory. Please point out a common usage scenario where you would want to clone a client purchase order reference number onto new invoices! Common Usage Scenario (not a rare unusual case).

Easy enough. A quote is given covering services or goods delivery every month for a year. The customer issues a purchase order covering the full year, but with service or goods to be authorized/confirmed one month at a time by some form of notice. Every month, after receiving the confirmation, you would clone the sales invoice; everything would be identical except issue date, including quote and order references. Such arrangements are frequently called blanket purchasing agreements, master orders, or indefinite delivery contracts. They are very common, especially in larger organizations where approval processes are based on thresholds. The annual contract has to go a long ways up the ladder for approval, but monthly portions are small enough to be handled much lower down.

Another example: a service contract for specific service categories is approved, but exact tasks to be performed are unknown. When a specific task in one of categories comes up, the buyer issues a task order with a detailed statement of work. You might clone a prior sales order, modifying only the line item description. You might similarly clone a previous sales invoice from when you did identical work at a different location. In both cases, the quote and order references would remain unchanged. These are typically called task order agreements. Competition for the basic agreement can be fierce, but if you win, you may be able to obtain task orders with no further competition, based solely on already-established qualifications and rates.