От заказа клиента до закупки комплектующих: как правильно считать потребность по ресурсным спецификациям

В производственной компании нередко возникает вполне практический вопрос: можно ли взять несколько Заказов клиента, определить по ресурсным спецификациям все необходимые материалы, учесть то, что уже лежит на складе, и сразу получить перечень недостающих комплектующих для закупки?

На первый взгляд задача выглядит простой. Из Заказа клиента берем готовую продукцию, находим ресурсную спецификацию, умножаем нормы материалов на количество изделий, вычитаем остатки и формируем Заказы поставщикам.

На небольшой демонстрационной базе такой алгоритм действительно может работать.

Но в реальной базе очень быстро появляются вопросы:

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

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

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

 

Сначала определим границу задачи

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

Поэтому нет смысла пытаться написать вторую полноценную систему обеспечения поверх типовой.

Но есть более узкая задача.

Предположим, производство работает под конкретные клиентские заказы. Заказы уже приняты, а производственные документы еще не созданы. Снабженцу необходимо заранее понять:

какие материалы понадобятся именно для выбранных Заказов клиента и чего из этого сейчас физически не хватает на складе?

В таком случае полезен предварительный расчет непосредственно от клиентского спроса:

Выбранные Заказы клиента
    ->
заказанная продукция
    ->
ресурсные спецификации
    ->
материалы и полуфабрикаты
    ->
общая материальная потребность
    ->
складской остаток
    ->
физический дефицит
    ->
источник закупки
    ->
Заказы поставщикам

Это не замена штатному обеспечению.

Это отдельный предварительный ответ на конкретный вопрос снабжения.

 

Возьмем простой мебельный пример

Пусть предприятие выпускает условную продукцию «Тумба с двумя ящиками Т-2».

В Заказе клиента указано:

Тумба с двумя ящиками Т-2 — 10 шт.

Но снабженцу сама тумба для закупки не нужна.

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

Тумба с двумя ящиками Т-2
|
+-- Корпус тумбы — 1 шт.
+-- Ящик в сборе — 2 шт.
+-- Опора мебельная — 4 шт.

Корпус тумбы и Ящик в сборе предприятие изготавливает самостоятельно.

У корпуса своя ресурсная спецификация:

Корпус тумбы
|
+-- ЛДСП 16 мм — 1,4 м2
+-- ХДФ 3 мм — 0,5 м2
+-- Кромка ПВХ 2 мм — 5 м
+-- Конфирмат — 12 шт.

У ящика своя:

Ящик в сборе
|
+-- ЛДСП 16 мм — 0,3 м2
+-- ХДФ 3 мм — 0,2 м2
+-- Направляющие 450 мм — 1 комплект
+-- Ручка мебельная — 1 шт.

Если заказано десять тумб, после полного раскрытия состава получаем:

 

Материал	Расчет	Общая потребность
ЛДСП 16 мм	10 × 1,4 + 20 × 0,3	20 м2
ХДФ 3 мм	10 × 0,5 + 20 × 0,2	9 м2
Кромка ПВХ 2 мм	10 × 5	50 м
Конфирмат	10 × 12	120 шт.
Направляющие 450 мм	20 × 1	20 комплектов
Ручка мебельная	20 × 1	20 шт.
Опора мебельная	10 × 4	40 шт.

 

Вот эта таблица уже значительно ближе к тому, что действительно интересует снабжение.

Но даже здесь мы пока еще не учитывали ни неоднозначные спецификации, ни остатки, ни способы обеспечения.

 

Не каждая строка «Материалов и работ» обязательно является покупным материалом

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

Поэтому алгоритм закупки не должен исходить из правила:

любая строка ресурсной спецификации = товар, который надо купить.

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

Для закупочного расчета необходимо сначала определить назначение строки.

Если это обычный покупной материал — он участвует в материальной потребности.

Если это производимый полуфабрикат — нужно раскрыть его состав.

