Basket App help!

[Inventors]

We are currently developing an eccommerce store on oscar and we have encountered a few issues.

The first major problem is within the basket app. It is changing everything to unit prices and then rounding down or up the price depending, because it can't cope with 3 decimal places.

Classic example we've looked at e.g, 500 business cards with a unit price of £0.084p is being rounded down to £0.08p.

We do not want the price to be rounded down or up. We want the exact prices that we have in our pricelist.

 Basket app only stores unit prices with 2 decimal places. A product has to land as a Line in the basket and there is price_incl_tax and price_excl_tax.

Both are with decimal places=2. They are then used as cache so the prices are compared later, at checkout.

How do we raise baskets precision without reimplementing whole basket?

We do not want to copy original model file and use it as customized basket and change the precision there. It is a lot of code to support in the future.

We don't want to just override those fields by creating child objects either. It is not permitted in Django too.

Currently, If we calculate with high precision - later user gets warning that price has changed because calculated price=0.084 is compared with cached price 0.08

 Order and/or checkout apps also store price for caching with 2 decimal places. 

Please can you help?

Many thanks

[Fabrizio Messina]

mmh, I'm sorry but https://docs.djangoproject.com/en/1.1/topics/db/models/#field-name-hiding-is-not-permitted so you have to fork the basket.abstract_models Line, another way could be to do some magic with quantity and divide this number by ten or some other number to recalculate final the price, a sorta of floating point rep http://en.wikipedia.org/wiki/Floating_point , you just have to add a new N+field with the base to the real model, and update the calc with a simple division, you could then decide the base programmatically based uppon the product price overriding the save method.

I'm not sure about this but this could lead to a DRY violation as it's probable that you should change other models coherently, it would be better to be able to define the decimal numbers and the number length in price through setting in a simple set.

[Fabrizio Messina]

If you have to work with very small number, let's say <10^-4 It will probably be more appropriate to define a small integer field to use as exponential with base 10 and then power it by -n. i.e.:

from decimal import Context

class Basket(...):

    exp=models.SmallIntegerField()

    def save(...):

        super

        exp =  product.price.as_tuple().exponent+2

        price =  product.price * Context().power(10,exp)

        self.save()

    def price_excl_tax(..):

        return super(...) * Context().power(10,-exp)

    etcetera

I don't remember logic and names in detail so you should use this example as guideline

On Thursday, August 15, 2013 11:51:03 PM UTC+2, Inventors wrote:

[David Winterbottom]

On 15 August 2013 22:51, Inventors <in...@theimip.com> wrote:

We are currently developing an eccommerce store on oscar and we have encountered a few issues.

The first major problem is within the basket app. It is changing everything to unit prices and then rounding down or up the price depending, because it can't cope with 3 decimal places.

Classic example we've looked at e.g, 500 business cards with a unit price of £0.084p is being rounded down to £0.08p.

We do not want the price to be rounded down or up. We want the exact prices that we have in our pricelist.

 Basket app only stores unit prices with 2 decimal places. A product has to land as a Line in the basket and there is price_incl_tax and price_excl_tax.

Both are with decimal places=2. They are then used as cache so the prices are compared later, at checkout.

How do we raise baskets precision without reimplementing whole basket?

​That's quite a tricky requirement.  

Do you need to raise the precision for all money fields across all models, or just for the unit price field of the basket line?  

Further, could you treat the 500 cards as a single "unit" and perhaps add a new basket field for the per-card price?  That's what we've done in Tangent projects where bundles of items are sold.

 

We do not want to copy original model file and use it as customized basket and change the precision there. It is a lot of code to support in the future.

We don't want to just override those fields by creating child objects either. It is not permitted in Django too.

Currently, If we calculate with high precision - later user gets warning that price has changed because calculated price=0.084 is compared with cached price 0.08

 Order and/or checkout apps also store price for caching with 2 decimal places. 

Please can you help?

Many thanks

--
https://github.com/tangentlabs/django-oscar
http://django-oscar.readthedocs.org/en/latest/
https://twitter.com/django_oscar
---
You received this message because you are subscribed to the Google Groups "django-oscar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-oscar...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-oscar.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-oscar/7d1d3899-befa-4ca7-ac2c-5c8c195f3d7f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
David Winterbottom
Head of Programming

Tangent Labs
84-86 Great Portland Street
London W1W 7NR
England, UK

[Inventors]

Thanks, I am looking into this.