Скачать документ

Приложение №1

к Лицензионному договору

на использование программного обеспечения Mobile SMARTS

 на условиях акцепта оферты

(далее также - Договор)

по Счету №___________

Лицензия: [Код лицензии, напр. MS-WH15-MOVE-LC-008]

Операция/Функция: [Название модуля/функции, напр. "Перемещение по ячейкам"]

Для Системы: [Название базового продукта, напр. Mobile SMARTS Склад 15]

Лицензиат: [Название компании Лицензиата]

Версия: 1.0

Дата: [Дата создания]

Настоящий документ определяет порядок и условия некоторых Тарифов Лицензии, в соответствии с которым осуществляется кастомизация (адаптация и/или модификация (доработка)) Программного обеспечения за счет использования функционального назначения с целью обеспечить возможность использования Программного обеспечения Лицензиатом.

Все термины и определения, использованные в настоящем Приложении, применяются в том значении, в каком они определены в Договоре, если прямо не установлено иное.

Введение

1.1. Цель документа: Четко определить только те изменения и дополнения в функционале, которые будут реализованы в рамках Лицензии на кастомизацию для Лицензиата.

1.2. Область действия Кастомизации:

• Конкретные бизнес-процессы Лицензиата, под которые адаптируется функционал: [Кратко опишите 1-3 ключевых процесса, напр.: "Перемещение товаров между ячейками зоны хранения по запросу отдела комплектации", "Корректировка остатков при обнаружении расхождений в зоне временного хранения"].

• Что БУДЕТ изменено/добавлено в типовом функционале: Перечислено в Разделе 3.

1.3. Контекст и Связи:

• Интегрируемые системы Лицензиата: [Список систем, с которыми ДОЛЖЕН взаимодействовать, напр.: 1C:УТ 11.4, WMS Oracle, внутренняя система учета тары].

• Используемое оборудование Лицензиата: [Типы ТСД/смартфонов, сканеров, принтеров этикеток, напр.: Zebra TC52, Honeywell EDA51, интерфейс SPP].

1. Текущая Ситуация и Цели Кастомизации

2.1. Описание "Боли" / Недостатка Функционала: [Кратко (1-3 предложения) опишите, как сейчас происходит работа на объекте автоматизации "как есть", напр.: "Процесс перемещения не учитывает необходимость подтверждения веса тары при перемещении групп товаров на паллетах", "Нет возможности указать причину перемещения для внутреннего учета и анализа"].

2.2. Бизнес-Цели Кастомизации: Какие конкретные бизнес-проблемы должна решить эта адаптация?

• Цель 1: [Напр.: Повысить точность учета перемещаемых товаров за счет [конкретный механизм]].

• Цель 2: [Напр.: Сократить время выполнения операции "Перемещение" на X% за счет [конкретный механизм]].

• Цель 3: [Напр.: Обеспечить бесшовную передачу данных о перемещениях в систему [Название системы] без ручного ввода].

.3. Ожидаемый Бизнес-Эффект: [Какие измеримые улучшения ожидаются после внедрения кастомизации? Напр.: "Снижение ошибок при перемещении на 15%", "Уменьшение времени оформления перемещения на 30 секунд на операцию"].

2. Реестр функционала

Только изменения в рамках Лицензии. Каждое — конкретное и проверяемое.

3. Алгоритм действия функционала

Как теперь работает процесс с учётом изменений. Только ключевые шаги!

Бизнес-Процесс 1: Автоматическая проверка доступности ТМЦ при создании Отгрузки

• Суть: Система автоматически и в реальном времени проверяет физическую возможность отгрузить именно те товары, в именно том количестве и с именно того склада, которые указаны в заказе клиента, перед тем как отгрузка будет создана и зафиксирована в системе.
• Сценарий работы:

1. Триггер: Пользователь (менеджер по продажам, логист) инициирует создание документа "Отгрузка товара" на основании "Заказа клиента" в системе.
2. Автоматическая проверка: Система автоматически запускает проверку для каждой позиции в заказе:

• Доступен ли требуемый товар на указанном складе?
• Достаточно ли свободного остатка (учитывая уже существующие резервы под другие отгрузки)?
• Соответствует ли качество товара требованиям (не заблокирован ли он, не находится ли на карантине, не просрочен)?

