Integration with SBIS (Retail)

The quick incremental update of modified items (catalog guard and delta file) has been removed. Read this before updating: an item created or corrected in SBIS will no longer arrive at the site within a few minutes; it will arrive with the next full exchange. The reason is honest: SBIS has no way to ask "what has changed since such-and-such hour," so the mechanism had to be built via a workaround—comparing catalog snapshots and fetching each item with a separate request. This hit the limit on request frequency and threatened to block the exchange channel, while on the site side it required separate scheduling coordination. We continue to search for a way to deliver changes quickly and will restore it when it is reliable.

The module silently lost products during exchange—up to 39 percent of the price list. SBIS limits request frequency: no more than 50 requests per minute; exceeding this results in a rejection and a two-minute block. The rejection comes as a normal response, and the module read it as "there is nothing in this folder"—the entire folder was skipped, with no single error in the report. A measurement on a live database showed that instead of 3844 items reaching the site, only 2326 arrived, and each time different ones. Now rejections are recognized, the exchange proceeds at an allowed pace, and the number of requests is visible in the run report.

Products without a section are no longer discarded. Previously, the section was determined indirectly: items were taken from the price list, and the section was selected from the catalog export. An item missing from that export lost its section and disappeared from the site; if an entire folder failed to appear in the export, it too disappeared. On a live database, the "Bearings" branch disappeared this way—31 items with price and stock. Now the section is taken directly from the catalog, so there is no way to lose it.

Two honest operating modes, and choosing between them is the first question in settings. "From SBIS catalog" — products, the tree structure, and characteristics are taken directly from the catalog; a price list is not needed at all: everything in the specified folder is imported, and maintaining a second copy of the assortment is no longer required. "From price list" — the previous approach for those who manually assemble the showcase and set their own prices within it. The form displays only the fields needed for the selected mode.

The export report now shows the number of requests to SBIS and the number of waiting periods.

Stock levels are taken from the catalog in any mode. Previously, they bypassed the price list, and items not included in the price list had no stock at all. A product has stock regardless of whether it is sold via the price list or not.

The catalog folder code is now required in any mode: it limits the traversal to a single branch. Without it, the traversal covers the entire organization's nomenclature.

When the module is installed, the "from price list" mode is enabled by default. Switching to the catalog changes both the export composition and the prices, so it should be enabled only by the owner consciously.

Customer invoice based on the store order. Once the order is placed, the invoice is automatically generated in SBIS: prices, VAT, and details are taken from the accounting system, and the invoice number is also taken from there; the website does not maintain its own numbering. The print form is attached to the order and sent to the customer via email with the attachment. The invoice is issued exactly once: a repeated click returns the already issued invoice rather than creating a second one—two invoices for a single order mean someone will pay for a cancelled one.

The order composition is verified against the warehouse before issuance. If a position is missing or has no price, the invoice is not issued, the order is moved to the manager approval stage, and the customer is shown exactly which positions are holding up the order. An invoice for a composition that is not in stock is more dangerous than no invoice at all: payment is made immediately based on it.

Reservation of goods for the issued invoice. Goods are reserved in the SBIS warehouse immediately after issuance, with the term set by configuration. The reservation reduces the stock quantity received on the website, so the goods are no longer offered to other customers.

The "Invoices" tab in the module settings. Issuance, order stages, reservation, bank details, and department—all in one place. Stages are selected from a list with their names, not codes.

The print form lacked both bank details and VAT. There were three reasons for this, and each failed silently: the document was created, the amount was correct, and there were zero errors. The attachment was sent in format 3.01, where tax is specified via tags rather than attributes; along with the file, its details—type, subtype, and version—were not transmitted, leaving the document unformatted; the print form was taken from the link to the document itself, which is a template, whereas the ready-made invoice exists as a separate attachment.

The invoice was issued with an extraneous warehouse. The organization is now explicitly named: without this, SBIS selects it automatically based on the document author's account, and along with it, its warehouse is inserted; accounting cannot recognize such a document, and stock levels become inconsistent.