Если строка не является складским материалом, нельзя без дополнительного правила отправлять ее в Заказ поставщику как обычную номенклатуру.

 

Главная ошибка при полуфабрикатах: остановиться на первом уровне

Вернемся к нашей тумбе.

Если читать только спецификацию готового изделия, можно получить:

Корпус тумбы — 10 шт.
Ящик в сборе — 20 шт.
Опора мебельная — 40 шт.

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

Но это неверно, если корпус и ящик производятся внутри предприятия.

Для них нужно открыть собственные ресурсные спецификации и продолжить расчет.

В итоге структура задачи становится многоуровневой:

Тумба
    -> Корпус тумбы
        -> ЛДСП
        -> ХДФ
        -> Кромка
        -> Крепеж

    -> Ящик в сборе
        -> ЛДСП
        -> ХДФ
        -> Направляющие
        -> Ручка

    -> Опоры

Причем уровней может быть больше двух.

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

Поэтому правильный расчет должен уметь раскрывать дерево до тех пор, пока не будут получены конечные материальные потребности.

 

При раскрытии состава обязательно нужна защита от циклов

В правильно настроенной нормативной информации изделие не должно в конечном итоге содержать само себя.

Но программный механизм не должен полагаться на идеальность данных.

Представим ошибочную цепочку:

Корпус А
    -> Заготовка Б

Заготовка Б
    -> Комплект В

Комплект В
    -> Корпус А

Без проверки уже пройденных узлов такой расчет будет раскрывать состав бесконечно.

Поэтому при каждом переходе необходимо помнить путь, по которому мы пришли к текущему изделию.

Если очередная спецификация возвращает нас в уже пройденный узел, эта ветка должна остановиться с понятной диагностикой.

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

 

«Найти основную спецификацию» сложнее, чем кажется

В исходной постановке задачи естественно звучит фраза:

«Для каждой строки продукции найти основную ресурсную спецификацию».

Но на реальной базе для одной номенклатуры может существовать несколько вариантов.

Например, для нашей тумбы могут быть заведены:

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

Поэтому правило «взять первую найденную» опасно.

Оно не решает неоднозначность — оно скрывает ее.

Надежнее разделять три ситуации:

 

Результат поиска	Действие
Подходящая спецификация не найдена	Показать проблему и не рассчитывать эту продукцию дальше
Однозначно определена одна спецификация	Использовать ее автоматически
Осталось несколько подходящих вариантов	Применить однозначное правило предприятия либо дать пользователю выбор

 

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

 

Количество материала нужно пересчитывать относительно количества выхода

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

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

Возьмем условный мебельный фасад.

Выход по спецификации:
5 фасадов

Кромка ПВХ:
12,5 м

Заказано 12 фасадов.

Неправильный расчет:

12 × 12,5 = 150 м

Потому что 12,5 метра относятся не к одному фасаду, а сразу к пяти.

Правильный расчет:

12 × 12,5 / 5 = 30 м

В общем виде:

потребность материала = количество требуемой продукции × норма материала / количество выхода по спецификации

Количество выхода поэтому является не вспомогательным реквизитом, а частью самого расчета.

 

Формульная норма — это не обычное число

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

Например, расход кромки может зависеть от размеров детали, а расход листового материала — от параметров изделия.

Если для количества используется расчетное правило, нельзя просто взять находящееся рядом числовое значение и считать его готовой нормой.

У надежного инструмента здесь два допустимых пути.

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

Второй: если конкретный вариант расчета пока не поддерживается, явно остановить строку и сообщить пользователю о причине.

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

 

Сначала нужно собрать общую потребность, и только потом смотреть остаток

Это одна из самых важных частей всей задачи.

Допустим, выбраны два Заказа клиента.

 

Источник	Потребность в ЛДСП 16 мм
Заказ клиента № 1	24 м2
Заказ клиента № 2	16 м2
Свободно на складе	25 м2

 

Если каждый заказ считать отдельно, получится:

Заказ № 1:
24 - 25 = 0

