Opencart integration with accounting systems
Opencart is one of the most common online stores. In many cases, the task of integration with a warehouse accounting system (most often with 1C) arises.
Integration involves, at a minimum, transferring orders from the IM to the warehouse system for processing and sending goods to the buyer and updating the quantity of goods in the IM in accordance with the actual availability in the warehouse.
Also often the task is to synchronize the goods themselves, their parameters, photos and so on.
The difficulty is that, as a rule, changes need to be made both in the IM and in the warehouse system, which means that the developer must know both systems or need to involve another developer. There are ready-made solutions, but they usually require finishing or paid, and still require finishing.
To solve this problem, a module has been created for OpenCard which extends the OpenCart API allowing changes to be made only on the side of the accounting system.
The module is free open source, located on the github .
The module was developed for a specific accounting system, but is written so that it can be used by any other third-party programs.
The module is installed in the IM either in the standard way through the admin panel or by simply copying it to the catalog / controller / api folder. The module consists of one file. No changes to the settings or opencards structure are required.
Of course, in the admin panel you need to generate the KEY API, which will then be set in the warehouse system settings for logging into the API before accessing it.
Work verified with OpenCart 2.3 and 3.0
The module provides several API functions for working with orders and goods.
In accordance with the open-card agreements, parameters are passed by the POST method and a special token must be received before accessing the API. Data is exchanged in JSON format. All these are standard tools for working with the OpenCart API.
When new orders appear in the IM, they must be imported into the warehouse system, that is, based on them, appropriate documents (records, etc.) must be created in the warehouse system, processed and sent to the customer
Orders are imported by calling the orders () function.
To receive only the necessary orders, the status_id parameter with the status of orders is passed. Since the statuses in the open map are created by the admin panel and can be anything, you first need to get a list of statuses using the statuses () method, which returns a key-value array with identifiers and status names.
The accounting system presents these statuses for clarification in some sort of drop-down list. The manager selects from these statuses the one that corresponds to the new order.
With the order comes a list of goods and customer data for delivery.
To identify orders, the accounting system must write the order ID in some attribute of the internal order. These identifiers update statuses in the MI and also verify that the order has already been imported.
Status updates in the MI are performed by the updateorder () function
The manager selects the necessary orders (accounting system) in the desired state (for example, the order is being processed) and updates the statuses of the corresponding initial orders in the IM. The key-value array is transferred - the order ID of the IM and the status ID of the IM from the drop-down list proposed by the system.
For example, orders can be updated after being accepted for processing, shipped to the customer, delivered to the customer, and closed. This is at the discretion of the manager.
Of course, if the statuses in both systems are clearly defined and do not change, then API calls with fixed statuses can be hung on some scheduler and called automatically.
When working with goods, it is most often necessary to update the actual quantity of goods in the warehouse and the prices in the store.
In order to exchange data, goods in the IM must be synchronized with goods in the warehouse. Compliance is provided by the article, but if you wish, you can adjust the code and use another parameter, for example, the name (although this is not a good idea).
To add products to the store, use the addproducts () function.
Goods that are not yet there are transferred to the store. In order not to transfer duplicates, you can get from the store a list of articles there existing using the articles () method.
In order for goods to fall directly into the desired category, you must first obtain a list of categories using the cats () method and give the manager the opportunity to select the desired category from the list. After that, the goods are re-registered using standard tools in the OpenCart admin panel.
Goods are transferred in the form of a name, article, description (if any), price and quantity. In some cases, the task is to transfer attributes, all descriptions, photographs, and so on from the warehouse. But on this account there are doubts about the advisability of creating all this on the side of the accounting system.
Firstly, for the classic warehouse accounting, the name and article number, that is, the data that is used in invoices and orders, is enough.
Secondly, the IM admin panel already has regular means for forming product cards.
Thirdly, the transfer and coordination of such complex structures as a tree of categories, attributes, images and so on is a very troublesome business and, as follows from the above, is not necessary.
Such solutions make sense if the accounting system works with other resources, uploads data to marketplaces, for example. Although I am sure there are modules for the open card that upload characteristics and photos of goods to marketplaces from the open card.
If it turns out that the IM already has some goods at the time of implementation of the warehouse system, you can get a list of goods from the IM using the getproducts () method and add it to the goods catalog of the accounting system. Uniqueness is also checked by article.
Further, the main functions updatequantity () and updateprice () for updating the quantity and price in the MI in accordance with the warehouse data. The functions transmit the key-value array (article number or price) and do not require parameters, that is, they can be started by the scheduler.
As already mentioned, the advantage of the module is the absence of any changes in the OpenCart code. If necessary, the module is easily finalized - to transfer additional data you just need to add a new key to the corresponding associative array. The data will be packed and then unpacked in the same form on the receiving side.
In case the accounting system is written in PHP, there is a ready-made function for calling the opencards API (you can simply remove the line of the error message from the system).
Integration involves, at a minimum, transferring orders from the IM to the warehouse system for processing and sending goods to the buyer and updating the quantity of goods in the IM in accordance with the actual availability in the warehouse.
Also often the task is to synchronize the goods themselves, their parameters, photos and so on.
The difficulty is that, as a rule, changes need to be made both in the IM and in the warehouse system, which means that the developer must know both systems or need to involve another developer. There are ready-made solutions, but they usually require finishing or paid, and still require finishing.
To solve this problem, a module has been created for OpenCard which extends the OpenCart API allowing changes to be made only on the side of the accounting system.
The module is free open source, located on the github .
The module was developed for a specific accounting system, but is written so that it can be used by any other third-party programs.
The module is installed in the IM either in the standard way through the admin panel or by simply copying it to the catalog / controller / api folder. The module consists of one file. No changes to the settings or opencards structure are required.
Of course, in the admin panel you need to generate the KEY API, which will then be set in the warehouse system settings for logging into the API before accessing it.
Work verified with OpenCart 2.3 and 3.0
The module provides several API functions for working with orders and goods.
In accordance with the open-card agreements, parameters are passed by the POST method and a special token must be received before accessing the API. Data is exchanged in JSON format. All these are standard tools for working with the OpenCart API.
Work with orders
When new orders appear in the IM, they must be imported into the warehouse system, that is, based on them, appropriate documents (records, etc.) must be created in the warehouse system, processed and sent to the customer
Orders are imported by calling the orders () function.
To receive only the necessary orders, the status_id parameter with the status of orders is passed. Since the statuses in the open map are created by the admin panel and can be anything, you first need to get a list of statuses using the statuses () method, which returns a key-value array with identifiers and status names.
The accounting system presents these statuses for clarification in some sort of drop-down list. The manager selects from these statuses the one that corresponds to the new order.
With the order comes a list of goods and customer data for delivery.
To identify orders, the accounting system must write the order ID in some attribute of the internal order. These identifiers update statuses in the MI and also verify that the order has already been imported.
Status updates in the MI are performed by the updateorder () function
The manager selects the necessary orders (accounting system) in the desired state (for example, the order is being processed) and updates the statuses of the corresponding initial orders in the IM. The key-value array is transferred - the order ID of the IM and the status ID of the IM from the drop-down list proposed by the system.
For example, orders can be updated after being accepted for processing, shipped to the customer, delivered to the customer, and closed. This is at the discretion of the manager.
Of course, if the statuses in both systems are clearly defined and do not change, then API calls with fixed statuses can be hung on some scheduler and called automatically.
Work with goods
When working with goods, it is most often necessary to update the actual quantity of goods in the warehouse and the prices in the store.
In order to exchange data, goods in the IM must be synchronized with goods in the warehouse. Compliance is provided by the article, but if you wish, you can adjust the code and use another parameter, for example, the name (although this is not a good idea).
To add products to the store, use the addproducts () function.
Goods that are not yet there are transferred to the store. In order not to transfer duplicates, you can get from the store a list of articles there existing using the articles () method.
In order for goods to fall directly into the desired category, you must first obtain a list of categories using the cats () method and give the manager the opportunity to select the desired category from the list. After that, the goods are re-registered using standard tools in the OpenCart admin panel.
Goods are transferred in the form of a name, article, description (if any), price and quantity. In some cases, the task is to transfer attributes, all descriptions, photographs, and so on from the warehouse. But on this account there are doubts about the advisability of creating all this on the side of the accounting system.
Firstly, for the classic warehouse accounting, the name and article number, that is, the data that is used in invoices and orders, is enough.
Secondly, the IM admin panel already has regular means for forming product cards.
Thirdly, the transfer and coordination of such complex structures as a tree of categories, attributes, images and so on is a very troublesome business and, as follows from the above, is not necessary.
Such solutions make sense if the accounting system works with other resources, uploads data to marketplaces, for example. Although I am sure there are modules for the open card that upload characteristics and photos of goods to marketplaces from the open card.
If it turns out that the IM already has some goods at the time of implementation of the warehouse system, you can get a list of goods from the IM using the getproducts () method and add it to the goods catalog of the accounting system. Uniqueness is also checked by article.
Further, the main functions updatequantity () and updateprice () for updating the quantity and price in the MI in accordance with the warehouse data. The functions transmit the key-value array (article number or price) and do not require parameters, that is, they can be started by the scheduler.
As already mentioned, the advantage of the module is the absence of any changes in the OpenCart code. If necessary, the module is easily finalized - to transfer additional data you just need to add a new key to the corresponding associative array. The data will be packed and then unpacked in the same form on the receiving side.
In case the accounting system is written in PHP, there is a ready-made function for calling the opencards API (you can simply remove the line of the error message from the system).
All Articles