The account number started with a one. The empty SBIS number was filled in automatically; now the number is requested in advance from the accounting system, and numbering remains continuous.

The reason for SBIS rejection is no longer lost. In background tasks, translation is unavailable, and together with the message wrapper, the service response text itself disappeared — what went out was 'the accounting system did not accept the document' without a single word explaining why.

Step-by-step export of the product catalog and stock levels. Buttons on the "Export" page no longer wait for a result from a single request: the process runs in 20-second segments, and the page shows how much has been collected and how many sections remain. A connection break causes no data loss; the next click resumes from the same point. Why: a catalog with three thousand items takes 5–10 minutes to export, while a typical hosting web server terminates the request around the one-minute mark and returns a 504 error. Exports from the admin panel never completed before and appeared as a "connection error" despite SBIS being operational. Verified on 23.09.2026 on reg.ru: a catalog with 3226 products and 110 categories was collected in 19 steps.

Methods "Nomenclature::runStep()" / "Stocks::runStep()" and the "resetStep()" action; the "export_step" action in the admin AJAX endpoint.

The cron schedule still triggers the previous single-attempt path — see "DEBT.md".

Dimensions arrive at the site as three separate numbers instead of one length repeated three times. The YML format keeps all three dimensions in a single line as a tag labeled dimensions containing 60.000/2.000/3.000, while in Bitrix length, width, and height are three separate fields. One tag does not split into three fields: the import converted the string to a number and each time returned 60 — the length was set correctly, but width and height silently repeated it. No error occurred: the file was correct, but the mapping could not express the required values. Now, alongside the old tags, tags labeled length_mm, width_mm, and height_mm are exported.

Weight and dimensions are now in the same units as Bitrix stores them. YML uses kilograms for weight and centimeters for dimensions, while Bitrix uses grams and millimeters. Previously, conversion had to be set manually in the import profile. Now there is a tag labeled weight_g in grams, and the three new dimension tags are directly in millimeters — fields can be mapped directly without conversion. The old tags labeled weight and dimensions remain as they were, and already configured profiles are untouched.

An empty dimension does not become zero. If only length is specified in the SBIS card, only it will be written to the file, while width and height will remain without a tag — otherwise the import would overwrite existing site values with zeros.

The schedule now includes a start time. Previously, only the interval was set, and the first run was scheduled for now plus the interval, i.e., at a random time. Moreover, Bitrix calculated the next run from the end of the previous one, so a daily export drifted forward by the duration of the exchange. Where the file is fetched by the hosting schedule, this breaks the order: the export arrives during the import time, and the site starts receiving yesterday's file — without any errors in the reports. Now, alongside the interval, there is a time field, and the specified hour is maintained.

The schedule table shows when the next run will occur. The value is taken directly from Bitrix, not recalculated: it must show what the site will actually do.

The module's tables no longer conflict with the database encoding. The encoding was hardcoded, causing the standard website check "Table Encodings in DB" to fail on databases with different encodings. Now the module does not specify an encoding at all and uses the one set for the database; existing tables are converted to it during updates.

The module no longer conflicts with neighboring Vinttra modules over the menu icon. The handler for the common item "Vinttra.Hub" had the same name across several of our modules: on a site with two of them, the icon depended on which one loaded first. The names have been separated into their own namespaces.

Four unused addresses have been removed from the delivery. The "ajax/" folder duplicated a live handler and was never called, yet it remained as four extra entry points on the site. During updates, these files are deleted from already installed sites.

Russian comments in page markup have been translated to Latin script. Users do not see them, but in archives they appeared as "?".

New and modified items arrive on the website within minutes, not the next day. A 'catalog guardian' has appeared: every few minutes it queries SBIS for the catalog composition, compares it with the previous check, and compiles into a separate small file only what has appeared or changed. The full exchange, which used to occur once a day, continues as before; the guardian does not replace anything but bridges the gap between 'a manager created an item in SBIS' and 'it is visible in the store.' A person working in SBIS does not need to access the website admin panel.

