# INTEKEY WMS — требования к инфраструктуре заказчика

| | |
|--|--|
| **Версия документа** | 2.1 от 2026-08-25 |
| **Автор** | Симонов Михаил, CTO, Intekey |
| **Заменяет** | редакцию 2.0 от 2026-08-14 (добавлены §3.1 «Два контура», §16.1 «Защищённый туннель», §16.2 «Доступ для Intekey Deployer») |
| **Назначение** | приложение к договору / ТЗ; чек-лист готовности площадки к внедрению |
| **Кому адресован** | ИТ-служба заказчика, служба эксплуатации склада, закупки |

---

## 0. Как читать документ

Каждое требование имеет уровень:

| Уровень | Смысл |
|---------|-------|
| **Обязательно** | без этого система не может быть введена в эксплуатацию или не покрывается SLA |
| **Рекомендуется** | без этого система работает, но с деградацией скорости/надёжности; риск на стороне заказчика |
| **Опционально** | нужно только при определённом сценарии (морозильный склад, облачная 1С, печать через FTP и т. п.) |

Конфигурации даны тремя типоразмерами. Выберите свой по фактическому профилю склада:

| Типоразмер | ТСД (одновременно) | АРМ | Строк документов в сутки | Ячеек хранения |
|-----------|--------------------|-----|--------------------------|----------------|
| **S** — малый склад | до 10 | до 10 | до 1 000 | до 5 000 |
| **M** — средний склад | до 30 | до 25 | до 10 000 | до 30 000 |
| **L** — крупный / 3PL | 30+ | 25+ | 10 000+ | 30 000+ |

---

## 1. Как устроена INTEKEY WMS (чтобы требования были понятны)

```
   ТСД (Wi-Fi)          АРМ склада/офиса         Принтеры этикеток
   сканирование         веб- и desktop-клиент    (сеть, ZPL)
        │                      │                        ▲
        └──────────┬───────────┘                        │
                   ▼                                    │
        ┌──────────────────────┐   печать заданий ──────┘
        │  СЕРВЕР ПРИЛОЖЕНИЙ   │
        │  (бизнес-логика WMS, │◄──── REST/JSON ─────  1С / ERP (инициатор — ERP)
        │   расчёты, печать)   │────── REST/JSON ────► Yard, MobileSMARTS
        └──────────┬───────────┘
                   │ SQL (много мелких запросов, задержка критична)
                   ▼
        ┌──────────────────────┐
        │   СЕРВЕР БАЗЫ ДАННЫХ │  PostgreSQL
        │  (остатки, история)  │
        └──────────────────────┘
```

Четыре факта, из которых следует всё остальное:

1. **Вся логика выполняется на сервере.** ТСД и рабочие станции — «тонкие»: они показывают экран и передают
   скан. Поэтому мощность нужна серверу, а не терминалам, и поэтому связь ТСД→сервер должна быть непрерывной.
2. **Одна операция кладовщика — это десятки мелких обращений к базе.** Значит для связки «сервер приложений ↔
   сервер БД» важнее *задержка* (миллисекунды), чем *ширина канала* (мегабиты).
3. **Часть расчётов (план подбора, план размещения, пополнение) — тяжёлые однопоточные алгоритмы.** Значит важна
   не только суммарная многоядерность, но и частота одного ядра.
4. **Система работает автономно от интернета.** Приёмка, размещение, подбор, отгрузка, печать продолжают
   работать при полностью оборванном внешнем канале — при условии, что локальная сеть и Wi-Fi живы.

---

## 2. Чего мы **не** требуем

Это часть требований — она снимает лишние затраты из бюджета проекта.

| Не требуется | Почему |
|--------------|--------|
| Терминальный сервер / RDS и CAL-лицензии | клиент работает в браузере, ничего не публикуется через RDP |
| Лицензии на серверную ОС и СУБД | серверная часть работает на Linux и PostgreSQL — обе свободные, лицензии не покупаются |
| Оборудование конкретного вендора | подходят любые серверы, ТСД и принтеры, отвечающие параметрам ниже |
| Выделенный ЦОД / стойка | достаточно закрытого помещения с питанием и охлаждением |
| Отдельное ПО на ТСД | экраны терминала открываются в браузере устройства |
| Покупка дополнительного ПО «в довесок» | INTEKEY WMS самодостаточна, сторонние продукты для работы не нужны |

---

## 3. Серверное оборудование

### 3.1. Два контура: продуктивный и тестовый — **Обязательно**

Заказчик выделяет **две среды (PROD и TEST)** и предоставляет Intekey доступ к обеим. В каждой среде — сервер
приложений и сервер БД; их можно совместить на одном хосте (§3.4).
Это не «вторая копия для пользователей» — **это инфраструктура процесса поставки обновлений**: обновления
INTEKEY WMS ставятся нашим инструментом **Intekey Deployer**, и ему нужны оба контура.

| Контур | Роль в поставке обновлений | Доступ Intekey |
|--------|---------------------------|----------------|
| **TEST** | Deployer выкатывает новую версию **сюда первой**: мы проверяем работоспособность, обмен с 1С/ERP и воспроизводим инциденты до того, как версия попадёт на продуктив | **обязателен** |
| **PROD** | Deployer выкатывает сюда **уже проверенную на TEST** версию; рабочий контур склада | **обязателен** |

