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
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
