Next generated increment_id completely wrong after DB conversion?

[csdougliss]

Preconditions

1. Magento EE 1.14.3.10 (no orders in DB, for testing)
2. Magento EE 2.2.6
3. PHP 7.1.24
4. MySQL 5.7.24

Steps to reproduce

1. In Magento 1 - eav_entity_store, last_increment_id is 307719923, store_id is 3, entity_type_id is 5 (order)

2. Convert DB from Magento 1 to Magento 2 using data migration tool

3. After data conversion - sequence_order_3 is 72434671

4. sales_sequence_profile is 3 3 3 1 1 4294967295 4294966295 1

5. After place order - order number is 3072434672

Expected result

1. Next order number should be 307719924, not 3072434672

Actual result

1. Order number 3072434672

Additional notes

Not only is the next order increment Id the wrong sequence, it is also 1 extra number longer.

It's possible to reduce the length to what we have here by adding:

<type name="Magento\Framework\DB\Sequence\SequenceInterface">
        <arguments>
            <argument name="pattern" xsi:type="string">%s%'.08d%s</argument>
        </arguments>
    </type>

However, this does not fix the issue that the order increment Ids are not following the correct sequence after db conversion.

[victor-v-rad]

Hi @craigcarnell

Increment policy for sales entities (orders, invoices ...) has changed in M2. See my comment for more detail. And the tool can do nothing about it. The number 3072434672 is because 72434672 is the maximum number in eav_entity_store table for entity_type_id is 5 (order). It means there is a record ?072434672 in increment_last_id column for some store_id (not 3).
You can change \Migration\Step\SalesIncrement\Helper::getMaxIncrementForEntityType() method so that it will return 307719924 if you will

[csdougliss]

@victor-v-rad Thanks for the clarification. Still slightly confused..

The problem is this number is always increasing and therefore cannot be hard coded.

Why can't getMaxIncrementForEntityType() take it's value from store view level from m1?

[victor-v-rad]

I did not mean hard-coded number but tp change the algorithm of getMaxIncrementForEntityType() method so that it will return the number as you expected

[csdougliss]

Isn't the value 72434672 per store so shouldn't pick up the correct value from m1? Or take the highest number from the collection of store views?

[victor-v-rad]

yes the tool takes the highest number from the collection of store views

[csdougliss]

@victor-v-rad The tool does not appear to be operating correctly.

If the increment Id is now based on store, and not store view, then the tool is not picking the highest store increment_id for that group of store.

Why would it pick up the highest increment_id for all stores? Magento 2 can maintain a separate list per Store can it not?

It is picking a completely different increment_id globally (the highest number it can find).

For example,

Store View 3 has a increment_last_id of 307736459 in eav_entity_store for entity_type_id 5
Store View 15 has a increment_last_id of 1572443269

Store View 3 is part of Website 3
Store View 15 is part of Website 13

In Magento 2, it is picking the value 72443211 for sequence_order_3, which I assume comes from Store 15 in M1, as that is the closest value I can possibly find!!

Here is my eav_entity_store values:

entity_store_id	entity_type_id	store_id	increment_prefix	increment_last_id
1	5	1	1	107000026
3	5	3	3	307736459
11	5	5	5	507500001
13	5	15	15	1572443269
19	5	16	16	1670360959
29	5	11	11	1170011998
33	5	31	31	3170083011
37	5	34	34	3470019230
2	6	1	1	107000011
5	6	3	3	357494074
12	6	5	5	507500000
14	6	15	15	1571261903
20	6	16	16	1670311589
30	6	11	11	1170002444
34	6	31	31	3170064538
38	6	34	34	3470019224
10	7	3	3	307021032
26	7	15	15	1570006584
27	7	16	16	1670004818
32	7	11	11	1170000021
35	7	31	31	3170001425
40	7	34	34	3470000503
4	8	3	3	307251308
15	8	15	15	1571271487
21	8	16	16	1670420121
22	8	1	1	107000009
31	8	11	11	1170000660
36	8	31	31	3170056576
39	8	34	34	3470018961

Store ID 3 is under Website Id 3.
There are 4 stores in Website 3. There is no increment_id in eav_entity_store except for Store 3.

This needs fixing also for invoices, credit memos, rma, shipment as well presumably.

You acknowledged this in #163 but the issue was then closed?

[csdougliss]

@victor-v-rad any update on this issue please?

[csdougliss]

@victor-v-rad can you confirm is anyone is looking at this please?

[victor-v-rad]

If the increment Id is now based on store, and not store view, then the tool is not picking the highest store increment_id for that group of store. Why would it pick up the highest increment_id for all stores?

Sorry for not answering to your question right away. Yes, you are right. It will be better if the tool find the highest number from store group and not from all stores. Internal ticket MAGETWO-97203 to fix it

[csdougliss]

@victor-v-rad Excellent, looking forward to a fix. If you manage to resolve this internally, I would be happy to test this before the next release of the tool.

[victor-v-rad]

Fixed. Please test

[csdougliss]

@victor-v-rad Is there any way in my composer.json to specify this commit or branch? When I try I get:

  Problem 1
    - The requested package magento/data-migration-tool dev-2.3-develop as magento/data-migration-tool[2.3.0, 2.0.0, 2.0.2, 2.0.5, 2.0.7, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.2.6, 2.2.7] but these are rejected by your constraint.

Same for the commit.

[victor-v-rad]

I can install the tool by the command composer require magento/data-migration-tool:dev-2.3-develop in my M2.3.0 with out the issues you have

[csdougliss]

@victor-v-rad

composer require magento/data-migration-tool:dev-2.3-develop

In InitCommand.php line 706:
                                                                                            
  Could not find package magento/data-migration-tool in a version matching dev-2.3-develop

Do I need to add it as a repository?

[csdougliss]

@victor-v-rad I got it to work by adding to composer.json

"magento/data-migration-tool": {
            "type": "vcs",
            "url": "[email protected]:magento/data-migration-tool.git"
        }

[csdougliss]

@victor-v-rad This has worked tremendously well!

Please can this be included in 2.3.1? Thank you 👍

[victor-v-rad]

Glad it works ) Will be included into 2.3.1