[jira] Updated: (OFBIZ-287) POS take deposits and complete sales with deposits
Locked
[jira] Updated: (OFBIZ-287) POS take deposits and complete sales with deposits
 
|
[ https://issues.apache.org/jira/browse/OFBIZ-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Risaliti updated OFBIZ-287: --------------------------------- Component/s: (was: pos) INCORPORATING ISSUE > POS take deposits and complete sales with deposits > -------------------------------------------------- > > Key: OFBIZ-287 > URL: https://issues.apache.org/jira/browse/OFBIZ-287 > Project: OFBiz > Issue Type: New Feature > Components: INCORPORATING ISSUE > Affects Versions: SVN trunk > Reporter: Marco Risaliti > Assignee: Jacques Le Roux > > 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. - You can reply to this email to add a comment to the issue online. |
Re: [jira] Updated: (OFBIZ-287) POS take deposits and complete sales with deposits
|
|
Hi Marco,
why are you moving the issues for the "pos" component into the "INCORPORATING ISSUE" cirtual component? Jacopo Marco Risaliti (JIRA) wrote: > [ https://issues.apache.org/jira/browse/OFBIZ-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Marco Risaliti updated OFBIZ-287: > --------------------------------- > > Component/s: (was: pos) > INCORPORATING ISSUE > >> POS take deposits and complete sales with deposits >> -------------------------------------------------- >> >> Key: OFBIZ-287 >> URL: https://issues.apache.org/jira/browse/OFBIZ-287 >> Project: OFBiz >> Issue Type: New Feature >> Components: INCORPORATING ISSUE >> Affects Versions: SVN trunk >> Reporter: Marco Risaliti >> Assignee: Jacques Le Roux >> >> 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? > |
Re: [jira] Updated: (OFBIZ-287) POS take deposits and complete sales with deposits
Administrator
|
Yes, what is the goal indeed ?
Jacques From: "Jacopo Cappellato" <[hidden email]> > Hi Marco, > > why are you moving the issues for the "pos" component into the "INCORPORATING ISSUE" cirtual component? > > Jacopo > > Marco Risaliti (JIRA) wrote: >> [ https://issues.apache.org/jira/browse/OFBIZ-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] >> >> Marco Risaliti updated OFBIZ-287: >> --------------------------------- >> >> Component/s: (was: pos) >> INCORPORATING ISSUE >> >>> POS take deposits and complete sales with deposits >>> -------------------------------------------------- >>> >>> Key: OFBIZ-287 >>> URL: https://issues.apache.org/jira/browse/OFBIZ-287 >>> Project: OFBiz >>> Issue Type: New Feature >>> Components: INCORPORATING ISSUE >>> Affects Versions: SVN trunk >>> Reporter: Marco Risaliti >>> Assignee: Jacques Le Roux >>> >>> 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? >> > > |
|
|
I'm curious too, but would love it if someone was working on a facility
in POS to accept (and redeem/refund) deposits.... If there's another issues that is covering this (ie, INCORPORATING ISSUE), which one it? Cheers, Iain Jacques Le Roux wrote: > Yes, what is the goal indeed ? > > Jacques > > From: "Jacopo Cappellato" <[hidden email]> >> Hi Marco, >> >> why are you moving the issues for the "pos" component into the >> "INCORPORATING ISSUE" cirtual component? >> >> Jacopo >> >> Marco Risaliti (JIRA) wrote: >>> [ >>> https://issues.apache.org/jira/browse/OFBIZ-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>> ] >>> >>> Marco Risaliti updated OFBIZ-287: >>> --------------------------------- >>> >>> Component/s: (was: pos) >>> INCORPORATING ISSUE >>> >>>> POS take deposits and complete sales with deposits >>>> -------------------------------------------------- >>>> >>>> Key: OFBIZ-287 >>>> URL: https://issues.apache.org/jira/browse/OFBIZ-287 >>>> Project: OFBiz >>>> Issue Type: New Feature >>>> Components: INCORPORATING ISSUE >>>> Affects Versions: SVN trunk >>>> Reporter: Marco Risaliti >>>> Assignee: Jacques Le Roux >>>> >>>> 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? >>> >> >> > > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.5/1191 - Release Date: 20/12/2007 2:14 PM |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |