Step 5: Migrate transaction data

You can migrate transaction data by running certain commands.

About this task

  • When migrating from 9.3, 9.4, or 9.5 to 10.0, run the following command:
    • ${ANT_HOME}/bin/ant -Druntime=<INSTALL_DIR> -Druntime.old=<INSTALL_DIR_OLD> 
      -f buildmigration.xml -logfile <logfile> 
      -Dtarget=upgrade-transaction-tables migrate
      
  • When migrating from 9.3, 9.4, or 9.5 to 10.0, from the <INSTALL_DIR>/COM/Migration/9.5/COM_Add-in directory, run the following command:
    ${ANT_HOME}/bin/ant -f ycdmigration.xml -Druntime=<INSTALL_DIR>
    -Druntime.old=<INSTALL_DIR_OLD> 
    -DYANTRA_RUNTIME_NEW=<INSTALL_DIR>
    -Dtarget=upgrade-transaction-tables 
    migrate -logfile <logfile>
    
    Important:
    • As part of the transaction data migration, only the factory defaults are upgraded.
    • If you are migrating from 9.3, 9.4, or 9.5 to 10.0, along with COM_Add-in, but do not want to upgrade Sterling Call Center or Sterling Store Engagement (Legacy) run the following command:
      ${ANT_HOME}/bin/ant -f ycdmigration.xml -Druntime=<INSTALL_DIR>
      -Druntime.old=<INSTALL_DIR_OLD> 
      -DYANTRA_HOME_NEW=<INSTALL_DIR>
      -DYANTRA_RUNTIME_NEW=<INSTALL_DIR>
      -Dtarget=upgrade-transaction-tables -Dcom.recertification=true
      migrate -logfile <logfile>
      
  • This command performs the following inner tasks:
    • pre-transaction-migration
    • migrate-transaction-data
    • post-transaction-migration
    • apply-fc-setup
  • Typically you update the unique transaction indexes by running the install-transaction-indexes target before you update tables with the upgrade-transaction-tables target. However, if more than one record exists in the YFS_USER table for DISPLAY_USER_ID or ENTERPRISE_CODE, you must run the upgrade-transaction-tables target before you run the install-transaction-indexes target. Otherwise, the install-transaction-indexes target fails because a unique index cannot be created for the YFS_USER table.
  • If you have deleted any factory setup records and the upgrade-transaction-tables target fails, you must add the deleted records to the database before continuing the upgrade.
  • If an SQLCODE=-204, SQLSTATE=42704 error is displayed when you run the upgrade-transaction-tables target on Db2®, you can ignore the error message.
  • If you are upgrading from 9.0 or earlier version, and if the ORA-12899: value too large for column COMMON_CODE_KEY in YFS_COMMON_CODE error message is displayed, ensure that either the COMMON_CODE_KEY is not more than 19 bits or change the migrator <INSTALL_DIR>\Migration\9.0\transaction\xmls\migrator_customer_common_codes.xml where you append 5 bits 90MIG to COMMON_CODE_KEY by ensuring that the total length is not more than 24 bits.
  • The YSCPreInstallMetadataCreator class is called to create the factory setup for the metadata shard. The class creates records in the following tables:

    
    PLT_DB_COLONY
    PLT_DB_COLONY_POOL
    PLT_DB_POOL 
    

    These tables store connection properties for a Sharded deployment.

    • The *.done files created in the 9.3 status folder for the task upgrade-transaction-tables are:

      • transaction_ant_pca_migration.xml.done
      • transaction_ant_migration.xml.done
      • transaction_ant_postmigration.xml.done
      • transaction_ant_premigration.xml.done
      • transaction_ant_applyfcsetup.xml.done
      • transaction_Add-in_applycomfcsetup.xml.done
    • The *.done files created in the 9.4 status folder for the task upgrade-transaction-tables are:

      • transaction_ant_pca_migration.xml.done
      • transaction_ant_migration.xml.done
      • transaction_ant_postmigration.xml.done
      • transaction_ant_premigration.xml.done
      • transaction_ant_applyfcsetup.xml.done
      • transaction_ant_applicationversion.xml.done
      • transaction_ant_metadatamigrator.xml.done
      • transaction_ant_apiresourcemigrator.xml.done
      • transaction_Add-in_applycomfcsetup.xml.done
    • The *.done files created in the 9.5 status folder for the task upgrade-transaction-tables are:

      • transaction_ant_pca_migration.xml.done
      • transaction_ant_migration.xml.done
      • transaction_ant_postmigration.xml.done
      • transaction_ant_premigration.xml.done
      • transaction_ant_applyfcsetup.xml.done
      • transaction_ant_applicationversion.xml.done
      • transaction_ant_metadatamigrator.xml.done
      • transaction_ant_apiresourcemigrator.xml.done
      • transaction_Add-in_applycomfcsetup.xml.done
  • When migrating from 9.3, 9.4, or 9.5 to 10.0, run the following queries if necessary:
    • If you have custom status modification groups, run the respective update query to fix status modification records inserted during the upgrade.
    • If custom status modification group is created for ORDER_FULFILLMENT:
      update YFS_STATUS_MODIFICATION set STATUS_MOD_GROUP_KEY='ORDER_FULFILLMENT' WHERE ORGANIZATION_CODE = 'DEFAULT'
       AND STATUS_MOD_GROUP_KEY IS NULL AND STATUS_MODIFICATION_TYPE_KEY IN 
      ( SELECT STATUS_MODIFICATION_TYPE_KEY FROM YFS_STATUS_MODIFICATION_TYPE WHERE PROCESS_TYPE_KEY='ORDER_FULFILLMENT' )
    • If custom status modification group is created for PO_FULFILLMENT:
      update YFS_STATUS_MODIFICATION set STATUS_MOD_GROUP_KEY='PO_FULFILLMENT' WHERE ORGANIZATION_CODE = 'DEFAULT' 
      AND STATUS_MOD_GROUP_KEY IS NULL AND STATUS_MODIFICATION_TYPE_KEY IN 
      ( SELECT STATUS_MODIFICATION_TYPE_KEY FROM YFS_STATUS_MODIFICATION_TYPE WHERE PROCESS_TYPE_KEY='PO_FULFILLMENT' )
    • If the custom status modification group is created for QUOTE_FULFILLMENT:
      update YFS_STATUS_MODIFICATION set STATUS_MOD_GROUP_KEY='QUOTE_FULFILLMENT' WHERE ORGANIZATION_CODE = 'DEFAULT' 
      AND STATUS_MOD_GROUP_KEY IS NULL AND STATUS_MODIFICATION_TYPE_KEY IN 
      ( SELECT STATUS_MODIFICATION_TYPE_KEY FROM YFS_STATUS_MODIFICATION_TYPE WHERE PROCESS_TYPE_KEY='QUOTE_FULFILLMENT' )
Important: This note is applicable only to those customers who want to upgrade Sterling Order Management System Software to release 10.0 and then install Sterling Store Inventory Management release 9.3.

The YFS_SHIPMENT_LINE table in Sterling Order Management System Software has a column named BACKROOM_PICKED_QTY and Sterling Store Inventory Management has a column named BACKROOM_PICKED_QUANTITY which was referred with the XML name BackroomPickedQuantity. However, this XML name now points to BACKROOM_PICKED_QTY column. The shipment APIs return the value of this column in the BackroomPickedQuantity attribute.

Therefore, for existing shipments, users must update the value of BACKROOM_PICKED_QTY same as BACKROOM_PICKED_QUANTITY by running an SQL query like update yfs_shipment_line set backroom_picked_qty=backroom_picked_quantity.