**Зачем это нужно.** Intekey Deployer забирает собранную версию из нашего репозитория и разворачивает её на
площадке заказчика по регламенту «сначала TEST → проверка → затем PROD». Это даёт:

- **быстрые поставки** — типовое обновление раскатывается за минуты, без ручного копирования архивов,
  ручной правки конфигов и ручных ночных работ — выкладка идёт в согласованное окно автоматически;
- **воспроизводимость** — на PROD уезжает ровно та версия, которая отработала на TEST;
- **безопасный откат** — предыдущая версия остаётся на площадке, возврат выполняется той же командой;
- **отсутствие «отладки на живом складе»** — гипотезы по инцидентам и доработки проверяются на TEST,
  продуктивные остатки не затрагиваются.

Дополнительно TEST-контур используется для обучения персонала заказчика и для приёмки доработок — но
основное его назначение именно техническое: без него поставка обновлений штатным способом невозможна.

**Без выделенного TEST-контура** обновления и разбор инцидентов приходится вести непосредственно на
продуктивной базе — это прямой риск для учёта заказчика и основание для увеличения сроков по SLA.

**Требования к ресурсам контуров**

| Контур | Ресурсы |
|--------|---------|
| **PROD** | по типоразмеру согласно §3.2 и §3.3 |
| **TEST** | допускается ~50 % от PROD, но не ниже: 4 потока CPU / 16 ГБ RAM / 100 ГБ SSD на роль. Диск может быть SSD без требований к IOPS: нагрузочные характеристики на TEST не проверяются |

**Условия, обязательные для TEST-контура**

- TEST **изолирован от PROD**: отдельные серверы (ВМ), отдельная база, отдельные учётные записи обмена;
- TEST подключается к **тестовой** базе 1С/ERP, а не к продуктивной (см. §11.1);
- периодически на TEST разворачивается обезличенная копия продуктивной базы — иначе проверка обновления
  не показательна;
- печать с TEST направляется на выделенный принтер или в файл, чтобы не выпускать «тестовые» этикетки в цех.

**Оба контура должны быть доступны Intekey через защищённый туннель между инфраструктурами (§16.1).**

### 3.2. Сервер приложений — **Обязательно**

| Параметр | S | M | L | Зачем |
|----------|---|---|---|-------|
| CPU (потоков) | 8 | 8–12 | 16+ | параллельные сессии ТСД и АРМ |
| Базовая частота ядра | ≥ 2,4 ГГц | ≥ 2,6 ГГц | ≥ 3,0 ГГц | расчёт планов подбора/размещения однопоточный: частота напрямую = секунды ожидания кладовщика |
| RAM | 32 ГБ | 64 ГБ | 96–128 ГБ | серверные кэши модели данных и открытые формы держатся в памяти |
| Диск | 200 ГБ SSD | 250 ГБ NVMe | 500 ГБ NVMe | приложение, логи, временные файлы печати |
| ОС | Linux (см. §4) | | | |

### 3.3. Сервер базы данных — **Обязательно**

| Параметр | S | M | L | Зачем |
|----------|---|---|---|-------|
| CPU (потоков) | 8 | 8–16 | 16–32 | конкурентные транзакции остатков/резервов |
| RAM | 32 ГБ | 64 ГБ | 128 ГБ | под кэш PostgreSQL: чем больше рабочего набора в памяти, тем меньше обращений к диску |
| Диск | 500 ГБ NVMe | 1 ТБ NVMe | 2 ТБ NVMe | база + журналы + запас на рост истории |
| Отказоустойчивость диска | RAID1 | RAID1 / RAID10 | RAID10, WAL на отдельном томе | отказ одного диска не должен останавливать склад |
| Производительность диска | ≥ 50 000 IOPS | ≥ 100 000 IOPS | ≥ 200 000 IOPS | random 8K, задержка < 2 мс — это **главный** параметр отзывчивости WMS |

**Методика замера производительности диска — обязательна для всех типоразмеров.** Значения IOPS в таблице
выше действительны только при следующих условиях замера, иначе цифры несопоставимы:

- блок **random 8K**, смешанная нагрузка 70 % чтение / 30 % запись;
- **задержка < 2 мс** на указанном уровне IOPS (IOPS в отрыве от задержки не являются критерием: на большой
  глубине очереди высокие IOPS достигаются ценой задержки в десятки миллисекунд);
- замер **на целевой ОС Linux** и **на том томе и той ёмкости**, которые уйдут под базу, а не на временном
  разделе;
- размер тестового файла **≥ 64 ГБ** — на файле в 1–2 ГБ измеряется кэш накопителя и кэш ОС, а не диск;
- прямой доступ в обход кэша ОС (`--direct=1`), длительность прогона ≥ 300 секунд.

Проверочные команды (`fio` и штатная утилита PostgreSQL):

```bash
# основной замер: random 8K, 70/30, 5 минут
fio --name=rnd8k --filename=/var/lib/postgresql/fiotest --size=64G \
    --bs=8k --rw=randrw --rwmixread=70 --ioengine=libaio --direct=1 \
    --iodepth=32 --numjobs=4 --group_reporting --runtime=300 --time_based \
    --percentile_list=50:95:99:99.9

# задержка одиночной операции
fio --name=lat --filename=/var/lib/postgresql/fiotest --size=64G \
    --bs=8k --rw=randread --ioengine=libaio --direct=1 \
    --iodepth=1 --numjobs=1 --runtime=60 --time_based

# фиксация коммита WAL — самый показательный тест для PostgreSQL
/usr/lib/postgresql/16/bin/pg_test_fsync
```

