Как оптимизировать распределенную базу 1С:УТ 10.3 и навести порядок на кассовых узлах?

Рано или поздно любая активно развивающаяся розничная или оптово-розничная сеть сталкивается с кризисом роста своей ИТ-инфраструктуры. Классическая схема на базе конфигурации «1С:Управление торговлей 10.3» и распределенных информационных баз (РИБ), которая годами работала без сбоев, начинает «сыпаться». Периферийные узлы разрастаются до критических объемов в 7–11 Гб, файловые базы данных регулярно повреждаются, а кассовые зоны зависают из-за неоптимальных обменов через OLE/COM-соединения.

В этой статье мы подробно проанализируем архитектурные проблемы такой топологии и разработаем пошаговый план оздоровления системы без радикального и болезненного для персонала перехода на новые конфигурации.

Выясняем причины: почему классическая схема РИБ начинает давать сбои?

Прежде чем приступать к активным действиям, давайте разберем физические причины происходящего хаоса. В рассматриваемой ситуации мы имеем центральную SQL-базу объемом 100 Гб и 20 файловых периферийных узлов по 7–11 Гб. Кассы работают через самодельный фронт-офис, который во время работы кассира инициирует OLE-подключение к базе товароведа.

Здесь кроются три критические уязвимости:

1. Ограничение файлового формата базы данных (1CD). Внутри файла .1CD размер одной таблицы не может превышать 4 Гб. Когда общая база разрастается до 10 Гб, таблицы индексов и итогов регистров приближаются к этому лимиту. Любой сетевой сбой, некорректное завершение работы компьютера или аварийное отключение питания приводят к разрушению файловой структуры и повреждению базы данных.
2. Использование COM/OLE для оперативного обмена. Технология OLE крайне чувствительна к качеству локальной сети и стабильности операционной системы. Когда кассовое рабочее место открывает OLE-сессию к базе объемом 10 Гб, происходит монопольное блокирование таблиц СУБД, утечка оперативной памяти и зависание интерфейса кассира в момент расчета с покупателем.
3. Избыточность данных в РИБ. База товароведа на торговой точке не должна весить 10 Гб. Это явный признак того, что в узел мигрируют лишние исторические данные, чужие документы и системный мусор (индексы полнотекстового поиска, логи обменов, регистры версионирования).

Рассмотрим пошагово, как исправить архитектурные ошибки и построить отказоустойчивую систему.

Шаг 1. Перевод периферийных узлов РИБ на клиент-серверный вариант (PostgreSQL)

Чтобы раз и навсегда забыть о регулярном «осыпании» баз на точках, нам необходимо полностью отказаться от файлового режима работы на рабочих местах товароведов. Единственным надежным решением является перевод узлов на клиент-серверную архитектуру.

Поскольку покупка полноценных лицензий MS SQL Server на 20 торговых точек потребует колоссального бюджета, мы рассмотрим использование бесплатной СУБД PostgreSQL (а именно специализированной сборки Postgres Pro для 1С).

Для реализации этой схемы на каждой точке нам потребуется:

• Установить СУБД PostgreSQL на локальный компьютер товароведа (или локальный сервер магазина).
• Использовать технологию автономного сервера 1С или приобрести недорогие лицензии типа «1С:Сервер мини на 5 подключений». Это полностью легальный и бюджетный способ развернуть клиент-сервер на торговой точке.

В результате СУБД будет самостоятельно контролировать целостность данных, транзакционность и кэширование, гарантируя защиту от повреждения индексов при внезапном отключении электричества.

Шаг 2. Ликвидация OLE-соединений и переход на режим KKM-Offline

Работа кассового аппарата должна быть автономной и бесконфликтной. Кассир не должен зависеть от того, проводит ли в этот момент товаровед тяжелый документ поступления или формирует ли ведомость по взаиморасчетам.

Мы настоятельно рекомендуем отказаться от самодельного фронт-офиса, работающего по OLE, и рассмотреть переход на режим KKM-Offline с использованием профессионального кассового ПО (например, Frontol) или возвратом к штатному РМК «1С:Управление торговлей 10.3» через локальный обмен.

Схема взаимодействия выглядит следующим образом:

1. База 1С (товароведа) выступает в роли бэк-офиса. Кассовая программа Frontol работает автономно на собственной СУБД Firebird.
2. Обмен между 1С и кассовой программой происходит бесконтактно — через файлы формата XML или TXT (формат АТОЛ).
3. Раз в час (или по расписанию) 1С выгружает во внешнюю папку текстовый файл с актуальными остатками, ценами и штрихкодами. Кассовый софт автоматически затягивает этот файл.
4. В конце смены кассовый софт выгружает файл отчета о продажах, который загружается в 1С в виде документа ОтчетОРозничныхПродажах.

Ниже приведен пример концептуального кода для выгрузки актуального прайс-листа из 1С в текстовый файл для кассового терминала:

// Создаем структуру текстового файла для кассового ПО
ПутьКФайлу = "C:\Exchange\goods.txt";
ТекстДок = Новый ТекстовыйДокумент;

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ЦеныНоменклатурыСрезПоследних.Номенклатура.Код КАК Код,
    |	ЦеныНоменклатурыСрезПоследних.Номенклатура.Наименование КАК Наименование,
    |	ЦеныНоменклатурыСрезПоследних.Цена КАК Цена,
    |	Штрихкоды.Штрихкод КАК Штрихкод
    |ИЗ
    |	РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ТипЦен = &ТипЦен) КАК ЦеныНоменклатурыСрезПоследних
    |		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.Штрихкоды КАК Штрихкоды
    |		ПО ЦеныНоменклатурыСрезПоследних.Номенклатура = Штрихкоды.Владелец";

