cancel
Showing results for 
Search instead for 
Did you mean: 

Feature Request - Custom Totals Database Schema Improvement

0 Kudos

Feature Request - Custom Totals Database Schema Improvement

Feature request from fooman, posted on GitHub May 07, 2015

Custom Totals are a great feature of Magento. I do believe we can improve their implementation and reduce overall complexity by keeping custom totals in separate dedicated database tables similar to how we store line items.

With the current structure to add a new custom total to cover base and order currency plus tax, at my last count, one has to add:

1.) 13 columns to table sales/order 2.) 4 columns to sales/invoice 3.) 4 columns to sales/creditmemo

Not everyone gets this right including for example Enterprise custom totals:

getData('base_' . $code)

vs.

sales/order::gw_card_base_price_invoiced

I believe if we had the following tables

sales/order_totals sales/order_invoice_totals sales/order_creditmemo_totals

with the following columns:

total_id
parent_id
code 
amount 
base_amount 
tax_amount 
base_tax_amount
calculation_order 

and additionally for the sales/order_totals table

description 
amount_invoiced 
base_amount_invoiced 
amount_refunded 
base_amount_refunded 
tax_amount_invoiced 
base_tax_amount_invoiced  
tax_amount_refunded  
base_tax_amount_refunded  

this would help a lot with the aim to a.) remove duplication of efforts (every custom total shouldn't need to add all these columns) b.) take away complexity of having to set up the database to reduce chances for errors

Additionally to keep track of tax I think these should be linked through to the same table that we use to keep track of taxed items to allow for multiple taxes on the totals (and be able to reconstruct this later). If we don't link to the tax table we should at least add tax_percentage.

5 Comments
Not applicable
Status changed to: Investigating
 
Not applicable

Comment from barbazul, posted on GitHub May 08, 2015

+1

Current totals implementation y near to impossible to get right, and there is very little documentation on the subject.

Also, there is too much code duplication as most custom totals work more or less the same El 07/05/2015 19:02, "Kristof, Fooman" notifications@github.com escribió:

Custom Totals are a great feature of Magento. I do believe we can improve their implementation and reduce overall complexity by keeping custom totals in separate dedicated database tables similar to how we store line items.

With the current structure to add a new custom total to cover base and order currency plus tax, at my last count, one has to add:

1.) 13 columns to table sales/order 2.) 4 columns to sales/invoice 3.) 4 columns to sales/creditmemo

Not everyone gets this right including for example Enterprise custom totals:

getData('base_' . $code)

vs.

sales/order::gw_card_base_price_invoiced

I believe if we had the following tables

sales/order_totals sales/order_invoice_totals sales/order_creditmemo_totals

with the following columns:

code amount base_amount tax_amount base_tax_amount calculation_order

and additionally for the sales/order_totals table

description amount_invoiced base_amount_invoiced amount_refunded base_amount_refunded tax_amount_invoiced base_tax_amount_invoiced tax_amount_refunded base_tax_amount_refunded

this would help a lot with the aim to a.) remove duplication of efforts (every custom total shouldn't need to add all these columns) b.) take away complexity of having to set up the database to reduce chances for errors

Additionally to keep track of tax I think these should be linked through to the same table that we use to keep track of taxed items to allow for multiple taxes on the totals (and be able to reconstruct this later). If we don't link to the tax table we should at least add tax_percentage.

— Reply to this email directly or view it on GitHub https://github.com/magento/magento2/issues/1247.

Not applicable

Comment from choukalos, posted on GitHub May 08, 2015

@Fooman @barbazul how would you like this to impact service contracts or do you want that? If impact to service contracts should it just be passed through to the appropriate service contracts for get's but not puts/posts?

Not applicable

Comment from fooman, posted on GitHub May 10, 2015

The service contracts on the order, invoice, creditmemo should remain the same I guess, ie $order->getShippingAmount() would still produce the same value. However I'd advocate for an addition to the OrderInterface:

/**
 * Gets totals for the order.
 *
 * @return \Magento\Sales\Api\Data\OrderTotalInterface[] Array of totals.
 */
public function getTotals();
Not applicable

Comment from choukalos, posted on GitHub May 11, 2015

Created JIRA story - MAGETWO-37216 to backlog.