Как превратили МойСклад в систему управления сериями, сроками годности, складами и бухгалтерским обменом

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

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

Кроме того, серийный учёт влиял на бухгалтерский обмен. Данные, которые корректно хранились в МойСклад, не всегда можно было без подготовки передать в 1С.

Поэтому проект развивали не как набор отдельных доработок, а как систему взаимосвязанных механизмов. Общая задача была простой: сделать так, чтобы МойСклад сам применял правила компании в момент обработки заказа, перемещения, отгрузки, приёмки и подготовки отчётности.

Что требовалось построить
Все задачи разделили на несколько крупных контуров:

• автоматический подбор товара по сериям и срокам годности;
• работа одной логики в двух аккаунтах МойСклад;
• перемещения между складами с учётом доступности товара и неснижаемого остатка;
• автоматизация связанных складских и платёжных документов;
• подготовка данных МойСклад для бухгалтерского контура и 1С;
• прикладные доработки цен, печатных форм, контрагентов и отчётов.

Центром всех этих механизмов оставался МойСклад. Внешние сервисы использовались только там, где требовалось выполнить действие через API, обработать загружаемый файл или подготовить данные для другой системы.

Автоматический подбор серий и сроков годности
Одной из ключевых доработок стал автоматический подбор состава заказа.
Когда заказ создаётся в МойСклад, сервис проверяет доступные остатки и при необходимости заменяет позиции на нужные серийные варианты.

Для первого аккаунта задали следующую последовательность:

• сначала используются товары без серии;
• пока на складе есть серийные остатки, одна бессерийная единица сохраняется как неснижаемый остаток;
• если бессерийного товара не хватает, недостающее количество подбирается из серий с минимальным сроком годности;
• когда серийные остатки заканчиваются, ограничение на последнюю бессерийную единицу снимается;
• после успешной проверки заказ переводится в статус «Укомплектован».

Та же логика применяется к заказам, которые приходят из интернет-магазина в статусе ожидания.
Сервис проверяет наличие серийных остатков и, если товара достаточно, формирует корректный состав заказа. Если подходящих остатков нет, заказ остаётся в исходном статусе.

То есть система не создаёт видимость готовности там, где фактически не хватает нужного товара.
Во втором аккаунте менеджеры создают заказы вручную. Здесь действует тот же принцип ротации, но проверка учитывает несколько складов.

В рамках конкретного заказа сначала выбирается один итоговый склад, после чего сервис подбирает позиции с учётом доступных на нём серий и сроков годности.

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

Контроль критических сроков
Автоматический подбор помогает правильно расходовать остатки, но компании также важно заранее видеть товар, срок годности которого приближается к критическому значению.
Для обоих аккаунтов настроили регулярные уведомления. В письмо попадают позиции, у которых до окончания срока годности осталось не более шести месяцев.

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

Дополнительно предусмотрели архивирование неактуальных серий с нулевым остатком. Это помогает не перегружать текущую работу устаревшими карточками и при этом сохранять порядок в серийном учёте.
В итоге МойСклад не просто фиксирует срок годности как характеристику партии, а участвует в управлении товаром: подсказывает, какие остатки требуют внимания, и помогает использовать их в предусмотренной бизнесом последовательности.

Автоперемещения и работа нескольких складов
Отдельный блок доработок связан со складами.
Для продаж через Ozon использовались выделенные юридическое лицо и склад. Заказы площадки должны были обрабатываться через этот склад, но нужного количества товара на нём могло не оказаться.
Мы реализовали автоматическое перемещение недостающих позиций с основного склада.

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

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

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

Благодаря этому склад в МойСклад выбирается не произвольно, а по правилам операционной модели компании.

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

Для определённых контрагентов при создании отгрузки сервис автоматически создаёт связанную приёмку.
В неё переносятся организация, контрагент, проект, валюта, склад, договор, комментарий и товарные позиции. Вместе с позициями передаются количество, цена, НДС, скидка, вес, объём, себестоимость, страна, ГТД, РНПТ и сведения, связанные с партийным учётом.

Входящий номер приёмки формируется на основе номера и даты отгрузки, а владелец документа наследуется от отгрузки.

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

Для операций маркетплейсов сделали отдельный обработчик отчётов.
Пользователь загружает таблицу на внешней странице, после чего сервис находит в МойСклад заказ по номеру продавца и связанную с ним отгрузку.

Входящий платёж создаётся на сумму самой отгрузки, затем документ проводится и получает статус оплаты.
При этом значения из сторонней колонки задолженности не используются — источником суммы остаётся документ МойСклад.

Подготовка данных для 1С
Серийный учёт создавал отдельную сложность при передаче отчёта комиссионера в 1С.
В МойСклад позиции могли быть привязаны к сериям, тогда как в бухгалтерской системе соответствующая номенклатура велась без них. При обычном импорте бухгалтеру пришлось бы исправлять строки вручную.
Мы скорректировали формирование отчёта.

Если исходная позиция в МойСклад является серийной, в выгружаемый файл подставляется соответствующий бессерийный товар. При этом количество и стоимость сохраняются.
Таким образом, данные адаптируются под требования 1С без изменения самого серийного учёта в МойСклад.
В другом сценарии отчёт комиссионера из МойСклад преобразуется из XLS в XML, пригодный для импорта в 1С.

Здесь МойСклад остаётся источником операционных данных, а внешний обработчик переводит их в формат, необходимый бухгалтерскому контуру.

Дополнительные прикладные доработки
По мере развития системы появились и более компактные автоматизации:

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

Эти решения не являются отдельным центром проекта. Их ценность в другом: они дополняют основную модель и убирают повторяющиеся действия именно там, где стандартных возможностей МойСклад недостаточно для процессов компании.

Что получил бизнес
В результате на базе МойСклад сформировали глубокий товарно-складской контур, который учитывает специфику продукции и реальную структуру бизнеса.

Система теперь помогает:

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

Главный итог проекта — стандартный МойСклад расширили под отраслевую модель компании, не перенося товарное ядро в другую систему.

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

Кейс проекта «СТЭЙНОУ» наглядно показывает, как МойСклад можно адаптировать под сложную товарную модель, когда стандартного учёта уже недостаточно. Вместо ручного контроля серий, остатков, перемещений и подготовки данных для 1С компания получила систему, которая сама применяет заданные правила в ключевых операциях.