Запрос.УстановитьПараметр("Период", ТекущаяДата());
Запрос.УстановитьПараметр("ТипЦен", Справочники.ТипыЦенНоменклатуры.НайтиПоНаименованию("Розничная"));

РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();

Пока Выборка.Следующий() Цикл
    СтрокаВыгрузки = Строка(Выборка.Код) + ";" + Выборка.Штрихкод + ";" + Выборка.Наименование + ";" + Строка(Выборка.Цена);
    ТекстДок.ДобавитьСтроку(СтрокаВыгрузки);
КонецЦикла;

ТекстДок.Записать(ПутьКФайлу, КодировкаТекста.ANSI);

При такой схеме касса работает со скоростью локальной СУБД Firebird. Кассир пробивает чеки мгновенно, даже если база 1С на компьютере товароведа полностью зависнет или перезагрузится.

Шаг 3. Настройка жесткой фильтрации в плане обмена РИБ

Чтобы уменьшить размер баз на торговых точках с 10 Гб до приемлемых 1.5–2 Гб, мы должны исключить миграцию лишней информации. Товароведу в конкретном магазине совершенно не нужно знать остатки на складах других регионов, видеть чужие заказы покупателей и анализировать финансовые документы центрального офиса за прошлые годы.

Проанализируем правила регистрации объектов в плане обмена. Для этого откроем конфигуратор и настроим фильтрацию на уровне кода в модуле плана обмена. Нам понадобится использовать предопределенный обработчик ПриОтправкеДанныхПодчиненному.

Рассмотрим пример ограничения миграции документов реализации товаров прошлых периодов:

Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента)
    
    // Исключаем миграцию документов старше 3 месяцев
    Если ТипЗнч(ЭлементДанных) = Тип("ДокументОбъект.РеализацияТоваровУслуг") Тогда
        Если ЭлементДанных.Дата < ДобавитьМесяц(ТекущаяДата(), -3) Тогда
            ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
            Возврат;
        КонецЕсли;
        
        // Передаем документы только по складу конкретного узла
        Если ЭлементДанных.Склад <> ЭтотУзел().СкладПолучатель Тогда
            ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
        КонецЕсли;
    КонецЕсли;
    
КонецПроцедуры

После внедрения подобных фильтров необходимо произвести свертку баз на периферийных узлах. Удаление неиспользуемых ссылок, очистка кэша метаданных и реиндексация таблиц позволят существенно высвободить дисковое пространство и повысить скорость работы системы.

Шаг 4. Прямая интеграция 1С с сайтом (Bitrix) и отказ от буферных баз

Использование третьей промежуточной базы данных для обмена с сайтом — это источник постоянного рассинхронизатора метаданных и двойной работы для программиста. Нам необходимо избавиться от этого «костыля».

Современные веб-технологии позволяют настроить прямую интеграцию по стандарту CommerceML напрямую с центральной базой УТ 10.3:

• Мы публикуем центральную информационную базу УТ 10.3 на веб-сервере Apache или IIS.
• Для обмена используется штатный протокол HTTP/HTTPS. Битрикс умеет отправлять запросы непосредственно в опубликованную базу 1С.
• Используем официальный бесплатный модуль обмена от компании Битрикс для УТ 10.3. Он регулярно обновляется и поддерживает выгрузку каталогов товаров, цен, остатков, а также оперативный забор заказов покупателей в режиме реального времени.

При такой схеме заказы с сайта мгновенно попадают в центральную базу УТ 10.3, а остатки оперативно обновляются на веб-ресурсе, исключая продажу отсутствующего на складах товара.

Шаг 5. Работа с персоналом и гибридный переход

Сопротивление персонала — один из главных факторов провала крупных ИТ-проектов. Если сотрудники привыкли к интерфейсу обычных форм УТ 10.3, попытка насильно пересадить их на «1С:Розницу 2» или «1С:УТ 11» на управляемых формах вызовет саботаж работы торговых точек.

Мы предлагаем применить эволюционный (гибридный) подход:

1. Бэк-офис и товароведы остаются в УТ 10.3. Для них ничего не меняется, интерфейс остается прежним. Мы лишь оптимизируем надежность базы (перевод на Postgres) и скорость обменов.
2. Кассовая зона переводится на специализированный софт. Если мы используем специализированную фронт-систему (например, Frontol), кассиры видят на экране простой плиточный интерфейс. Обучение работе на такой кассе занимает не более одного дня. Кассиру не нужно знать принципы работы 1С — он просто сканирует штрихкоды и принимает оплату.
3. Постепенное тестирование альтернатив. Если заказчик выражает желание использовать «1С:Розницу 2/3», мы запускаем ее в тестовом режиме на 1–2 магазинах на период в один месяц. Обмен настраивается через правила конвертации данных (КД 2.0). По итогам теста руководство торговой сети сможет принять взвешенное решение о целесообразности масштабного перехода.

Резюме и план действий

Чтобы навести порядок в информационной системе компании, выполним следующие шаги:

1. Проведем аудит нетиповых доработок в конфигурации УТ 10.3.
2. Переведем базы данных товароведов на бесплатную СУБД Postgres Pro.
3. Перенастроим правила регистрации объектов в планах обмена РИБ для снижения веса баз на точках до 2 Гб.
4. Откажемся от OLE в пользу файлового обмена (KKM-Offline) с фронт-системами на кассах.
5. Опубликуем центральную базу на Apache для прямой интеграции с 1С-Битрикс без промежуточных баз.

Такой подход позволит сэкономить бюджет предприятия на покупку лицензий Microsoft SQL, сохранит привычную рабочую среду для сотрудников офиса и гарантирует бесперебойную работу кассовых зон при любых сетевых неполадках.