3. Оценка результата:

• Если ВСЕ позиции доступны: Система создает документ "Отгрузка товара", автоматически резервирует товар под эту отгрузку, переводит статус отгрузки в "Готово к комплектации" или аналогичный. Пользователь получает уведомление об успешном создании.
• Если ОДНА ИЛИ БОЛЕЕ позиций НЕДОСТУПНЫ: Система НЕ СОЗДАЕТ документ "Отгрузка товара". Вместо этого:

• Формируется отчет/список проблемных позиций с указанием причины (недостаток, резерв, блокировка и т.д.).
• Автоматически отправляется уведомление (email, системное оповещение) ответственному пользователю (менеджеру заказа, логисту склада) с этим отчетом.
• Статус заказа клиента может быть изменен на "Требует согласования" или "Проблема с наличием".

4. Действия пользователя (при проблеме): Получив уведомление, пользователь анализирует проблему: ищет товар на другом складе, согласовывает замену с клиентом, уточняет сроки пополнения остатков и т.д. Только после устранения проблемы создание отгрузки повторяется.

Бизнес-Процесс 2: Обязательная фотофиксация состояния товара и пломб при погрузке

• Суть: В момент передачи груза перевозчику выполняется обязательная цифровая фиксация (фото/видео) состояния товара, упаковки и пломб транспортного средства, привязанная непосредственно к документу отгрузки. Без этого этап погрузки не может быть завершен.
• Сценарий работы:

1. Триггер: Этап отгрузки "Погрузка на транспортное средство" завершен физически (двери фургона/контейнера закрыты, пломбы установлены).
2. Обязательное действие: Сотрудник склада (кладовщик, ответственный за погрузку) или водитель перевозчика (в зависимости от политики) обязан использовать мобильное приложение компании или терминал сбора данных, интегрированный с системой управления складом (WMS/ERP):

• Открывает задание "Фотоотчет по отгрузке [Номер]" в приложении.
• Делает серию фотографий согласно заданному шаблону (например):

• Общий вид загруженного товара в кузове (с разных ракурсов).
• Крупный план упаковки 1-2 ключевых/ценных позиций (если применимо).
• Крупный план установленных пломб на дверях ТС с четко видимыми номерами.
• Фото документа (ТТН/CMR), если он уже подписан.

• Приложение автоматически привязывает фото к документу отгрузки, геолокацию и временную метку.

3. Валидация системой:

• Система проверяет, что сделаны фото всех требуемых типов (общий вид, пломбы).
• Если фото сделаны и соответствуют требованиям: Система позволяет закрыть этап "Погрузка". Статус отгрузки меняется на "Погружено/Готово к отправке". Фото сохраняются в карточке отгрузки.
• Если фото не сделаны, не того типа или плохого качества: Система НЕ ПОЗВОЛЯЕТ закрыть этап. Пользователь получает предупреждение с указанием, что именно нужно переделать/доснять.

4. Доступность: Загруженные фото становятся частью документальной базы по отгрузке и доступны для просмотра менеджерам, клиентскому сервису и руководству в случае возникновения претензий по качеству или комплектности при получении.

Бизнес-Процесс 3: Интеграция с API транспортных компаний для автоматического создания заявок и трекинга

• Суть: Система автоматически передает все необходимые данные о готовой к отправке отгрузке в систему выбранного перевозчика через его API, создает заявку на перевозку и получает обратно трек-номер для отслеживания, исключая ручной ввод данных.
• Сценарий работы:

1. Триггер: Отгрузка переведена в статус "Погружено/Готово к отправке" (после успешной фотофиксации или иного подтверждения) и в ее реквизитах указан выбранный перевозчик (TК).
2. Автоматическая передача данных: Система автоматически формирует запрос к API выбранной ТК:

• Собирает все необходимые данные из отгрузки и связанного заказа: адреса отправителя/получателя, контакты, список товаров (описание, кол-во, вес, объем, коды), номер отгрузки, реквизиты документов, данные по страхованию (если есть).
• Отправляет структурированный запрос (обычно в формате JSON/XML) через защищенное соединение в систему перевозчика.

3. Обработка ТК и получение трек-номера:

• Система перевозчика принимает запрос, валидирует данные, создает внутреннюю заявку/накладную.
• В ответе API перевозчик возвращает уникальный идентификатор заявки (AWB, накладной) и трек-номер для отслеживания.

4. Автоматическое обновление отгрузки:

• Система Лицензиата автоматически получает ответ от API ТК.
• Записывает полученный трек-номер и идентификатор заявки в соответствующие поля документа "Отгрузка товара".
• Переводит статус отгрузки в "В пути" или "Передано перевозчику".

5. Автоматическое информирование клиента: Система автоматически генерирует и отправляет сообщение (email, SMS) клиенту с информацией о том, что заказ передан перевозчику, и включает в него полученный трек-номер и ссылку (если есть) для отслеживания на сайте ТК.

Бизнес-Процесс 4: Автоматическое управление статусами Отгрузки на основе событий (датчики, сканеры)

• Суть: Ключевые статусы отгрузки изменяются автоматически системой в реальном времени при регистрации физических событий с помощью IoT-устройств (датчики, сканеры штрихкодов), а не вручную пользователем.
• Сценарий работы:

1. Этап "Комплектация":

• Событие: Сотрудник склада сканирует штрихкод товарной единицы (коробки, паллеты) сканером, подключенным к WMS.
• Автоматическое действие системы:

• Проверяет, относится ли этот товар к текущей отгрузке.
• Если да - автоматически отмечает позицию как "Отобранная" в задании на комплектацию.
• Когда сканируется последняя позиция из списка на комплектацию для данной отгрузки, система автоматически переводит статус отгрузки в "Скомплектовано" или "Готово к погрузке".

2. Этап "Погрузка":

• Событие 1 (Вариант А): Сканирование последней товарной единицы на погрузочной рампе специальным сканером.
• Событие 1 (Вариант Б): Срабатывание датчика веса на погрузочной рампе, фиксирующее, что вес груза соответствует ожидаемому весу отгрузки, и последующие 30 секунд не было движения (условно - двери закрылись).
• Автоматическое действие системы: При регистрации любого из этих событий система автоматически переводит статус отгрузки в "Погружено".

3. Этап "Отправка":

• Событие: Водитель сканирует QR-код или штрихкод на бумажной копии Товарно-транспортной накладной (ТТН) при выезде со склада с помощью мобильного приложения или терминала ворот.
• Автоматическое действие системы: Система автоматически:

• Распознает отгрузку по коду ТТН.
• Фиксирует точное время сканирования как время отправки.
• Переводит статус отгрузки в "В пути" или "Отправлено".
• Запускает процесс информирования клиента (если интегрировано с процессом 3).

Бизнес-Процесс 5: Система превентивного оповещения о возможных задержках отгрузки

• Суть: Система постоянно отслеживает прогресс подготовки отгрузок и автоматически генерирует предупреждения для ответственных лиц и/или клиентов до наступления планового времени отгрузки, если обнаруживает риски срыва сроков.
• Сценарий работы:

1. Постоянный мониторинг: Система в фоновом режиме отслеживает все отгрузки в статусах, предшествующих "Отгружено" (например, "К отгрузке", "В комплектации", "На оформлении").
2. Триггер для проверки: За определенный, настраиваемый интервал времени до плановой даты/времени отгрузки (например, за 2 часа) система запускает проверку для каждой такой отгрузки.
3. Проверка условий риска: Система проверяет наличие "красных флагов":

• Не все требуемые этапы подготовки завершены (товар не зарезервирован/не скомплектован, документы не подписаны, ТТН не сформирована, фотоотчет не загружен).
• Есть системные предупреждения, связанные с отгрузкой (нехватка упаковочных материалов на складе, отсутствие водителя/машины по графику, сбой в работе оборудования).
• Прогнозируемое время на завершение оставшихся этапов превышает оставшееся до плановой отгрузки время.

4. Генерация и отправка оповещений:

• Если риск обнаружен: Система автоматически генерирует и отправляет оповещения:

