Fix weight-based shipping rate breakpoints evaluation

[Huncsuga]

Description

• This PR fixes an issue where weight-based shipping rates ignore or inconsistently apply pricing breakpoints due to mismatched weight units during comparison.

• When a Shipping Method is configured with Charge By: Weight, the cart’s total weight and the pricing break min_quantity values are not normalized to the same unit. As a result, defined Shipping Breakdowns (tiers) are skipped and the base price is often returned regardless of the actual cart weight.

• This change ensures that both values are compared using a consistent weight unit, allowing pricing breakpoints to be evaluated correctly.

Related Issue

Fixes #2381

Type

Bug fix

What was changed

• Normalized weight unit handling when evaluating shipping rate pricing breaks

• Removed incorrect scaling (×100) applied when saving weight-based pricing break values

• Ensured pricing break thresholds are stored and evaluated using the same unit as cart weight calculations

Expected Outcome

• Weight-based shipping tiers are applied correctly as cart weight increases

• Pricing breaks behave consistently regardless of the product’s configured weight unit (g / kg / lbs)

How to test

1. Create a Shipping Method with Charge By: Weight
2. Assign the Shipping Method to a Zone
3. Create a Shipping Rate with multiple weight-based pricing breaks (e.g. 5, 10)
4. Create two product variants:
   • Variant A: weight = 2 kg
   • Variant B: weight = 1500 g
5. Add the following items to the cart:
   • 1 × Variant A (2 kg)
   • 3 × Variant B (3 × 1500 g = 4.5 kg)
6. Verify that the shipping rate correctly evaluates the total cart weight (6.5 kg)
7. Confirm that the appropriate pricing tier is applied based on the combined weight

[Copilot]

Pull request overview

This PR fixes a bug where weight-based shipping rate breakpoints were evaluated incorrectly due to inconsistent weight unit handling. The fix ensures cart weights and pricing tier thresholds are normalized to kilograms before comparison, allowing weight-based shipping tiers to apply correctly.

Key Changes:

• Normalized all weight calculations to kilograms using the Converter facade
• Removed incorrect scaling factor (×100) when saving and loading weight-based pricing breakpoints
• Added UI helper text and suffix to clarify that weight thresholds should be entered in kg

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
packages/table-rate-shipping/src/Drivers/ShippingMethods/ShipBy.php	Converts product weights to kg before calculating total cart weight
packages/table-rate-shipping/src/Filament/Resources/ShippingZoneResource/Pages/ManageShippingRates.php	Removes ×100 scaling for weight values and adds kg suffix/helper text to form field
packages/table-rate-shipping/resources/lang/en/relationmanagers.php	Adds English helper text indicating weight should be entered in kg
packages/table-rate-shipping/resources/lang/ro/relationmanagers.php	Adds Romanian helper text indicating weight should be entered in kg
packages/table-rate-shipping/resources/lang/hu/relationmanagers.php	Adds Hungarian helper text indicating weight should be entered in kg

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[alecritson]

Thanks @Huncsuga Sorry for the lengthy delay in getting to look at this. Only a couple of comments if you're happy to pick this back up.

Also one concern is now we're not multiplying the value by 100 we need to ensure the pricing manager still works on the table-rate-shipping add-on. We'd need some tests to ensure everything this changes is covered.

[alecritson]

This silently excludes the line's weight from the total, potentially qualifying the cart for a cheaper shipping tier. A fallback like $line->purchasable->weight_unit ?: 'kg' would be safer than silently zeroing the weight.

[alecritson]

Any existing installation with weight-based shipping rates stored as multiplied integers (e.g., 500 meaning 5 kg) will have breakpoints that never match after upgrade, since 5.0 >= 500 is false.

A state class would be needed to rescale existing min_quantity values would be needed