[ http://issues.apache.org/jira/browse/OFBIZ-287?page=all ]
Jacopo Cappellato updated OFBIZ-287:
------------------------------------
Description:
Copy of http://jira.undersunconsulting.com/browse/OFBIZ-733 from Ray Barlow.
==============================================
Certain products are delivered direct by the supplier or if the shop does not
generally stock a specific product the customer wants from a supplier they can
be ordered and this normally requires an up front deposit from the customer.
Could this really be considered a "special" gift certificate type? You've taken
money and the customer has a receipt/voucher/certificate that will be redeemed
when the sale is completed?!
All Comments Work Log Change History Sort Order:
Comment by Si Chen [06/Feb/06 11:10 AM] [ Permlink ]
This should be created as a Payment from customer of the CUSTOMER_DEPOSIT type.
Product should be received by the store, picked up by the customer, and
invoiced in the regular way.
Comment by Jacques Le Roux [11/Mar/06 02:10 AM] [ Permlink ]
I will work on this soon
Jacques
Comment by Si Chen [31/Mar/06 01:35 PM] [ Permlink ]
Jacques, I agree this may be a way to solve the issue of advance payments, but
it is not necessarily the only one. I'm not sure if it's the optimal one
either. If you're ready to start working on it, let me know. We could discuss
it further. Si
Comment by Bradley Plies [31/Mar/06 04:32 PM] [ Permlink ]
One way to view this is from the perspective of a hub-centric exchange where
buyers & sellers meet and make deals. The seller may put up a price for a
product, a buyer likes the price and agrees. In a hub-centric model like I've
worked on before, the buyer and seller do not deal with each other directly.
They can be completely anonymous to each other and both send their money and
goods to the exchange which in turn handles all the processing, authentication,
and specific fulfillment needs of each party.
The buyer & seller execute a trading transaction where the buyer must send
money to the exchange and the seller must send their product to the exchange.
The buyer can then take delivery of the product when they are ready.
As you can see in this scenario, the buyer "prepaid" for a product and the
fulfillment of the product (taking delivery, or even selling it back to yet
someone else) is a seperate activity entirely.
Comment by Si Chen [05/Apr/06 09:37 AM] [ Permlink ]
Actually, now I remember what you should do: after the order is authorized, in
the order manager you can manually transact a portion of it (through the
accounting manager's Transactions tab) as a Customer Deposit. When you ship the
order, the balance will be collected automatically.
Comment by Si Chen [02/May/06 10:49 AM] [ Permlink ]
Do we still need this issue to be open? Is this need taken care of now?
Comment by Jacques Le Roux [02/May/06 01:47 PM] [ Permlink ]
Si,
Sorry I can't take a look at this issue before next week. I'll tell you then.
Thanks
Jacques
Comment by Ray Barlow [04/May/06 04:29 AM] [ Permlink ]
If the functionality you've suggested meets the requirements, which I've no
reason to doubt I've just not tested it, then this is a great start. But it
does not close this feature request for me in terms of a POS solution as it is
not acceptable to expect the POS user to switch out of the Xui app into HTML
backends, log in find orders etc to manage a deposit, a good short term work
around maybe but not the final requirement of quick and easy to use POS deposit
screens.
Comment by Si Chen [04/May/06 06:05 PM] [ Permlink ]
OK. So are you working on a POS equivalent of this? Just look at how
orderheader.ftl in ordermgr does it.
If you plan on working on such, I will keep the issue open.
Comment by Si Chen [05/May/06 01:05 PM] [ Permlink ]
All you actually need to do is a button which takes a payment and creates an
OFBiz Payment of "CUSTOMER_DEPOSIT" type.
More curious is: does the POS allow you to look up a customer somehow?
was:
Certain products are delivered direct by the supplier or if the shop does not
generally stock a specific product the customer wants from a supplier they can
be ordered and this normally requires an up front deposit from the customer.
Could this really be considered a "special" gift certificate type? You've taken
money and the customer has a receipt/voucher/certificate that will be redeemed
when the sale is completed?!
All Comments Work Log Change History Sort Order:
Comment by Si Chen [06/Feb/06 11:10 AM] [ Permlink ]
This should be created as a Payment from customer of the CUSTOMER_DEPOSIT type.
Product should be received by the store, picked up by the customer, and
invoiced in the regular way.
Comment by Jacques Le Roux [11/Mar/06 02:10 AM] [ Permlink ]
I will work on this soon
Jacques
Comment by Si Chen [31/Mar/06 01:35 PM] [ Permlink ]
Jacques, I agree this may be a way to solve the issue of advance payments, but
it is not necessarily the only one. I'm not sure if it's the optimal one
either. If you're ready to start working on it, let me know. We could discuss
it further. Si
Comment by Bradley Plies [31/Mar/06 04:32 PM] [ Permlink ]
One way to view this is from the perspective of a hub-centric exchange where
buyers & sellers meet and make deals. The seller may put up a price for a
product, a buyer likes the price and agrees. In a hub-centric model like I've
worked on before, the buyer and seller do not deal with each other directly.
They can be completely anonymous to each other and both send their money and
goods to the exchange which in turn handles all the processing, authentication,
and specific fulfillment needs of each party.
The buyer & seller execute a trading transaction where the buyer must send
money to the exchange and the seller must send their product to the exchange.
The buyer can then take delivery of the product when they are ready.
As you can see in this scenario, the buyer "prepaid" for a product and the
fulfillment of the product (taking delivery, or even selling it back to yet
someone else) is a seperate activity entirely.
Comment by Si Chen [05/Apr/06 09:37 AM] [ Permlink ]
Actually, now I remember what you should do: after the order is authorized, in
the order manager you can manually transact a portion of it (through the
accounting manager's Transactions tab) as a Customer Deposit. When you ship the
order, the balance will be collected automatically.
Comment by Si Chen [02/May/06 10:49 AM] [ Permlink ]
Do we still need this issue to be open? Is this need taken care of now?
Comment by Jacques Le Roux [02/May/06 01:47 PM] [ Permlink ]
Si,
Sorry I can't take a look at this issue before next week. I'll tell you then.
Thanks
Jacques
Comment by Ray Barlow [04/May/06 04:29 AM] [ Permlink ]
If the functionality you've suggested meets the requirements, which I've no
reason to doubt I've just not tested it, then this is a great start. But it
does not close this feature request for me in terms of a POS solution as it is
not acceptable to expect the POS user to switch out of the Xui app into HTML
backends, log in find orders etc to manage a deposit, a good short term work
around maybe but not the final requirement of quick and easy to use POS deposit
screens.
Comment by Si Chen [04/May/06 06:05 PM] [ Permlink ]
OK. So are you working on a POS equivalent of this? Just look at how
orderheader.ftl in ordermgr does it.
If you plan on working on such, I will keep the issue open.
Comment by Si Chen [05/May/06 01:05 PM] [ Permlink ]
All you actually need to do is a button which takes a payment and creates an
OFBiz Payment of "CUSTOMER_DEPOSIT" type.
More curious is: does the POS allow you to look up a customer somehow?
> POS take deposits and complete sales with deposits
> --------------------------------------------------
>
> Key: OFBIZ-287
> URL: http://issues.apache.org/jira/browse/OFBIZ-287
> Project: OFBiz (The Open for Business Project)
> Issue Type: New Feature
> Components: pos
> Affects Versions: SVN trunk
> Reporter: Marco Risaliti
>
> Copy of http://jira.undersunconsulting.com/browse/OFBIZ-733 from Ray Barlow.
> ==============================================
> Certain products are delivered direct by the supplier or if the shop does not
> generally stock a specific product the customer wants from a supplier they
> can be ordered and this normally requires an up front deposit from the
> customer.
> Could this really be considered a "special" gift certificate type? You've
> taken money and the customer has a receipt/voucher/certificate that will be
> redeemed when the sale is completed?!
>
>
> All Comments Work Log Change History Sort Order:
> Comment by Si Chen [06/Feb/06 11:10 AM] [ Permlink ]
> This should be created as a Payment from customer of the CUSTOMER_DEPOSIT
> type. Product should be received by the store, picked up by the customer, and
> invoiced in the regular way.
> Comment by Jacques Le Roux [11/Mar/06 02:10 AM] [ Permlink ]
> I will work on this soon
> Jacques
> Comment by Si Chen [31/Mar/06 01:35 PM] [ Permlink ]
> Jacques, I agree this may be a way to solve the issue of advance payments,
> but it is not necessarily the only one. I'm not sure if it's the optimal one
> either. If you're ready to start working on it, let me know. We could discuss
> it further. Si
> Comment by Bradley Plies [31/Mar/06 04:32 PM] [ Permlink ]
> One way to view this is from the perspective of a hub-centric exchange where
> buyers & sellers meet and make deals. The seller may put up a price for a
> product, a buyer likes the price and agrees. In a hub-centric model like I've
> worked on before, the buyer and seller do not deal with each other directly.
> They can be completely anonymous to each other and both send their money and
> goods to the exchange which in turn handles all the processing,
> authentication, and specific fulfillment needs of each party.
> The buyer & seller execute a trading transaction where the buyer must send
> money to the exchange and the seller must send their product to the exchange.
> The buyer can then take delivery of the product when they are ready.
> As you can see in this scenario, the buyer "prepaid" for a product and the
> fulfillment of the product (taking delivery, or even selling it back to yet
> someone else) is a seperate activity entirely.
> Comment by Si Chen [05/Apr/06 09:37 AM] [ Permlink ]
> Actually, now I remember what you should do: after the order is authorized,
> in the order manager you can manually transact a portion of it (through the
> accounting manager's Transactions tab) as a Customer Deposit. When you ship
> the order, the balance will be collected automatically.
> Comment by Si Chen [02/May/06 10:49 AM] [ Permlink ]
> Do we still need this issue to be open? Is this need taken care of now?
> Comment by Jacques Le Roux [02/May/06 01:47 PM] [ Permlink ]
> Si,
> Sorry I can't take a look at this issue before next week. I'll tell you then.
> Thanks
> Jacques
> Comment by Ray Barlow [04/May/06 04:29 AM] [ Permlink ]
> If the functionality you've suggested meets the requirements, which I've no
> reason to doubt I've just not tested it, then this is a great start. But it
> does not close this feature request for me in terms of a POS solution as it
> is not acceptable to expect the POS user to switch out of the Xui app into
> HTML backends, log in find orders etc to manage a deposit, a good short term
> work around maybe but not the final requirement of quick and easy to use POS
> deposit screens.
> Comment by Si Chen [04/May/06 06:05 PM] [ Permlink ]
> OK. So are you working on a POS equivalent of this? Just look at how
> orderheader.ftl in ordermgr does it.
> If you plan on working on such, I will keep the issue open.
> Comment by Si Chen [05/May/06 01:05 PM] [ Permlink ]
> All you actually need to do is a button which takes a payment and creates an
> OFBiz Payment of "CUSTOMER_DEPOSIT" type.
> More curious is: does the POS allow you to look up a customer somehow?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