Заказ № 2:
16 - 25 = 0

Обработка сообщит, что закупка не требуется.

Но два заказа вместе требуют:

24 + 16 = 40 м2

Физически на складе находится только 25 м2.

Реальный дефицит:

40 - 25 = 15 м2

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

Поэтому последовательность должна быть такой:

детальные потребности -> объединение совместимых потребностей -> складской остаток -> дефицит

А не наоборот.

 

Но объединять все только по номенклатуре тоже нельзя

Предыдущий вывод легко довести до другой крайности: сложить вообще все строки одинаковой номенклатуры.

Это тоже может дать ошибку.

Материал может отличаться:

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

Например, ЛДСП одного декора и ЛДСП другого декора нельзя считать единым запасом только потому, что у них похожее назначение.

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

Поэтому объединять нужно не «одинаковые названия», а действительно совместимые потребности.

 

Потребность и физический складской запас — это не совсем один и тот же ключ

Здесь появляется еще один тонкий момент.

Допустим, один материал требуется под два разных назначения:

 

Потребность	Количество
Назначение А	18 м2
Назначение Б	17 м2
Общий свободный остаток	20 м2

 

Сами потребности могут оставаться раздельными.

Но если эти двадцать квадратных метров — один общий свободный физический запас, нельзя вычесть его полностью и из первой, и из второй строки.

Иначе снова получится:

18 - 20 = 0
17 - 20 = 0

хотя общая потребность составляет 35 м2, а свободно только 20.

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

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

Именно в этом месте особенно важно не выдавать простой расчет физического остатка за замену штатного механизма КА.

 

Что именно считать количеством из Заказа клиента

Есть еще один вопрос, который легко пропустить.

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

Но четыре уже были произведены либо потребность по ним уже зарегистрирована и обеспечена другим путем.

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

Поэтому до автоматизации нужно определить бизнес-правило:

мы рассчитываем материалы на исходное количество заказа или только на еще не обеспеченный остаток?

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

Но для универсального рабочего места это условие необходимо сделать явным.

Иначе одна и та же кнопка будет давать правильный результат для нового заказа и завышенный — для частично выполненного.

 

Остаток «сейчас» и обеспечение к будущей дате — разные вопросы

Предварительный расчет часто строится очень просто:

Потребность - физический остаток = дефицит

Для оперативной оценки это полезный показатель.

Но он отвечает только на вопрос:

сколько материала физически не хватает на выбранном складе в момент расчета?

Он не учитывает автоматически:

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

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

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

 

Поставщик из способа обеспечения — хорошая идея, но есть важное условие

В исходной задаче есть разумное требование: если для комплектующих уже настроены способы обеспечения, не заставлять пользователя вручную выбирать поставщика каждый раз.

Но способ обеспечения нельзя автоматически трактовать как «поставщик».

Источник обеспечения может означать различный способ получения номенклатуры.

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

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

А для другого материала источником обеспечения может оказаться другой склад предприятия. В этом случае превращать источник в контрагента Заказа поставщику было бы ошибкой.

Далее снова возможны три ситуации:

 

Настройка	Что делать
Однозначно определена закупка у одного поставщика	Предложить поставщика автоматически
Есть несколько допустимых вариантов закупки	Применить правило предприятия либо запросить выбор
Подходящий источник закупки не найден	Оставить строку на ручное решение, а не подставлять случайного контрагента

 

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

 

Не стоит автоматически подменять отсутствующий материал аналогом

На многих предприятиях существуют взаимозаменяемые материалы.

Например, одну модель направляющих можно заменить другой.

Но из самого факта наличия аналога не следует, что внешний закупочный расчет имеет право самостоятельно произвести замену.

Такая замена может влиять на:

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

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

 

Сначала расчет, потом запись документов

Даже если все предыдущие этапы выполнены правильно, не стоит сразу создавать Заказы поставщикам в момент нажатия кнопки «Рассчитать».

