"Сложность" понятие субъективное… мне например все понятно, и для чего и почему...

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

Чего делать не надо не в 1С?

Остатков, и аналогично делает программист...

Формирование движений и запись в регистр — разные вещи…
Если интересен пример формирования движений и проведения:
Методика оперативного проведения и управляемые блокировки https://1c.chistov.pro/2013/07/blog-post_25.html

heckNegative = DATA BOOLEAN (Stock);
allowNegative = DATA BOOLEAN (Customer);

CONSTRAINT CHANGED(quantity(SkuLedger l)) AND balance(stock(l), sku(l)) < 0 
           AND checkNegative(stock(l)) AND NOT allowNegative(customer(l))
    MESSAGE 'Остаток по товару на складе должен быть положительным';

А этот код кто будет писать, не программист ли часом? Какие преимущества описания ограничений в платформе, по сравнению с описанием ограничений в конкретной конфигурации?

Бизнес логика — она в любом случае есть, если не говорить про регистр типа "sku, count".
Проведение по регистрам в 1С:

Движения.ПартииТоваровНаСкладах.Записать();

или так:

Движения.ПартииТоваровНаСкладах.Записывать = Истина;

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

price 'Цена' (Stock st, Sku sk, DATETIME dt) = 
    GROUP LAST price(PriceLedger l)
          ORDER dateTime(l), l
          WHERE dateTime(l) <= dt
          BY stock(l), sku(l);

А это что, тоже называется "Декларативно"?
В 1С вообще -программист не реализовывает регистры… а как там реализовано по большому счету все равно.

Разговор немого с глухими…
Я описал недочёты(ошибки) в статье, которые кардинальным образом влияют на функционал.

Давайте напишем какая 1С говно — и на этом фоне прорекламируем себя?
Подавляющие большинство программистов будет кивать гривами(бородой), соглашаться и ставить плюсы.

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

Вы описали только периодический регистр сведений.

В индекс и в порядок добавляется сам регистр, так как, в отличие от 1С, в lsFusion могут быть записи с одинаковым временем.

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

Это цитата из их документации.

Ну вот пришли… считайте это недосмотром 1С, все совсем по другому… желательно было дать почитать любому программисту 1С

• Строка документа может порождать "много" записей в регистре остатков(оборотов) — например, списание по партиям при партионном учете
• Есть промежуточные итоги, а не только актуальные.

• Грубо говоря plain-таблица с периодом и без, с наличием итоговых записей начала и конца периода и без них.
• Если говорить о периодическом регистре с итогами: можно хранить не только последнюю "цену", но и другие данные...
• И да, в 1С можно вносить данные по всем измерениям в один период (секунду) — но только при наличии дополнительного упорядочивания по документу, так и называется "По позиции регистратора".

Статья маркетинговая фигня

p.s. слава богу в 1С нет ООП. Незачем ООП тащить в DSL — чем проще, тем лучше.

Вы точно предоставили вывод своего алгоритма?
Почему не {5,6,7,8,9,10},{4,3,2},{1} — так ведь более оптимально...

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

1. Вариант: стиль Савдэп — производим что угодно, лишь бы рабочий не стоял.
   В итоге склады перегружены, валяется старьё...
2. Производим по плану(прошлого года как пример), не взлетело — храним пока не сгниёт или не продастся.
3. Клиент отказался — храним
4. Кладовщики берут всегда свежий товар — работают по FILO, в таком случае старье всегда будет.

WMS решает только 4-ю проблему, для других как мертвому припарка — вроде все под контролем, но проблему со старыми остатками оно не решит.

Остальное должен разруливать отдел ПДО…

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

Специфика такова, что списание должно быть максимально по FIFO… например через 1 год — начинает исчезать надпись с этикетки, через 2 возможно изменение цвета краски, 3 проблемы со смазкой… и т.п. и т.д.
Отправить клиенту партию новых, а потом прислать старую; после такого выслушивается миллион претензий и рекламаций с требованиями о скидках.
Серийный номер явно не гравируется(лазером наносится), а значит старую продукцию можно относить в ремонт с новой этикеткой :) "поломалось на гарантии" — вы же нам шлете "старье"

