Unique Payment ID

[LukeDouglas]

I am posting this in the Bug Reports as this is a 'bug' even though WHMCS developers designed the functionality to ensure that 'unique' payment ID's must be used. This is a flaw, pure and simple. When you have hundreds of clients with most paying by check number, you will eventually have payment ID's that match, ie: Ck#1142!! This is causing a big problem with my staff in posting payments. If the design for this functionality was based purely to ensure that payments were not doubled up, that is a functionality that should not be the responsibility of the program but the responsibility of the people using the application. You can't program for stupidity, at least not in this situation as it creates other unnecessary problems such as trying to post the same check number used on two different bank accounts to record a payment on two different invoices.

 

This needs to be fixed!!!

[WHMCS Nate]

Hello Luke,

 

As a broad rule discussions like this are not the purpose of this specific forum area. Normally I would reply with an explanation about why we made the choice we made and then close this thread. I think that works counter to your goals. You clearly have raised this issue before and gotten an explanation that you disagree with.

 

So instead I am going to move this to the technical issues area of the forum where people can discuss it further.

 

Have a great day,

 

Nate C

[LukeDouglas]

Nate,

 

I won't bring up the subject again. It's just frustrating to have to create unique id's for the same check number, ie: 'Ck #1001', 'Chk #1001', 'Check #1001', 'Chk No.1001', etc, etc, etc.

 

Luke

[WHMCS Nate]

Luke,

 

To quickly provide a touch of commentary. I can say that this is an bit of functionality that caused serious confusion for people when it allowed using the same ID for different transactions and when the behavior changed.

 

When you add a transaction through the add transaction interface it allows you to enter a transaction ID and a Description. One alternative way to interact with the system as it behaves now would be to use an ID that has a higher chance of remaining unique like including the first 5 digits of the account number the payment came from & the check number, or using the transaction number with your bank for depositing the check, or something totally different and then use the description to mention the check number.

 

I do notice that the description field is not present when adding payment in the invoices tab, if adding a description field there as well would enable you to more easily track back transactions without having to have unique IDs, that is something we can look at adding.

 

I understand that this would require a change in behavior, but would that be something your team can adapt to?

 

Have a great day,

 

Nate C

[blakeh]

Why is the transaction not unique already because it's only attached to a specific invoice?

This change is very frustrating. We get ACH payments and there is no other specifier other than it's an ACH payment and we have to figure out new unique things to put in the payment field.

 

This really is a bad change and I don't think it takes into considerations bookkeeping practices or even other software packages.

 

For instance, I can enter the same check number in Quickbooks or Xero all day long because the transactions unique nature is composed not just of the ID, but what customer and invoice it's attached to.

 

WHMCS in making this change is almost trying to push that a transaction is unique and stand alone, regardless of it's other properties such as what customer and invoice it's attached to.

 

Now I realize that you can have a transaction attached to no invoice, but it still has to be attached to a customer.

 

But depending on the user to be the generator of unique IDs and not handling it behind the scenes really does seem shortsighted.

 

Maybe it would be better that this is a configuration option that can be turned on or off for each installation. I recognize that you may have users that this has created trouble for, but now that it's been changed, it's creating issues for a new group of people.

 

Just my two cents.

 

bh

[blakeh]

I think I figured out the WHMCS thinking here. You're looking at the transaction ID as a unique for tracking payments. I'm looking at it as just attaching a payment to an invoice.

 

I would suggest that for manually entered transactions (add payment to invoice, etc) you need to give us some where to generate a unique transaction ID. I don't care about the transaction ID when I post a check, cash or ACH payment. If someone gives cash, I just want to type in cash. But if you need something unique, then generate a random/unique prefix for me, or take what I put in the transaction field (ACH, Cash, Check #, etc) and prepend or append a unique ID to it to maintain your requirements.

 

Something needs to change. I can keep figuring how how to type ACH or CASH with new and exciting things in the field.

 

bh

[CavalloComm]

OK - here is a good answer to this. We import our transactions to QuickBooks.. and for that, QuickBooks requires a unique ID, otherwise it will fail, and not import.

What I do is add a dash, and the date at the end, like DDMMYY or something

[blakeh]

I recognize that some software like QB require a unique ID, the point I've been trying to make is that WHMCS should generate and take care of that behind the scenes and not depend on user input to do a unique ID.

 

If you've been running the software for years do you really want to deal with the issue that you can't enter a reference number because 5 years ago you entered the same thing?

 

