Back to Home

Export of two or more directories from Bitrix to 1C on request

1s · 1s-bitrix

Export of two or more directories from Bitrix to 1C on request

Many faced the task of exporting a catalog from Bitrix to 1C.

But not everyone managed to find a suitable option. The built-in Bitrix tools do not give freedom of action in this regard. Consider what options Bitrix offers:

1) at the address Store - Settings - Export Directory

But in the settings you can specify only one directory for export, and if you need to upload more it is no longer suitable.

2) Shop - data export - looked, saw that there is already where to take a walk.

You can configure export to YML and CSV. And even in crowns to place on schedule. And even make unloading on request from 1C, though using castles. This functionality is already worthy of consideration, but due to the rake and the fact that I wanted a "clean" XML is also swept away.

And then the question arose - what to do? Take YML? Or CSV? Or maybe there are other options?

It was decided to sort through the standard exchange between 1C and Bitrix.

The request goes to the file /bitrix/admin/1c_exchange.php - this is a link to the file /bitrix/modules/sale/admin/1c_exchange.php - this file performs the import and export operations in Bitrix.

The following request types and their settings were unearthed: sale, crm, catalog, reference, get_catalog, listen.

The purpose was clear from the name. In this list we are interested in get_catalog - it is he who creates the export file, here is what the piece of code that interests us looks like:

elseif($type=="get_catalog") 
{ 
   $APPLICATION->IncludeComponent("bitrix:catalog.export.1c", "", Array( 
       "IBLOCK_ID" => COption::GetOptionString("catalog", "1CE_IBLOCK_ID", ""), 
       "INTERVAL" => COption::GetOptionString("catalog", "1CE_INTERVAL", "-"), 
       "ELEMENTS_PER_STEP" => COption::GetOptionString("catalog", "1CE_ELEMENTS_PER_STEP", 100), 
       "GROUP_PERMISSIONS" => explode(",", COption::GetOptionString("catalog", "1CE_GROUP_PERMISSIONS", "1")), 
       "USE_ZIP" => COption::GetOptionString("catalog", "1CE_USE_ZIP", "Y"), 
       ) 
   ); 
} 


We can observe that export settings are taken from option 1 already considered by us above, which are stored in the database.

We will continue to work with these data. They decided to leave the standard functionality and created a duplicate, renaming the request type to get_catalog1 with the information block identifier:

elseif($type=="get_catalog1") 
{ 
   $APPLICATION->IncludeComponent("bitrix:catalog.export.1c", "", Array( 
       "IBLOCK_ID" => "6", 
       "INTERVAL" => COption::GetOptionString("catalog", "1CE_INTERVAL", "-"), 
       "ELEMENTS_PER_STEP" => COption::GetOptionString("catalog", "1CE_ELEMENTS_PER_STEP", 100), 
       "GROUP_PERMISSIONS" => explode(",", COption::GetOptionString("catalog", "1CE_GROUP_PERMISSIONS", "1")), 
       "USE_ZIP" => COption::GetOptionString("catalog", "1CE_USE_ZIP", "Y"), 
       ) 
   ); 
} 

Tested, everything works. But I did not want to create such duplicates for each information block. We needed the flexibility and scalability of the solution.

The solution was found quite simple: pass the identifier number from 1C in the query line. And intercept the value of the variable via GET.

The result is the following:

elseif($type=="get_catalog1") 
{ 
   $APPLICATION->IncludeComponent("bitrix:catalog.export.1c", "", Array( 
       "IBLOCK_ID" => $_GET['blockid'], 
       "INTERVAL" => COption::GetOptionString("catalog", "1CE_INTERVAL", "-"), 
       "ELEMENTS_PER_STEP" => COption::GetOptionString("catalog", "1CE_ELEMENTS_PER_STEP", 100), 
       "GROUP_PERMISSIONS" => explode(",", COption::GetOptionString("catalog", "1CE_GROUP_PERMISSIONS", "1")), 
       "USE_ZIP" => COption::GetOptionString("catalog", "1CE_USE_ZIP", "Y"), 
       ) 
   ); 
} 

The query line from 1C contains the following segment ... & iblockid = 6 & ..., respectively $ _GET ['blockid'] is equal to the 6th information block. To import another infoblock, it is enough to register the ID of the necessary infoblock in the request.

PS: This solution may not correspond to the “True Path” of Bitrix, or it may correspond - I do not know.

But I know for sure - just such an option satisfies all the needs of this project and solves all the problems associated with the integration of 1C and Bitrix.

I worked in tandem with the 1C programmer, as a result of which I can’t tell in detail about the difficulty of the work done on importing and processing the received data from 1C.

Read Next