The composition is compared, not the quantity. The number of items does not reveal which one is new: SBIS does not provide creation dates at all. Therefore, the guardian maintains a fingerprint for each item—name, price, section, weight, dimensions—and can see by name what has appeared, what has changed, and what has disappeared. All in a single query for the entire check.

The delta accumulates until a full export. The file is not rewritten each time but appended to: otherwise, an item that the import has not yet retrieved would be lost during the next check. The daily exchange retrieves everything at once and clears the accumulator.

Important: the delta file requires a separate import profile—a copy of the main one, but with actions disabled when an item is missing in the file. The file contains multiple items, and standard settings would deactivate the entire catalog based on it. The hint for the setting states this directly.

Fuse for delta size. If more items have changed than specified in the setting (default is one hundred), the incremental reload is skipped — such changes will be handled by the full export. This protects against a flood of requests after price list regeneration, when fingerprints change for all items at once.

Lock against simultaneous exchanges. It did not exist at all: while the exchange occurred once a day, this was not a problem, but with the guard, the collision became a matter of time. Now, full export and the guard do not step on each other's feet, and the lock is automatically removed upon expiration so that a failed process does not permanently lock the exchange.

The delta file is created immediately, even if empty. An import profile pointed at a non-existent file does not crash but hangs: verified on a live site—the process ran for ten minutes with an empty log. If such processes were launched every few minutes, they would accumulate until memory was exhausted.

Products with a price no longer disappear from the export. When binding sections to the catalog, the module used to discard everything not found in the SBIS catalog export, treating this as a sign that 'the product has no price'. This sign is incorrect: the catalog export does not return the entire price list. On a live database with 3598 price list positions, only 2956 were included in the export, and among the 642 discarded items, 68 had a price set — including in the catalog card. Products silently disappeared from the website: the file was assembled without errors, the import report was clean, and the disappearance could only be detected by searching for a specific barcode. Now, the section for such products is reconstructed based on the category mapping between the price list and the catalog, compiled from products found in both sources. Only those for which no section exists at all are discarded.

Filtering out products without a price has become a configurable setting. Previously, it existed only as a side effect of the previous point and unnecessarily removed extra items. Now it is an explicit rule: 'Products without a price: do not export / export together with the rest'. The default preserves the previous behavior for each installation: when binding sections to the catalog, such products were not exported before, and when binding to the price list, they were exported.

The 'Run Manually' page shows what was filtered out. After the exchange, next to the number of exported products, it displays how many were excluded due to missing price, how many due to missing section in the SBIS catalog, and how many had their section reconstructed. The silent loss of part of the catalog was exactly the reason this version was needed.

The error message 'there is not a single product in the catalog export' no longer lies. It previously cited missing product prices as the cause; the actual frequent cause is that the folder code for the catalog in the settings points to the wrong branch.

The price list banner no longer conflicts with the setting below it. It advised uploading the price list on top without recreating it. This is correct for binding sections to the price list, but harmful for binding to the catalog: catalog numbers survive a rebuild, whereas an overlay accumulates in the price list items that have long been absent from the catalog. On a live database, a rebuild completely removed eight folders containing a mix of products from different catalog categories. Now the banner text depends on the selected mode.

The module can no longer crash a neighboring Wintra module. The demo mode banner class had the generic name "WintraTrialNotice" — the same as in our other modules. If another module was nearby, the second one would redeclare the class and crash with a fatal error, and it was the neighbor that crashed, not the culprit. The class has been renamed to "WintraSbisTrialNotice".

The "Matching with B24" page no longer modifies data upon simple opening. It silently deleted from the database decisions for positions that no longer exist in the SBIS snapshot — directly during page loading, without checking the session token. If opened by an administrator via someone else's link, it would behave the same way. The deletion was unnecessary: actual cleanup is performed during plan recalculation and is protected by a token. Now the page only hides outdated records from the selection.

Error messages no longer display internal details. In three places — on the matching and comparison pages with Bitrix24 and during webhook verification — the exception text was printed, which included the webhook address and the portal response. Instead, a clear explanation of what to check is displayed.

