[jira] Created: (OFBIZ-288) FinAccount Transactions for Gift Certificates, Calling Cards, Customer Accounts, etc.

[Nicolas Malin (Jira)]

FinAccount Transactions for Gift Certificates, Calling Cards, Customer Accounts, etc.
-------------------------------------------------------------------------------------

                 Key: OFBIZ-288
                 URL: http://issues.apache.org/jira/browse/OFBIZ-288
             Project: OFBiz (The Open for Business Project)
          Issue Type: New Feature
          Components: accounting
    Affects Versions: SVN trunk
            Reporter: Marco Risaliti


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"
 
 

 All    Comments    Work Log    Change History       Sort Order:  
Comment by Jacques Le Roux [29/Mar/06 08:17 AM] [ Permlink ]
Si,

Is there a way to link this issue to OFBIZ-733 ?

Jacques

Comment by Si Chen [31/Mar/06 01:35 PM] [ Permlink ]
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.

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:14 PM] [ Permlink ]
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.

Comment by Si Chen [31/Mar/06 08:49 PM] [ Permlink ]
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.

Comment by Si Chen [31/Mar/06 08:54 PM] [ Permlink ]
by the way, for those of you who want to try it, this is a simple beanshell test suite for it.

Comment by Si Chen [05/Apr/06 09:41 AM] [ Permlink ]
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.

Comment by Si Chen [05/Apr/06 09:43 AM] [ Permlink ]
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.

Comment by Jacques Le Roux [05/Apr/06 10:22 AM] [ Permlink ]
Thanks Si,

I'll think about it.

Jacques

Comment by Si Chen [04/May/06 05:57 PM] [ Permlink ]
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?

Comment by Marco Risaliti [13/Sep/06 04:23 PM] [ Permlink ]
Hi Si,

which is the status of this issue, it has been completed and so it can be closed ?

Thanks
Marco

Comment by Jacques Le Roux [14/Sep/06 01:43 PM] [ Permlink ]
It's OK for my part. I created a new issue in Apache Jira because I want to keep these comments.

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

       

[Nicolas Malin (Jira)]

     [ http://issues.apache.org/jira/browse/OFBIZ-288?page=all ]

Marco Risaliti updated OFBIZ-288:
---------------------------------

    Attachment: finaccount.bsh

> FinAccount Transactions for Gift Certificates, Calling Cards, Customer Accounts, etc.
> -------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-288
>                 URL: http://issues.apache.org/jira/browse/OFBIZ-288
>             Project: OFBiz (The Open for Business Project)
>          Issue Type: New Feature
>          Components: accounting
>    Affects Versions: SVN trunk
>            Reporter: Marco Risaliti
>         Attachments: finaccount.bsh
>
>
> 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"
>  
>  
>  All    Comments    Work Log    Change History       Sort Order:  
> Comment by Jacques Le Roux [29/Mar/06 08:17 AM] [ Permlink ]
> Si,
> Is there a way to link this issue to OFBIZ-733 ?
> Jacques
> Comment by Si Chen [31/Mar/06 01:35 PM] [ Permlink ]
> 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.
> 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:14 PM] [ Permlink ]
> 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.
> Comment by Si Chen [31/Mar/06 08:49 PM] [ Permlink ]
> 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.
> Comment by Si Chen [31/Mar/06 08:54 PM] [ Permlink ]
> by the way, for those of you who want to try it, this is a simple beanshell test suite for it.
> Comment by Si Chen [05/Apr/06 09:41 AM] [ Permlink ]
> 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.
> Comment by Si Chen [05/Apr/06 09:43 AM] [ Permlink ]
> 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.
> Comment by Jacques Le Roux [05/Apr/06 10:22 AM] [ Permlink ]
> Thanks Si,
> I'll think about it.
> Jacques
> Comment by Si Chen [04/May/06 05:57 PM] [ Permlink ]
> 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?
> Comment by Marco Risaliti [13/Sep/06 04:23 PM] [ Permlink ]
> Hi Si,
> which is the status of this issue, it has been completed and so it can be closed ?
> Thanks
> Marco
> Comment by Jacques Le Roux [14/Sep/06 01:43 PM] [ Permlink ]
> It's OK for my part. I created a new issue in Apache Jira because I want to keep these comments.

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

       

