kylewest
commented
6 years ago @StephenPAdams - great bug report. I agree 100% with everything you posted including the potential fixes.
Ideally we'd be able to show rates per package and allow the user to select Priority for the first and Ground for the others; however, that certainly does open up a can of worms. The biggest of which is breaking functionality for everyone currently using DotNetShipping. There's also the question of whether the other carriers behave similarly.
I think we could handle 90% of the use cases by going with your Quickie fix and adding a InfoMessage (or whatever) property to Shipment with something along the lines of:
Removed Priority Mail Express 1-Day, Priority Mail 2-Day from returned rates. Rate not available on all packages in Shipment.
I'm on vacation until labor day, but if this is something you want to work on I'll have access to email and can push a new release to nuget when it's complete (or do you have access to do that too?).
Kyle
Recently had a customer order 9 packages worth of items, essentially this configuration:
...however what ends up coming back from USPS is some really goofy rates. And I believe it's because there's a package that returns Priority Mail and Ground (the 14x14x6 box) and the other packages all return just Ground. You can see the raw formatted XML response here: https://gist.github.com/StephenPAdams/d3a9ec8c41eea5bbef7acde71ace08c2
Anyways, inside of the USPSProvider's ParseResult, it actually does a join by MailService. So the Ground total ends up being correct. However, you'll see any of the Priority Mail options all with very cheap rates like the Priority Mail 2 Day at $9.75.
The problem is when the rates are returned to the DotNetShipping SDK and then surfaced up...it appears that Priority Mail 2 day for $9.75 is the rate for all 9 packages...which isn't the case. If you look at the XML response, there are multiple top level PACKAGE nodes. But not each Package node has the same MailService in each. I'm guessing it's because some packages are available under certain services.
I think this is a more complicated problem. But a quickie fix would be to make sure that the MailService is available in each returned package. If it's not, it's removed as a rate. Otherwise we'd have to use unique package identifiers and then have the rates broken down by package and then there'd need to be a layer to calculate/tally them appropriately.