In real life, it’s a rare company that gets by with just one 1C database. The most common situation is two bases, accounting and payroll.

The bases must be connected - salaries have been accrued, accrued taxes must go to the accounting department for payment.

To connect several databases, there is Exchange 1C. How does he work?

What is Exchange 1C?

There is a chain of stores and a central office. Every store and office has a warehouse. Goods are moved from warehouse to warehouse (mainly from the central warehouse to store warehouses), and are sold in stores.

The 1C Retail database is used in the office and the same database in each store. Bases in stores are subordinate to the base in the office.

In the office, documents are created on the movement of goods from warehouse to warehouse, and prices are set. Documents are uploaded to subordinate databases and goods “appear” there.

Stores create documents about completed sales of goods. Documents are uploaded to the office database and sales “appear” there.

This scheme is called distributed information base(RIB). Procedures for “uploading” documents – two-way 1C exchange. And setting up this scheme is URIB or URIBD (distributed information database management).

Principles of exchanging directories in 1C

1C directories (and the set of all directories “in the complex” is called NSI - normative reference Information) – should usually be the same in different databases. This means that even if there are several databases, the list of goods, warehouses, and contractors is the same in different databases.

A common practice is when a directory is allowed to be edited in one database, and it is copied (“migrated”) to the others. As we have discussed before, each 1C element has a unique identifier - GUID. Directories are usually copied together with their GUID, and are thus identical throughout the distributed information system.

Otherwise, when several initially existing databases are connected, or when directories can be created in different databases at the same time, their GUIDs will be different. There is a matching mechanism for this. In a special information register during 1C exchange, information is recorded that the element from database No. 1 with GUID xxx is equal to the element in this database with GUID yyy. Initially, existing elements that are no longer equal must be compared automatically (using other details, for example, by name or by tax identification number and checkpoint) or manually.

Principles of Document Exchange in 1C

Documents in 1C are posted according to registers and are then considered “posted”. This gives rise to understandable difficulties during transfer.

One option is to transfer only the documents and transfer them again after downloading. This method is often used, but it can give rise to errors - the document may not be posted in the new database, since the conditions during the process may be different than they were at the time the document was posted in the original database.

Another option is to transfer documents and registers together. As we understand, the question immediately arises - either we transfer all documents in general and then the entire register in general, or we are forced to choose for transfer only movements on the transferred documents.

Let's say we need to transfer an item from the Nomenclature directory. This directory has 10 fields, of which 5 are strings and numbers, and 5 are links to other directories.

Accordingly, when transferring one element of the Nomenclature, we are forced to search for and transfer also 5 elements of other directories.

Thus, when transferring one directory element or one document, 100 or more other 1C objects can be transferred via link.

In fact, it is said that almost all configuration references refer to each other in one way or another.

1C exchange plans

Let's assume that we have created a distributed database and carried out a 1C exchange. Goods have been purchased to the central warehouse and prepared for shipment to stores. In 1C, the office entered the necessary documents for the movement of goods. Requires them to be loaded into stores.

What to do? Carry out a full 1C exchange again? Long and ineffective! It would be much better to calculate what exactly was added or changed by users in the office, so that only changes would be sent to stores.

There are 1C exchange plans for this. The programmer creates a 1C exchange plan in advance for carrying out 1C exchanges with some other database, for example with our stores.

The 1C exchange plan notes when users work with directories and documents what has been added or changed since the last 1C exchange with this database.

Creation of URIB 1C

So, we will create a distributed database from scratch. Initially, we have a “parent” office base. From it we will select databases of stores that will be subordinate to it.

Typical configurations already have standard 1C exchange plans. The types of bases for which they are intended are intuitively clear from the name:

• Exchange 1C with a website: exchange with a 1C:Bitrix website
• Exchange 1C UPP-UT or UT-Retail: typical exchanges with sister configurations
• Full – 1C exchange with a database based on the same configuration.

RIB - distributed information base - can also be made on the basis of the 1C “Full” exchange plan. In the configurator, in this 1C exchange plan, the “Distributed infobase” checkbox should be checked.

The 1C exchange plan created in the configurator indicates that we are going to exchange with this configuration. In Enterprise mode, in the same 1C exchange plan, you now need to specify specific databases based on this configuration.

Let's go to the 1C exchange plan (Operations/Exchange Plan; can also be in another menu, often in the Service/XXX menu).