[Nicolas Malin (Jira)]

     [ http://issues.apache.org/jira/browse/OFBIZ-288?page=all ]

Jacques Le Roux closed OFBIZ-288.
---------------------------------

    Resolution: Duplicate

Duplicate of OFBIZ-286

> FinAccount Transactions for Gift Certificates, Calling Cards, Customer Accounts, etc.
> -------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-288
>                 URL: http://issues.apache.org/jira/browse/OFBIZ-288
>             Project: OFBiz (The Open for Business Project)
>          Issue Type: New Feature
>          Components: accounting
>    Affects Versions: SVN trunk
>            Reporter: Marco Risaliti
>         Attachments: finaccount.bsh
>
>
> 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"
>  
>  
>  All    Comments    Work Log    Change History       Sort Order:  
> Comment by Jacques Le Roux [29/Mar/06 08:17 AM] [ Permlink ]
> Si,
> Is there a way to link this issue to OFBIZ-733 ?
> Jacques
> Comment by Si Chen [31/Mar/06 01:35 PM] [ Permlink ]
> 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.
> 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:14 PM] [ Permlink ]
> 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.
> Comment by Si Chen [31/Mar/06 08:49 PM] [ Permlink ]
> 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.
> Comment by Si Chen [31/Mar/06 08:54 PM] [ Permlink ]
> by the way, for those of you who want to try it, this is a simple beanshell test suite for it.
> Comment by Si Chen [05/Apr/06 09:41 AM] [ Permlink ]
> 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.
> Comment by Si Chen [05/Apr/06 09:43 AM] [ Permlink ]
> 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.
> Comment by Jacques Le Roux [05/Apr/06 10:22 AM] [ Permlink ]
> Thanks Si,
> I'll think about it.
> Jacques
> Comment by Si Chen [04/May/06 05:57 PM] [ Permlink ]
> 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?
> Comment by Marco Risaliti [13/Sep/06 04:23 PM] [ Permlink ]
> Hi Si,
> which is the status of this issue, it has been completed and so it can be closed ?
> Thanks
> Marco
> Comment by Jacques Le Roux [14/Sep/06 01:43 PM] [ Permlink ]
> It's OK for my part. I created a new issue in Apache Jira because I want to keep these comments.

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

       

[Nicolas Malin (Jira)]

     [ http://issues.apache.org/jira/browse/OFBIZ-288?page=all ]

Jacques Le Roux reassigned OFBIZ-288:
-------------------------------------

    Assignee: Jacques Le Roux

> FinAccount Transactions for Gift Certificates, Calling Cards, Customer Accounts, etc.
> -------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-288
>                 URL: http://issues.apache.org/jira/browse/OFBIZ-288
>             Project: OFBiz (The Open for Business Project)
>          Issue Type: New Feature
>          Components: accounting
>    Affects Versions: SVN trunk
>            Reporter: Marco Risaliti
>         Assigned To: Jacques Le Roux
>         Attachments: finaccount.bsh
>
>
> 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"
>  
>  
>  All    Comments    Work Log    Change History       Sort Order:  
> Comment by Jacques Le Roux [29/Mar/06 08:17 AM] [ Permlink ]
> Si,
> Is there a way to link this issue to OFBIZ-733 ?
> Jacques
> Comment by Si Chen [31/Mar/06 01:35 PM] [ Permlink ]
> 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.
> 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:14 PM] [ Permlink ]
> 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.
> Comment by Si Chen [31/Mar/06 08:49 PM] [ Permlink ]
> 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.
> Comment by Si Chen [31/Mar/06 08:54 PM] [ Permlink ]
> by the way, for those of you who want to try it, this is a simple beanshell test suite for it.
> Comment by Si Chen [05/Apr/06 09:41 AM] [ Permlink ]
> 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.
> Comment by Si Chen [05/Apr/06 09:43 AM] [ Permlink ]
> 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.
> Comment by Jacques Le Roux [05/Apr/06 10:22 AM] [ Permlink ]
> Thanks Si,
> I'll think about it.
> Jacques
> Comment by Si Chen [04/May/06 05:57 PM] [ Permlink ]
> 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?
> Comment by Marco Risaliti [13/Sep/06 04:23 PM] [ Permlink ]
> Hi Si,
> which is the status of this issue, it has been completed and so it can be closed ?
> Thanks
> Marco
> Comment by Jacques Le Roux [14/Sep/06 01:43 PM] [ Permlink ]
> It's OK for my part. I created a new issue in Apache Jira because I want to keep these comments.

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