Tracking customer payments

[nattivillin]

What if you don't use Quickbooks?

How can CommitCRM keep track of when a charge was paid, how much, etc?

We are considering using CommitCRM in our retail stores and ditching quickbooks. The biggest problem is keeping up with the multiple deposits, upfront charges, last minute additions, etc.

Once you add a charge to the ticket, how can you show a charge as paid? How can you show a charge as partially paid?

Ive looked all over and it seems that CommitCRM in no way is capable of tracking payments.

[lpopejoy]

Re: Tracking customer payments

There is no way... For payments you would have to use Quickbooks.

CommitCRM really doesn't work well for a retail store scenario, IMO. It would be really nice if CommitCRM would extend the program just a bit to allow payment tracking, open balance, etc... Then those numbers could go over to Quickbooks just like the invoices do.

Depending on your size, Quickbooks Point of Sale might work well for you, but, I know, the problem is then you don't have any of that retail "history" inCommitCRM.

Let us know what you decide - it's a hard choice, and maybe you can come with a better solution.

[nattivillin]

Re: Tracking customer payments

Figured as much, just wanted to make sure i was not overlooking it.

After 2 years, we have come to enjoy using CommitCRM for our field work. Then employees starting asking we don't we use it in the stores for everything, since its fast, stable, and the history viewing and tracking is great. Especially if we start sending all client email communication through the connector, it now shows up in the history. Who said it, who did it, is all at our fingertips, much more than QB could ever do.

But we cant use it like that with out some way to receive and track payments. People make deposits, people make partial payments, people are due refunds & other retail happenings.

We were trying to get away from using 2 systems. Separate things in QB, separate things in CommitCRM.

CommitCRM seems to be focused on customers who only do billing. I guess that how most support businesses do it. That is the only way it could work with QB, someones job is to create invoices and send out bills.

We have people standing in line waiting to drop off, pickup, make deposits, etc. You would need multiple copies of QB and multiple databases for it to work that way with CommitCRM. QB is already so slow we run separate databases at each store.

What a mess

[lpopejoy]

Re: Tracking customer payments

I feel your pain. So what you would LIKE to do is have ONE CommitCRM database and use that at all of your stores? That way you have the same history regardless of where you go, right?

If you have some development skills, you could write your own application that would integrate with CommitCRM AND could also then either create QB IIF files to import the payment information or integrate directly with Quickbooks as well using their COM API (kind of like CommitCRM does) or if it was a web app, use the Quickbooks Web Connector to pull in all the payment information.

[nattivillin]

Re: Tracking customer payments

We only have/need 1 CommitCRM db, we have multiple qb databases. CommitCRM works well with terminal services.

Writing another program would still be using 2 programs. Unless we are going to write our own module to connect payments inside of CommitCRM.

If someone is good enough to do that you have a customer, and you could sell it to anyone who needs it.

CommitCRM should add it as a module like the rest of them. Then people who want it can buy it and people who need it don't have to mess with it.

$250 bucks to add some form of payment center to CommitCRM doesn't sound bad, id buy it as soon as it was released.

[Support Team]

Re: Tracking customer payments

Thanks guys.

We can see how it would have helped, however, at this point we're focusing on other more popular requests.
A payment module requires much more than it seems. As there are good solutions for this available in the market using the link with QuickBooks or enhancing it with RangerMSP's API and the other products APIs sounds like the right solution.

We'll keep this in mind though. Thanks nattivillin for bringing this up.

Thanks,
Sheli

[nattivillin]

Re: Tracking customer payments

What other products API can we use? Is there a list of products that commit's api works well with, or it a matter of finding one that works?

If you wont offer it as a module, how about partnering up with some companies to drive them business from here. Then we would know it at least works before buying.

[Support Team]

Re: Tracking customer payments

RangerMSP has an API, other products, like QuickBooks, have their APIs, you can use both side APIs to develop almost anything you need.

What we referred to earlier is that we're not going to develop it ourselves, at least at this stage, however, the available APIs already provide you with the option to develop such integrations yourself.

Thanks again for all your feedback,
Sheli

[sb020397]

Re: Tracking customer payments

What is on the roadmap for Quickbooks online? Balances before creating tickets would be priceless. Collections are getting hard and I'm tried of my staff creating tickets for people with balances past 100 days. Granted we can create popup's to notify them but that is a lot of work as well.

[Support Team]

Re: Tracking customer payments

Thank you for posting this. In case we get this correctly, we will take a note about your suggestion to show balances from QuickBooks Online in RangerMSP.

[sb020397]

Re: Tracking customer payments

This would be so amazing! Be nice if we could sync balances too but this would be a great start.

Wonder if it is achievable thru the online services and the QB Online API.