Module update no longer risks hanging. The update script connected the module at the moment its files were only half copied. The connection has been removed; registering the menu handler in it is not required.

Sections can be linked to the SBIS catalog instead of the price list. Until this version, website sections were linked to the folder number in the price list tree. This number is reassigned with every price rebuild: on a live database, after a full rebuild of 3510 items, the item number changed for all, while the catalog code changed for none. As a result, the exchange recreated the section tree, leaving the previous sections empty, and this happened silently—the import ran without errors. Now, settings include the option "Link sections to: SBIS catalog / price list". The structure is retrieved via one additional query; no per-item requests were added.

The update does not break anything. For sites updating from previous versions, the linkage remains as before—price list based. Catalog-based linkage is enabled only manually and warns about the consequences. New installations immediately receive linkage to the catalog.

Limitation on exporting a single catalog folder. In the SBIS catalog, accounting folders such as "Archive", "Not for sale", and "Not indexed" usually sit alongside trading folders. Without this limitation, they were included in the file and created as empty sections on the website. A field "SBIS catalog folder code" has been added.

Barcodes are distributed by type. SBIS returns barcodes as an array in an unpredictable order: for one item, EAN13 comes first, for a neighbor, second, after an internal short code. The import profile takes the first one, so part of the items silently changed their symbolic code, along with their page address: on the live catalog, 27 out of 2854 items were affected; their previous links now return 404. Now, alongside the general tag, a tag for each type is exported—"barcode_ean13", "barcode_shortcode", and so on—and in the import profile, each type is assigned to its own field. The general tag is preserved; configured profiles are unaffected.

Weight, dimensions, and country of origin. Previously, they were not exported at all: the item list does not provide these fields. Now, they are taken from the catalog export via the same query. On a test database, weight was filled for 736 items.

The "Load from SBIS" button in the characteristic filter now works again. Previously, the list of characteristics was collected from the first page of the nomenclature starting from the root of the catalog. If the root contained only folders—which is how any standard catalog is structured—no products appeared in the selection, and the module responded with "no characteristics in the nomenclature." This message sounded like a factual statement about the user's data. Now, the module traverses the tree and stops once it has gathered enough products; it now clearly distinguishes between "no characteristics" and "no products in the selection."

The "Save" panel is no longer hidden below the fold. Since the settings form is long, users previously had to scroll to find the button. The action panel is now fixed to the bottom of the form and is always visible.

Secrets in the settings are now hidden. The protected key, service key, and Bitrix24 webhook address were previously displayed as plain text and could be read from the screen. They are now hidden, just like the employee password.

The "Reserves and External Codes" block has been split into two. Previously, four fields were listed together, although they function as independent pairs: login and password provide reserves, while connection with the checkbox enables marketplace external codes. A user configuring the settings read the block from top to bottom and might select a connection unnecessary for reserves. Now, there are two separate blocks with their own headings and explanations; the second is marked as rarely needed.

It is now clear what "external_id" means. The product's universal code is always exported and requires no settings—it is a separate tag unrelated to the "external codes" checkbox. The settings block explicitly states this and also specifies the cost of enabling external codes in minutes.

The "Manual Run" page has been organized. Blocks now follow the workflow sequence: nomenclature, stock, and Bitrix24. All buttons look identical and indicate that work is in progress. Previously, the stock export button lacked both visual consistency and status indication, making a click appear as if it "did not work." The Bitrix24 block is now shown only when the integration is configured. The description of stock export has been clarified: it is not faster than nomenclature export, as the entire catalog is traversed.

Distorted characters in the interface have been removed. Dashes, arrows, and separators were hardcoded in the markup and appeared as diamonds on UTF-8 sites—for example, in the "Size" and "Updated" columns of the current files table.

Text on the settings page no longer turns into "?????" on UTF-8 sites. The "To obtain reserves and external codes" block was hardcoded in the page markup. The marketplace archive is built in cp1251 encoding, causing such text to display as question marks on UTF-8 sites. All block labels have been moved to the language file—Bitrix now delivers them in the site's encoding.

