Regression: price_excl_tax is necessary for availability

[maiksprenger]

I get to upgrade an old Oscar project, and that went really well. Thanks for keeping Oscar so backwards-compatible! I noticed just a small regression for a corner case:

I work on a project where it was essential that Oscar stores the tax-inclusive price and the price without tax is calculated. The reasoning is that the tax-inclusive prices are legally binding, and doing it this way ensures that a bug in the price calculation logic has less of an impact.

This was easily done by storing the price_incl_tax on the stock record, and writing a short pricing policy for it. But two recent changes here and here make this harder, because they look at a price_excl_tax and assume because that is not set, the product is not available to buy.

I'd like to argue that pricing and availability are concepts that should be kept separate, and the two commits linked above essentially bypass Oscar's pricing logic.

My workaround was to backport the StockRequired policy from Oscar 1.4.

[solarissmoke]

@maikhoepfel I think you're right that pricing and availability should be kept separate.

The issue that those commits were trying to fix was an exception if you try to add a product without price_excl_tax to the basket. How do you handle that issue in your case?

[maiksprenger]

Hey, For me it’s not a problem, because all products have a tax-inclusive price set, and every time Oscar wants to know about the price of a product, the pricing strategy is queried and hence Oscar has the price it needs. I presume you mean products without a price at all. Is Oscar even prepared to handle that? If not, it’s a matter of making sure forms enforce a price, and dropping out with a more helpful exception if the product was created manually. If Oscar should be able to handle products without a price, I’d return a Unavailable() class in the pricing policy like we do for shipping, and make sure all parts of Oscar can deal with it. But that’s just my opinion - I haven’t digged into Oscar for a while. Samir Shah <notifications@github.com> schrieb am Do. 5. Apr. 2018 um 06:55:

…

@maikhoepfel <https://github.com/maikhoepfel> I think you're right that pricing and availability should be kept separate. The issue that those commits were trying to fix was an exception if you try to add a product without price_excl_tax to the basket. How do you handle that issue in your case? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2664 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfF81ObjubBbfulRf3IBbl9D0tL7VANks5tlaPKgaJpZM4TFP7f> .

[solarissmoke]

Proposed fix here: #2679.

I have only reverted the changes in #1913 and offered a different way to handle the issue that it was trying to fix.

#2294 seems to be correct to me in the sense that that change was to pricing policy rather than availability policy - and for FixedRateTax it makes sense to return UnavailablePricing if price_excl_tax is not set - if you don't know it then you need to use a different strategy.