In the list of databases in the 1C exchange plan there is one with a green circle in the picture. This element stands for THIS BASE. The remaining elements indicate OTHER bases with which 1C is being exchanged.

It is necessary that both the name and code of all elements be filled in.

To create a store subbase:

• Place the cursor in the list on the 1C exchange plan element, which we created as a “store base”
• Select the menu item “Actions/Create initial image”.

As a result, one database will be created with the initial data uploaded into it. This must be repeated for each element of the 1C exchange plan, except for the CURRENT BASE.

Theory of 1C exchanges

The theory of 1C exchange is quite simple:

• One of the databases (usually the center’s database) initiates 1C exchange according to a schedule or “by event” (login to the database of a specific user, etc.)
• 1C exchange consists of downloading a file from the database
• The file must be moved to a place where a slave database can pick it up (usually a share or ftp, less often e-mail)
• The slave database downloads the received file
• As confirmation that the information has been received, the slave database uploads a “response” file, which is loaded back into the central database in the same way
• The 1C exchange session is completed.

There are other methods of exchanging 1C, not through files, but, for example, through a direct COM connection between two databases. Its advantages:

• No "space to store and transfer files" required
• No need to re-upload confirmation
• Everything happens faster due to the first two points.

However, the limitation is clear - the bases must be so accessible to each other in order to be able to initiate a COM connection.

Setting up RIB 1C

In the constants of standard configurations (Operations/Constants; or Service/Program Settings) there is usually general setup 1C exchanges. This is a prefix in element codes and document numbers to easily determine in which database it was created. And internal method saving information about the place where directories and documents were created.

Now you need to configure how the process of periodic exchange of 1C information between the created databases will take place.
All RIB settings in 1C are in standard configurations, usually in the menu Service/Distributed information bases/Configure RIB nodes.

For each previously created “remote store base” element, you need to add a settings element.

The settings indicate the 1C exchange method: file (share), file (FTP), file (e-mail).

Creating and setting up a distributed 1C information base in a thin client

Let's look at a similar setup in a standard configuration based on a thin client - Trade Management edition 11.
Settings (and creation from scratch) are located on the Administration tab of the interface. Item “Data exchange”.

Select “Create an exchange in a distributed infobase”.

From the very beginning, 1C will ask us to indicate how we are going to exchange information with the subordinate database. Here is the configuration option “via a file on the ball”.

Here is the configuration option via an FTP file.

The name of our 1C exchange setup.

And immediately a proposal to create an “initial image” - that is, the slave database itself with uploading primary information into it.

Unlike the configuration on a thick client, both 1C exchange settings are in one place.

Error 500 after installing the module means that something happened critical error in php.

To identify the problem you can:
1. Open the logs/error.log file on your server. At the end of this file there will be all the latest critical errors.
2. Open Tools > Error Logs in the admin panel - errors are displayed here, but not always.
3. Enable output php errors to the screen - add the following code to the end of the .htaccess file:

Php_value display_errors 1
php_value display_startup_errors 1
php_value error_reporting E_ALL

Possible reasons:

1. If you have not downloaded modules in the archive through the admin panel before -you need to install free modification according to the instructions and then reinstall the module

2. Perhaps the installed module is missing own page settings and accordingly it will not be in the list of Modules

Two solutions:

1. If this error occurs when installing the module from the admin panel, you need to install the free one. It will install without problems through the same add-on installer, just after installation, do not forget to update the modifications and then you can start installing any modules on Opencart 2.

2. You can also solve this error in another way: register access to FTP in the admin System > Settings > Store > FTP tab.

If you see the message " Access is denied! You do not have permission to access this page. If you need it, contact your administrator." - you need to give administrators rights to manage the module or page.

Solution: in the Opencart 2 admin panel go to System > Users > User Groups > Administrators and here we click “Select all” below both blocks, then Save.

Another reason for this error to appear may be correct installation module - the files were not loaded into place. Upload the module files manually to the server or install the fix and reinstall the module.

If the module is one XML file, then its extension should be .ocmod.xml

If the module is an ocmod.zip archive, then you do not need to unpack it, but install it as is. Such an archive must have an upload folder (can be empty), and there may also be modification files: install.xml, install.php, install.sql. There should not be any other files in the root of the archive.

