[ http://issues.apache.org/jira/browse/OFBIZ-286?page=comments#action_12450866 ] Jacques Le Roux commented on OFBIZ-286: ---------------------------------------
Thanks Si, I have just achieved "POS Cash/Paid in and out of drawer" (OFBIZ-237) and I will take a look at OFBIZ-287 soon... I hope... I will commit OFBIZ-237 tomorrow I think. I have to think about issue related (Y and Z reports for instance) before this commit. > FinAccount Transactions for Gift Certificates, Calling Cards, Customer > Accounts, etc. > ------------------------------------------------------------------------------------- > > Key: OFBIZ-286 > URL: http://issues.apache.org/jira/browse/OFBIZ-286 > Project: OFBiz (The Open for Business Project) > Issue Type: New Feature > Components: pos > Reporter: Jacques Le Roux > Assigned To: Jacques Le Roux > Priority: Minor > Attachments: finaccount.bsh > > > Comments from olf Jira. I want use this on POS... > We will be implementing support for FinAccount and FinAccountTransactions as > a way to purchase and pay with gift certificates, calling cards, or customer > accounts in OFBiz. Below is a general outline of how it would work: > Setting up Gift Certificates as Products > 1.Create a new ProductType = "FIN_ACCOUNT" with isPhysical="N" and isDigital > = "Y" > 2.Add a new field Product.fixedAmount which stores the amount of the gift > certificate. (This allows the price to be different than the amount, for > promotions and such.) > Ordering Gift Certificates > 1.When gift certificate is ordered, system generates a unique random 12-digit > code of numbers and uppercase letters. It then creates FinAccount, stores > email in a ContactMech and associates it with FinAccount through a > FinAccountContactMech. It creates a CommunicationEvent for the gift message > and stores the gift message there, sets the CommunicationEvent to PENDING, > and associates it with FinAccount through a finAccountId on > CommunicationEvent. > 2.Associate finAccountId with ShoppingCartItem, OrderItem, and InvoiceItem > with finAccountId. This allows us later to create a feature where people > could add value to a FinAccount. > 3.When the order is created, the gift certificate products will be fulfilled > automatically and separately from the other physical products using the > checkDigitalFulfillment services. Note: This will always be the case, > regardless of whether the physical items are in stock or not. Separate > invoices will be generated for the gift certificates and physical products. > 4.When a payment is processed, then the FinAccountTransaction is created for > the finAccountId. This assures that gift certificates won't be charged until > the payment is actually collected. FinAccountTransaction is only related to > payment. > Using Gift Certificates to Pay > 1.Setting up Gift Certificates as PaymentMethods with PaymentMethodType = > FIN_ACCOUNT (or GIFT_CERTIFICATE) Model it similar to EXT_BILLACT payments > Add finAccountId to OrderPaymentPreference. OrderPaymentPreference.maxAmount > stores maximum amount to be deducted from the FinAccount. > 2.On check out, separate box for Gift Certificate code. > 3.Look up FinAccount from gift certificate code (case insensitive) > 4.Authorize the FinAccount (new authorizeFinAccount service) which checks if > gift certificate balance plus all un-expired authorizations (in a new entity > FinAccountAuths) > order amount > 5.If not, return to ask user to add another payment method > 6.Modify authOrderPaymentPreference so that for GIFT_CERTIFICATE it > authorizes based on balances of FinAccount in FinAccountTransactions and > FinAccountAuths and store the new authorization in FinAccountAuths > 7.Modify captureOrderPayments to create a FinAccountTransaction. Release > FinAccountAuth by updating its expiration date to time of payment. > Email > 1.Email address is Stored in ContactMech and associated with > FinAccountContactMechPurpose > 2.Message is stored as a CommunicationEvent with the finAccountId > 3.Create new ProductStoreEmailSetting for the template of the email > 4.Get all CommunicationEvent which are PENDING with finAccountId, find > matching email setting from (3) based on type of CommunicationEvent, and send > them. > 5.SECA to send email when any FinAccountTransaction happens? > Order Cancellation > 1.If an order is cancelled, we should release the authorization by setting > its expiration date to time in the past. > Returns > 1.New refundToFinAccount service which creates a Payment and a > FinAccountTransaction to increase value of FinAccount, related with paymentId > 2.Modify processRefund/processCreditReturn to call service from (1). If > multiple payment methods are available, refund to credit card, then to gift > certificates. Each payment methods should be refunded up to the maximum of > the original OrderPaymentPreference amount. > (Note about Recording Gift Certificate Authorizations: It is important to > record the authorizations explicitly rather than rely upon an implicit check > of current balances because orders usually cause inventory to be reserved for > the customer. Thus, we don't want several FinAccount transactions to cause > excessive inventory to be set aside, when in fact the transactions could not > go through.) > Entity Model Changes > 1.New Product.fixedAmount field > 2.FinAccountContactMechPurpose entity with fields: finAccountId*, > contactMechId*, fromDate*, thruDate, contactMechPurposeTypeId > 3.New CommunicationEvent.finAccountId > 4.OrderItem.finAccountId > 5.InvoiceItem.finAccountId > 6.OrderPaymentPreference.finAccountId > 7.FinAccountAuth entity with finAccountAuthId*, finAccountId, authAmount, > currencyUomId, authTimestamp, fromDate, thruDate > New Seed Data > ContactMechPurposeTypeId = "GIFT_CERT_RECIPIENT" > CommunicationEventTypeId = "GIFT_CERT_MESSAGE" > PaymentMethodTypeId = "FIN_ACCOUNT" and "GIFT_CERTIFICATE" > Toutes Commentaires Temps Consommé Historique des > changements Sort Order: [navigator.ascending.order] > Commentaire de la part de Jacques Le Roux [29/mars/06 08:17 AM] > [ Lien permanent ] > Si, > Is there a way to link this issue to OFBIZ-733 ? > Jacques > Commentaire de la part de Si Chen [31/mars/06 01:35 PM] > [ Lien permanent ] > It turns out that there are some configuration issues for gift certificates > such as expiration dates, length of authorization, length of account codes, > etc. These seem most logically associated at the product store level, so I am > going to create a ProductStoreFinActSetting entity for configuring them. > Also a couple of other notes - > 1. FinAccountTrans only referenced Payment but did not store its own amount. > This can be problematic if one payment was used to purchase or activate > several FinAccounts. So FinAccountTrans needs its own amount field. > 2. FinAccount also needs from and thru dates to govern expiration of various > types of accounts. > Commentaire de la part de Si Chen [31/mars/06 01:35 PM] > [ Lien permanent ] > 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 > Commentaire de la part de Bradley Plies [31/mars/06 04:14 PM] > [ Lien permanent ] > Neat idea. Plan seems pretty thorough. I have a few scenarios or use cases to > offer for consideration which may not be of any value to what you are > intending to do. > 1. 12 character code - to prevent brute force attempts to identify and use > valid gift certificate numbers, some websites I've encountered also introduce > a "claim code" in addition to the gift certificate number. Even though a 12 > character code represents a large space of potential cert numbers. (10 digits > + 26 capital alphabet characters) ^ 12 digits = 4,738,381,338,321,616,896 > combinations. Given that the number will be random, there is still a > possibility of generating a number that is already in use so therefore a > collission-resolution policy (retry) will be necessary. > 2. I know the intent is for digital/online gift cards, but how might this > also be usable with a physical store / POS that *can* sell gift cards/certs > online? Could this be used for a physical storefront? Suppose you bought an > online gift certificate at Best Buy, it could feasibly also be used at a > physical store too right? Suppose there was a case of having preloaded gift > cards for sale at a physical store that aren't "activated" until purchased > through a POS register. Naturally a physical gift card won't have a claim > code as merely being in possession of the card is all the authentication > required... unless the card could be tampered with. > Just other related ideas to consider that may not have much bearing on your > plan or intent. > Commentaire de la part de Si Chen [31/mars/06 08:49 PM] > [ Lien permanent ] > With r 7154 thru r 7164 the basic support is in place for tracking balances, > authorizations, and available balances. Now we'll slowly integrate them into > the whole checkout. > Commentaire de la part de Si Chen [31/mars/06 08:54 PM] > [ Lien permanent ] > by the way, for those of you who want to try it, this is a simple beanshell > test suite for it. > Commentaire de la part de Si Chen [05/avr./06 09:41 AM] > [ Lien permanent ] > Just a note: > I am merging these features with the some older GiftCertificateServices. So > what happens now is: > 1. You set up a Digital Product with a ProductContent for external async > fulfillment pointing to a gift certificate purchase service. > 2. You configure a survey to collect purchase information in a new > ProductStoreFinActSetting. > 3. The purchase/authorize/capture/release/refund processes for a gift > certificate are created as payment gateway services and associated with > GIFT_CARD payment types via ProductStorePaymentSettings. > The system would then treat your gift certificate as a GIFT CARD and execute > normal order processing. > Commentaire de la part de Si Chen [05/avr./06 09:43 AM] > [ Lien permanent ] > Also, to follow up Brad's comment, > 1. The length of account code is configurable in ProductStoreFinActSetting, > and whether a PIN # is required is configured there as well. > 2. Yes, this should work in POS as well as ecommerce, though I do not > currently have plans to implement in POS. > Commentaire de la part de Jacques Le Roux [05/avr./06 10:22 AM] > [ Lien permanent ] > Thanks Si, > I'll think about it. > Jacques > Commentaire de la part de Si Chen [04/mai/06 05:57 PM] > [ Lien permanent ] > At this point most of it is done. We just need to move some view and > management screens back. > What does everybody think of changing [Billing Account] tab in accounting > manager to [Accounts] tab, with separate sub-tabs for Billing and Fin Account? -- 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
