Work Order Deposits Revisited

One solution might be to go ahead and refund CASH, but do not take it from the till. Then, select the customer account, press F12 and enter positive cash and negative ON ACCOUNT. This way, there will be no net impact on cash and the refund on account will appear on the customer statement.

Never tried it, but seems it should work...

Jason

"Terrible Tom" wrote:

TT,

This all gets back to the deposit for an "On Account" customer. Why take a deposit for an "On Account" customer? You already trust him to pay the bill, why do you need a deposit?

There are lots of reasons. One that I have frequently is that I do NOT trust the customer with a charge account, but rather than give them a refund, I want to give them a refund "on account" so they will spend more money in my store. This is like giving "store credit" for a refund without having a gift card or voucher program.

Another example: I sell very expensive items by special order, so when a regular customer (with a credit account) places an order, I need to collect a deposit for cash flow purposes. Then, when the item arrives, I place the balance on thier account and charge interest on the balance.

Jason

"Jeff" wrote:

Jason,

Don't shoot the messenger, I'm just telling you how the program is designed and the thought process behind it.

If you think it should be changed, on the Community webpage go to New and make a suggestion for a change or vote for an existing suggestion, which I'm sure is already in there.

I didn't mean to pull out my Uzi, Jeff. You asked a question, I answered it.

I agree with the thought process that when you "refund" a deposit, usually you are doing it with cash. Since there is a workaround, there's not much point to changing the system...

The main problem I see here is how the statement looks. If you enter a transaction on the wrong account and later reverse it, it shows up on that customer's statement. I'd like to be able to mark certain transactions as "invisible" so they don't appear at all on statements. But that's another thread...

Cheers,

Jason

"Jeff" wrote:

As to why, well, it's not uncommon at all for my customers to pay for their entire order up front then change some small facet of the order. The resulting balance is rarely identical to the original balance, but I don't want to require a customer spending thousands to come in and give me an extra $50 before I'll deliver. Similarly, if the change results in a credit I'd like to encourage them to find something else to buy before I issue a refund. I don't want to take a deposit 'on account'. I want to refund a deposit and have it show as a credit on account. We also do a lot of special order deliveries on a COD basis, almost all of which have a deposit of 1/3 the order total.

Here's what we've figured out since the original post: You can only refund a WO deposit with a similar transaction type. I suspect that you are correct about the 'on account' thing. RMS won't (and rightly so) take a deposit on account. A refund of a deposit is simply a negative deposit, so it won't permit it to be tendered on account. You can, however, allocate some or all of the deposit to 'on account' when picking up the order. In one example, a customer ordered a $1699 item with a 100% deposit. The customer opted to go with a different model with better availability that sold for $1469. You cannot refund the deposit 'on account'. You can, however, pick up the entire order and put the outstanding balance (positive or negative) 'on account'. I believe that we will be adding the item at the regualr price, deleting the original item and adding our non-inventory 'COMMENT' line with 'DELETE ME' as the description and $230 as the price. When we add the S/N before shipping, we can delete the COMMENT and tender the deposit overpayment on account, resulting in the credit we sought from the git-go. So the answer, I think, is waiting until the order ships to put the credit on account. Now that I've figured this out, I can see how this is probably proper accounting procedure.

IMO, Jason's solution of setting the customer and tendering an empty transaction with positive cash and negative 'on account' is not good. It'd be better to tender the refund as cash paid out then set the customer and take a payment (F8) of the same amount of cash (as I described in the original post). It's two transactions and it looks bad on the monthly statement, but it works.

Strangely, I find that many of my problems are caused by a failure to think through the entire proper accounting procedure for whatever it is I'm trying to do.

Thanks for the advice, Tom

Tom,

Actually, if I am reading this right, your solution results in a line on the customer statement that will read "payment received," which it certainly is not. My solution is no better, however (if it even works!)

Now I am starting to see your problem better. Interesting...

Jason

"Terrible Tom" wrote:

TT & Jason,

There are two more options;

One option is to change the customer's properties before the deposit to a non On Account type, tender it and change it back. Without really testing this, it shouldn't have any issues with the Statements. I'll play some more.

Another is to set up the customer again, without the On Account and then merge the 2 customers together.

;-)

Jeff & Jason,

I think we've decided to leave the deposit with the WO until the order ships, at which time we can apply any overpayment to their account. Of course, if the customer comes in looking for their money, we can easily do a cash or CC refund. Check refunds might take a little longer (check refunds all come from HQ, so the stores won't be able to do anything at the time).