This error means that you are trying to install a modifier that is already installed or perhaps one of your modules has the same ID.

To solve this error, you need to remove before installing old version modifications in the Modules > Modifications section.

If you don’t have such a module, but the ID is the same, then you need to change the value of the parameter in the installed XML modifier, make this parameter unique by adding several characters.

This error means that you are trying to install too volumetric xml modifier.

The number of characters in the ocmod.xml file should not exceed 65535 .

To solve the error, you need to split the modification xml file into several parts, the main thing is not to forget to set each unique value in , you can add the numbers 1,2,3... to the current value as part identifiers.

Another solution is to change the type in the fields where modifications are stored in the “oc_modification” table of the database. You need to run the following SQL query:
ALTER TABLE oc_modification CHANGE xml xml MEDIUMTEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ;

In the application 1C: Accounting 8(version 3.0) provides for simplified data exchange with online stores. This article explains how to use this exchange.

Terms of data exchange

1C:Accounting 8 supports data exchange with online stores created on the basis of CMS systems:

• 1C-Bitrix;
• 1C-UMI;
• other CMS systems that support the exchange protocol CommerceML version 2.08 (see link).

When exchanging data with online stores created on the basis of CMS systems other than 1C-Bitrix And 1C-UMI, you need to ensure that the online store website contains a script that supports the 1C exchange protocol with the website. A description of the requirements for the script is given at the link.

Setting up data exchange

To set up data exchange between 1C:Accounting 8 and an online store, you must:

Performing data exchange

To exchange data with an online store you must:

As a result of the download, customer invoices will be generated in 1C: Accounting 8. These accounts can be used to process sales, receive funds, or prepare a package of documents for shipment.

1. Guidelines on the reflection in accounting of sales through an online store are given in the “Directory business transactions. 1C: Accounting 8", see link.

2. Exchange with an online store is configured and functions identically both for the local information base “1C: Accounting 8” and when working with “1C: Accounting 8” hosted in the service website or in another service created using 1cFresh technology.

Exchange restrictions

Data exchange "1C: Accounting 8" with online stores is:

• one-way - information is transferred only from the online store to “1C: Accounting 8”;
• simplified - only data on orders received through the online store are transferred, as well as data on product range, contractors and prices used in orders. Based on this information, invoices are created for customers in 1C:Accounting 8. It is not possible to perform any other operations with the online store.

Much more possibilities for integration with an online store are provided by the solutions “1C: Trade Management”, “1C: Integrated Automation”, “1C: ERP 2” and “1C: Managing Our Company”. See articles for example.

Home Implemented solutions

Data exchange with the online store

Doing business via the Internet – key condition success of a modern trading company. An increasing number of trading companies are creating their own online stores and web showcases, posting their trade offers on the web site and organizing the acceptance of orders from customers.

As a rule, online trading is not the only sales channel for such companies. To increase the efficiency of the company, it is advisable to integrate all sales channels into a single corporate trade management system, which can be built on the 1C:Enterprise platform.

Specialized systems are designed for creating and directly managing an online store, for example "1C-Bitrix: Site Management". A specialized system ensures interaction between the online store and customers via the Internet. And the 1C:Enterprise system regularly exchanges commercial data with an online store via the Internet or a shared local network and manages the execution of received orders.

Thus, when integrating with an online store, the 1C:Enterprise system plays the role of a back office.

To organize data exchange between the 1C:Enterprise system and an online store, 1C and 1C-Bitrix have developed and published a standard that uses the XML-based commercial information exchange standard CommerceML 2.

Implementation of exchange in the 1C:Enterprise system

Organization of data exchange on the side of website management systems

Information on the use of a website management system for organizing an online store integrated with the 1C:Enterprise system is published on company websites.

Send this article to my email

The main reasons for the need to implement exchange between 1C databases are the presence of branches and the separation of accounting types, because Often companies operate in several information databases. Setting up 1C 8.3 exchange allows you to eliminate double work - entering the same documents and directories in two programs, as well as quickly deliver the necessary system objects for various branches and departments.

In the case when it is necessary to exchange between branches, the RIB (Distributed Information Base) is used. This is an exchange mechanism between identical configurations. It represents a tree with the most important root node on top, below a pair of interconnected nodes. Changes can be made in any node of this system, and they will be transmitted to other connected nodes. It also distributes not only data, but also configuration changes from the root node to the slave nodes.

