Payments from Commerce 1 have wrong decimal place

@benjifisher I am using this as a process plugin as a work around:

<?php

namespace Drupal\my_custom\Plugin\migrate\process;

use Drupal\commerce_price\Calculator;
use Drupal\migrate\MigrateExecutableInterface;
use Drupal\migrate\MigrateSkipRowException;
use Drupal\migrate\ProcessPluginBase;
use Drupal\migrate\Row;

/**
 *
 * @MigrateProcessPlugin(
 *   id = "commerce1_migrate_payment_amount"
 * )
 */
class PaymentAmount extends ProcessPluginBase {

  /**
   * {@inheritdoc}
   */
  public function transform($value, MigrateExecutableInterface $migrate_executable, Row $row, $destination_property) {
    if($value) {
      $new_value = [
        'number' => Calculator::divide($value, bcpow(10, 2)),
        'currency_code' => 'USD',
      ];

      return $new_value;
    }
  }
}

I've seen the same thing but not consistently. I haven't been able to discern any pattern as to when it happens.

To support other currencies, we should use Drupal\commerce_price\MinorUnitConverter::fromMinorUnits instead of assuming it should be divided by 100.

An alternative approach is taken by https://www.drupal.org/project/commerce_migrate/issues/3262612 , which allows the CommercePrice process plugin to be used with these values by passing it array of amount and currency_code.

I'm seeing the data showing as it does in the issue summary - commerce_payment.amount_number values show as e.g. "572.0000". I suspect the patch should resolve the problem, but I suspect #8 is probably the best approach.

That said, here's some test coverage.

I thought so - the balance_number needed to be changed too.

This moves over the amount/currency logic from #3262612 and adds the test coverage from here, but doesn't include Benji's original change.

The logic from #3262612 doesn't help :-\

Going back to the original solution, this should fix the second payment record.

Let's add test coverage for the third successful order that's migrated.

#16 works on my test sandbox and on my live test data with > 30,000 payments

A tests-only version of patch #16.

Most of the test failures are because of incompatibilities with PHP 8.1, so I opened #3270534.

I've tested the patch in #16 and it's working great for me - thanks!

setting to RTBC

Thanks for finding and fixing this and providing a test. Just one point.

+++ b/modules/commerce/src/Plugin/migrate/source/commerce1/PaymentTransaction.php
@@ -68,6 +68,12 @@ public function prepareRow(Row $row) {
+      $amount = (float) $amount / 100;

This is assuming that the currency uses two fraction digits. It would be more robust to get the actual fraction digits for the currency and use that, like the ShippingFlatRate source plugin.
Something like this,

    if ($amount = $row->getSourceProperty('amount')) {
      $currencyRepository = new CurrencyRepository();
      $currency_code = $row->getSourceProperty('currency_code');
      $fraction_digits = $currencyRepository->get($currency_code)->getFractionDigits();
      $amount = bcdiv($amount, bcpow(10, $fraction_digits), $fraction_digits);
      $row->setSourceProperty('amount', $amount);
    }

Patch in #16 worked for me as well, thanks! (Currencies used here have two fraction digits.)

Adding in the suggestion from #22

The patch provided by @quietone works without any issues.

I am going to commit #24 because it didn't modify the tests and they still passed. The same way of handling the currency fraction digits is used in the CommercePrice process plugin and the ShippingFlatRate source plugin.

Thanks everyone for working on this problem