Результаты этих трёх команд достаточно прислать в Intekey для подтверждения типоразмера.

**Критично: HDD под базу данных недопустим**, равно как и «тонкие» тома в СХД без гарантированных IOPS.
На HDD расчёт плана размещения, который на NVMe занимает 2–3 секунды, занимает минуты — и кладовщик стоит.

### 3.4. Совмещение и виртуализация — **Рекомендуется**

- Для **S и M** сервер приложений и сервер БД допустимо разместить на **одном физическом хосте** — суммируйте
  требования (например, M: 16 потоков / 128 ГБ RAM / 1 ТБ NVMe). Это часто выгоднее и быстрее, чем два хоста,
  так как исчезает сетевая задержка между приложением и базой.
- Виртуализация (VMware, Proxmox, Hyper-V, KVM) допускается при условиях: ресурсы CPU и RAM **зарезервированы**
  (без overcommit), диск не thin-provisioned без гарантии IOPS, ВМ не мигрирует между хостами в рабочую смену.
- **Снапшот виртуальной машины не является резервной копией базы данных** — см. §14.

### 3.5. Сеть между приложением и базой — **Обязательно**

| Параметр | Значение |
|----------|----------|
| Полоса | ≥ 1 Гбит/с |
| Задержка (RTT) | < 1 мс — один L2-сегмент или один гипервизор |
| Недопустимо | разнос серверов приложений и БД по разным площадкам/через VPN/через WAN |

Причина — п. 2 из §1: одна операция ТСД порождает десятки SQL-запросов. Лишние 5 мс задержки на запрос
превращаются в лишние секунды на каждое сканирование.

---

## 4. Системное программное обеспечение

| Компонент | Требование | Комментарий |
|-----------|-----------|-------------|
| ОС сервера | **Обязательно:** Ubuntu Server 22.04/24.04 LTS, Debian 12, Rocky/AlmaLinux 9 | **CentOS 7 из прошлой редакции более не рекомендуется:** снят с поддержки в 2024 г., обновления безопасности не выпускаются. Для новых внедрений — только актуальные LTS-дистрибутивы |
| СУБД | **Обязательно:** PostgreSQL 14–16 (рекомендуется 16) | ставится и настраивается в рамках внедрения |
| Java-платформа | OpenJDK 17 | устанавливается в рамках внедрения, отдельная закупка лицензий не требуется |
| Офисные приложения на АРМ | LibreOffice или совместимый пакет | только для просмотра выгрузок XLS и отчётов |
| Синхронизация времени | **Обязательно:** NTP на серверах WMS (приложение и БД) и на серверах смежных систем — 1С/ERP | Все операции штампуются временем **сервера**, а АРМ и ТСД — это разные формы одного веб-приложения, поэтому расхождение часов между рабочими местами невозможно в принципе. Синхронизация нужна между серверами: иначе разъезжаются метки в журналах и сопоставление документов с 1С |
| Часовой пояс | единый на серверах WMS и смежных систем | |

---

## 5. Рабочие станции (АРМ)

**Обязательно**

| Параметр | Значение | Зачем |
|----------|----------|-------|
| CPU / RAM | 4 ядра / 8 ГБ | работа с широкими формами и отчётами |
| Диск | SSD | |
| Экран | ≥ 1920×1080 | формы диспетчера, комплектации и 3D-топология склада не помещаются на 1366×768 |
| ОС | **Linux** | поддерживаемая платформа рабочих мест |
| Браузер | Chrome / Chromium или Яндекс.Браузер актуальной версии | |
| Сеть | проводной Ethernet 100 Мбит/с и выше | Работа АРМ сводится к веб-клиенту: типовая страница справочника — **до 1 МБ**, гигабит к рабочему месту не нужен. Больше требуется только на нетипичных для WMS сценариях — выгрузка тяжёлых файлов и больших массивов данных. Проводное подключение предпочтительнее Wi-Fi по стабильности, а не по скорости |

**Рекомендуется:** на АРМ приёмки и контроля отгрузки — USB-сканер штрихкодов в режиме эмуляции клавиатуры.

---

## 6. Терминалы сбора данных (ТСД)

**Обязательно**

Ключевое требование для ТСД легаси (веб-клиент в браузере) — **Android версии 10 и выше**; приложение
TSD 2.0 работает на Android 7+. Остальное подбирается под задачи конкретного склада.

| Параметр | Значение | Зачем |
|----------|----------|-------|
| ОС | **Android 10 и выше** — для ТСД легаси (веб-клиент в браузере); приложение TSD 2.0 работает на Android 7+ | для веб-клиента на этой версии гарантированы обновляемый через Play браузер Chrome/WebView и актуальные патчи безопасности; на более ранних версиях корректная работа экранов ТСД не гарантируется |
| Сканер | **аппаратный**; тип (1D/2D, дальность, угол считывания) подбирается под задачу склада | тип сканера зависит от того, что и с какого расстояния читают: этикетка на коробке в руках, ячейка на верхнем ярусе или марка ЧЗ. Сканирование камерой в 3–5 раз медленнее и не работает по потёртым и бликующим этикеткам |
| Клавиатура | **желательно физическая** (цифровая или алфавитно-цифровая) | ввод количества и кодов без вызова экранной клавиатуры, которая перекрывает форму; работа в перчатках |
| Wi-Fi | 802.11ac (5 ГГц), поддержка 802.11r/k/v | бесшовный роуминг между точками доступа при движении по складу |
| Браузер | Chrome или актуальный WebView | экраны ТСД открываются в браузере; установка отдельного приложения не требуется |
| Питание | АКБ на полную смену + запасные АКБ или кредлы | |
| RAM, экран | ориентир: ≥ 2 ГБ, ≥ 4″ | комфорт работы, а не совместимость |

