Добрый день. Есть не особо сложный отчет на СКД которые выводит данные из двух (ТЧ1 и ТЧ2) документов, к Основной ТЧ1 подставляет нужные данные из ТЧ2 второго документа. Но есть Нюансы
Так как выводим мы их построчно как есть, без группировок, сложений и т.д.

ТЧ1 имеет допустим
Товар1 - 10 штук
Товар1 - 5 штук
Товар1 - 15 штук

ТЧ2 имеет допустим
Товар1- 15 штук
Товар1 - 15 штук

В данном случаи он делает дубли строк в отчете. Так как не понимает как эти 15 и 15 штук, раскидать на 10 5 15 строки. А нужно прикрутить метод ФИФО грубо говоря

То есть ТЧ2 Товар1 - 15 штук, хватает на Товар1 10 штук + 5 штук. следовательно в этих строках он берет данные из ТЧ2 товар1 - 15 штук

Далее ТЧ2 товар 15 штук хватает на ТЧ1 товар 15 штук, он должен понимать что ТЧ2 Товар 15 штук, первая строка уже израсходована на 10+15. И осталось только вторая строка 15 штук.

Надеюсь понятно объяснил, как это реализовать в СКД или где посмотреть где это реализовано, так и не допер еще.

не делай это в запросе

циклы и рекурсии в запросы не подвезли еще

(1) А тут даже не запросом, а СКД. Хотят без программирования, мышкой.

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

(4) вот и порешай фифо в ПриКомпоновке

(4) сейчас при таких ситуациях он делает дубли строк и т.д. криво в общем в этих случаях ибо они ранее не встречались и не предполагались.

(4) Это не надо делать в СКД

(7) я понимаю, хотя я нашел статью как реализовывают ФИФО в СКД, создают отдельную колонку, там считают и т.д. статья там на инфостарте, но там криво то же все.

Я не понимаю как в отчете СКД, ПриКомпоновкеРезультата запилить ФиФо.. при этом важно это или нет. таких случаев за 1 календарный год.. допустим 2-3.. из 1000.  Проверять же надо будет все 1000 строк, ты же изначально не знаешь где там по фифо а где все норм и так

(8) Вообще непонятно, зачем ФИФО в отчёте...

(9) А как реализовать эту ситуацию без "фифо".

Если у тебя в отчете строки
товар1 - 5
товар1 - 10
товар1- 20

А в ТЧ2 которое добавляется к этой строке (причем документа Два.. в одном 15 в другом 20) то есть не в одном документе ТЧ) в отчете
Товар1 - 15
Товар1-  20

Надо же как то объяснить что первые 15 идут на 5+10
А вторые 20 идут на - 20

Первый пришел.. 15.. распределился на 5+10..
второй пришел 20 распределился на 20.
ФИФО

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

(5) +100500

(8) считай не ПриКомпоновке, а прямо в запросе.

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

А когда это всё в одном запросе в схеме СКД - проще. Сам отчет выполнялся раз в месяц, особых требований по производительности не было.

Отчетов было много одинаковых, только схема СКД в них различалась, очень удобно было копипастить.

(12) Какое распределение делать в документах? Вы в идеальном мире живете?  мы нет. Мы об упр. учете, а не бухгалтерском.

Есть Заказ Клиента. с разными сроками Отгрузки по каждой строке.
Там Товар1- 5 штук, срок отгрузки допустим 3 дня
Далее Товар1 - 10 штук, срок отгрузки через 3 недели
Далее товар1 - 15 штук, срок отгрузки через 2 месяца..

Далее Заказ Поставщику один поставщик готов завтра привести 15 штук но цена на 20% дороже. Но все это заложено в цену продажи само собой))
Второй поставщик готов привести еще 15 штук но цена на 20% дешевле но сроки 3 недели. а не завтра. Логично что ты делаешь 2 заказа поставщику, зачем переплачивать 20% и заказывать все у одного если сроки позволяют.

Заказываем 15 у первого поставщика
и 15 у второго.
Получаем 2 документа Заказа Поставщика 15 и 15.

А в Заказе клиента 3 строки. Это образный пример.

В идеальном варианта менеджер типо должен разбить первый заказ поставщика на 5 + 10 .. две строки. Но он делает 1 строку 15 штук.  Почему? потому что менеджеры по продажам не видят чужие документы ему приходит что надо заказать 15 штук он заказывает. он не разбивает свой заказ единственный на 5+10 у одного поставщика. он не знает что там 5+10. надо 15 и надо. опять же образно

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

(16) *менеджеры по закупкам

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

(16) бессмыслица какая-то

(14) так вот прям в запросе и не получается. есть пример?

(18) строки из ТЧ2 (Заказ поставщику). в отчете выводят данные срок поставки от поставщика, номер заказа поставщику, сам поставщик и т.д.

ТЧ1 это основная заказыКлиента.

Товар1-5
Товар1 - 10

К ним добавляются строки заказаПоставщику но там Товар1-15 (количетсво)

В итоге в отчете появляется

Товар1-5.. срок отгрузки по договору 10.10.10, срок поставки от поставщика 9.10.10 допустим. Поставщик тот-то.

