I am working on a top to bottom rewrite of the UPS shipping provider (BV 5.6) because we have had serious performance issues with the default UPS provider.



Through analysis, I discovered that the first stage of the provider calls a method on the order object that splits the order into multiple "groups". After more analysis I realized that these "groups" are actually separate shipments. So all providers by default split the "ships separately" items at this stage into separate shipments.



However, after digging deeper I realized that there is no need to split out the "ships separately" items at that point. After all, there is no limit to the number of packages in a shipment - "ships separately" as far as I can tell could just mean put in a separate box in the same shipment that has the same origin and destination.



The key difference is that because "ships separately" is broken into a different shipment, it means everything that ships separately requires a separate API call to UPS to get the rate for the package. If there is a quantity of 200 of the item ordered, that is 200 round trips to the UPS API. However, if the "ships separately" items were considered a separate package in the same shipment, it would only require 1 call to the UPS API.



So, is there anything I am missing about "ships separately" that is preventing them to be packaged together in the same API request? The only thing I can come up with is that the author of BV decided that it should be done at that point to ensure that every 3rd party shipping provider respects the "ships separately" flag, but as the logic can be overridden anyway I don't see what is gained for this huge performance loss.