**Рекомендуется**

- Резервный фонд ТСД **10–15 %** от рабочего парка (поломки, зарядка, потери).
- Защита не ниже IP54; для холодных зон — модели с рабочей температурой до −20 °C и подогревом окна сканера
  (**опционально**, для морозильных/холодильных складов).
- MDM или киоск-режим: терминал открывается сразу на экране WMS, посторонние приложения недоступны.

### 6.1. Рекомендуемые модели

**Технических ограничений по производителям нет** — подойдёт любой Android-терминал, отвечающий требованиям
выше. Но есть ограничения эксплуатационные, сформированные опытом внедрений: по надёжности, поведению сканера
в складских условиях и ремонтопригодности мы рекомендуем модели:

| Производитель | Модели |
|---------------|--------|
| Point Mobile | PM352, PM452 |
| CipherLab | RK95 / RK96, RK25 / RK26 |
| M3 Mobile | US20 / US30, UL20 |

Терминалы других производителей допустимы, но их поведение в эксплуатации мы не подтверждаем практикой.

---

## 7. Wi-Fi на складе — **Обязательно** (главный риск проекта)

Wi-Fi — источник большинства проблем при запуске WMS. Кладовщик работает на ходу, между металлическими
стеллажами, заполненными товаром; сигнал, уверенный на пустом складе, пропадает на заполненном.

| Параметр | Требование | Почему именно так |
|----------|-----------|-------------------|
| Уровень сигнала | **≥ −67 dBm** во всей рабочей зоне | ниже — потери пакетов и «зависшие» сканы |
| Отношение сигнал/шум | ≥ 25 дБ | |
| Высота замера | 1,0–1,5 м (рука с ТСД), **в проходах между стеллажами** | замер на уровне потолка ничего не доказывает |
| Зона покрытия | все проходы, зоны приёмки/отгрузки, мезонины, холодильные и морозильные камеры, зона зарядки | «мёртвая зона» = участок, где склад работает на бумаге |
| Перекрытие соседних точек | 15–20 % | иначе разрыв при переходе между точками |
| Роуминг | 802.11r/k/v, **единый SSID и единая подсеть (VLAN) на весь склад** | переход между разными подсетями рвёт рабочую сессию — кладовщик теряет незавершённое задание |
| Диапазон | приоритет 5 ГГц; 2,4 ГГц — как резерв для старых ТСД | |
| Потери пакетов | < 1 % | |
| RTT ТСД → сервер | < 50 мс, джиттер < 30 мс | |
| Управление | контроллер точек доступа, отключение устаревших низких скоростей | |
| Питание точек доступа | PoE от коммутатора, подключённого к ИБП (§13) | при моргании света склад не должен «слепнуть» |

**Обязательно: радиообследование (site survey) на заполненном складе** до запуска и повторно — после
изменения схемы хранения или установки новых стеллажей. Обследование пустого склада результата не даёт.

Что происходит, если требование не выполнено: терминал теряет соединение → операция не подтверждается →
кладовщик сканирует повторно → в учёте появляются расхождения, а скорость операций падает на 20–40 %.
Диагностируется это как «тормозит WMS», хотя сервер при этом простаивает.

---

## 8. Локальная сеть и порты

**Обязательно**

| Параметр | Значение |
|----------|----------|
| Магистраль и порты серверов | 1 Гбит/с (10 Гбит/с — для L) |
| Сегментация | отдельный VLAN для серверов WMS; отдельный VLAN для ТСД |
| Питание сетевого оборудования | коммутаторы ядра и PoE-коммутаторы — от ИБП |
| Адресация серверов и принтеров | статические IP или фиксированный DHCP-резерв |

Порты, которые должны быть открыты (внутри контура заказчика):

| Порт | Направление | Назначение |
|------|-------------|------------|
| 80 / 443 | АРМ, ТСД → сервер приложений | веб-клиент и экраны ТСД |
| 7651, 7652 | АРМ → сервер приложений | desktop-клиент (если используется) |
| 5432 | сервер приложений → сервер БД | PostgreSQL; **наружу закрыт** |
| 9100 | сервер приложений → принтеры этикеток | прямая печать ZPL/EPL |
| 21 / 990 | сервер приложений → FTP-принтер | **опционально**, при печати через FTP |
| 22 | сеть управления и туннель Intekey → серверы PROD и TEST | администрирование, поддержка, выкладка обновлений Intekey Deployer (§16.2) |
| UDP 1194 (OpenVPN) / IP-протокол 47 (GRE) / UDP 500, 4500, 1701 (L2TP-IPsec) | концентратор заказчика ↔ концентратор Intekey | защищённый туннель между инфраструктурами; конкретный набор зависит от выбранной технологии (§16.1) |
| 80 / 443 входящий | сервер 1С/ERP → сервер приложений | вызовы обмена; инициатор обмена — ERP (§11) |
| 443 / 80 исходящий | сервер приложений → Yard, MobileSMARTS | смежные системы, к которым WMS обращается сам (§11.2) |