3! Да верхней оценкой
Да простят меня пользователи Хабра за код. Можете тестировать до дыр =)

Функция Лог( Массив)
    Если Массив.Количество()>0 Тогда 
        Сообщить("Объединение партий");
        Для каждого флп_объеденить Из Массив Цикл
            Сообщить(Символы.Таб +  флп_объеденить);
        КонецЦикла;
        Сообщить("Конец объединение");
    КонецЕсли;
КонецФункции

Данные = Новый ТаблицаЗначений;
Данные.Колонки.Добавить("Дата");
Данные.Колонки.Добавить("Партия");

ЗаполнитьЗначенияСвойств(Данные.Добавить(), Новый Структура("Дата, Партия", Дата('20190101'), "1 партия"));
ЗаполнитьЗначенияСвойств(Данные.Добавить(), Новый Структура("Дата, Партия", Дата('20190130'), "2 партия"));
ЗаполнитьЗначенияСвойств(Данные.Добавить(), Новый Структура("Дата, Партия", Дата('20190201'), "3 партия"));
ЗаполнитьЗначенияСвойств(Данные.Добавить(), Новый Структура("Дата, Партия", Дата('20190228'), "4 партия"));
ЗаполнитьЗначенияСвойств(Данные.Добавить(), Новый Структура("Дата, Партия", Дата('20190301'), "5 партия"));
ЗаполнитьЗначенияСвойств(Данные.Добавить(), Новый Структура("Дата, Партия", Дата('20190330'), "6 партия"));

Данные.Сортировать("Дата Возр");

флп_Объединяемые = Новый массив;
С = 30; //дней макисмум
МаксимальнаяДата = Дата('00010101');
Для каждого флп_строка Из Данные Цикл
    Если МаксимальнаяДата > флп_строка.Дата Тогда
        флп_Объединяемые.Добавить(флп_строка.Партия);
    Иначе
        Лог(флп_Объединяемые);
        флп_Объединяемые = Новый массив;
        МаксимальнаяДата = флп_строка.Дата + С*60*60*24;
        флп_Объединяемые.Добавить(флп_строка.Партия);
    КонецЕсли;
КонецЦикла;
Лог(флп_Объединяемые); //остаток

Объединение партий
    1 партия
    2 партия
Конец объединение
Объединение партий
    3 партия
    4 партия
    5 партия
Конец объединение
Объединение партий
    6 партия
Конец объединение

Я думаю алгоритм в 10 строчек кода — нельзя назвать сложным

1. тогда T_max — уже будет не тот
2. Дата результирующей партии зависит от количества изделий.

Давайте проще поступим — вы приведете исходные данные на которых ваш алгоритм сформирует меньше кластеров, чем предложенный выше.

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

1. Алгоритм не от 0 до T_max — а от T_min до T_max, результат тот же был...
2. Почему то для центра кластера выбирается "взвешенная" дата партии — при таком раскладе ай ай ай…
   1 мелкая партия
   2 и 3 партии большие
   На первом этапе: 1 и 2 партии сливаются — центр смещается ко второй
   На втором этапе уже 4( 1 + 2) и 3 партия сливаются и тут ай ай ай ой ой ой. По факту 1 и 3 партия слились, что не допустимо по условиям задачи =)
   

p.s. да в общем то неважно какой центр выбирать… что так, то эдак. Пока не будет информации о минимальной и максимальной даты в партии — будут некорректные слияния

Как у вас 1,2 и 3 партии слились, если разница между 1 и 3 превышает С?
Аналогично 6,7,8....

В вашем 2-м решении в одном кластере оказались партии с датами более С

то, если там нет пропусков длиной более C, тогда минимальное число партий ВСЕГДА будет ] T / С [

Наверное имелось ввиду: если разбить интервал от Т_min до Т_max, с длиной пропуска С — всегда получится точное количество новых партий (при округлении вверх). Разница формирования будет зависеть лишь от направлении сворачивания партий слева-справа.

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