:

Work Order Deposits on store account

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
Reply to
=?Utf-8?B?TWFyaWUgUg==?=
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
formatting link
Reply to
=?Utf-8?B?VGVycmlibGUgVG9t?=
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
formatting link
Reply to
=?Utf-8?B?V3JhdWJlcnRv?=
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
in
on
formatting link
Reply to
Terrible Tom
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 properties somewhere, but I vote no on the suggestion to allow On Account to be used for deposits.
in
on
formatting link
Reply to
Mark S
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
a
in
on
allow
this
formatting link
Reply to
Wrauberto
If you take a deposit on account, it's basically the same thing as not requiring any deposit. In both situations you're trusting the customer to come in and pay at a later date, so why take a deposit at all? I don't know about the accounting part, but it just seems plain silly to accept a deposit on account. Just my 2 cents. Craig
formatting link

Reply to
Craig
I checked with my Navision partner, and Navision allows this scenario. This is a valid business practice and should be accommodated in RMS.
Rob
formatting link
Reply to
Wrauberto
If a customer already has a house account, and we trust them to pay when we send them the bill at the end of the month, we should be able to add that 'transaction' to the same bill. The only difference in that 'transaction' is that we're doing a special order on it (work order or back order, it's the same for this issue). That's why it would make sense to have that option. If the store owner doesn't want this feature, they can turn it OFF, but it should be an option for the end-user.
formatting link
Reply to
Fady Eldeiry
This is a multi-part message in MIME format.
------=_NextPart_000_043B_01C6E702.B6B11FD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Fady,
If you trust them to pay their bill, why not trust them to NOT require a = deposit.
It is an option, change the deposit amount to $0 for this special order.
--=20 * Get Secure! -
formatting link

You must be using Outlook Express or some other type of newsgroup reader = to see and download the file attachment. If you are not using a reader, = follow the link below to setup Outlook Express. Click on "Open with = newsreader" under the MS Retail Management System on the right.
formatting link

**********
"Fady Eldeiry" wrote in = message news: snipped-for-privacy@microsoft.com... If a customer already has a house account, and we trust them to pay = when we=20 send them the bill at the end of the month, we should be able to add = that=20 'transaction' to the same bill. The only difference in that = 'transaction' is=20 that we're doing a special order on it (work order or back order, it's = the=20 same for this issue). That's why it would make sense to have that = option. =20 If the store owner doesn't want this feature, they can turn it OFF, = but it=20 should be an option for the end-user.
scenario. This=20
not=20
customer to=20
don't know=20
a deposit=20
type of
or GAAP
that it=20
(1997)
not to=20
that=20
Give us one
it a toggle
but if I=20
deliver the
immediately=20
could=20
cancel the=20
manners=20
it's right.
correctly.
somewhere,=20
deposits.
design=20
happy,=20
futures=20
payment in any=20
tender, so=20
since this=20
will actually=20
give us=20
sale at=20
not just=20
their=20
manners=20
be=20
customers.
pass the=20
notify RMS=20
account=20
a 100%=20
like RMS to=20
responds to=20
suggestion, click=20
button,=20
Newsreader and=20
formatting link
soft.public.pos=20
------=_NextPart_000_043B_01C6E702.B6B11FD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=EF=BB=BF
Fady,   If you trust them to pay their bill, why not = trust them=20 to NOT require a deposit.   It is an option, change the deposit amount to = $0 for=20 this special order. -- *Get Secure! -
formatting link

  You must be using Outlook Express or some other type of newsgroup = reader=20 tosee and download the file attachment.  If you are not using a = reader,=20 followthe link below to setup Outlook Express.  Click on "Open = with=20 newsreader"under the MS Retail Management System on the right.  
formatting link
  **********