---

## 9. Пропускная способность: расчёт

Значения — расчётные, по типовому профилю складских операций; для площадок класса L уточняются нагрузочным
тестом на этапе пилота.

| Потребитель | Средний трафик | Пик | Комментарий |
|-------------|----------------|-----|-------------|
| Один ТСД | 30–60 кбит/с | до 1 Мбит/с | одно сканирование — обмен на 2–10 КБ |
| Один АРМ, веб-клиент | 150–400 кбит/с | до 8 Мбит/с | первая загрузка интерфейса 3–8 МБ, далее типовая страница справочника — до 1 МБ |
| Один АРМ, desktop-клиент | 100–300 кбит/с | до 5 Мбит/с | |
| 3D-топология склада | — | 10–20 Мбит/с разово | загрузка модели при открытии |
| Печать этикетки (ZPL) | 5–50 КБ на этикетку | — | |
| Печать документа (PDF) | 0,2–2 МБ на документ | — | |
| Пакет обмена с 1С/ERP | 1–5 МБ на 1 000 строк | — | §11 |

**Формула ориентировочной оценки полосы внутри склада:**

```
Полоса (Мбит/с) ≈ [ N_ТСД × 0,06 + N_АРМ × 0,4 + 20 (печать и интеграции) ] × 2 (запас)
```

Пример для M-склада (30 ТСД + 20 АРМ): `(1,8 + 8 + 20) × 2 ≈ 60 Мбит/с`.

**Вывод, который важно донести:** гигабитной локальной сети хватает с многократным запасом даже крупному
складу. Узкое место WMS — **не полоса, а стабильность радиопокрытия и задержки**. Инвестиции в качество
Wi-Fi окупаются, инвестиции в 10 Гбит/с к рабочим местам — нет.

---

## 10. Интернет-канал

### 10.1. Что работает без интернета

**Полностью весь склад:** приёмка, размещение, подбор, комплектация, контроль, отгрузка, перемещения,
инвентаризация, печать этикеток и документов. Система размещена на площадке заказчика и от внешнего канала
не зависит.

Сюда же относится **работа с кодами маркировки «Честный знак»**: в текущей реализации учёт марок в WMS
автономен, проверка кодов выполняется на стороне ERP — своего обращения к ГИС МТ система не делает и
интернет для складских операций с марками ей не нужен.

### 10.2. Что перестаёт работать без интернета

| Функция | Последствие обрыва |
|---------|--------------------|
| Удалённая поддержка Intekey | инцидент нельзя диагностировать; SLA по реакции не выполняется |
| Обмен с облачной 1С / облачной ERP | документы не поступают на склад и не уходят обратно |
| Обновления системы и ОС | накапливается технический долг и уязвимости |
| Почтовые уведомления и выгрузки контрагентам | не отправляются |

### 10.3. Требования к каналу

| Параметр | S | M / L | Уровень |
|----------|---|-------|---------|
| Основной канал | ≥ 25/25 Мбит/с | ≥ 50/50 Мбит/с симметрично | Обязательно |
| Резервный канал (второй провайдер или LTE) | рекомендуется | **обязательно**, с автопереключением | Обязателен для M/L |
| Белый статический IP или VPN-концентратор | обязательно | обязательно | Обязательно |
| RTT до площадки поддержки | < 60 мс, потери < 0,5 % | | Рекомендуется |
| Доступность канала | 99,5 % | 99,5 % | Рекомендуется |

**Резервный канал становится обязательным**, если 1С/ERP заказчика размещена в облаке (1С:Фреш, аренда,
внешний ЦОД): в этом сценарии обрыв внешнего канала останавливает поступление документов на склад так же,
как обрыв локальной сети.

---

## 11. Интеграции — в том числе с 1С

### 11.1. Интеграция с 1С — **поддерживается**

INTEKEY WMS штатно интегрируется с 1С: «Управление торговлей», «ERP Управление предприятием», «Комплексная
автоматизация», «Управление нашей фирмой», а также с отраслевыми и самописными конфигурациями. Отдельный
«коннектор» покупать не нужно — обмен входит в состав системы.

**Со стороны 1С обмен выполняет наш модуль `WMS.INconnect`.** Это готовый компонент интеграции, который
Intekey поставляет и устанавливает в базу заказчика: разрабатывать обмен с нуля силами 1С-подрядчика не
требуется. Модуль отвечает за выгрузку справочников и документов в WMS и загрузку факта обратно в учёт.
Для типовых конфигураций он ставится как есть; для отраслевых и самописных — адаптируется по результатам
обследования (объём адаптации оценивается отдельно).

**Что передаётся**

| Направление | Данные |
|-------------|--------|
| 1С → WMS | номенклатура, единицы измерения, штрихкоды, характеристики и партии, контрагенты, заказы поставщикам, ожидаемые поступления, заказы клиентов и реализации, задания на перемещение и инвентаризацию |
| WMS → 1С | фактически принято (с расхождениями к плану), фактически отгружено, состав грузовых мест, перемещения, результаты инвентаризации, статусы документов |

**Варианты обмена** (выбирается на этапе обследования):

