by pricerc » Tue May 04, 2021 11:35 am
So I was finally able to get back to this yesterday.
On my VM, using the customer's data (that you had for DEV-7704), a batch of 268 lines was taking several seconds per line to update.
I run VMware on a Ryzen 7 4800H, running at 3.something GHz. The VM is configured with 8 cores and 16GB of RAM. The single virtual hard drive is hosted on a SATA SSD, although the process is very much CPU-bound. So my VM is at least comparable to a customer's machine. If anything, it's probably got more grunt than most of my customers' systems.
So I don't know why it would be an order of magnitude slower than someone else's database.
Anyhoo.
Last night, I ended up reverse-engineering the code that lives in clsPayLineInvoice.set_CurrencyRateUsedOnBatch, and taking out the bits that don't apply to what I'm doing.
The whole batch now takes about a second.
On looking through the code, is seems, quite reasonably, to be geared towards a user editing a single transaction. It has a bunch of sanity checks, and bubbles changes up to the UI. There is also a bit of escalation in the mix, so that related values are getting updated correctly.
Stepping through the code. The biggest delay seemed to be when setting RecordMode, which triggered the UI update, which in turn causes some further sanity checking on the values so that error messages can be displayed to the user.
Including AutoAllocateCreditsSpecificCreditor also delayed the process a little, but not as much as setting RecordMode.
In my case, most of that doesn't matter - The exchange rate changes are being applied to an otherwise correct batch. So there are no changes happening to the FX values themselves, only to the local currency values that are being affected. This includes: PaymentAmount, OutstandingAmount, PaymentFromBankAmount, PaymentFromCreditsAmount, DiscountedAmount, DiscountAmount, GSTAmount.
So I don't need most of the safety checks. And I don't need any code that changes any of the FX versions of those amounts.
The customer also doesn't have credits in their FX payment batches, and so AutoAllocateCreditsSpecificCreditor doesn't apply to our situation and I was able to leave that out (as a safety check, I disable the change rates button if any exist in the batch).
So for each payment line, I now update the amounts mentioned above, using logic extracted from set_CurrencyRateUsedOnBatch, set_PaymentFXAmount, and set_DiscountedFXAmount.
I do the changes grouped by creditor, and run ReCalculateTotals for each creditor after processing all the lines for the creditor.
After all creditors have been processed, I run CalculateTotals on the payment batch.
Then I call DisplayBatch and CheckEditStatus on the form to refresh it.
Having suppressed most of the standard logic by setting the "IsReading" property on the batch and "SuppressCalculation" on the lines, I did have to resort to reflection to update the batch's ChangeFlag after doing the updates, otherwise the "Save" and "Cancel" buttons didn't get enabled.
- Attachments
-
Plugin AERP - EFT UI.xml
- Updated plugin
- (58.33 KiB) Downloaded 1654 times