То есть общии данные.. что строки из заказа клиента обработаны и срок не сорван.

Группировка стоит "Заказ клиента"
Далее выводит строки товара из заказа клиента.
и к ним должны присоеденится строки из ЗаказаПоставщика с их данными

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

Только строк из заказа клиента с одним и тем же товаром может быть 10.. с разным количеством..
А строк из Заказа поставщику.. может быть 1-2-3 с другим количеством...
Но общее количетсво одинаковое.

(18) мне в отчете нужно соеденить строки заказа клиента со стороками заказа поставщика.
Но они не сходятся..
В заказе клиента может быть 3 строки.. а в заказе поставщика 2 две
товар1-5
товар1-10
товар1- 20

А в заказе поставщика товар1 - 15 товар1 - 20.

и в отчете он должен понять что товар1-15 штук идет на 5+10
а втовар1 -20 идет на 20. что бы в эти строки отчета. подставить нормер заказа поставщика, срок поставки от поставщика и т.д.

(21) Ну так и пиши:
ТЧ1, колонки Товар, срок отгрузки, количество отгрузки
ТЧ2, колонки Товар, срок поставки, количество поставки

(24) где куда?

Сейчас все выводит как надо. если количество ТЧ1 = количеству Тч2
и товар ТЧ1 = товару Тч2.

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

Если убрать тч1 количетсво = тч2 количетсва. и он попадает на сютуацию как я описал

Он делает дубли строк
из серии


Това1 - 5 штук  - Номер ЗаказаПоставщику 10
Товар1- 5 штук  Номер ЗаказаПоставщику 11
Това1 - 10 штук  - Номер ЗаказаПоставщику 10
Товар1- 10 штук  Номер ЗаказаПоставщику 11
Товар1- 15 штук - Номер Заказа Поставщику 11

Так как в обоих заказов поставщику по 15 штук он не учитывает что ЗаказПоставщику номер 10.. где 15 штук. тратиться на 5+10 строки из Заказа Клиента.
А заказ поставщику 11 штук тратится на заказ клиента товар1 - 15 штук.

А должен

Това1 5 штук - Номер заказаПоставщику 10
Това1 10 штук - Номер заказапоставщику 10
Ибо в этом ЗаказеПоставщику 15 штук
Товар1 15 штук - Номер ЗаказаПоставщику 11
ибо в этом ЗаказеПоставщику 15 штук

То есть Заказ Клиента 1 документ .  Заказа Поставщика 2-а документа Тч1 получается - 1 ТЧ2 получается 2 штуки.
Между ними разное количество строк с одной и той же номенклатурой и разными количествами.
Так как ТЧ1 основная, то в ТЧ2 надо считать по ФИФО первое пришло, первое присоединилось в отчете к строке ТЧ1, если количество по строке из ТЧ2 закончено он переходит к другой стороке ТЧ2

обе ТЧ связаны основанием ЗаказКлиента

в ПриКомпоновке получил результат
пробежался, посчитат фифу
засунул в компоновку программно и вывел

(29) А есть где то пример для тупых на подобии?

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

Ваша СКД будет нервно курить в сторонке, пока ей готовят готовую таблицу, извините за тавтологию

(0) задача в принципе решаемая запросом. Если партий/списаний будет не тысячи по одному товару, то даже без потерь производительности.
Для прод всё равно так делать не стоит.

А так:
1. считаем нарастающий итог в обеих таблицах
2. соединяем по пересечению отрезков

(32) Фу

Перестаньте ограничивать себя СКД и языком запросов

(34) так это не интересно. я могу из двух ТЧ, собрать данные как надо по итогу для вывода.. и вывести их. тупо в отчет, у нас там нет ни каких группировок даже, раскрасок и т.д. чуть ли не эксель по факту. Но тогда и СКД не нужно получается в данном случаи..
Просто отчет изначально был на СКД и он работает и все к нему привыкли. просто раньше не было таких ситуаций. а сейчас они аля.. 2 раза в год. из 1000 других строк. поэтому и думал изначально как то в СКД прикрутить.

(35) Перестаньте бредить

(33) ага, на вкус фломастеры разные.
Однозначно так делать не стоит, задавая такие вопросы на форумах.

(35) Если настройки СКД никто не крутит, то перепиши на тупую выборку и забудь.

Ну ок. ПриКомпоновкеРезультата
создал ТЗ новое, заполнил это ТЗ результатом, отредактировал ТЗ как мне надо, в этих проблемных строках.

А как теперь эту верную ТЗ подсунуть обратно и вывести эти данные в отчет.

а все, вопрос снят

(40) так поделись для последователей. Хоть какая-то польза от ветки будет.

(41) доделаю сейчас поделюсь.
Но таким методом решения данной проблемы, получается почти х2 по времени формирования отчета
Пока получить результат в ТЗ, пока этот результат обработал, пока засунул правильное обратно, вывел.

(43) Покажите постановку Вашей задачи

(0) Внешние наборы данных в помощь. Формируем кодом таблицу ФИФО/ЛИФО, а уж потом в СКД работаем с ней.

(46) Бессмыслица