Доброго дня!
Не смог сформулировать поисковой запрос, ибо не знаю, как правильно назвать то, что мне надо.
Есть документ реализации товаров. В нем естественно список товаров с количеством. Я делаю выборки поступлений, в которых есть хотя бы один товар из реализации. Мне понадобилось это в ответ на запрос налоговой по конкретным реализациям для подтверждения происхождения товара. Пришла в голову логичная идея хоть как-то минимизировать возню в архиве, так как вполне частая ситуация, когда несколько товаров из реализации могли прийти одним поступлением. Вот теперь собственно вопрос, как это рассчитать? Прямой перебор в общем случае может быть очень долог, ибо при большом количестве товаров будет очень долго работать. Может быть до n! перестановок. Причем n - это количество поступлений. Если кто сталкивался с подобным алгоритмом или знает как он называется - маякните плиз, куда стукнуться можно.

Конфа? Релиз? Платформа?

налоговая может требовать что угодно. Но не на все имеет право. ЛИбо первичку могут запрашивать, либо карточки счета, ОСВ по счету, да хоть анализ. с остальным шлите в сад, не обязаны вы для них такую выборку делать. отправляйте карточку 41-го (43,10) пусть выискивают сами, что им нужно.

(1) Речь про алгоритм, релиз то вам тут что даст? Считайте, что версия платформы необходимая для актуальной БП.
(2) Ну знаете, я не того полета птица, чтобы рассказывать главбуху, как ему учет вести. Зато он мне не рассказывает, как надо программировать :)

А в чем проблема? Взять различные из РТУ, собрать все ПТУ с вхождениями.

(4) Проблема длительности перебора всех вариантов. У нас есть реализации и по 1000 позиций. Поступления есть с 2013 года. На ходовые позиции поступления могут исчисляться сотнями за эти 10 лет.

(6) Вы что хотите, получить минимальное количество документов поступления (независимо от их даты), покрывающее все товары выбранного документа реализации?

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

(7) УТ 10.3, партионный учет не ведется, к сожалению. Но мне даже стало интересно, как там то можно вытащить подобные данные? А то, что я хочу вытащить вы сформулировали абсолютно точно.

Посмотри на инфостарте публикации Ильдаровича. Задача эквивалентна раскладке долгов клиентов по документов от сейчас взад. Там у него запросом это решается.

Фактически это ранец

(10)+ https://ru.wikipedia.org/wiki/Задача_о_рюкзаке

(8) Не самая тривиальная задача. Можно конечно начать с документа, наиболее пересекающегося с реализацией, потом добавить документ, наиболее пересекающийся по невошедшим в первый документ товарам и т.п. Решение будет неплохое, но не всегда наилучшее. Например, если 10 позиций покрываются тремя поступлениями 8+1+1 - это будет лучше, чем два документа 5+5. Что-то из теории множеств здесь, наверное.

(11) Похоже, я предложил "жадный алгоритм")

Имхо тут лучше организационное решение
Чтобы минимизировать возню в архиве - надо просто сделать электронный архив

Т.е. тупо сканируем все входящие документы, привязываем к номенклатуре и простейшим запросом по одной кнопке отправляем пачку в ФНС

(14) А какие отправлять? В этом и вопрос.

(15) Понятно, что задача получить строго минимальное количество документов скорее академическая, будет их 200 или 220 - скорее всего, практической разницы нет. Поэтому я бы остановился на "жадном" алгоритме ввиду простоты реализации.

(15) надо учитывать количество
ибо в реализации может быть 100 а в приходе всего 10 и ФНС спросит а где остальное?

так что банальный алгоритм обратного перебора по каждой номенклатуре пока не наберется кол-во

Если партионный учет не ведется то идет учет по среднему. Мало достать документы которые покрывают нужный остаток товара.
Нужно достать все документы на остаток на момент отгрузки.
поступление 1 товар 1 -10 шт по 21 рублю.
поступление 2 товар 1 -10 шт по 22 рубля.
поступление 3 товар 1 -10 шт по 23 рубля.

На момент расхода у на 30 шт по 22 рубля.
Расход 1 товар 1 - 20 шт по 22 рубля.
Если достать только поступлени 1 и 2. которые покрывают нужный расход товара то возникает логичный вопрос какого вы по 22 рубля списываете когда из этих поступлений у вас средневзвешенная цена 21,50 должна быть.

Такс, за расклады спасибо, то, что надо. Не знал про задачу о рюкзаке. Я первичный отбор сделал. Убрал ПТУ, которые поставляют только один товар, убрал ПТУ, которые полностью входят в другие ПТУ. Из оставшихся вытащил те товары, которые надо собственно закрыть (остальные закроются ПТУ по одному товару). Сейчас думаю, стоит ли вытащить ПТУ с более. чем одним товаром, но не пересекающимися с другими ПТУ из оставшихся. Собрал случайные выборки из 1000 товаров и получилось, что задачу можно упростить, так как много поставщиков монобрендов.

