View Issue Details

IDProjectCategoryView StatusLast Update
0006223OXID ERP InterfaceOXID ERP Interface - subpublic2019-12-17 08:59
Status resolvedResolutionfixed 
Product Version2.14.0 
Target VersionFixed in Version2.14.2 
Summary0006223: shopid switches to 1 if tmp file cache is cleared during import
DescriptionTheres (probably) a bug in oxerpbase which causes a change of the shopid during long lasting imports. Shop-ID is set to "1" if the tmp file cache has been cleared. The reason can be found in oxerpbase:: loadSessionData() up from line 337:

if (oxNew('OXERPCompatibility')->isShopEE()) {
            $oUtils = $this->getUtils();
            $aSessionCache = $oUtils->fromFileCache( "erp_c_fieldnames_" . $sSessionID );

            $iLang = $aSessionCache['lang'];
            $myConfig->setShopId( $aSessionCache['actshop'] );

So if the file is not found, shopid will be empty here, which causes a switch to shopid "1" later on. A missing tmp file can be caused by some cache resetting operations during long lasting imports (several hours).

We discovered the problem when we had a huge import of data from ERP system to the shop and we noticed that quite a lot of subshop prices ended up in oxarticles table instead of oxfield2shop table.

Steps To ReproduceStart ERP import for subshops and during the run just empty the tmp folder. You will notice that from now on all the data go to shop "1" instead of the right subshops.
Additional InformationOne possible solution (of one our developers) can be found in the attached file.
TagsSolution Provided



2015-08-31 16:20


oxERPBase__loadSessionData.php (2,395 bytes)


2015-08-31 17:12

administrator   ~0011189

Problem can occur if:

1. You are using EE
2. You have subshops
3. You add something to subshop
4. You use ERP interface
5. clean tmp after ERP login and before something is added (Normally tmp folder is not cleared while shop is running)

Reduced severity because this combination is a rare case.


2015-08-31 18:14

reporter   ~0011195

Actually, I'm not sure if it's a "rare case" cause we did not find out yet WHY tmp files are deleted. As the import runs up from 4:00 am and the shop is not live yet, we can be pretty sure that nobody deleted tmp files willingly. There must be some shop operation which cause the deletion. So this actually may be another bug?


2015-09-01 09:12

administrator   ~0011196

There is a pattern which prevents the shop from deleting the files in tmp which are needed for ERP. See here:

That must be a function of a module or maybe a server cron job which deletes the tmp files.


2019-04-02 11:30

reporter   ~0012834

We're having the exact same issue.

We noticed, that sometimes the importer wrote to shop 1 instead of the given shop-id from the session and analyzed it further. We found out, that the import broke every time after we deployed a new release. We clear the cache during our deployment process and kind of reset the shop-id in the erp session by that.

I don't think, that this is a rare case, since most projects use automated deployments these days where you clear the cache with every deployment.


2019-12-17 08:40

administrator   ~0013071

The mentioned pull request is present in v3.1.0 and v2.14.2 so the issue is fixed