HomeHome Product Discus... Product Discus...Enhancement Req...Enhancement Req...Record payment failures and reference transactions in PaymentHistoryRecord payment failures and reference transactions in PaymentHistory
Previous
 
Next
New Post
6/23/2011 1:18 PM
 

PayHistID creates a 1 to 1 relationship between SalesOrders and PayHist. This may work for one single orders with one item and one payment, but real world use case demonstrates orders may have multiple transactions including failed authorizations, credits, refunds , errors and/or other adjustments.

This fundamental design issue should be corrected, especially for integration with other management software or accounting systems.

 

Benefits

Allows multiple payment transactions per order

Records multiple error codes from failed transactions

Customers and employees can view related transactions in a single place without hunting through other systems

Customers statements will match online transactions

Maintains actual order sequence for audit trail

Prevents duplicate/phantom orders from failed transactions

 

Affects

Smith.BuyNow

Smith.MyAccount

 

Database

Add column OrderID to PayHist

Update OrderID from StoreOrders using PayHistID

Drop column PayHistID from StoreOrders

Drop column CustomerID from PayHist (unnecessary duplication, unless needed elsewhere)

Business Logic

Literally modify PayHistID to OrderID as required

User Interface

Ability to create additional payment records

Add [PAYMENTDETAILS] token for emails, invoices, etc.

 
New Post
6/24/2011 11:38 AM
 

Hi Dwayne,
I agree with you that adding the order id to the payhist table would make sense if you are integrating an accounting or erp system and using the cart database as your "master". The reason that it is a 1-1 relationship right now is because currently there is no transaction type type in the cart that creates multiple payment records on an order. There are many ways to integrate different operational systems and I think the account/erp system should be the master and the cart be the slave. As you said in your case where you are using the cart db as the master you can just add the orderid to the payhist table and then when you are migrating you data from your accounting/erp systems you will be able to store multiple payhist records for an order. Currently, the cart is designed and built as an order taking system and we have not yet built in all the "virtual terminal" transaction types for issuing credits and refunds but instead rely on the pre built capabilities of the payment gateway virtual terminal or the account system for those transaction types. I'm sure at that the current pace of development in the cart we will add those other transaction types in the cart and implement your suggestions.


Thanks for your thorough analysis and feedback!

 


Scott Kelly
Project Manager
DotNetNuke Consulting, DotNetNuke Store and DNN Ecommerce
 
New Post
6/24/2011 3:48 PM
 

I understand. It is still an enhancement request for the benefit of others as well.

 

 
Previous
 
Next
HomeHome Product Discus... Product Discus...Enhancement Req...Enhancement Req...Record payment failures and reference transactions in PaymentHistoryRecord payment failures and reference transactions in PaymentHistory