Search for a command to run...
In this guide, you'll learn how to install the 1C:Enterprise plugin, register it in Medusa and set up the exchange in 1C.
The plugin is published to Gorgo's private package registry. To install it, apply for the beta. Once your application is approved, you get a license key that gives you access to the registry.
packages are published to the registry, not the public npm registry. Point your package manager at this registry for packages and pass it your license key. Yarn 2 and later reads its settings from , npm and pnpm from :
1npmScopes:2 gorgo-store:3 npmRegistryServer: "https://registry.gorgojs.com"4 npmAuthToken: "${GORGO_LICENSE}"For Yarn and npm, the license key comes from the environment variable, so the key itself stays out of your project's repository. Set this variable on your machine and in CI, wherever dependencies get installed.
Since version 11.5.3, pnpm doesn't expand environment variables in registry URLs and credentials from the project . That's why the pnpm holds only the registry URL, and you save the key in your user-level pnpm settings instead. Run this command on your machine and in CI before installing dependencies:
The command writes the key to your user's pnpm settings rather than to the project, so it stays out of the repository as well.
Install the plugin together with the Integration Module:
yarn add @gorgo/medusa-integration @gorgo-store/medusa-erp-1cRegister the plugin and its integration provider in the file of your Medusa application:
medusa-config.ts
The configuration registers two things:
The plugin has no options in . You set the sales channel, the region, the price types and everything else in the Medusa Admin, as described in Manage 1C:Enterprise Settings in the Medusa Admin. The plugin has no secret fields either, so you don't need to set an on the Integration Module for it.
The Integration Module keeps settings in its own tables. Run the following command to apply the database migrations:
yarn medusa db:migrate1C starts the exchange itself, so you set it up on the 1C side. In the site exchange settings of your 1C configuration, set:
The plugin checks the login and password the same way the Medusa Admin does on sign-in. Create a separate user for the exchange. That way 1C doesn't store an employee's password, and you can delete that user or change its password without affecting anyone else.
You don't need to configure compression or file chunk size. The plugin tells 1C itself that it accepts zip archives and file chunks of up to 1 MB. From the received files, it imports the catalog () first, then the offers () and the orders ().
The plugin keeps the exchange session in the memory of the Medusa process. If the server restarts in the middle of an exchange, the exchange is interrupted and you have to run it again. If your backend runs as several instances, route every request to to the same one. Otherwise a request that lands on another instance gets an authorization failure, even though the login and password are correct.
The exchange publishes every product it receives, including one you unpublished by hand. If part of the items in your 1C database is hidden from the site, for example with a "Удалить с сайта" property, register the handler from the Draft for Products Hidden on the Site example before the first exchange. Otherwise the very first export puts those products on the storefront.
The plugin recognizes a Medusa record by its from 1C, not by its name or article:
So renaming a product or changing its article in 1C doesn't create duplicates in Medusa.
The plugin writes the offer's article to the variant's SKU as long as no other variant holds that SKU. In 1C an article doesn't have to be unique, while a SKU in Medusa does, so the plugin saves a variant whose article is taken without a SKU and logs it. The variant always keeps the article itself in , and that's what the plugin sends as in the catalog and order exports to 1C. To fill the SKU your own way, use the hook, as in the SKU for a Taken Article example.
The plugin builds a new product's handle from its name, transliterated, and part of its . For an that's a GUID, that's the first group, and any other goes in whole. For example, a product named "Фильтр масляный" with the gets the handle , so products with the same name don't get the same handle. The plugin doesn't change an existing product's handle unless Update the handle when a product is renamed in 1C is on, see Edit the Exchange Rules.
Exchange entries in the Medusa log start with . After every catalog and offers batch, the plugin writes a progress line:
The plugin commits each batch separately, so the batches processed before an interruption stay in the database. Repeating the whole exchange is safe, because the plugin matches both products and variants by their 1C , as described in Record Matching.
When an offer's article is already the SKU of another variant, the plugin logs a warning:
On the following exchanges, the plugin logs the same conflict at the level, so the log doesn't repeat the same warnings.
When the exchange fails, 1C receives a response with the reason, and the same reason goes to the log. To see the duration of every import step, enable the log level, for example with the environment variable.