Two silent failures caused by the same issue have been fixed. The API request parameter name for SBIS and the indicators of temporary blocking in the service response were also hardcoded in Russian: after compilation, they no longer matched, causing pagination and retry on rate limiting to fail silently.

The demonstration mode is visible in the module. A standard Bitrix countdown banner has appeared on the module pages: "Module demonstration mode. Days remaining: N" with a link to purchase.

A clear message is displayed after the demo period ends. When the demonstration period expires, the module pages show the reason and a link to activate instead of an empty page or an error.

Security. Technical details of errors (connection check, exchange with SBIS and Bitrix24, re-sending orders, exports) are no longer exposed to the user; a generalized message is shown instead. The debug log for stock exports has been removed from the distribution: previously it was written to a publicly accessible site folder.

Interface encoding. Arrows, checkmarks, and status icons are now implemented using HTML entities and are no longer distorted on sites using UTF-8 encoding.

Fix: recursive traversal of the section hierarchy in enrichReserves(). Version 1.2.11 performed drill-down only for the top level; if the SBIS catalog was hierarchical deeper than 1 level, products at level 2 and above were silently skipped (matched=0). Precedent chromart.ru: after adding a product to a new subfolder, the SBIS catalog structure was rebuilt (ROOT ? 2 sections ? subfolders ? products), and all 18 reserved items disappeared from stocks.xml. Now using BFS traversal: parseFlat() extracts lines with TypeRecord=Nomenclature, and remaining Section entries are added to the queue as depth+1. Cycle protection via visited, depth limit max_depth=5. Each level is logged: drill DBId tag d=depth tag rows=n tag matched=k tag sub=m tag.

Affected file: src/lib/stocks.php (enrichReserves() — BFS added via queue instead of a single pass).

Fix: Reserves via 'ReserveBalancesReport.GetData' (UI report 'Reserve Balances') instead of 'MovementsByReserves.GetData'. Up to version 1.2.10, it used a per-item RPC call for each product ID. SBIS with a catalog of more than 100 products triggered rate limiting and blocked the method for 86400 seconds (support confirmed the limit: 60 requests per minute). The new method covers the entire catalog in a single prefetch session: INIT (obtain 'PrefetchSessionId') ? READ root (list of sections) ? drill-down for each section (flat list of products). On a catalog of 200 products, the process completes in approximately 1 second with no rate limiting. The 'enrichReserves($rows)' contract is preserved.

Fix: Garbled characters in the 'Export Type' dropdown of the schedule — hardcoded Russian text in cp1251 PHP has been removed. The schedule type 'reserves' (separate channel via 'runReserves()') has been completely removed: reserves now enrich 'stocks.xml' directly in 'WintraSbisStocks::run()', so a separate schedule is no longer needed. Removed: 'WintraSbisStocks::runReserves()', handler 'type=reserves' in 'WintraSbisSchedule::runById', and option 'reserve_doc_type' (field 'Where reserves are stored' — now unnecessary, as the new RBR method returns reserves regardless of document type).

Protection against rate limiting when enriching external_code. 'Nomenclature.NomenclatureRead' does not accept an array of IDs, requiring per-item calls. Default throttle is 1100ms between RPC calls (~54 req/min, below the 60 limit). Adaptive backoff is applied on 'too frequent' or 'not found or unavailable' errors. Progress markers are logged in '/upload/sbis/stocks-debug.log' every 50 products. Throttle is configurable via option 'enrich_ext_sleep_ms' (default 1100).

Checkbox 'Get external codes from marketplaces' in settings. On a catalog of 200 products, enrichment takes approximately 3.7 minutes (60 req/min limit). Not all clients need this code — now there is an explicit opt-in checkbox 'enrich_ext_codes_enabled'. By default, it is disabled, so no requests are sent.

File-based debug log '/upload/sbis/stocks-debug.log' (not 'CEventLog'). Many client sites keep 'log_filename = null' in '.settings.php', and 'AddMessage2Log' silently ignores it. A custom file log ensures diagnostics. Rotation occurs at >500KB.

