Work Order Deposits on store account

May 02, 2006 9 Replies

We have a very customer that wants to use workorders to pass the items to a warehouse management package to pick and ship and then notify RMS when the work order is fulfilled and most of their busuness in on account customers in order to process we need to tender the whole workorder with a 100% deposit on account and we are unable to do it at his time. We would like RMS to allow deposits to be charged on account.



Marie


---------------- This post is a suggestion for Microsoft, and Microsoft responds to the suggestions with the most votes. To vote for this suggestion, click the "I Agree" button in the message pane. If you do not see the button, follow this link to open the suggestion in the Microsoft Web-based Newsreader and then click "I Agree" in the message pane.



formatting link
0c37ce-37e8-48fc-a0bc-63900b9ef36c&dg=microsoft.public.pos


I disagreed with your selection, and I'll tell you why: a deposit on account is vapor. It's a promise to promise to pay in the future.

Create your work orders with zero deposits then invoice the fulfilled orders and tender on account.

Tom

"Marie R" wrote:

formatting link
0c37ce-37e8-48fc-a0bc-63900b9ef36c&dg=microsoft.public.pos

Despite what others may say, Microsoft is well aware of this design flaw and so far nothing is happening on this issue.

If Microsoft would fix this then your customer would be happy, will-call customers could be accomodated and I could process my wine futures better.

Yes, this is a design flaw. We should be able to take a payment in any form we desire. A promise to pay is something that we view as a tender, so be it.

Using the logic of Tom, we cannot use a credit card either since this is also a promise to pay. We are trusting that the processor will actually give us our money in the future, just as we trust a customer to give us money in the future.

We should also be able to book a layaway or a work order as a sale at the time we place the order, or at the time the order is filled, not just as the order is filled. this would allow customers to use RMS to fit their business model, not just use it in the more narrow fashion.

Keep in mind that many customers use different functions for manners other than they were intended or named. Let our customers (or us) be inventive. Make RMS flexible and we can provide a "solution" to more customers.

Rob

"Marie R" wrote:

formatting link
0c37ce-37e8-48fc-a0bc-63900b9ef36c&dg=microsoft.public.pos

It's not a design flaw. It's design intent and it is founded in good bookkeeping and accounting principles. Nothing will ever happen.

A promise to pay is called 'on account'. A promise to promise to pay is nothing, and that's what you get when you take a deposit on account. A deposit on an order is not an asset, it's a liability. It remains a liability until the product or service on order has been delivered. Either you got a deposit or you didn't. If you got one, enter the amount in the Order Details and tender it. If you didn't, you can put the entire amount on account when the order ships. If you want to bill the customer right away, skip the order process altogether and just invoice 'em all.

There's your answer. Forget layaways and orders, just invoice everybody at the time the order is placed. Put it on their account and just put the invoice in a shoebox called "will call". When they start complaining that their warranty started 3 weeks before delivery or that their statement says they owe for product they haven't received, you take the call... The big problem with the invoice first model: Inventory. RMS says X but physical is actually Y. It's a problem when counting and it's a real problem in the event of a theft/fire/natural disaster. Your backup data says your inventory was $X when in reality it was much higher due to undelivered 'sales'.

I am all for flexibility and I am also struggling with finding processes that meet both my business needs and RMS' limitations.

I am not trying to rain on your parade, but rather trying to explain the (very valid) logic for this limitation. It's an accounting thing, and I assure you that it will never change.

Tom

formatting link
0c37ce-37e8-48fc-a0bc-63900b9ef36c&dg=microsoft.public.pos

I don't know about wine futures and the other stuff you want, but if I had an employee who tried to charge deposits on account I'd fire them.

I also don't want to pay sales tax on orders either until I deliver the products. If you book them as sales, the sales tax is due immediately even if you collected nothing.

A credit card is as good as cash in my book. Sure the customer could refute the charge, but why would they do that unless they want to cancel the order?

Just because someone wants to do something dumb doesn't mean it's right. I'm all for flexibility but don't ruin what is already working correctly.

I'd like to see orders visible under the customer pr> Despite what others may say, Microsoft is well aware of this design flaw and

formatting link
0c37ce-37e8-48fc-a0bc-63900b9ef36c&dg=microsoft.public.pos

I just spoke with my Navision partner and Navision allows this type of scenario. For accounting, I'll trust Navision more than RMS.

Also, in all of my searching I have not found a single law, rule or GAAP item that says this should not happen. I did find a reference that it might be unlawful to charge interest on layaways, but that was an old (1997) reference and limited to one state.

You are certainly allowed to make a policy within your company not to allow deposits on account. But, don't shut down the entire of RMS for that policy.

Heck, I'd be happy if they just let us do this on Work Orders. Give us one method of booking a sale and taking a payment on account. Make it a toggle option. Something. Anything.

Rob

"Mark S" wrote:

formatting link
0c37ce-37e8-48fc-a0bc-63900b9ef36c&dg=microsoft.public.pos

formatting link
0c37ce-37e8-48fc-a0bc-63900b9ef36c&dg=microsoft.public.pos

I checked with my Navision partner, and Navision allows this scenario. This is a valid business practice and should be accommodated in RMS.

Rob

"Craig" wrote:

formatting link
0c37ce-37e8-48fc-a0bc-63900b9ef36c&dg=microsoft.public.pos >

formatting link
0c37ce-37e8-48fc-a0bc-63900b9ef36c&dg=microsoft.public.pos > >

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required