We’ve been having issues with orders not having recalculated Order Totals after applying updates to line items via the API (primarily to PPU). Looking at previous topics on the subject, the most common methods for working around this are to use recalculateTax() after applying these updates or to use applyPaymentPlan() to have it recalculate the total. Neither option is currently resulting in the desired outcome (and both are fairly hacky to begin with, with each resulting in additional noise being created on orders, which isn’t ideal). At one point in one of our scripts, we were able to use the recalculateTax() option, but it suddenly stopped working some time back (probably June/July 2019ish).
In addition to those methods, we’ve also tried using the REST method for creating a payment on an order with similar results. As a result, this method throws an error when the payment is larger than the order total.
Are there any updated solutions to this issue (documented or otherwise)?
To switch gears a bit, we’re also having issues applying multiple promo codes to an order when creating one with the XML-RPC placeOrder() method. One of the arguments that this method accepts is an array of promo codes to apply to the order, but it only ever applies one promo code at most, and it’s always the last item in the array.
Is there a way to force it to apply multiple promo codes (given that an array would imply that it can handle it), or do we pretty much have to pick the most important one and just run with that? From what I can see in the table schema, promo codes can only be written at the time of order creation, so we can’t go and update them after the fact.