I've always treated the field when adding a payment to an invoice as a reference or memo field. It should be such. Let the software generate unique IDs used for exports and internal tracking. That's what other accounting packages do. Have the user be responsible for this just seems like a weakest link issue. Especially because it's now an issue because of the a code change.

[Damo]

I agree that it's been a pain in the butt since the change came in but as Nate pointed out above the description field can be used as the descriptor. It would be good to see this on the Add Payment screen.

 

We now use the invoice ID and the cheque number. ie Invoice#-cheque#

[netwood]

Yeah, this code change sux and I don't agree with the reasoning behind it at all.

WHMCS shouldn't dictate how we need to enter payments.

If WHMCS needs to have a unique transaction number, then code one behind the scene.

[rrobbins]

If you want to be able to have duplicate transaction IDs you can vote for this feature: https://requests.whmcs.com/topic/disable-unique-transaction-id-validation

[WHMCS John]

Hi,

In the meantime, duplication transaction IDs can be entered via the Billing > Transactions List > Add Transaction tab.

[blakeh]

Hi,

In the meantime, duplication transaction IDs can be entered via the Billing > Transactions List > Add Transaction tab.

 

So if I understand what you're saying, there is a unique check on the add payment to invoice process, but not on the add manual transaction entry? So in other words, there is no consistent unique checking throughout the system??

 

A change was made at the point where most people use it that caused problems, but the supposed reason for the change isn't uniformly enforced throughout the software, which defeats the argument for making the change?

 

Please tell me I'm wrong in my understanding of this.

 

bh

[LukeDouglas]

Whether it is consistently applied across the application or not, it's a dumb idea. Here's why.

 

I have about 100 clients that I bill periodically (monthly/quarterly/annually) as well as custom invoices. I have tried to apply a payment from client C but I couldn't use check #127 because I had another client that I had applied a check that was also #127 on their account. Most new businesses start at check #101 or #1001 so it is probably a certainty that you will receive checks with the same check number from different clients. Moreover, if you receive a check for multiple invoices, we use to be able to use the same check number to apply to multiple invoices for that client. Now you can't do that. You have to apply the check to just one invoice for the full amount which creates a credit and then apply that credit to multiple invoices. I have had clients send me emails and call me to complain that they want the check number on the invoice payment confirmation so they can match up with their records. Sorry, they are out of luck. This causes issues with my clients and I, for one, do not like that WHMCS staff is making management decisions for me. If I want to use the same check number on multiple invoices, that is my business, not WHMCS.

 

It was a 'dumb' move on the part of the development team.

 

FYI, I have over 30+ years of application development so I do know a thing or two about issues like this. I also know that if you don't 'think' about how your design affects your target customer, you can screw up big time. This is just a situation where the WHMCS development team didn't have their thinking cap on.

 

WHMCS, please remove this restriction.

 

Luke

[myworksdesign]

OK - here is a good answer to this. We import our transactions to QuickBooks.. and for that, QuickBooks requires a unique ID, otherwise it will fail, and not import.

What I do is add a dash, and the date at the end, like DDMMYY or something

 

We also import our transactions from WHMCS to QuickBooks Online - using our own custom module

 

WHMCS + QuickBooks Online Sync

 

It's a pain for us as well, because if we bulk-pay a few invoices in WHMCS, like if the client paid with a check - it puts in the same transaction number ( the check number ) for these transactions just fine!! But if we try and add another single transaction with the same check number, it gives us the error. There's absolutely no need to limit by transaction number.

 

Our QuickBooks Online module does handle it perfectly, syncing mass payments over to QuickBooks Online!

[LukeDouglas]

myworksdesign,

 

It's a pain and totally uncalled for but it appears WHMCS is steadfast in their position so don't expect a resolution to this 'bug'.

[VoiNetworks]

Another vote to disable the transaction ID unique requirements when manually entering payments.

[othellotech]

I have tried to apply a payment from client C but I couldn't use check #127 because I had another client that I had applied a check that was also #127 on their account

As an FYI the "best" way to enter checks (or cheques as we call them) into WHMCS is

sortcode/accountno/chequeno

as sometimes you'll need to know that additional info and at least then the checks will be unique

 

Although it's quite possible to need duplicate transaction ids from other payment methods - we have 3 bank accounts USD, EUR and GBP and direct-to-bank payments have many times had the same "unique ref" from the bank as it's only unique within account - temporarily adding -ccy to the end to solve this whcms change impacting our normal processes