If it is necessary to separate types of accounting, for example, maintaining operational ones in the trading database, and regulated ones in the accounting database, universal exchange mechanisms are available with flexible settings data synchronization.

One of the latest developments 1C is the EnterpriseData data exchange format. It is easy to use and is intended for exchange within the company both between 1C databases and third-party programs.

The implementation of data exchange in an enterprise can be represented in the form of sequential procedures.

First of all, it is necessary to determine between which databases there should be an exchange; will it be a two-way or one-way exchange; if one-way, then which database will transmit information and which will only receive; if this is a complex branch network, then it is necessary to register a database construction scheme.

Then select the appropriate format: RIB, universal format; exchange according to exchange rules; exchange without exchange rules.

The next step is to select a vehicle to carry out the exchange. Available big choice technologies, we will highlight the main ones: directory (local or network), FTP resource, COM connections, web service, email.

The fourth step will be to identify the data: documents, reference books and, if necessary, detail them down to their individual details to be transferred.

And in conclusion, a schedule of exchange frequency is prescribed

Each option for setting up 1C 8.3 exchange requires careful preparation. Its implementation is beyond the capabilities of every user; it is necessary to take into account many nuances and understand the principles of the exchange. Particular attention will need to be paid to configuration if the databases: contain modifications or many additional ones. details, differ in platform versions or are used outdated versions configurations, the enterprise is large and uses automated system, consisting of a large number of bases. Errors are unacceptable here, because... may lead to irreparable consequences. Independent implementation of exchange in 1C is recommended only if you need to set up a simple transfer of information between standard configurations.

If you doubt your abilities, it is better not to save, but to contact a competent specialist who will help solve the complex problem of setting up 1C 8.3 exchanges.

If you still decide to configure 1C exchanges without involving experts, it is recommended to first test on copies of the databases, and before starting work in the working databases, upload the configurations to be able to return to the original state in case of errors.

Below we give a detailed example of setting up 1C 8.3 exchange unilaterally between standard configurations Trade Management 11 (UT) and Enterprise Accounting 3.0 (BP). The example is relevant for many companies engaged in wholesale and retail trade. In the UT, management accounting is maintained, in the BP - regulated, the exchange is necessary to facilitate the work of users.

This algorithm is also suitable for other standard configurations on the 1C 8.3 platform

First of all, we will carry out preparatory work for the information receiver, i.e. for BP. We launch the program in Enterprise mode. You need to set the Data synchronization constant (section Administration → Data synchronization).

Pay attention to the Prefix field; here you need to specify a value that will allow you to subsequently distinguish (by the value of the directory code or document number) in which program the objects were originally created. In our example, the usual abbreviation BP and UT is suitable, if the 1C 8.3 exchange setup is performed for a complex exchange between a large number of databases, as well as identical configurations, you will need to enter each database with its own clear designation.

Since the power supply unit is only a receiver of information, we proceed to setting up the UT.

Here, just like in the BP, you need to enable synchronization and specify a prefix. This information is available in the Master data and administration section → Data synchronization settings.

Select the setup method: Specify settings manually. Further.

Let's set up a direct connection option, when both programs are located in one local network, we will indicate the parameters for connecting to the information security directory on this network, and also fill in the authentication information about the user (in the BP database). Further.

The system will check the correctness of the specified data and if positive result will display the 1C 8.3 exchange settings window.

Click the Change data upload rules link to access settings for the exchange. We will clarify the master data - upload only those used in documents, select organizations and the option of working with contracts - without reference, separation of documents by warehouse. The exchange begins on March 1 of the current year.

We write down the introduced rules and close them.

Since the example is about one-way transmission of information, in the next settings window to receive data from another program, you should set the values ​​to Do not send. Record and close. Further.

Now you need to check the entered parameters and if they are correct, click Next, otherwise return to the previous step by clicking Back.

You will then be prompted to synchronize. Click Finish.

If it is necessary to correlate identical objects of two configurations, a window for comparing data will open. We perform the comparison and click Next.

When transferring objects, problematic situations may arise; you can view the results by clicking the Warnings during data synchronization link.

After synchronization is completed, a window will be displayed confirming the successful completion of this process.

Here, using the Configure command or after, in the synchronization script, you can configure the schedule automatic execution exchange.