Чтение и изменение данных лучше разделить.

Рабочий сценарий может выглядеть так:

1. Выбрать Заказы клиента
2. Рассчитать потребность
3. Просмотреть состав и диагностические сообщения
4. Проверить дефицит и поставщиков
5. Отметить строки, которые действительно нужно закупать
6. Отдельно сформировать Заказы поставщикам

В результирующей таблице полезно показывать как минимум:

 

Поле	Зачем оно нужно
Материал	Что требуется
Характеристика	Какой именно вариант материала
Общая потребность	Сколько нужно по выбранным заказам
Учтенный остаток	Сколько снимается за счет склада
К закупке	Рассчитанный физический дефицит
Склад	Где возникла потребность
Поставщик	Кому предполагается сформировать заказ
Состояние	Можно ли строку использовать дальше или требуется решение пользователя

 

Так снабженец видит будущую закупку до того, как в базе появятся новые документы.

 

Заказы поставщикам безопаснее сначала создавать без проведения

Формирование Заказа поставщику уже изменяет информационную базу.

Проведение документа добавляет еще один уровень последствий: начинают работать типовые проверки и связанные механизмы конкретной базы.

Кроме того, в реальном внедрении могут присутствовать расширения, дополнительные обязательные реквизиты, собственные проверки и подписки на события.

Поэтому для тиражного внешнего инструмента разумное поведение по умолчанию:

сформировать и записать черновик Заказа поставщику, но не проводить его автоматически.

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

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

 

Одна ошибка не должна уничтожать результат по всем поставщикам

Предположим, после расчета нужно сформировать четыре Заказа поставщикам.

Три группы заполнены корректно.

В четвертой не определен необходимый реквизит.

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

Но эти закупки независимы.

Поэтому логичнее обрабатывать каждую группу отдельно:

Поставщик А
    -> попытка создания
    -> собственный результат

Поставщик Б
    -> попытка создания
    -> собственный результат

Поставщик В
    -> попытка создания
    -> собственный результат

Тогда одна проблемная группа не лишает пользователя результата по остальным.

 

Повторный запуск не должен создавать те же документы еще раз

Из предыдущего требования возникает следующая задача.

Допустим, три Заказа поставщикам создались, а четвертый нет.

Пользователь исправил исходные данные и повторил операцию.

Если механизм ничего не знает о предыдущем запуске, первые три документа будут сформированы еще раз.

Поэтому повторный запуск нужно проектировать с самого начала.

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

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

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

Для обычного рабочего места это можно отдельно ограничить организационно либо усилить техническую защиту.

Но сам повтор после частичной ошибки как минимум не должен штатно плодить одинаковые документы.

 

Почему не стоит смешивать поддержку разных релизов с самим расчетом

Если инструмент должен работать в нескольких версиях КА, внутреннее устройство объектов между релизами необходимо проверять отдельно.

Плохой путь — постепенно разнести по всему расчетному коду условия:

если одна версия ...
если другая версия ...
если реквизит называется так ...
иначе искать другой реквизит ...

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

Надежнее разделить:

расчетную часть, которая оперирует понятиями «заказ», «продукция», «спецификация», «материал», «остаток», «поставщик»;

и

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

Тогда изменение версии не требует переписывать саму математику потребности.

 

Номер релиза еще не доказывает совместимость

Для внешней обработки особенно важно различать два утверждения.

Первое: в конфигурации найдены необходимые объекты и реквизиты.

Второе: весь пользовательский сценарий реально выполнен на конкретном релизе.

Это не одно и то же.

Для второго утверждения необходимо фактически:

1. открыть обработку;
2. выбрать Заказы клиента;
3. получить продукцию;
4. определить ресурсные спецификации;
5. раскрыть хотя бы один многоуровневый состав;
6. получить складские остатки;
7. рассчитать дефицит;
8. определить источник закупки;
9. создать тестовый Заказ поставщику;
10. повторить операцию и убедиться, что лишний документ не появляется.

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

 