| Вариант | Как работает | Когда применяется |
|---------|--------------|-------------------|
| **`WMS.INconnect`** (основной) | модуль в 1С вызывает REST/JSON-сервисы WMS и забирает факт теми же вызовами | типовые и доработанные конфигурации 1С — рекомендуемый сценарий |
| **Файловый обмен** | выгрузка/загрузка JSON, CSV или XLS через сетевой каталог | резервный сценарий для устаревших конфигураций и офлайн-контуров |

> **Инициатором обмена всегда выступает 1С/ERP**, а не WMS: WMS отвечает на вызовы внешней системы.
> Учитывайте это при настройке сети — доступ нужен в направлении «1С → WMS», а не наоборот.

**Технические свойства обмена, важные для ИТ-службы**

- Сопоставление объектов идёт по идентификатору внешней системы (`externalId`), обмен **идемпотентен**:
  повторная отправка того же пакета не создаёт дублей документов.
- Поддерживается сценарий **нескольких баз 1С / нескольких юрлиц на один экземпляр WMS** — «склад ERP»
  из 1С сопоставляется с зоной топологии WMS, документы автоматически маршрутизируются.
- Ошибки обмена логируются с телом запроса и ответа — разбор расхождений не требует повторения ситуации.

**Что требуется от заказчика — Обязательно**

| Требование | Зачем |
|------------|-------|
| Согласие на установку модуля `WMS.INconnect` в базу 1С и окно для установки | модуль ставится в конфигурацию заказчика; при закрытой конфигурации потребуется снятие с поддержки или установка расширением |
| Сетевая доступность сервера 1С из сегмента WMS (или наоборот), открытый порт HTTPS | без связности обмен невозможен |
| Для обмена через `WMS.INconnect` публикация базы 1С **не требуется**: обмен инициирует 1С, модуль не публикует входящих веб-сервисов. Опубликованная база 1С (веб-сервер) либо согласованный файловый каталог нужны **только для иных вариантов интеграции** (файловый обмен, нетиповые сценарии) | точка подключения для иных вариантов интеграции |
| Отдельная учётная запись 1С для обмена, с правами только на нужные объекты | безопасность и разбор действий |
| **Тестовая (копийная) база 1С** | обмен отлаживается не на рабочей базе |
| Ответственный специалист по 1С на стороне заказчика или его подрядчика | согласование состава полей, доработки на стороне 1С |
| Согласованный регламент: перечень документов, состав полей, частота обмена | определяет объём работ и сроки |

**Нагрузка**: пакет на 1 000 строк — 1–5 МБ. Регламентный обмен раз в 5–15 минут не заметен на канале.
Для обмена «онлайн по событию» требуется RTT до сервера 1С **< 200 мс**.

### 11.2. Прочие интеграции

| Система | Направление | Требование к инфраструктуре | Уровень |
|---------|-------------|-----------------------------|---------|
| Внешние ERP (не 1С) | входящий REST/JSON | доступность по HTTPS, учётная запись | Опционально |
| Система управления двором (Yard) | двусторонний | сетевая связность с сервисом двора | Опционально |
| MobileSMARTS («Клеверенс») | исходящий от WMS | доступность сервера MobileSMARTS по HTTP | Опционально |

---

## 12. Печатное оборудование

**Обязательно**

| Позиция | Требование | Зачем |
|---------|-----------|-------|
| Принтеры этикеток | поддержка прямых команд **ZPL/EPL**, интерфейс Ethernet, статический IP, порт 9100 | сервер печатает напрямую и в фоне; принтеры «только по драйверу Windows» не подходят |
| Размещение | минимум по одному принтеру в зоне приёмки и в зоне отгрузки/комплектации | иначе кладовщик ходит за этикеткой через весь склад |
| Принтер документов | сетевой лазерный A4 | накладные, задания, акты |
| Расходники | термо- или термотрансферные этикетки под согласованный шаблон (обычно 58 или 100 мм) | ширина фиксируется на этапе обследования |

**Не рекомендуется:** принтеры этикеток, подключённые по USB к рабочей станции — из них нельзя печатать
серверными фоновыми заданиями (автопечать при закрытии тары, пакетная печать этикеток ячеек).

**Опционально:** печать через FTP-принт-сервер и печать ZPL по HTTP — поддерживаются, если такая схема уже
используется у заказчика.

Подходят Zebra, TSC, Honeywell, Godex, Proton и аналоги.

---

## 13. Электропитание и помещение

**Обязательно**

| Требование | Зачем |
|------------|-------|
| ИБП на серверы, коммутаторы ядра и PoE-коммутаторы точек доступа, ≥ 20 минут автономии | моргание питания при работающей базе — риск повреждения данных и потери смены |
| Корректное автоматическое завершение работы серверов по сигналу ИБП (USB/SNMP) | ИБП без автоотключения защищает только от коротких провалов |
| Закрываемое помещение с ограниченным доступом | |
| Температура 18–24 °C, контроль влажности, пылезащита | сервер в открытом шкафу на складе выходит из строя из-за пыли и перегрева |

**Рекомендуется:** отдельная питающая линия для серверного оборудования; учёт того, что при пропадании
питания на складе точки доступа гаснут раньше сервера — ТСД встанут первыми.

---

## 14. Резервное копирование и восстановление — **Обязательно**