• Внутреннее: Ответственному менеджеру заказа, логисту склада, диспетчеру (через email, SMS, чат-бот, системные алерты). Сообщение содержит: номер отгрузки/заказа, плановое время, список невыполненных этапов/проблем, степень риска.
• Внешнее (опционально, по настройкам договора): Клиенту (через email, SMS). Сообщение содержит вежливое уведомление о потенциальной задержке, ее причине (в общих чертах, например, "задержка в оформлении документов", "дополнительная проверка качества") и ориентировочный новый срок (если его можно оценить) или обещание оперативной информации. Важно: Внешние оповещения обычно требуют настройки правил (для каких клиентов/типов заказов отправлять) и шаблонов сообщений.

5. Действия пользователя: Получив внутреннее оповещение, ответственный сотрудник оперативно вмешивается: ускоряет процесс, решает возникшую проблему (находит упаковку, звонит перевозчику, подталкивает подписание документов), пересчитывает сроки и при необходимости обновляет информацию у клиента.

4. Ограничения

5.1. Требования к серверному оборудованию

5.2. Требования к сетевой инфраструктуре

Лицензиат обязуется обеспечить:
- Доступ к среде тестирования и среде разработки для Лицензиара не ниже уровня локального Администратора. Предпочтительный доступ RDP.
- Доступность портов:
  • 9000
  • 10503 на целевом сервере
- Для тестирования ТСД, требуется предоставить VPN доступ к среде разработки и тестирования или обеспечить доступность вышеуказанных портов из internet.
- Качество сетевого соединения:
                    ТСД ↔ Сервер (онлайн режим):
  • Показатель потери пакетов: не более 1% (тест пакетами 512 байт)
  • Пропускная способность канала связи: ≥100 Мбит/с
  • Стабильность соединения: потери пакетов ≤1%

                    Сервер Mobile SMARTS ↔ Учетная система:
  • Показатель потери пакетов: не более 1% (тест пакетами 512 байт)
  • Пропускная способность канала связи: ≥100 Мбит/с
  • Стабильность соединения: потери пакетов ≤1%

5.3. Ограничения по обработке документов

- Суммарное количество типовых документов для 1 типового сервера: ≤2000 единиц
- Максимальное количество строк: 500
- Отсутствие фотографических материалов
- Максимальный объем: 3,5 МБ
- Лимит одновременных пользователей в коллективном документе: 5 человек

5.4. Ограничения информационной системы

- Номенклатурный справочник: до 500 000 позиций
- Учет остатков: до 500 000 строк
- Время выгрузки справочника номенклатуры объемом 1 000 000 позиций: ≤2 часа
- Ограничение по времени обновления справочников: должно завершиться до начала рабочего дня объекта автоматизации
- ТСД на один сервер: максимум 50 единиц
- Базы МС на одной виртуальной машине: не более 3
- Общее количество пользователей в системе: до 10 000
- В режиме офлайн работы обновление справочников: не чаще 1 раза в сутки
- При обновлении номенклатуры и справочников объемом более 500 000 строк, единовременные изменения не должны затрагивать более 30% записей

5.5. Требования к производительности учетной системы

- Время отклика: ≤60 секунд на запрос. Включает суммарное время выполнения всех запросов в рамках одного действия на ТСД
- Параллельная обработка: ≥10 одновременных запросов на эндпоинт
- Пропускная способность: до 500 запросов/минуту

5.6. Обеспечение

Лицензиат обеспечивает:
- Доступ к серверной инфраструктуре
- Сетевую доступность
- Доступ к (Учетная система, УКЭП для работы с Честный ЗНАК, прочие)
- Информационная безопасность:
  • Резервное копирование данных
  • Ведение журнала действий
  • Мониторинг сервера

4.2. Ограничение ответственности Лицензиара

- Функционирование ТСД:
  • Состояние устройств
  • Сетевое подключение
  • Сканирующий модуль
- Работа печатающих устройств:
  • Сетевая доступность
  • Расходные материалы
  • Bluetooth-подключение
Исполнитель не несет ответственности за:
- "Меркурий"
- Честный ЗНАК
- ЕГАИС

Календарный план

Лицензиат ознакомился полностью с текстом Функциональных требований, его положения ему понятны и полностью соответствуют потребностям Лицензиара.

Лицензиар понимает и соглашается, что изменения в настоящий текст Функциональных требований могут повлечь изменения условий (Тарифа) Лицензии, то есть дополнительной оплаты.