Before this commit, the invoice creation flow of a sales order checked
if the amount of the generated invoice was positive or negative - if it
was negative, then the invoice would be converted to a refund instead.

Unfortunately, this check was done before the move was actually created
\- meaning that the only way to compute the total of the move was to
multiply the quantities and unit prices of what was about to be included
in the move - ignoring taxes altogether. Since taxes would then be
applied during the move's creation, you could in fact have a refund that
ended up being negative because some products would end up with
different taxes.

A simple (although weird) example would happen if you registered a
down payment that was actually greater than the subtotal of your
quote (but lower than the total with taxes included).
Example:
Create a quote for a 100$ product with 15% tax
Register a downpayment of 105$ and validate that invoice
Invoice the rest:
 => you end up with a refund of -10$, while you should have a 10$
invoice instead.

Since the downpayment did not have taxes, the second invoice was
computed as being negative (100$ for the product - 105$ to deduce the
down payment), even though after the 15% tax gets applied on the product
(but not on the downpayment), the invoice is actually positive.

This commits moves the switch from invoice to refund to *after* the move
actually gets created, ensuring taxes are taken into account.