I've found some time now to explain what our patch is doing.
The changes are actually in production in our system and generate correct accounting for the German tax system.
When we have sales tax in a purchase invoice it means that we actually get a tax refund/rebate ("Vorsteuer").
The change at @@ -2144,6 +2122,18 @@ sets the glAccountId in the acctgTransEntry according to the tax authority party and geo id found in the invoice items. This is necessary so that the right account for the tax authority is used in the posting of the transaction.
The changes were basically copied from the createAcctgTransForSalesInvoice method, where the same logic is implemented. (For sales invoices we have to pay taxes, so it is a creditEntry. For purchase invoices we get a tax rebate, so it is a debitEntry.)
The change at @@ -2165,6 +2155,7 @@ also just makes the purchase invoice code more like the sales invoice code. The unattributedTaxTotal has to be posted to a tax account. In the sales invoice this is already set, in the purchase invoice it isn't – the patch fixes that. This is basically like the fallback in the change @@ -2144,6 +2122,18 @@, where we set the same value when we can't find a matching configuration for the tax authority. In case we have unattributed tax entries, we don't even need to try to find a tax authority configuration and simply set the fallback account type, so it gets posted to the default tax account.
Regarding @@ -2173,6 +2164,10 @@: The call to getInvoiceTaxTotal was simply missing here. A few lines down the variable invoiceTaxTotal is accessed. Without applying the patch it is never set.
Jacopo is right for @@ -1841,28 +1841,6 @@ and @@ -2359,39 +2354,6 @@ – they are just (unrelated) cleanup. Like the comment says, the functionality has moved to the createAcctgTransAndEntriesForPaymentApplication method, and as far as I can tell is working correctly.
I hope the changes make more sense now.