| Параметр | Требование |
|----------|-----------|
| Полная копия базы | ежедневно |
| Журналы транзакций (WAL) | непрерывное архивирование |
| **RPO** (допустимая потеря данных) | ≤ 15 минут |
| **RTO** (время восстановления) | ≤ 4 часов |
| Место хранения | **вне сервера БД** — NAS, второй хост или защищённое хранилище |
| Глубина хранения | ≥ 14 ежедневных копий + 3 месячных |
| Объём под копии | 2–3 × размера базы |
| Проверка восстановления | **не реже раза в квартал, с фиксацией результата** |

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

---

## 15. Мониторинг и журналы — **Рекомендуется**

| Что контролировать | Порог оповещения |
|--------------------|------------------|
| Доступность сервера приложений и СУБД | недоступность > 1 минуты |
| Загрузка CPU | > 85 % дольше 10 минут |
| Свободное место на дисках | < 20 % |
| Рост объёма базы | аномальный прирост за сутки |
| Успешность резервного копирования | любая неуспешная задача |
| Ошибки в журналах приложения | появление критических записей |

Журналы приложения и СУБД хранить не менее 30 суток и предоставлять по запросу при обращении в поддержку —
без них разбор инцидента сводится к пересказу.

---

## 16. Безопасность и доступ поддержки

### 16.1. Защищённый туннель между инфраструктурами — **Обязательно**

Доступ поддержки Intekey организуется **не набором персональных подключений к отдельным серверам, а одним
защищённым туннелем между инфраструктурой заказчика и инфраструктурой Intekey**. Поддерживаемые технологии
(выбирается любая из перечисленных — по стандартам ИБ заказчика и возможностям его оборудования):

| Технология | Комментарий |
|-----------|-------------|
| **OpenVPN** | вариант по умолчанию: не требует «белого» IP с обеих сторон при наличии концентратора, работает поверх любого канала |
| **GRE** (в связке с IPsec) | если у заказчика маршрутизаторы с поддержкой GRE и требуется маршрутизируемая связность подсетей |
| **L2TP** (в связке с IPsec) | если это штатный, уже согласованный службой ИБ заказчика механизм |
| IPsec / WireGuard | допустимы как эквивалентная замена |

**Что это даёт заказчику с точки зрения информационной безопасности:**

- **ни один сервис WMS не публикуется в интернет** — ни SSH, ни веб-клиент, ни порт СУБД: весь трафик
  поддержки идёт внутри туннеля, снаружи не видно ни одного открытого порта;
- **трафик шифруется на всём протяжении** между площадками, включая выкладку обновлений и передачу логов;
- **доступ ограничен точками входа** — туннель терминируется на согласованных адресах и маршрутизируется
  только в подсети WMS (PROD и TEST), а не во всю сеть заказчика;
- **доступ управляем и отзываем** — отключение туннеля одним действием прекращает весь доступ Intekey,
  без ревизии учётных записей на каждом сервере;
- **весь доступ журналируется** на стороне концентратора и доступен для аудита службе ИБ заказчика.

Туннель поднимается совместно на этапе подготовки площадки и проверяется с обеих сторон **до** начала
опытной эксплуатации.

### 16.2. Доступ для Intekey Deployer — **Обязательно**

| Требование | Зачем |
|------------|-------|
| Доступ (SSH внутри туннеля) к **обоим контурам** — PROD и TEST (§3.1) | поставка обновлений выполняется инструментом Intekey Deployer по маршруту TEST → проверка → PROD; без доступа к обоим контурам регламент не выполняется |
| Сервисная учётная запись для развёртывания с правами на каталоги приложения и перезапуск сервисов WMS | Deployer работает от отдельной учётной записи, а не от root и не от учётных записей администраторов заказчика |
| Исходящий доступ с серверов WMS к репозиторию поставки Intekey — **или** доставка пакетов через туннель | пакет обновления должен попасть на площадку; при полностью закрытом контуре используется вариант с туннелем |
| Согласованное окно обновления PROD | остановка сервиса приложений на время выкладки — минуты |

**Что это даёт заказчику:** обновления ставятся быстро и одинаково на всех площадках, версия на PROD
совпадает с принятой на TEST, откат на предыдущую версию выполняется штатной командой. Ручные выкладки
(копирование архивов, правка конфигов «руками») исключаются — вместе с человеческим фактором в них.

### 16.3. Прочие требования безопасности — **Обязательно**

| Требование | Зачем |
|------------|-------|
| Смена паролей, установленных по умолчанию (СУБД, ОС, точки доступа, принтеры) | |
| Персональные учётные записи администраторов | разбор действий |
| Порт СУБД недоступен из офисной сети и из интернета | |
| Исключения антивируса для каталогов PostgreSQL и сервера приложений | сканирование файлов базы «на лету» снижает производительность дисковой подсистемы в разы |