I often find myself managing the exception. This is bad, and I know it. The problem we're discussing is only a consideration on a small percentage of our transactions. Yes, it's a legitimate concern, but in the overall scheme of things it's a small concern. The "we'll credit your account when the order ships" method will work 95% of the time that this scenario presents itself. 4.9 of the remaining 5% will be 'customer present' situations, leaving me with a one in a thousand problem.

Thanks for the advice and groupthink, Tom

TT,

Actually, you _always_ should manage the exceptions. The run-of-mill stuff just happens! ;-)

I should have typed 'managing *to* the exception'. An activity to be avoided, IME. You don't want to trash a good procedure because it doesn't fit ships, at which time we can apply any overpayment to their account. Of

TT,

I understood, I was just yanking your chain a little. ;-)

I have read all about this problem of returns / cancel workorder deosits cannot go on account. but here is the problem I have today

A cashier removed all items from a work order and tendered to Account and the work order is gone but the money is not on Account and I cannot find the money anywhere. So where is the money and how to I get rms to associate it with the customers account ?

Where did the money we had on deposit go to?

We post our batches and export to Peachtree so I might see it tomorrow, any advice , help or guidance will be appreciated

DD,

One of these days I'm going to figure it out too. It's on my very long list of things to do!

When you change the items to ZERO and save you have an option to refund or not. If you do not refund the total stays on the closed work order. If you do refund you must select a payment other than Account. I am attaching a report that will list you the total of the Deposits that are associated with closed Work Orfers.

Other option if you want is to give you a SQL program to re-open theclose work orders that have Balance and allow you to go back to them one at a time and refund them correctly.

A program can also be written to apply the deposit to the account but this will be complex and cistly development. Hope attached report helps.

begin 666 Custom - Deposit Balance Report.zip M4$L#!!0````(`,2 JC3G3T)PY ,``"X5```C````0W5S=&]M("T@1&5P;W-I M="!"86QA;F-E(%)E+ MD9B)>A(]'C(.'DT,_;&99+%/72P2 M=5WM?CH2Z%N):7M'4S+6LZWI&"C) M-I7L704#UP!=%WM!WI&[ZX%'VB34/\=^!NFQA2X=U.5,GY.+'.)C,AAACN/E MR.OONCR=B]_>[*$^RX= LU8OT_YOW/[N]3[] M3X-)>)+>4QG-J7SE+D"-X2MRT3[=N8U_?[,/&]O#Z>O9L/PNY4_+KUN.:2;Q3BU7>>ILM66F[*Y?D3VTXHN.WNL89$KD2 I^ZHPIG%CM70I'RUC MKY 2TFBQ7LC_OLWCN_)NI)U #)! W%S/K^=[5OH^]E[;F%]7OUVWU/61:T3P M3?A'#MAA$=ZV_^'IVYS)RYY:^_1N[AE

Thank you for your quick reply, I did find it on our deposit report after reading your report.

I would be interested in a sql statement to repopen the work order so I can clear the total to keep the database accurate.

WE DID CHOOSE TO REFUND, THE CASHIER SELECTED ACCOUNT, TO CREATE A STORE CREDIT,(BECAUSE IT WAS SHOWING A A VALID CHOICE) IT STILL CLOSED THE WORKORDER WITH THE DEPOSIT ASSOCIATED TO IT. THIS SEEMS TO BE A QUALITY ISSUE WITH RMS, IT SHOULD NOT CLOSE WORKORDER WITH DEPOSITS IT WOULD SEEM NO TO BE "GENERALLY ACCEPTED ACCOUNTING PRACTICE" RULES TO HAVE MONEY DISSAPPEAR AND BECOME UNUSABLE. BUT IT IS A GREAT WAY TO BOOK MONEY AND NOT PAY INCOME TAX ON IT.

IS THERE A WAY TO DISABLE THE "ACCOUNT" TENDER ON THE WORK ORDER AND BACKORDER & LAYAWAY, TENDER WINDOWS, AND STILL KEEP IT AVAILABLE FOR OTHER TENDER WINDOWS THAT ARE NOT SHOWNING A DEPOSIT DUE / REFUND?

THIS ISSUE SEEMS TO BE A "QUALITY ISSUE" IF THE ABILITY TO REFUND TO ACCOUNT FROM A DEPOSIT IS NOT USABLE, THEN THE ACCOUNT TENDER SHOULD NOT BE ACCESSABLE. ON THOSE TENDERS THAT INVOLVE THIS TYPE OF TRANSACTION