"Fady Eldeiry" <Fady snipped-for-privacy@discussions.mic= rosoft.com>=20
snipped-for-privacy@microsoft.com...If=20 a customer already has a house account, and we trust them to pay when = we=20 send them the bill at the end of the month, we should be able to = add that=20 'transaction' to the same bill.  The only difference in that=20 'transaction' is that we're doing a special order on it (work = order or=20 back order, it's the same for this issue).  That's why it = would make=20 sense to have that option.  If the store owner doesn't want = this=20 feature, they can turn it OFF, but it should be an option for the=20 > I checked with my = Navision=20 partner, and Navision allows this scenario. This > is a valid = business=20 practice and should be accommodated in RMS.> > = Rob>=20 > > > If you take a deposit on =
account, it's basically the same thing as not > > requiring = any=20 deposit. In both situations you're trusting the customer to > = > come=20 in and pay at a later date, so why take a deposit at all? I don't know =
> > about the accounting part, but it just seems plain silly = to=20 accept a deposit > > on account. Just my 2 cents.> = >=20 Craig> > "Wrauberto" <Wrauberto@discussions= .microsoft.com>=20 wrote in message > > news:DD3= snipped-for-privacy@microsoft.com...>=20 > >I just spoke with my Navision partner and Navision allows = this type=20 of> > > scenario. For accounting, I'll trust Navision = more than=20 RMS.> > >> > > Also, in all of my searching = I have=20 not found a single law, rule or GAAP> > > item that says = this=20 should not happen. I did find a reference that it > > >=20 might> > > be unlawful to charge interest on layaways, = but that=20 was an old (1997)> > > reference and limited to one=20 state.> > >> > > You are certainly allowed = to make a=20 policy within your company not to > > > allow> = > >=20 deposits on account. But, don't shut down the entire of RMS for that = >=20 > > policy.> > >> > > Heck, I'd be = happy if=20 they just let us do this on Work Orders. Give us one> > > = method=20 of booking a sale and taking a payment on account. Make it a = toggle>=20 > > option. Something. Anything.> > >> > = >=20 > >=20 >> > >> I don't know about wine futures and the = other stuff=20 you want, but if I > > >> had an> > >> =
employee who tried to charge deposits on account I'd fire = them.> >=20 >>> > >> I also don't want to pay sales tax on = orders=20 either until I deliver the> > >> products. If you book = them as=20 sales, the sales tax is due immediately > > >> even = if>=20 > >> you collected nothing.> > >>> = >=20 >> A credit card is as good as cash in my book. Sure the = customer could=20 > > >> refute> > >> the charge, but = why would=20 they do that unless they want to cancel the > > >>=20 order?> > >>> > >> > Keep in mind = that many=20 customers use different functions for manners > > >> = >=20 other> > >> > than they were intended or = named.>=20 > >>> > >> Just because someone wants to do = something=20 dumb doesn't mean it's right.> > >> I'm all for = flexibility=20 but don't ruin what is already working correctly.> >=20 >>> > >> I'd like to see orders visible under = the=20 customer properties somewhere, > > >> but> > =
>> I vote no on the suggestion to allow On Account to be used = for=20 deposits.> > >>> > >> "Wrauberto"=20 wrote:> > >>> > >> > Despite what = others=20 may say, Microsoft is well aware of this design > > >> = >=20 flaw and> > >> > so far nothing is happening on = this=20 issue.> > >> >> > >> > If = Microsoft=20 would fix this then your customer would be happy, > > = >> >=20 will-call> > >> > customers could be accomodated = and I=20 could process my wine futures > > >> > = better.> >=20 >> >> > >> > Yes, this is a design flaw. = We should=20 be able to take a payment in any > > >> > = form> >=20 >> > we desire. A promise to pay is something that we view as = a=20 tender, so > > >> > be it.> > >>=20 >> > >> > Using the logic of Tom, we cannot use = a credit=20 card either since this > > >> > is> > = >>=20 > also a promise to pay. We are trusting that the processor will = actually=20 > > >> > give> > >> > us our = money in=20 the future, just as we trust a customer to give us > > = >> >=20 money in> > >> > the future.> > >>=20 >> > >> > We should also be able to book a = layaway or a=20 work order as a sale at > > >> > the> > = >>=20 > time we place the order, or at the time the order is filled, not = just=20 > > >> > as the> > >> > order is = filled.=20 this would allow customers to use RMS to fit their > > = >> >=20 business> > >> > model, not just use it in the more = narrow=20 fashion.> > >> >> > >> > Keep in = mind=20 that many customers use different functions for manners > > = >>=20 > other> > >> > than they were intended or = named. Let=20 our customers (or us) be > > >> > = inventive.> >=20 >> > Make RMS flexible and we can provide a "solution" to = more=20 customers.> > >> >> > >> > = Rob>=20 > = >=20 >> >> > >> > > We have a very customer = that=20 wants to use workorders to pass the > > >> > > = items to=20 a> > >> > > warehouse management package to pick = and=20 ship and then notify RMS > > >> > > when = the>=20 > >> > > work order is fulfilled and most of their = busuness in=20 on account > > >> > > customers in> > = >>=20 > > order to process we need to tender the whole workorder with = a 100%=20 > > >> > > deposit on> > >> > = >=20 account and we are unable to do it at his time.  We would like = RMS to=20 > > >> > > allow> > >> > > =
deposits to be charged on account.> > >> > = >>=20 > >> > > Marie> > >> > >> = >=20 >> > > ----------------> > >> > > = This post=20 is a suggestion for Microsoft, and Microsoft responds to > > =
>> > > the> > >> > > suggestions = with the=20 most votes. To vote for this suggestion, click > > >> = >=20 > the "I> > >> > > Agree" button in the = message pane.=20 If you do not see the button, > > >> > > follow=20 this> > >> > > link to open the suggestion in = the=20 Microsoft Web-based Newsreader and > > >> > >=20 then> > >> > > click "I Agree" in the message=20 pane.> > >> > >> > >> > > =
formatting link
> > > > > >
------=_NextPart_000_043B_01C6E702.B6B11FD0--
Reply to
Jeff

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.