**Рекомендуется:** HTTPS с сертификатом заказчика (или Let's Encrypt при наличии белого IP) для веб-доступа;
интеграция аутентификации с Active Directory при наличии такого требования безопасности.

---

## 17. Последствия невыполнения требований

| Если не выполнено | Что увидит заказчик |
|-------------------|---------------------|
| Провалы Wi-Fi в проходах | «WMS тормозит и вылетает»; повторные сканирования; расхождения в остатках; падение выработки на 20–40 % |
| HDD или СХД без гарантии IOPS под базой | расчёт заданий на подбор/размещение занимает минуты; очередь на выдачу заданий |
| Недостаточно RAM | своп, эпизодические «замирания» интерфейса у всех пользователей одновременно |
| Разные подсети / несколько SSID на складе | обрывы сессии при каждом переходе между зонами |
| Нет ИБП | некорректная остановка СУБД, риск повреждения базы, потеря результатов смены |
| Нет проверенного бэкапа | восстановление учёта остатков невозможно; инвентаризация всего склада |
| Нет защищённого туннеля и удалённого доступа | инцидент разбирается «по переписке», срок устранения растёт кратно; обновления невозможно поставить штатным способом |
| Нет выделенного TEST-контура | штатная поставка обновлений через Intekey Deployer невозможна: выкладка и разбор инцидентов ведутся прямо на продуктивной базе, сроки по SLA не гарантируются |
| USB-принтеры этикеток | не работает автоматическая и пакетная печать |
| Нет тестовой базы 1С | отладка обмена ведётся на рабочей базе — риск для учёта заказчика |

---

## 18. Чек-лист готовности площадки

Заполняется совместно до начала опытной эксплуатации.

**Серверы и ПО**
- [ ] Выделены две среды: PROD и TEST (§3.1), в каждой сервер приложений и сервер БД (допустимо совмещение, §3.4), обе переданы под управление проекта
- [ ] TEST соответствует §3.1, изолирован от PROD и подключён к тестовой базе 1С
- [ ] Сервер приложений PROD соответствует §3.2 (типоразмер: ____)
- [ ] Сервер БД соответствует §3.3, диск NVMe/SSD с подтверждёнными IOPS
- [ ] Установлена поддерживаемая ОС (§4), PostgreSQL 14–16
- [ ] NTP настроен на серверах WMS и смежных систем, часовой пояс единый

**Сеть**
- [ ] Гигабит между сервером приложений и БД, RTT < 1 мс
- [ ] Выделены VLAN для серверов и для ТСД
- [ ] Порты из §8 открыты и проверены
- [ ] Проведено радиообследование **на заполненном складе**, отчёт передан
- [ ] Уровень сигнала ≥ −67 dBm во всех рабочих зонах, единый SSID и подсеть, роуминг 802.11r

**Каналы и доступы**
- [ ] Основной интернет-канал по §10.3, белый IP или VPN-концентратор
- [ ] Резервный канал (обязателен для M/L и при облачной 1С)
- [ ] Поднят защищённый туннель между инфраструктурами (OpenVPN / GRE / L2TP, §16.1), проверен с обеих сторон
- [ ] Предоставлен доступ Intekey Deployer к обоим контурам — PROD и TEST (§16.2)
- [ ] Согласовано окно обновления PROD и регламент проверки версии на TEST

**Оборудование склада**
- [ ] ТСД закуплены по §6, включая резервный фонд 10–15 %
- [ ] Принтеры этикеток сетевые, ZPL/EPL, статические IP, тестовая печать выполнена
- [ ] АРМ соответствуют §5, разрешение ≥ 1920×1080

**Эксплуатация**
- [ ] ИБП установлен, автоотключение серверов проверено
- [ ] Настроено резервное копирование, **выполнено тестовое восстановление**
- [ ] Настроен мониторинг и оповещения
- [ ] Назначены ответственные: ИТ-администратор, ответственный по 1С, руководитель склада

**Интеграция с 1С** (если применимо)
- [ ] Определён вариант обмена (§11.1) и регламент: документы, поля, частота
- [ ] Согласована установка модуля `WMS.INconnect`, проверена совместимость с конфигурацией
- [ ] Только для иных вариантов интеграции (не `WMS.INconnect`): база 1С опубликована / согласован каталог обмена
- [ ] Заведена учётная запись обмена
- [ ] Предоставлена тестовая база 1С

---

## 19. Разделение ответственности

| Зона | Заказчик | Intekey |
|------|----------|---------|
| Закупка серверов, ТСД, принтеров, сетевого оборудования | ✔ | консультирует по спецификации |
| Монтаж и настройка Wi-Fi, радиообследование | ✔ | формулирует требования, проверяет результат |
| Каналы связи, белый IP, VPN-концентратор | ✔ | — |
| Выделение двух сред (PROD и TEST) и предоставление доступа к ним | ✔ | формулирует требования (§3.1), принимает результат |
| Организация защищённого туннеля между инфраструктурами (GRE / OpenVPN / L2TP) | ✔ на своей стороне | ✔ на своей стороне, согласует параметры (§16.1) |
| Поставка обновлений на TEST и PROD через Intekey Deployer | предоставляет доступ и окно обновления | ✔ |
| Проверка обновления на TEST перед выкаткой на PROD | участвует | ✔ выполняет |
| Установка и настройка ОС и PostgreSQL | ✔ (или по отдельному соглашению) | ✔ методически |
| Установка и настройка INTEKEY WMS | — | ✔ |
| Резервное копирование, мониторинг, ИБП | ✔ | ✔ задаёт регламент |
| Модуль `WMS.INconnect` в базе 1С | предоставляет доступ и окно для установки | ✔ поставляет, устанавливает, настраивает |
| Доработки конфигурации 1С сверх модуля | ✔ (силами своего 1С-подрядчика) | ✔ описывает контракт обмена |
| Настройка обмена на стороне WMS | — | ✔ |
| Обучение пользователей, сопровождение запуска | участвует | ✔ |

---

*Документ подготовлен для передачи заказчику. Конкретные значения по типоразмеру фиксируются в приложении
к договору по результатам предпроектного обследования.*

*Симонов Михаил, CTO, Intekey — 25 августа 2026 г.*