Cloning A/R receipts changed

I noticed a post 6 days ago, where AJD noted that when cloning Receipts and Payments, the reference number is brought into the clone. This was interfering with Automatic and Default references, as noted by Tut.

What I am concerned about, is that when I CREATE a receipt, and then clone it, not only is the reference number carrying forward into the cloned area, but the date is NOT. This has been an organizational tool (when instructing my data entry clerks) to have them clone all their entries after the first, so that the date will remain static, and all the A/R receipts posted for the day will be correct.

This only changed very recently. It is a major hassle, as I will have to go and manually check everyone’s entries now, or instruct them on generating a report to check themselves after each day’s batch is entered. I thought that was the purpose of CLONING…to carry forward the important info. (I agree with AJD that the Reference numbers shouldn’t necessarily be carried forward in a clone…how often will one customer’s reference number in a receipt-- their check number usually – match another customer’s??)

I have already seen where some inattentive clerks haven’t noticed that the date didn’t clone for them. This will create some trouble when reconciling bank statements.

Where can I make suggestions to have the cloning function return to its former behavior?

You just did.

I fail to see an issue under the circumstances you described, unless are you entering old receipts in batches and want some prior date to remain fixed. Normally, you would want receipts to be dated the day you enter them.

I noticed some changes as well that are now not consistent across the program.

If we open an invoice and clone it, the custom theme does not flow through to the new invoice. The date stays the same as the original invoice.

If we open a payment or receipt and clone it the custom theme DOES stay the same as the original transaction. The date changes to the current date.

I would prefer the custom theme transfer across, but the date changes to today, however at this point the behavior is not consistent across the program.

1 Like

Tut: Thank you for your reply. Yes, receipts are frequently entered into the system on a different day than the actual bank deposit was made, or as you noted— in older batches. But the record must show the actual date of the deposit, for reconciling the bank statements.

For instance, today I was helping the A/R department catch up with 2 weeks worth of data entry. So the system date was April 1, but I needed to post deposits (receipts) for March 19, March 21, and March 27. Each time I would clone a receipt, the date would revert back to April 1, and the previous customer’s reference number (check #) would clone. This renders the clone function useless, as I could simply enter an entirely NEW receipt instead and perform the same number of keystrokes for each entry, as I would be forced to do for a cloned transaction.

Not even one full week ago, the clone function in Receipts would carry forward the date, the customer (payer), the bank account, and the G/L account (accounts receivable). But now it ONLY clones the reference number and the G/L account. I am not sure why this change was made, or if it is a bug or result of some other change to cloning. I also don’t know if there is a work-around in Settings or Defaults that I could use to make the cloning function work the way I need it to, for convenience.

Thanks again. I appreciate your thoughts.

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?