Что обязательно проверить на контрольных примерах

Одного случая «одна тумба, одна спецификация, пустой склад» явно недостаточно.

 

Сценарий	Ожидаемое поведение
У изделия одна однозначная спецификация	Расчет продолжается автоматически
Спецификация отсутствует	Пользователь получает понятное сообщение, закупка по этой строке не формируется
Найдено несколько допустимых спецификаций	Не выбирается случайная первая запись
Спецификация задана на несколько единиц выпуска	Норма пересчитывается относительно количества выхода
В составе есть производимый полуфабрикат	Раскрывается его собственная спецификация
В дереве появился цикл	Ветка прекращается с диагностическим сообщением
Количество материала задается расчетным правилом	Не используется случайное сохраненное число
Два заказа требуют один и тот же материал	Сначала объединяется потребность, затем один раз учитывается общий остаток
Материал одинаковый, но характеристики разные	Потребности не смешиваются
Материал требуется на разных складах	Остаток одного склада не уменьшает потребность другого автоматически
Источник обеспечения не является закупкой	Он не превращается в поставщика Заказа поставщику
Поставщик не определен	Система просит решение пользователя, а не выбирает случайного контрагента
Ошибка одной закупочной группы	Успешные независимые группы сохраняют свой результат
Повторный запуск после частичной ошибки	Ранее созданные документы не создаются повторно

 

Как выглядит правильная последовательность целиком

После всех уточнений первоначальная короткая схема становится такой:

Выбрать Заказы клиента
    ->
определить количество продукции, которое действительно нужно рассчитывать
    ->
найти подходящие ресурсные спецификации
    ->
остановить неоднозначные позиции
    ->
пересчитать нормы относительно количества выхода
    ->
раскрыть производимые полуфабрикаты
    ->
остановить циклические и неподдерживаемые расчетные ветки
    ->
получить детальную материальную потребность
    ->
объединить только совместимые потребности
    ->
получить физические остатки
    ->
не использовать один запас несколько раз
    ->
получить физический дефицит
    ->
определить именно закупочные источники обеспечения
    ->
показать результат пользователю
    ->
сформировать черновики Заказов поставщикам
    ->
защитить повторный запуск от дублей

На этой схеме хорошо видно, что непосредственное создание Заказа поставщику находится почти в самом конце.

Сам документ создать несложно.

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

 

Когда такой инструмент полезен, а когда лучше оставить штатное обеспечение

Предварительный расчет непосредственно от Заказов клиента особенно понятен, когда предприятие:

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

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

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

 

Итог

Фраза «создать Заказы поставщикам по Заказу клиента и ресурсным спецификациям» скрывает значительно больше условий, чем кажется при первом прочтении.

Надежный расчет должен как минимум:

1. не выбирать случайную ресурсную спецификацию;
2. правильно учитывать количество выхода;
3. раскрывать собственные полуфабрикаты до конечных материалов;
4. останавливать циклические составы;
5. не подменять расчетные нормы произвольными числами;
6. сначала собирать общую совместимую потребность и только затем учитывать склад;
7. не использовать один физический остаток несколько раз;
8. отличать простой физический дефицит от полноценного обеспечения;
9. не превращать любой способ обеспечения в закупку у поставщика;
10. не создавать документы до проверки результата пользователем;
11. безопасно переживать частичную ошибку и повторный запуск.

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

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

 

Продолжение: практическая обработка для КА 2.5 и 2.6

В следующей части цикла перейдем от модели к практической реализации.

Будет разобрана внешняя обработка для Комплексной автоматизации 2.5 и 2.6, которая должна пройти весь рассмотренный выше путь непосредственно от выбранных Заказов клиента:

Заказы клиента
    ->
ресурсные спецификации
    ->
многоуровневый состав
    ->
общая потребность материалов
    ->
физические остатки
    ->
дефицит
    ->
источники закупки
    ->
черновики Заказов поставщикам

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

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

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