Retrieving the raw volume pricing discount percentage (not just the computed price)?

[delcorsets]

I'm working on a template-level optimization for a category page that displays a price table (piece/dozen/gross) across many length variants of the same product line. Each variant shares the same Volume Pricing price group configuration; the same quantity breakpoints, same percentage discounts (e.g., 12+ = 30% off, 144+ = 60% off), just applied to each variant's own different base price.

To avoid calling the volume item for every single product on the page (very costly at scale.. dozens of products per category), I'd like to call it once per product line, derive the discount percentage, and apply that same percentage to the other variants' own base prices via simple math.

The problem: neither the volume item nor Runtime_VolumePricing_Load_Product_Variant (JSON API) appear to expose the raw configured percentage.. both only return the final, already-rounded computed price at each tier (low, high, price, formatted_price). Reverse-engineering the percentage by dividing that rounded price back by the base price introduces just enough floating-point/rounding noise that it occasionally recovers the wrong whole-percent value, which is obviously a problem for something customer-facing.

Is there any documented way, MVT item, JSON API function, or otherwise, to retrieve the actual configured discount type/percentage for a Volume Pricing price group at the template or runtime level, rather than only the final computed price? Even read-only access to the Price Group's own pricing table (quantity/type/amount, matching what's shown in the admin UI) would solve this.

Any pointers appreciated.. happy to share more detail on the specific use case if helpful.

[Kent Multer]

Are you actually seeing a noticeable delay when viewing the category pages? Dozens of products might not be enough to cause that.

But to answer your question: there may not be a documented way to do it, but that's a limitation of the documentation, not the store. Some custom template code should be able to read the database and do the math. If you need help with that, you can PM or email me.

[delcorsets]

Wanted to update this thread with something we ran into while testing. Even when using the correct, confirmed percentage straight from the Price Group (not reconstructing or guessing it), we still hit a case where our own math didn't match Miva's actual output.

Specific example: a product with a $0.55 base price and a 50% Volume Pricing discount. $0.55 x 0.50 = $0.275 exactly, right on the boundary between two cents. Standard round-half-up rounds that to $0.28. But the actual cart price for that product came out to $0.27, meaning Miva's own internal engine rounded that same exact halfway value down, not up.

So it looks like there are two separate things going on: getting the correct percentage in the first place (the original question in this thread), and then knowing exactly which rounding rule to apply once you have it. Getting the percentage right doesn't help if the rounding step afterward doesn't match Miva's own behavior.

Is there any documentation on which rounding method Miva's engine actually uses internally for volume pricing calculations, specifically at exact halfway values like this? Standard round-half-up, round-half-down, round-half-to-even (banker's rounding), or something else, possibly related to how percentages and prices get represented internally? Even knowing the general rule would help a lot.

Kent Multer Thanks, I sent you a PM but as described above I discovered that the discount percentage alone would not have provided a foolproof solution.. it also seems to require more concreted knowledge of Miva's rounding rules.

[Rick Wilson]

I believe we follow Banker's Rounding, I'll have someone confirm.

[Kent Multer]

Yes, last I heard, the Miva store uses "banker's rounding," which IIRC rounds down instead of up for numbers ending in a 5, depending on whether the digit next to the 5 is odd or even. As a test, you can change the base price from .55 to .57, and see if it rounds .285 up to .29. Similarly, .59 divided by 2 should give a result of .29, because the store will round down for .295.

According to Google, the store does have a setting to turn this off, but only for sales tax calculations, not for other math. That matches what I recall. I have some code that I wrote for another client to do conventional rounding.

[delcorsets]

Rick Wilson Thanks for jumping into the thread. Wanted to share something concrete we ran into while testing, since it might be useful context.

We found two cases that look identical on paper but rounded in opposite directions. Both are Volume Pricing discounts, (not sales tax):

• $0.55 base price at 50% off = $0.275 exactly. Actual cart price came out to $0.27 (stayed down).
• $0.95 base price at 70% off = $0.665 exactly. Actual cart price came out to $0.67 (rounded up).

Both are exact halfway values under the "stay on 5, round down" rule mentioned in a different thread about rounding, but they went opposite directions.

Just want to flag this since it means "bankers rounding" doesn't fully explain what we're seeing in practice, at least not for volume pricing discounts specifically.

[Nick]

On the raw percentage: there's no JSON API function or MVT item that gives you that. Runtime_VolumePricing_Load_Product_Variant and the volume item both hand back low/high/price/formatted_price only. PriceGroupList_Load_Query and its Coupon/Customer variants return generic price group columns (rate, discount, markup) that only apply to legacy price groups, plus module metadata like id and name. Never the module's own config.

The pricing table Miva actually evaluates lives in pricegroup:config:table, an array of {low, high, type, amount} entries, where type is F (fixed), A (absolute), or P (percent). That gets populated from the DefaultPricingTable block in the price group's provisioning settings, or from VolumeDiscountOverrides for per-product overrides. It's read via PriceGroup_Load_Name inside modules/discount/volume.mvc, and the only place that data gets serialized back out is Volume_Discount_Cumulative / Volume_Discount_Progressive, which apply the percent and hand back a dollar amount. The percent itself never makes it past the module boundary.

If you want the exact value with no reverse-engineering, you're looking at a small custom module function that reads the price group directly. Same idea as how discount_customerspecific exposes Product_CustomerPriceList_Load_Query as a JSON API entry point, just to give templates a clean read into otherwise-internal module data. Call PriceGroup_Load_Name, read pricegroup:config:table (plus VolumeDiscountOverrideLookup_Load_Product if you're using overrides), return {quantity, type, amount}. One call per shared price group and you're covered for every variant in the line.

I can add this as a feature request as there have been a lot of discussion recently around getting the volume pricing data.

As far as how Miva handles rounding thing. All rounding goes through the MivaScript ROUND operator, and that operator consistently implements Banker's Rounding, round to even.

Your $0.55 / 50% case looks like it broke that rule but it didn't, it just rounds in a different order than you'd expect. The module doesn't take the discounted price and round it. It rounds the discount amount first, then subtracts:

DiscountState_Discount_Item_Fixed(
...,
( item_price * ( discount_percent / 100.0 ) ) ROUND scale
)

So what gets rounded is the discount, and the final price is price minus discount, not price times (1 minus percent) rounded directly. Same result in real-number math, but they can land a cent apart right at a boundary, which is exactly what happened here.

0.55 * 0.50 is $0.275. Round to even at 2 decimals means choosing between 0.27 and 0.28, and 8 is the even digit, so that rounds to 0.28 regardless of whether the engine treats it as an exact tie or as a value sitting a hair above 0.275. Either way it lands on 0.28. So the discount amount rounds to $0.28, and the final price is $0.55 minus $0.28, which is $0.27. What looks like the final price rounding down at the halfway point is actually the discount rounding up, then getting subtracted.

Hopefully this clears things up a bit.

[delcorsets]

Nick thank you that is excellent information.. Yes to the feature request for getting volume pricing data too!