(19) Только учтите, что задача о рюкзаке является NP-полной и решить её за полиномиальное (разумное) время теоретически невозможно. Вам надо искать лазейки, ставить ограничения.

Интересно, а через два месяца потребуют такую же инфу за следующий период. А алгоритмы "оптимального подбора" начнут подсовывать документы, которыми уже старые реализации закрывали. Никто потом не спросит, а как вы товар по этому поступлению уже два (три и т.д.) раза продали?
Может лучше уже нарисовать регистр партионного учета, если его нет, и заполнить его? А по нему уже отчет формировать на раз-два.

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

Нужно приходным документам присвоить какой то рейтинг в виде К-во строк*весовой коэффициент ассортимента + итоговое Кво*коэфициент количества.
Сортируем по убываю позиции или поставщику. Потом из выборки поступлений брать приходы с наибольшим коэффициентом и сокращать остальной подбираемый ассортимент
весовой коэффициент нужно будет подобрать экспериментально.

(0) Налоговая запрашивает документы в рамках проверки исчисления какого-то налога (вероятно НДС, но может быть и прибыль). Угадай, что и кому скажет ГБ, когда ему налоговая предъявит перерасчёт на основе подобранных "по алгоритму" (а не по учётной политике) документов?
Как настроено ведение учёта в БП?

(23) Это уже какой-то альфа-бета алгоритм из шахмат/шашек с отсечениями :)
(24) Мне задачу поставили так: надо какой-то отчет по РТУ, который показывает поступления по каждому товару, чтобы бухи не тратили время на формирование отчете по каждой позиции. Подбор оптимала уже моя инициатива :)

Ну в целом идейка пришла бабушке после приема таблеточки эспумизана... Надо построить алгоритм так, чтобы он последовательно выдавал варианты и сделать отсечку по времени. Я подобную задачу для какого-то сайта делал. Там была задача на выбор оптимальных поставщиков по корзине покупателя, т.е. их должен быть минимум (ибо транспортные), время поставки тоже покороче, сумма тоже поменьше. На выходе выкидывал два варианта, самый дешевый и самый быстрый. Ставили ограничение по времени сколько-то там.

(24) Учет в БП по средней. Но мопед не мой, я только объявление разместил. Более того, когда я спросил, надо ли ГТД учитывать, мне сказали, что не надо.

(25) Если Вы хотите автоматизировать прослеживаемость, то не получится. Там нужен реальный РНПТ

(27) Нет, прослеживаемость типовая. Тут именно для работы с архивом, сократить время выборки документов, которые надо отсканить/отксерить для отправки в налоговую.
(23) Что-то я сильно сомневаюсь, что налоговая займется подобным сравнением. Вообще я видел бумажку, которую налоговая прислала. Там тупо проверка какого-то контрагента, вот по его реализациям и делается выборка. Я РТУ даже в кучку собираю, чтобы по одному письму исключить указанную вами проблему.

Как же не хватает обвеса работы с массивами из какого-нибудь ruby или Python.

(25) Ты неправильно понял постановку задачи.
"Мне задачу поставили так: надо какой-то отчет по РТУ, который показывает поступления по каждому товару, чтобы бухи не тратили время на формирование отчете по каждой позиции." - тут слово "какой-то" подразумевает произвольную итоговую форму и то, что бухи не знают как его вытащить из программы самостоятельно. При этом связь поступления и реализации должна соответствовать принятой учётной политике.
"Подбор оптимала уже моя инициатива" - твоя фантазия, которая приведёт к печальным последствиям. Ты ограничен либо перебором, либо регистрами партионного учёта.

(30) Не надо так серьезно воспринимать. Мне просто интересна эта задача. Неозвученные проблемы бухов программиста не интересуют. Я задал достаточно вопросов, чтобы понять, что именно простая выборка им нужна. Ее я сделал, выкатил и они остались довольны. Добавкой подкинул список ПКУ, которые закрывают несколько строк РКУ. Оптимум (хотя бы приблизительный) делаю для души.

Я бы не мудрил особенно:
- запросом получил бы товары и документы приобретения к ним (довольно быстро, проверял);
- упорядочил бы приобретения (по дате, количеству строк, еще как-то);
- выбирал бы приобретения пока весь список расходной не покроется.
Формально, это транспортная задача (частный случай задачи о максимальном потоке в сети):
- двудольный граф: слева товары, справа приобретения;
- вершины-приобретения связаны с вершинами-товарами дугами с пропускной способностью = МИНИМУМ(количество товара в приобретении, количество товара в расходной);
Задача - максимальный поток в сети.

(32)+ Это не рюкзак. Задача о потоке полиномиально разрешима (одна из немногих переборных) и на практике довольно быстро.