Affected files: 'lib/stocks.php', 'lib/nomenclature.php', 'lib/schedule.php', 'lang/ru/lib/stocks.php', 'install/admin/sbis_schedules.php', 'install/admin/sbis_settings.php', 'install/version.php'.

Fix: garbled text in the module UI on UTF-8 client sites. In version 1.2.9, lang files were converted to cp1251 during packaging together with PHP code. On a UTF-8 client Bitrix site, cp1251 bytes were sent to HTML without conversion, causing Russian strings in the admin panel to appear as garbled text. Lang files now remain UTF-8 in the archive; Bitrix 'Loc::loadLanguageFile' automatically converts them to match the site's LANG_CHARSET. PHP code (lib/install/admin) remains cp1251 (Marketplace requirement). Confirmed by a precedent on wintramedia.ru.

Fix: Reservations in stocks.xml now arrive correctly on clients' UTF-8 sites. Root cause: Hard-coded Russian strings in the module code (transliterated Russian identifiers: 'SBIS.Autentifitsirovat', 'DvizheniyaPoRezervam.PoluchitDannye', 'FiltrNomenklatura', filter/navigation field names, response column names). When publishing the module, files are converted to Windows-1251 (Marketplace requirement), causing json_encode to corrupt such strings on UTF-8 sites. SBIS receives an empty body, resulting in the error: 'Parse error: document is empty'. All runtime literals have been moved to the lang/ru directory with the same relative path and .php extension using Loc::loadMessages and Loc::getMessage. Bitrix automatically returns strings in the encoding of the current site (cp1251 to cp1251, UTF-8 to UTF-8), ensuring bidirectional compatibility.

Affected files: «lib/auth.php», «lib/stocks.php», «lib/nomenclature.php», «lib/bitrix24.php», «lib/orders.php», «lib/schedule.php», «lib/menu-helper.php», «lib/trial-notice.php», «ajax/get_marketplace_connections.php», «install/admin/sbis_ajax.php», «install/admin/sbis_schedules.php», «install/admin/sbis_help.php», «install/admin/sbis_settings.php» plus corresponding lang/ru/ directory files named according to the path structure.

Also, duplicate inline auth code has been removed from "ajax/get_marketplace_connections.php" and "install/admin/sbis_ajax.php" (case "marketplace_connections") — both now use the unified "WintraSbisAuth::sabySessionAuth()" / "sabyRpc()".

Technical release: re-subscription to delta-update with the correct archive structure. In version 1.2.7, the entire 'install/' folder and 'lang/*/install/' folder were mistakenly included (an intentional exclusion in 'mp-build.php' that contradicted the Marketplace rule of 'only modified files'). This exclusion has been removed. Archive 1.2.8 contains exactly 'lib/stocks.php' + 'install/version.php' + 'updater.php' + 'description.ru'.

No functional changes beyond version 1.2.7 (the fix for the hardcoded '[170]' in 'DvizheniyaPoRezervam.PoluchitDannye' was already in the code).

The hardcoded 'FilterCategoryProduct = [170]' has been removed from the 'DvizheniyaPoRezervam.PoluchitDannye' query ('src/lib/stocks.php' — 'runReserves()' and 'enrichReserves()'). This was a chromart-specific category ID for 'Products'; on other SBIS sites, the method silently returned an empty result '?' in 'stocks.xml' with 'reserve=0' always, without errors in the log. Now the category filter is empty — reserves are pulled for any nomenclature. Precedent: wintramedia.ru, product id=195, the reserve in the invoice was not displayed in the export.

What is new in version 1.2.6:

The "Load" button has been restored next to the "Website Connection" field in the module settings. It loads the list of SABY marketplace connections using the login and password.

A two-step dialog for module deletion has been restored, offering the choice to "Save settings" or "Delete everything".

Complete deletion of settings now truly clears all module options and resets the Bitrix cache.

The update is recommended for all users who use the "For obtaining reserves and external codes" block or plan to reinstall the module.