[ http://issues.apache.org/jira/browse/OFBIZ-286?page=all ]
Si Chen closed OFBIZ-286.
-------------------------
Resolution: Fixed
Hi Jacques, this has all been done a lot time ago.
> 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
