How to Fix "sales_order_data_exporter view does not exist" in Magento 2

The error means exactly what it says at the framework level: something asked Magento’s Mview configuration for a view with the ID sales_order_data_exporter, and no enabled module declares it. The declaring module is Magento_SalesOrdersDataExporter, shipped in the magento/commerce-data-export package and installed as a dependency of Adobe Payment Services (magento/payment-services). The fix is one of two moves: enable the module set the command expects, or remove the leftover references to it. Both take minutes. The diagnosis below tells you which one you need.

InvalidArgumentException: sales_order_data_exporter view does not exist.

The exception comes from vendor/magento/framework/Mview/View.php. The load() method throws it whenever a view ID is requested that is missing from the merged mview.xml configuration of all enabled modules.

Where the error shows up

• Running an indexer command that names the feed directly, for example the command from Adobe’s own Payment Services setup guide:

  bin/magento indexer:set-mode schedule sales_order_data_exporter sales_order_status_data_exporter store_data_exporter

• During bin/magento setup:upgrade or a deployment pipeline that includes such a command.

• In var/log/cron.log or var/log/system.log on stores where the module set changed but indexer references remained.

sales_order_status_data_exporter and store_data_exporter fail with the same message for the same reason. Everything below applies to them as well.

Diagnose: which situation are you in?

Run these two checks:

composer show magento/module-sales-orders-data-exporter
bin/magento module:status Magento_SalesOrdersDataExporter

Three outcomes:

1. Package missing: Composer reports the package is not installed. You either need to install Payment Services or remove whatever still references its indexers (fix 1 or fix 2).
2. Package present, module disabled: module:status prints the module under “disabled”. Enable it if you use Payment Services, or clean up if you don’t.
3. Package present, module enabled: the config the command needs exists, so the error points at a stale config cache or an environment mismatch (fix 3).

Fix 1: Install and enable the module set (you use Payment Services)

If the store should be running Payment Services and the package is missing, install it:

composer require magento/payment-services
bin/magento setup:upgrade

If the package is present but the modules are disabled, enable the exporter modules and re-run setup:

bin/magento module:enable Magento_DataExporter Magento_QueryXml Magento_SalesOrdersDataExporter
bin/magento setup:upgrade
bin/magento cache:clean config

Then the original command works:

bin/magento indexer:set-mode schedule sales_order_data_exporter sales_order_status_data_exporter store_data_exporter

Fix 2: Remove the references (you don’t use Payment Services)

The error keeps returning because something still asks for the feed. Find and remove those references:

1. Deploy scripts and crontab. Search your CI/CD configuration and server crontab for data_exporter. The indexer:set-mode line from an old Payment Services setup is the most common leftover.

2. Disable the modules consistently (when the package is still installed but unused):

   bin/magento module:disable Magento_SalesOrdersDataExporter
   bin/magento setup:upgrade
   bin/magento cache:clean config

   Or remove the package entirely with composer remove magento/payment-services.

3. Clean stale indexer state left in the database from a previous installation. Back up the database first:

   DELETE FROM mview_state   WHERE view_id    LIKE '%data_exporter%';
   DELETE FROM indexer_state WHERE indexer_id LIKE '%data_exporter%';

   Leftover changelog tables (names ending in _cl, such as sales_order_data_exporter_cl) can be dropped as well. They are recreated automatically if the modules are ever reinstalled.

Fix 3: Clear the cache and align environments (module already enabled)

The merged mview.xml configuration is stored in the config cache. Enabling or disabling modules without refreshing it leaves commands reading yesterday’s module list:

bin/magento cache:clean config

The other frequent source is environment drift: an app/etc/config.php copied from an environment with a different module set, or a database imported from staging into production. After any such sync, run bin/magento setup:upgrade so code, configuration, and database agree on which modules exist.

Verify the fix

bin/magento indexer:status

With the modules enabled, the exporter feeds appear in the list with a valid status. With the modules removed, the command completes without mentioning them and var/log/cron.log stays clean over the next cron runs.

Related reading

This error is one of a family of cryptic Magento messages. Our Magento 2 issues FAQ collects the rest. If the error appeared mid-upgrade, the guide to upgrading Magento 2.4.6 covers the deployment sequence that keeps module state consistent. And if your team is spending more time on deploy failures than features, that is exactly the kind of work our Magento development services take over.