December 14, 2011 at 13:43How we developed the integration of an online store with 1C: Enterprise and why it became mass. Part 3
In the final part of the story about our implementation of the integration of the 1C: Bitrix online store with the 1C: Trade Management system, I would like to talk about solving the business problem of exchanging data on customer orders.
Let me remind you of the essence of the previous topics on this topic:
In the first post, we talked about how the tasks facing the owners of online stores were analyzed, the concept of data exchange was selected, and a protocol for the exchange between 1C and the online store was developed.
In the seconda concrete solution to the business problem of uploading a database of goods from 1C to the site was demonstrated, including choosing the nomenclature for uploading, data processing settings on the site side, and also some technical solutions to ensure the stability of uploading on large volumes of data.
Well, now in our online store we have a catalog of goods unloaded from 1C, and now the goods need to be sold to the client in terms of the order processing process itself.
After adding the product to the basket, the client went to the checkout form to fill in the details.
He indicated contact information, a payment method and chose a delivery option. The order is assigned a specific number, it is saved in the system, the client has access to his personal account to view the history of orders.
What to do now? Of course, "process the order." But where to process it - on the site or in 1C? After all, we have integration. It is necessary to choose a business model for processing orders, and there are generally three such models:
Using the capabilities of the administrative part of the CMS to manage orders. Objectively speaking, such features in the 1C-Bitrix system: Site management are very wide and sufficient for most stores:
- search for orders by filter
- view order data,
- edit an order (contact details, order details),
- unlimited number of order statuses and different user permissions to work with each of the statuses
- printing documents and much more.
Typically, such a model is chosen by those for whom the store is the only or almost the main source of sales. All at once in one system, customers immediately see the changes in their orders, receive notifications.
If there is 1C, thenwhen the order has already been processed, the money has been received, the order has been delivered - they want to unload the order in 1C, for reporting.
Some customers, even seeing an abundance of processing capabilities in the admin panel of the site, insist that all processing be carried out in the 1C system . In other words, customers want the order created on the site to immediately appear in 1C for further processing.
Usually these are companies for which the online store is just one of the sales channels, along with, for example, retail or dealership sales. In this case, such a model is caused solely by the need to ensure all processing in a single place, in a single center for processing orders.
In this case, all processing is carried out in a single system, which stores the inventory, stock balances, reserves and so on. It is certainly also very convenient.
For such a business model, the key requirement for integrating 1C with the online store is the speed and completeness of receiving data on an order from the site . Additional complexity here: in order for customers to track the process of order execution in their personal account, it is necessary that 1C informs the site about those changes in orders that occur in it during work.
Sometimes it is required to organize various combined schemes, when part of the operations are performed on the site, and part in 1C. It is possible to carry out partial processing of orders on the site (for example, receiving an order and clarifying it with the buyer), and when the order goes into the specified status, transfer it to 1C.
As you can see, the business task of integrating orders at first glance is simple, but it has a number of nuances. Now let's look at our integration implementation functionality.
According to the exchange protocol , 1C regularly sends requests to the site and receives the resulting response in CommerceML format. In the administrative part of the 1C-Bitrix system there is a set of settings that affect the process of generating this answer.
The first part of the integration settings for orders is in the general settings for integration with 1C, on the “Orders” tab (we considered the “Catalog” tab in the previous part, it concerned the import of goods).
Here are indicated:
Unloading only paid or only orders with authorized shipment - strictly limits the unloading of orders with the flags “paid” and “for shipment”, regardless of status. After all, statuses are a custom thing, and they may not be associated with these flags.
The site prepared a CommerceML file with data on the order, including counterparty data, a list of items and service information, and gave 1C in response to a request. Now you need to configure how this order will now be processed and stored in 1C.
The process of saving an order involves several steps:
Let me remind you that on the “Basic Settings” tab you can configure the interval of 1C access to the site. For example, orders can be collected every 5 minutes.
On the tab exchange orders are configured:
1) The method of identification of contractors.
This setting controls the counterparty search algorithm from the site among existing counterparties in 1C. Today, there are 2 methods of identification to choose from - by name (usually for individuals) and by the combination of TIN + KPP for legal entities. In the near future we plan to add another identification option - by the user ID of the site (the name for large stores can still be repeated).
If the counterparty could not be found, a new one is created.
2) Parameters for creating new elements of the “Nomenclature” directory.
This setting is needed for cases when the goods are in the order, but they are not in 1C. Or can’t find it. In this case, to ensure the logical integrity of the data in 1C, it is necessary that the product exists - and in this case 1C simply imports it into its nomenclature directory.
On the “Advanced” tab, the parameters for conducting documents in 1C are indicated, including cancellation of orders, and the important setting is “Correspondence of order statuses”:
Like on the site side, 1C can also set the status of the “Customer Order” document according to the order status on the site. For example, if an order on the site is confirmed, then in 1C it automatically receives the status of “Agreed”. It's comfortable.
The exchange of orders, unlike the exchange of goods in the integration scheme, is two-way . Not only does the site give 1C data on incoming orders, but 1C also informs the site about those orders that were previously uploaded and changed in 1C. Usually this is an example of a model for processing orders in 1C, when payment and shipping are not performed on the site.
The manager in 1C can phone the client and during communication change the list of positions, price, make a discount, change the delivery or payment parameters. If the site is not informed about these changes, then the client will have outdated information on his orders in his personal account.
The scheme of work of 1C is as follows. If the orders downloaded from the site have been changed, then in the next exchange session 1C will upload these changes to the site (also in CommerceML format), and the site will accept them and update the information on the orders.
Another case of changing an order in 1C is a change in its status. The accountant received the payment and formed a payment order, the order has now become paid and on the site we also need to change the status. There are 2 more parameters in the settings of the online store module on the site:
that is, the site will automatically change the status of the order when receiving data from 1C for payment and (or) shipment. And to change the status, you can "hang" the handler, send a message to the client (by email or sms).
Total: integration is the task of informing the buyer, despite the fact that order processing takes place outside the site.
All the integration settings from 1C from the site to 1C-Bitrix that we examined are just the default default settings, which refer to the default integration script http: // <your_site> /bitrix/admin/1c_exchange.php.
But from a technical point of view, the entire integration interface on the site side is two components of the 1C-Bitrix system that the developer can use to create his own arbitrary interface for interacting with 1C, refine and expand the existing functionality.
These are the components “bitrix: catalog.import.1c” and “bitrix: sale.export.1c”. They are available directly in the visual editor. You can create your own integration script with individual settings. Everything is done elementary:
1) You can create a page on the site directly in the visual editor (you can make a single URL for both goods and orders, as in the default interface, or you can have different ones)
2) Place the exchange components from 1C on the page to configure the necessary parameters
In principle, with using steps 1 and 2, you can configure an individual exchange interface for each 1C, which integrates with the site. For example, you have several online stores on the same engine, and each of them exchanges its own 1C. Or you have one online store, but several suppliers, each of which has one 1C. It is more logical and correct to make for each 1C its own interface for importing goods.
But that is not all.
The components "catalog.import.1c" and "sale.export.1c" are the usual components 2.0 of the 1C-Bitrix platform. You can customize them with standard techniques, or even bring them into your namespace and arbitrarily change their source code.
For example, you can do additional data processing before writing to the site database, associate data with other site entities, and so on.
In a word, we give the opportunity not only to create our own interface settings, which are different from the default ones, but also to change our interface in general.
Using this opportunity, you can implement an exchange with other 1C products (naturally, if there is an integration mechanism on the other side), or with products of other vendors.
To summarize three posts on this topic.
Yes, not everything was managed to be made as convenient as possible, but work to improve integration has been ongoing continuously for several years and will continue.
We have very strong feedback from customers and partners. The support service has technical specialists for 1C products, which together with 1C-Bitrix developers can solve complex issues that are often at the junction of systems. All wishes are recorded and reasonable offers are necessarily implemented.
Together with 1C, we did not create some kind of closed architecture for integration and data exchange, but rather, we tried to make it convenient for use, open for improvements and modifications, and the prevalence of such integration among modern CMS for online stores confirms that this goal was achieved!
And to read the following entries in your stream, click "Like" in the company profile , and check your feed settings .
Let me remind you of the essence of the previous topics on this topic:
In the first post, we talked about how the tasks facing the owners of online stores were analyzed, the concept of data exchange was selected, and a protocol for the exchange between 1C and the online store was developed.
In the seconda concrete solution to the business problem of uploading a database of goods from 1C to the site was demonstrated, including choosing the nomenclature for uploading, data processing settings on the site side, and also some technical solutions to ensure the stability of uploading on large volumes of data.
Well, now in our online store we have a catalog of goods unloaded from 1C, and now the goods need to be sold to the client in terms of the order processing process itself.
After adding the product to the basket, the client went to the checkout form to fill in the details.
He indicated contact information, a payment method and chose a delivery option. The order is assigned a specific number, it is saved in the system, the client has access to his personal account to view the history of orders.
What to do now? Of course, "process the order." But where to process it - on the site or in 1C? After all, we have integration. It is necessary to choose a business model for processing orders, and there are generally three such models:
Processing orders directly on the site
Using the capabilities of the administrative part of the CMS to manage orders. Objectively speaking, such features in the 1C-Bitrix system: Site management are very wide and sufficient for most stores:
- search for orders by filter
- view order data,
- edit an order (contact details, order details),
- unlimited number of order statuses and different user permissions to work with each of the statuses
- printing documents and much more.
Typically, such a model is chosen by those for whom the store is the only or almost the main source of sales. All at once in one system, customers immediately see the changes in their orders, receive notifications.
If there is 1C, thenwhen the order has already been processed, the money has been received, the order has been delivered - they want to unload the order in 1C, for reporting.
Processing orders in 1C
Some customers, even seeing an abundance of processing capabilities in the admin panel of the site, insist that all processing be carried out in the 1C system . In other words, customers want the order created on the site to immediately appear in 1C for further processing.
Usually these are companies for which the online store is just one of the sales channels, along with, for example, retail or dealership sales. In this case, such a model is caused solely by the need to ensure all processing in a single place, in a single center for processing orders.
In this case, all processing is carried out in a single system, which stores the inventory, stock balances, reserves and so on. It is certainly also very convenient.
For such a business model, the key requirement for integrating 1C with the online store is the speed and completeness of receiving data on an order from the site . Additional complexity here: in order for customers to track the process of order execution in their personal account, it is necessary that 1C informs the site about those changes in orders that occur in it during work.
Mixed model
Sometimes it is required to organize various combined schemes, when part of the operations are performed on the site, and part in 1C. It is possible to carry out partial processing of orders on the site (for example, receiving an order and clarifying it with the buyer), and when the order goes into the specified status, transfer it to 1C.
Implementation of business models in the integration of 1C and 1C-Bitrix
As you can see, the business task of integrating orders at first glance is simple, but it has a number of nuances. Now let's look at our integration implementation functionality.
Site Side Settings
According to the exchange protocol , 1C regularly sends requests to the site and receives the resulting response in CommerceML format. In the administrative part of the 1C-Bitrix system there is a set of settings that affect the process of generating this answer.
The first part of the integration settings for orders is in the general settings for integration with 1C, on the “Orders” tab (we considered the “Catalog” tab in the previous part, it concerned the import of goods).
Here are indicated:
- The site from which orders are uploaded to 1C. There can be several stores on one engine and it is necessary to clarify from which it is to give orders on request 1C
- Groups of users who are allowed to download - user rights under which 1C will pick up orders
- Use zip compression - as in the transfer of goods, it allows to reduce the volume of transmitted traffic, although for the list of orders this gives not so much unloading
- Unload paid orders only
- Only ship orders with authorized shipping
- Unload orders starting from status
Unloading only paid or only orders with authorized shipment - strictly limits the unloading of orders with the flags “paid” and “for shipment”, regardless of status. After all, statuses are a custom thing, and they may not be associated with these flags.
Settings on the 1C side
The site prepared a CommerceML file with data on the order, including counterparty data, a list of items and service information, and gave 1C in response to a request. Now you need to configure how this order will now be processed and stored in 1C.
The process of saving an order involves several steps:
- Counterparty identification (search among existing ones or creating a new one)
- Identification of ordered items (search in the stock list directory or creating new ones)
- Creation and implementation of the document “Sales Order”
- Identification of order status and setting the status of the document “Sales Order”
Let me remind you that on the “Basic Settings” tab you can configure the interval of 1C access to the site. For example, orders can be collected every 5 minutes.
On the tab exchange orders are configured:
1) The method of identification of contractors.
This setting controls the counterparty search algorithm from the site among existing counterparties in 1C. Today, there are 2 methods of identification to choose from - by name (usually for individuals) and by the combination of TIN + KPP for legal entities. In the near future we plan to add another identification option - by the user ID of the site (the name for large stores can still be repeated).
If the counterparty could not be found, a new one is created.
2) Parameters for creating new elements of the “Nomenclature” directory.
This setting is needed for cases when the goods are in the order, but they are not in 1C. Or can’t find it. In this case, to ensure the logical integrity of the data in 1C, it is necessary that the product exists - and in this case 1C simply imports it into its nomenclature directory.
On the “Advanced” tab, the parameters for conducting documents in 1C are indicated, including cancellation of orders, and the important setting is “Correspondence of order statuses”:
Like on the site side, 1C can also set the status of the “Customer Order” document according to the order status on the site. For example, if an order on the site is confirmed, then in 1C it automatically receives the status of “Agreed”. It's comfortable.
Export of orders from 1C to the site
The exchange of orders, unlike the exchange of goods in the integration scheme, is two-way . Not only does the site give 1C data on incoming orders, but 1C also informs the site about those orders that were previously uploaded and changed in 1C. Usually this is an example of a model for processing orders in 1C, when payment and shipping are not performed on the site.
The manager in 1C can phone the client and during communication change the list of positions, price, make a discount, change the delivery or payment parameters. If the site is not informed about these changes, then the client will have outdated information on his orders in his personal account.
The scheme of work of 1C is as follows. If the orders downloaded from the site have been changed, then in the next exchange session 1C will upload these changes to the site (also in CommerceML format), and the site will accept them and update the information on the orders.
Another case of changing an order in 1C is a change in its status. The accountant received the payment and formed a payment order, the order has now become paid and on the site we also need to change the status. There are 2 more parameters in the settings of the online store module on the site:
that is, the site will automatically change the status of the order when receiving data from 1C for payment and (or) shipment. And to change the status, you can "hang" the handler, send a message to the client (by email or sms).
Total: integration is the task of informing the buyer, despite the fact that order processing takes place outside the site.
Additional integration options
All the integration settings from 1C from the site to 1C-Bitrix that we examined are just the default default settings, which refer to the default integration script http: // <your_site> /bitrix/admin/1c_exchange.php.
But from a technical point of view, the entire integration interface on the site side is two components of the 1C-Bitrix system that the developer can use to create his own arbitrary interface for interacting with 1C, refine and expand the existing functionality.
These are the components “bitrix: catalog.import.1c” and “bitrix: sale.export.1c”. They are available directly in the visual editor. You can create your own integration script with individual settings. Everything is done elementary:
1) You can create a page on the site directly in the visual editor (you can make a single URL for both goods and orders, as in the default interface, or you can have different ones)
2) Place the exchange components from 1C on the page to configure the necessary parameters
In principle, with using steps 1 and 2, you can configure an individual exchange interface for each 1C, which integrates with the site. For example, you have several online stores on the same engine, and each of them exchanges its own 1C. Or you have one online store, but several suppliers, each of which has one 1C. It is more logical and correct to make for each 1C its own interface for importing goods.
But that is not all.
The components "catalog.import.1c" and "sale.export.1c" are the usual components 2.0 of the 1C-Bitrix platform. You can customize them with standard techniques, or even bring them into your namespace and arbitrarily change their source code.
For example, you can do additional data processing before writing to the site database, associate data with other site entities, and so on.
In a word, we give the opportunity not only to create our own interface settings, which are different from the default ones, but also to change our interface in general.
Using this opportunity, you can implement an exchange with other 1C products (naturally, if there is an integration mechanism on the other side), or with products of other vendors.
General conclusions on integration:
To summarize three posts on this topic.
- A ready-made integration mechanism between 1C and the online store has been implemented, which allows you to solve a large number of typical customer tasks out of the box for unloading the catalog and exchanging orders
- There is a possibility of flexible integration settings both from 1C-Bitrik: Site management and from 1C: Trade management, in order to adjust to the specifics of the client’s business
- There are opportunities for customization and refinement of the integration functional
- Data exchange is performed using the open XML standard CommerceML
- The data exchange protocol is maximally simplified, uses HTTP (S) and takes into account the typical hosters restrictions on the operation of site scripts
- The integration architecture protects 1C: Enterprise as much as possible from threats from the Internet, 1C always acts as the initiator of the exchange, and the site only answers requests
Yes, not everything was managed to be made as convenient as possible, but work to improve integration has been ongoing continuously for several years and will continue.
We have very strong feedback from customers and partners. The support service has technical specialists for 1C products, which together with 1C-Bitrix developers can solve complex issues that are often at the junction of systems. All wishes are recorded and reasonable offers are necessarily implemented.
Together with 1C, we did not create some kind of closed architecture for integration and data exchange, but rather, we tried to make it convenient for use, open for improvements and modifications, and the prevalence of such integration among modern CMS for online stores confirms that this goal was achieved!
And to read the following entries in your stream, click "Like" in the company profile , and check your feed settings .