IE 2016

Неоплаченные долги при распределении оплаты по правилу ФИФО одним запросом и намного быстрее, чем Вы думали

Опубликовал ildarovich в раздел Программирование - Практика программирования

Предлагается метод  для быстрого нахождения неоплаченных долгов при распределении оплаты по правилу ФИФО, основанный на дихотомии. Описывается реализация метода в виде достаточно простого запроса, решающего за линейное время указанную задачу, считавшуюся ранее существенно более трудоемкой. Приводятся примеры  использования запроса в отчетах на СКД для конфигураций УТ, КА, УПП.

ВВЕДЕНИЕ

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

В учетных системах правило ФИФО может  применяться в процессе проведения документов, который фиксирует результат распределения оплаты в информационной базе.  Это порождает проблему поддержания последовательности проведения документов. Поэтому часто бывают желательны более легкие (с точки зрения вмешательства в работу учетной системы) и быстрые (не требующие перепроведения документов) альтернативные решения. В отчетах по неоплаченным долгам такие альтернативные решения основаны на  динамическом распределении долга покупателя по документам отгрузки, то есть распределении, выполняемом непосредственно при построении управленческих отчетов.

Препятствием для широкого использования динамического определения неоплаченных долгов является медленная работа  известного алгоритма при работе с реляционными СУБД.  Это обусловлено расчетом нарастающего итога за время, пропорциональное квадрату числа документов в цепочке взаиморасчетов контрагента. Однако в работе «Баттерфляй – метод быстрого расчета нарастающего итога» было показано, что существуют алгоритмы, решающие эту задачу за линейное время.

Тем не менее, в данной работе предложен другой, отличный от «Баттерфляй»,  более простой и быстрый специализированный метод, нацеленный на конкретную задачу нахождения неоплаченных долгов. Метод основан на алгоритме бинарного поиска - дихотомии. Метод реализован одним пакетным запросом.

Предлагаемый алгоритм по своей схеме похож на «метод Больцано-Вейерштрасса», опубликованный "группой математиков" в 1938 году. В указанной работе рассматривалась задача поимки льва в пустыне. А суть метода заключалась в том, что пустыня перегораживалась решеткой пополам, потом   половина, где находится лев, снова делилась пополам и так до тех пор, пока лев не окажется в достаточно маленькой клетке. Эта известная шутка объясняет картинку в заголовке статьи.

ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

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

Чтобы найти искомую секунду Х, возьмем отрезок времени длиной в  536870912 (два в двадцать девятой степени) секунд и назовем его Шаг536870912. Будем считать, что отрезок заканчивается в текущей дате (моменте, на который строится отчет).  Она обозначена как «Край». Такое число секунд соответствует примерно семнадцати годам. Значит, начало отрезка придется на февраль 1997 года.

 Пусть текущий долг одного конкретного контрагента соответствует величине «Долг». Найдем сумму отгрузок «ПолуСумма»  этому контрагенту в правой половине исходного отрезка.  Правая половина имеет длину 268435456 секунд и оканчивается в конце шага.

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

Для случая, когда текущий долг меньше или равен сумме отгрузок справа, делаем вывод, что точка Х находится в пределах правой половины отрезка. Поэтому просто уменьшим вдвое размер шага, оставив его конец на месте. И перейдем, таким образом, к шагу Шаг268435456 размером 268435456 секунд.

Для случая, когда текущий долг больше суммы отгрузок справа, делаем вывод, что точка Х находится в пределах левой половины отрезка. Поэтому делаем сдвиг - переносим конец шага на 268435456 секунд влево, также сокращая его размер вдвое, переходя к шагу Шаг268435456, но заканчивающемуся левее. При этом величину долга нужно сократить на найденную сумму отгрузок «ПолуСумма».

Повторив эту процедуру 29 раз, можно перейти к шагу Шаг1 длины 1, "край" которого равно искомому моменту Х.

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

На фиг.1 приведена схема, иллюстрирующая начало работы  метода.

Схема метода 

ОЦЕНКА ТРУДОЕМКОСТИ

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

Другие затраты будут связаны с суммированием  отгрузок по документам. На первом шаге в среднем  будут суммироваться  1/2 всех документов, на втором  1/4, на третьем  1/8 и так далее. Сумма ряда ½ + ¼ + 1/8 + 1/16 + 1/32 и так далее  равна, как известно единице. Поэтому затраты времени на суммирование отгрузок будут пропорциональны числу документов, то есть  ЛИНЕЙНО зависеть  от их количества!   Так же ЛИНЕЙНО от числа документов будет зависеть и время работы всего метода. Это значит, что если учет в базе ведется 5 лет, а отчет по всем контрагентам работает 30 секунд, то через 5 лет на том же сервере отчет будет работать всего 60 секунд!

РЕАЛИЗАЦИЯ

Приведем запрос, решающий данную задачу.

ВЫБРАТЬ
	Остатки.Организация,
	Остатки.Контрагент,
	Остатки.ДоговорКонтрагента,
	&Дата КАК Край,
	Остатки.СуммаВзаиморасчетовОстаток КАК Долг,
	0 КАК ПолуСумма,
	0 КАК Сдвиг
ПОМЕСТИТЬ Шаг536870912
ИЗ
	РегистрНакопления.ВзаиморасчетыСКонтрагентами.Остатки(ДОБАВИТЬКДАТЕ(&Дата, СЕКУНДА, 1), ДоговорКонтрагента.ВидДоговора = ЗНАЧЕНИЕ(Перечисление.ВидыДоговоровКонтрагентов.СПокупателем)) КАК Остатки
ГДЕ
	Остатки.СуммаВзаиморасчетовОстаток > 0
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	Обороты.ДоговорКонтрагента,
	Обороты.Период КАК Период,
	СУММА(Обороты.СуммаВзаиморасчетовОборот) КАК СуммаВзаиморасчетовОборот
ПОМЕСТИТЬ Обороты
ИЗ
	РегистрНакопления.ВзаиморасчетыСКонтрагентами.Обороты( , &Дата, Регистратор, ДоговорКонтрагента В (ВЫБРАТЬ Шаг.ДоговорКонтрагента ИЗ Шаг536870912 КАК Шаг)) КАК Обороты
ГДЕ
	Обороты.СуммаВзаиморасчетовОборот > 0

СГРУППИРОВАТЬ ПО
	Обороты.ДоговорКонтрагента,
	Обороты.Период

ИНДЕКСИРОВАТЬ ПО
	Обороты.ДоговорКонтрагента,
	Период
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	Шаг.ДоговорКонтрагента,
	Шаг.Край,
	Шаг.Долг,
	ЕСТЬNULL(СУММА(Обороты.СуммаВзаиморасчетовОборот), 0) КАК ПолуСумма,
	ВЫБОР КОГДА Шаг.Долг > ЕСТЬNULL(СУММА(Обороты.СуммаВзаиморасчетовОборот), 0)	ТОГДА -1 ИНАЧЕ 0	КОНЕЦ КАК Сдвиг
ПОМЕСТИТЬ Шаг268435456
ИЗ
	(ВЫБРАТЬ
		Шаг.ДоговорКонтрагента КАК ДоговорКонтрагента,
		Шаг.Долг + Шаг.Сдвиг * Шаг.ПолуСумма КАК Долг,
		ДОБАВИТЬКДАТЕ(Шаг.Край, СЕКУНДА, 536870912 * (Шаг.Сдвиг - 0.5) + 1) КАК Центр,
		ДОБАВИТЬКДАТЕ(Шаг.Край, СЕКУНДА, 536870912 * Шаг.Сдвиг) КАК Край
	ИЗ
		Шаг536870912 КАК Шаг) КАК Шаг
		ЛЕВОЕ СОЕДИНЕНИЕ Обороты КАК Обороты
		ПО Шаг.ДоговорКонтрагента = Обороты.ДоговорКонтрагента
			И (Обороты.Период МЕЖДУ Шаг.Центр И Шаг.Край)

СГРУППИРОВАТЬ ПО
	Шаг.ДоговорКонтрагента,
	Шаг.Край,
	Шаг.Долг
;
...
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	Шаг.ДоговорКонтрагента,
	Шаг.Край,
	Шаг.Долг,
	ЕСТЬNULL(СУММА(Обороты.СуммаВзаиморасчетовОборот), 0) КАК Сумма
ПОМЕСТИТЬ Шаг0
ИЗ
	(ВЫБРАТЬ
		Шаг.ДоговорКонтрагента КАК ДоговорКонтрагента,
		Шаг.Долг + Шаг.Сдвиг * Шаг.ПолуСумма КАК Долг,
		ДОБАВИТЬКДАТЕ(Шаг.Край, СЕКУНДА, Шаг.Сдвиг) КАК Край
	ИЗ
		Шаг1 КАК Шаг) КАК Шаг
		ЛЕВОЕ СОЕДИНЕНИЕ Обороты КАК Обороты
		ПО Шаг.ДоговорКонтрагента = Обороты.ДоговорКонтрагента
			И (Обороты.Период = Шаг.Край)

СГРУППИРОВАТЬ ПО
	Шаг.ДоговорКонтрагента,
	Шаг.Край,
	Шаг.Долг
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	Шаг.ДоговорКонтрагента.Организация КАК Организация,
	Шаг.ДоговорКонтрагента.Владелец КАК Контрагент,
	Шаг.ДоговорКонтрагента КАК ДоговорКонтрагента,
	Обороты.Период КАК Период,
	Обороты.Регистратор КАК Регистратор,
	ВЫБОР
		КОГДА Обороты.Период = Шаг.Край
			ТОГДА Шаг.Долг / Шаг.Сумма
		ИНАЧЕ 1
	КОНЕЦ * Обороты.СуммаВзаиморасчетовОборот КАК Долг,
	РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) КАК Долгота
ИЗ
	Шаг0 КАК Шаг
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ВзаиморасчетыСКонтрагентами.Обороты( , &Дата,	Регистратор, ДоговорКонтрагента В (ВЫБРАТЬ Шаг.ДоговорКонтрагента ИЗ Шаг0 КАК Шаг)) КАК Обороты
		ПО Шаг.ДоговорКонтрагента = Обороты.ДоговорКонтрагента
			И Шаг.Край < = Обороты.Период

В первом запросе пакета находится величина долга по каждому договору. Эта величина заносится в таблицу Шаг536870912. Во втором запросе пакета обороты отгрузок в разрезе договор+период по всем должникам переносятся во временную проиндексированную таблицу «Обороты». Далее запрос построен в точном соответствии с описанным алгоритмом и поэтому достаточно прозрачен. Поле «Сдвиг» отражает выбор того, в какую половину текущего интервала неопределенности нужно будет переходить на следующем шаге метода. Если Сдвиг равен -1, то производится смещение влево.

Для экономии места повторяющиеся  запросы пакета  после третьего сокращены - заменены многоточием.

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

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

ВАЖНОЕ ЗАМЕЧАНИЕ

В бочке меда достоинств данного метода есть одна ложка сахара. Метод не разделяет оплаченные и не оплаченные отгрузки по одному договору, если  они были выполнены в одну и ту же секунду Х.  Конечно, это очень редкая ситуация – несколько документов отгрузки одному  контрагенту, приходящиеся на одну и ту же единственную Х-секунду. Правило ФИФО ничего не говорит о порядке погашения этих документов. Поэтому логично включать в неоплаченные все такие отгрузки. При этом неоплаченной суммой каждой односекундной отгрузки предлагается считать одну и ту же долю суммы каждого документа.  То есть, если в одной секунде есть две отгрузки по 100 рублей, а текущий долг составляет 150 рублей, то обе эти отгрузки будут считаться не оплаченными на 75 рублей каждая. Это решение отличается от применяемого сейчас сомнительного приема, когда документы внутри одной секунды упорядочиваются по внутреннему идентификатору и таким образом погашаются в случайной последовательности.

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

ПРАКТИЧЕСКОЕ БЫСТРОДЕЙСТВИЕ

Метод  демонстрирует хорошее практическое быстродействие. Пока не удалось найти случая (помогите!), чтобы время работы метода определения неоплаченных долгов по всем покупателям-должникам превышало 35 секунд (крупная торговая компания с документами в базе за 7 лет).

ЧАСТНЫЕ ВЫВОДЫ

  1. Предложенный метод  очень универсален. Он берет информацию всего из одного  регистра. Меняя название этого регистра и условия выборки остатков и оборотов, можно легко настроить отчет на работу с самыми разными конфигурациями, быстрее, чем сейчас решать многие другие актуальные задачи. Например, строить отчеты по просроченным долгам (нужно добавить одно сравнение), кредиторской задолженности, остаткам партий товаров без ведения полноценного партионного учета и прочее.

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

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

ОБЩИЕ ВЫВОДЫ

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

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

НЕКОТОРЫЕ ССЫЛКИ

Тема реализации ФИФО достаточно популярна на Инфостарте. Из многих работ на эту тему хотелось бы  выделить Нарастающие итоги в запросе и методы ускорения его выполнения. Ее автор впервые упомянул термин «последовательное приближение», хотя, судя по описанию,  и ограничился в решении только сокращением объема группировок за счет их каскадирования (год – месяц - день). Стандартный метод описан в работе Дебиторка fifo по долгам контрагентов (УТ 10.3). Об актуальности задачи убедительно говорится в работе Отчет по дебиторской задолженности. Незаменим для компаний, реализующих товары с отсрочкой платежа и ведущих взаиморасчеты по договору "в целом". Метод ФИФО. Отсрочка платежа, сумма, дней просрочки. Дней средневзвешенное. Можно еще отметить недавнюю работу [УТ11] Дебиторка Фифо, вариант с внедрением нового регистра накопления (для значительного ускорения формирования отчета), которая подтолкнула данную публикацию, вызвав желания показать более легкий путь решения задачи. Ну и работу Просроченная дебиторская задолженность по датам без ведения учета по документам расчетов для УТ 10.3, в комментариях к которой есть слова "...мониторю различные ресурсы в надежде найти "третий вариант", но возможно его просто не существует в природе...", которые окончательно убедили заняться данной задачей. 

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
[УК10.3, УПП 1.3, КА] Отчет "Неоплаченные долги ФИФО"
.erf 11,34Kb
06.03.14
196
.erf 11,34Kb 196 Скачать
[УК10.3, УПП 1.3, КА] Отчет "Просроченные долги ФИФО"
.erf 12,16Kb
06.03.14
263
.erf 12,16Kb 263 Скачать

См. также

Лучшие комментарии

18. EarlyBird 04.04.2014 04:21
Коллеги, ваш интеллект потрясает, респект.
Я вообще ничего не понял из вашей дискуссии )
# Ответить
64. insurgut (файл скачал) 09.11.2015 17:00
С позволения автора выкладываю переделку отчета под УТ 11.1.
Ответили: (65)
# Ответить
6. ildarovich 05.03.2014 10:42
(4) Насколько я понял, Вы привели вариант реализация общеизвестного метода. Его основная отличительная особенность - соединение таблицы оборотов самой с собой по условию
ТаблицаПоследующихПриходов.Регистратор.МоментВремени >= ОсновнаяТаблицаРегистра.Регистратор.МоментВремени
Такое соединение называется "тэта-соединением". Оно приводит к тому, что в результате в выборке до группировки оказывается N^2/2 строчек, где N - число документов по одному договору в рассматриваемом периоде. Это значит, что если у Вас 100 документов отгрузки, то потребуется просуммировать 5000 строчек, а если 1000 документов отгрузки, то 500000. Эта нелинейная квадратичная зависимость и невозможность ограничить интервал снизу приводит к тому, что со временем производительность отчета быстро деградирует. Это реальная проблема. В больших торговых организациях отчет может работать десятки минут и часы. Возможно, в Вашей организации нет контрагентов с большим количеством отгрузок по одному договору и эта проблема не чувствуется.
Мне долгое время казалось, что для реляционных СУБД - это неизбежность и сделать ничего нельзя, а при желании ускорить отчет нужно считать нарастающий итог в коде или в СКД или сворачивать базу. Относительно недавно удалось преодолеть квадратичную зависимость и снизить ее до линейной (метод "Баттерфляй"). Подобный подход применен и здесь: повторением большого количества очень простых запросов, не требующих самосоединения оборотов, удалось создать метод, время работы которого не квадратично, а ЛИНЕЙНО зависит от числа отгрузок по одному договору. Это актуально для больших организаций - не нужно ничего "сворачивать", чтобы отчеты работали с нормальной скоростью.
То есть это совершенно новый по алгоритму метод, отличающийся от всех известных, основное отличие которого - высокая скорость работы на больших базах.
Ответили: (8)
+ 3 [ olezhe; ZLENKO; Yimaida; ]
# Ответить

Комментарии

1. speshuric 28.02.2014 16:37
(0) 1. А это правильно, что в первом запросе "Остатки(&Дата, ...", а во втором "ВзаиморасчетыСКонтрагентами.Обороты( , &Дата, "? Что будет, если будут обороты в момент &Дата?
2. Зачем во втором запросе ".Обороты" да еще и с периодичностью "Регистратор"? Не проще было прямо из движений их сформировать? Просто если посмотреть SQL-запрос, который при этим возникает, то он способен сбить с толку оптимизатор SQL.
Ответили: (2)
# Ответить
2. ildarovich 28.02.2014 17:00
(1) Спасибо за вопросы и замечания. Действительно, отчет совсем свежий и неточности еще могут быть. Уверен, определенный "тюнинг" запросу еще нужен.
1) Вопрос в голове был. Я действительно не проверил. Показалось, что конечный остаток с параметром 0:00:00 учитывает обороты в момент 0:00:00, а брал просто остаток. Проверю - исправлю (уже исправил! - взял остаток на следующую секунду - так кажется логичнее, если ищем отгрузки).
2) Думал про движения, но мне нужно было простым способом отобрать именно "отгрузки". Я решил, что считать отгрузкой удобнее всего факт, когда по документу в целом (регистратору) будет "плюс" долга. То есть расчет на случай, когда в документе несколько разнонаправленных движений по регистру. Возможно, в целевой конфигурации такого в этом регистре никогда не бывает, тогда действительно можно взять движения.
# Ответить
3. ildarovich 04.03.2014 16:14
Добавил отчет "Просроченные долги". Изменился только последний запрос - потребовалось ввести несколько дополнительных полей. Допустимое число дней задолженности хранится в соответствующем реквизите договора контрагента независимо от установленной галочки "Контролировать число дней задолженности". Реквизит оказывается в отчете и меняется прямо из отчета как показано на скриншоте.
# Ответить
4. sapit (файл скачал) 05.03.2014 03:24
Спасибо что ответили в моей теме, вот рабочий алгоритм оплат/отгрузок/ ит.п. фифо. проверен временем (на самой первой УТ 8.0, лет 10?). Весь запрос не привожу- много лишнего, но основная выборка здесь. Главное фильтр не делать отбрасывающий какие либо движения тогда работает.

ВЫБРАТЬ РАЗРЕШЕННЫЕ
	                |	""ПоДоговору_СуммаВзаиморасчетовОстаток > 0"" КАК ВедениеВзаиморасчетов,
	                |	Остатки.Организация КАК Организация,
	                |	Остатки.Контрагент КАК Контрагент,
	                |	Остатки.ДоговорКонтрагента КАК ДоговорКонтрагента,
	                |	ОсновнаяТаблицаРегистра.Период КАК ПериодВозникновенияЗадолженности,
	                |	ЕСТЬNULL(ОсновнаяТаблицаРегистра.Регистратор.ДатаОплаты, ОсновнаяТаблицаРегистра.Период) КАК ДатаОплаты,
	                |	ОсновнаяТаблицаРегистра.Регистратор КАК РасчетныйДокумент,
	                |	ВЫБОР
	                |		КОГДА СУММА(ТаблицаПоследующихПриходов.СуммаВзаиморасчетовОборот * ВЫБОР
	                |					КОГДА ТаблицаПоследующихПриходов.СуммаВзаиморасчетовОборот > 0
	                |							И ТаблицаПоследующихПриходов.Регистратор <> ОсновнаяТаблицаРегистра.Регистратор
	                |						ТОГДА 1
	                |					ИНАЧЕ 0
	                |				КОНЕЦ) > Остатки.СуммаВзаиморасчетовОстаток
	                |			ТОГДА 0
	                |		ИНАЧЕ ВЫБОР
	                |				КОГДА СУММА(ТаблицаПоследующихПриходов.СуммаВзаиморасчетовОборот * ВЫБОР
	                |							КОГДА ТаблицаПоследующихПриходов.СуммаВзаиморасчетовОборот > 0
	                |								ТОГДА 1
	                |							ИНАЧЕ 0
	                |						КОНЕЦ) > Остатки.СуммаВзаиморасчетовОстаток
	                |					ТОГДА СУММА(ВЫБОР
	                |								КОГДА ОсновнаяТаблицаРегистра.Регистратор = ТаблицаПоследующихПриходов.Регистратор
	                |									ТОГДА Остатки.СуммаВзаиморасчетовОстаток
	                |								ИНАЧЕ 0
	                |							КОНЕЦ) - СУММА(ТаблицаПоследующихПриходов.СуммаВзаиморасчетовОборот * ВЫБОР
	                |								КОГДА ТаблицаПоследующихПриходов.СуммаВзаиморасчетовОборот > 0
	                |										И ОсновнаяТаблицаРегистра.Регистратор <> ТаблицаПоследующихПриходов.Регистратор
	                |									ТОГДА 1
	                |								ИНАЧЕ 0
	                |							КОНЕЦ)
	                |				ИНАЧЕ СУММА(ОсновнаяТаблицаРегистра.СуммаВзаиморасчетовОборот * ВЫБОР
	                |							КОГДА ОсновнаяТаблицаРегистра.СуммаВзаиморасчетовОборот > 0
	                |									И ОсновнаяТаблицаРегистра.Регистратор = ТаблицаПоследующихПриходов.Регистратор
	                |								ТОГДА 1
	                |							ИНАЧЕ 0
	                |						КОНЕЦ)
	                |			КОНЕЦ
	                |	КОНЕЦ КАК СуммаОстаток,
	                |	0 КАК СуммаОборот,
	                |	0 КАК СуммаПриход,
	                |	0 КАК СуммаРасход
	                |ПОМЕСТИТЬ ПоДоговоруВЦеломДебиторка
	                |ИЗ
	                |	РегистрНакопления.ВзаиморасчетыСКонтрагентами.Остатки(
	                |			&ДатаКон,
	                |			(НЕ ДоговорКонтрагента.ВестиПоДокументамРасчетовСКонтрагентом)
	                |				И ДоговорКонтрагента В (&СписокОтобранныхДоговоров) {(Организация).* КАК Организация, (Контрагент).* КАК Контрагент, (Контрагент.ОсновнойМенеджерПокупателя).* КАК ОсновнойМенеджерПокупателя, (ДоговорКонтрагента).* КАК ДоговорКонтрагента, (ДоговорКонтрагента.ВидДоговора).* КАК ВидДоговора}) КАК Остатки
	                |		ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ВзаиморасчетыСКонтрагентами.Обороты(
	                |				,
	                |				&ДатаКон,
	                |				Регистратор,
	                |				(НЕ ДоговорКонтрагента.ВестиПоДокументамРасчетовСКонтрагентом)
	                |					И ДоговорКонтрагента В (&СписокОтобранныхДоговоров) {(Организация).* КАК Организация, (Контрагент).* КАК Контрагент, (Контрагент.ОсновнойМенеджерПокупателя).* КАК ОсновнойМенеджерПокупателя, (ДоговорКонтрагента).* КАК ДоговорКонтрагента, (ДоговорКонтрагента.ВидДоговора).* КАК ВидДоговора}) КАК ОсновнаяТаблицаРегистра
	                |			ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ВзаиморасчетыСКонтрагентами.Обороты(
	                |					,
	                |					&ДатаКон,
	                |					Регистратор,
	                |					(НЕ ДоговорКонтрагента.ВестиПоДокументамРасчетовСКонтрагентом)
	                |						И ДоговорКонтрагента В (&СписокОтобранныхДоговоров) {(Организация).* КАК Организация, (Контрагент).* КАК Контрагент, (Контрагент.ОсновнойМенеджерПокупателя).* КАК ОсновнойМенеджерПокупателя, (ДоговорКонтрагента).* КАК ДоговорКонтрагента, (ДоговорКонтрагента.ВидДоговора).* КАК ВидДоговора}) КАК ТаблицаПоследующихПриходов
	                |			ПО (ТаблицаПоследующихПриходов.ДоговорКонтрагента = ОсновнаяТаблицаРегистра.ДоговорКонтрагента)
	                |				И (ТаблицаПоследующихПриходов.Период > ОсновнаяТаблицаРегистра.Период
	                |					ИЛИ ТаблицаПоследующихПриходов.Период = ОсновнаяТаблицаРегистра.Период
	                |						И ТаблицаПоследующихПриходов.Регистратор.МоментВремени >= ОсновнаяТаблицаРегистра.Регистратор.МоментВремени)
	                |				И (ТаблицаПоследующихПриходов.Период <= &ДатаКонца)
	                |				И (ТаблицаПоследующихПриходов.СуммаВзаиморасчетовОборот > 0)
	                |		ПО Остатки.ДоговорКонтрагента = ОсновнаяТаблицаРегистра.ДоговорКонтрагента
	                |			И (ОсновнаяТаблицаРегистра.Период <= &ДатаКонца)
	                |			И (ОсновнаяТаблицаРегистра.СуммаВзаиморасчетовОборот > 0)
	                |ГДЕ
	                |	Остатки.СуммаВзаиморасчетовОстаток > 0
	                |
	                |СГРУППИРОВАТЬ ПО
	                |	Остатки.Организация,
	                |	Остатки.Контрагент,
	                |	Остатки.ДоговорКонтрагента,
	                |	ОсновнаяТаблицаРегистра.Период,
	                |	ОсновнаяТаблицаРегистра.Регистратор,
	                |	Остатки.СуммаВзаиморасчетовОстаток,
	                |	ЕСТЬNULL(ОсновнаяТаблицаРегистра.Регистратор.ДатаОплаты, ОсновнаяТаблицаРегистра.Период)
	                |;

.......
	                | X 
	                |ВЫБРАТЬ
	                |	ПоДоговоруВЦеломДебиторка.ВедениеВзаиморасчетов КАК ВедениеВзаиморасчетов,
	                |	ПоДоговоруВЦеломДебиторка.Организация КАК Организация,
	                |	ПоДоговоруВЦеломДебиторка.Контрагент КАК Контрагент,
	                |	ПоДоговоруВЦеломДебиторка.ДоговорКонтрагента КАК ДоговорКонтрагента,
	                |	ПоДоговоруВЦеломДебиторка.ПериодВозникновенияЗадолженности КАК ПериодВозникновенияЗадолженности,
	                |	ПоДоговоруВЦеломДебиторка.ДатаОплаты КАК ДатаОплаты,
	                |	ПоДоговоруВЦеломДебиторка.РасчетныйДокумент КАК РасчетныйДокумент,
	                |	ПоДоговоруВЦеломДебиторка.СуммаОстаток КАК СуммаОстаток,
	                |	ПоДоговоруВЦеломДебиторка.СуммаОборот КАК СуммаОборот,
	                |	ПоДоговоруВЦеломДебиторка.СуммаПриход КАК СуммаПриход,
	                |	ПоДоговоруВЦеломДебиторка.СуммаРасход КАК СуммаРасход
	                |ПОМЕСТИТЬ Источник
	                |ИЗ
	                |	ПоДоговоруВЦеломДебиторка КАК ПоДоговоруВЦеломДебиторка
.....

...Показать Скрыть
Ответили: (6)
# Ответить
5. sapit (файл скачал) 05.03.2014 03:33
Да, предварительно делайте выборку по договору/складу (отбирая с остатком <> 0) и фильтруйте по этим данным, иначе в обработку попадут лишние данные, а в целом работает очень шустро
# Ответить
6. ildarovich 05.03.2014 10:42
(4) Насколько я понял, Вы привели вариант реализация общеизвестного метода. Его основная отличительная особенность - соединение таблицы оборотов самой с собой по условию
ТаблицаПоследующихПриходов.Регистратор.МоментВремени >= ОсновнаяТаблицаРегистра.Регистратор.МоментВремени
Такое соединение называется "тэта-соединением". Оно приводит к тому, что в результате в выборке до группировки оказывается N^2/2 строчек, где N - число документов по одному договору в рассматриваемом периоде. Это значит, что если у Вас 100 документов отгрузки, то потребуется просуммировать 5000 строчек, а если 1000 документов отгрузки, то 500000. Эта нелинейная квадратичная зависимость и невозможность ограничить интервал снизу приводит к тому, что со временем производительность отчета быстро деградирует. Это реальная проблема. В больших торговых организациях отчет может работать десятки минут и часы. Возможно, в Вашей организации нет контрагентов с большим количеством отгрузок по одному договору и эта проблема не чувствуется.
Мне долгое время казалось, что для реляционных СУБД - это неизбежность и сделать ничего нельзя, а при желании ускорить отчет нужно считать нарастающий итог в коде или в СКД или сворачивать базу. Относительно недавно удалось преодолеть квадратичную зависимость и снизить ее до линейной (метод "Баттерфляй"). Подобный подход применен и здесь: повторением большого количества очень простых запросов, не требующих самосоединения оборотов, удалось создать метод, время работы которого не квадратично, а ЛИНЕЙНО зависит от числа отгрузок по одному договору. Это актуально для больших организаций - не нужно ничего "сворачивать", чтобы отчеты работали с нормальной скоростью.
То есть это совершенно новый по алгоритму метод, отличающийся от всех известных, основное отличие которого - высокая скорость работы на больших базах.
Ответили: (8)
+ 3 [ olezhe; ZLENKO; Yimaida; ]
# Ответить
7. wolfsoft 05.03.2014 11:08
Достойная публикация.
# Ответить
8. speshuric 05.03.2014 17:19
(6)"Мне долгое время казалось, что для реляционных СУБД - это неизбежность и сделать ничего нельзя". С полноценным, необрезанным TSQL и CTE - что нарастающий итог, что "глубина долга" решаются достаточно хорошо - быстро работает, лаконично, понятно.
А вот, кстати, LIFO - очень и очень непросто. Лет 7 назад я написал LIFO без курсоров на чистом TSQL, но после первой возникшей необходимости исправления, переписал на курсоры, чтобы можно было кому-нибудь объяснить, как это работает без бочки коньяка. Курсором, кстати, работает медленно, но линейно от количества записей.
Ответили: (9)
# Ответить
9. ildarovich 05.03.2014 18:51
(8) Есть сомнения, что оконные функции входят в стандарт T-SQL. Думаю, что когда стандарт расширяется, у каждого нововведения есть и сторонники и противники. А то, что эти функции реализованы в нескольких коммерческих СУБД и востребованы может быть еще недостаточно, если они противоречат каким-либо базовым принципам.
Говоря о реляционных СУБД я имел ввиду не какую-то конкретную СУБД, а принципы реляционной алгебры. Так вот, с этой точки зрения не то, чтобы оконные функции, а даже конструкция ORDER BY не является частью реляционной алгебры.
На стр.194 в строке 26 книги "SQL и реляционная алгебра" читаем
Пожалуйста, не поймите меня неправильно, я вовсе не хочу сказать, что конструкция ORDER BY бесполезна; однако я утверждаю, что в реляционном выражении для нее нет места...
В связи этим считаю, что приведенное решение опирается на более глубокие и устойчивые фундаментальные принципы и должно получить свою область применения.
То есть Вы агитируете за то, чтобы использовать для готовки аэрогриль, например, а я говорю о том, что не на любом необитаемом острове он есть и нужно знать и более доступные рецепты. Хотя вообще я не против прогресса.
Ответили: (10)
# Ответить
10. speshuric 05.03.2014 20:05
(9)
Если говорить про стандарты, то CTE вошли в SQL-99, оконные функции вошли в SQL-2003. В MS SQL начали появляться в 2005-м и 2008-м, но с некоторыми ограничениями. LAG и LEAD, которые есть в оракле и в MSSQL2012 кажется пока еще не в стандарте (а мощные функции, кстати).
А если говорить про реляционную модель, то тут же надо делать кучу оговорок:
  • SQL далёк-далёк от реляционной модели.
  • Реляционная модель отделена от реализации. Нельзя говорить о времени выполнения того или иного реляционного выражения.
  • Реляционная модель, к сожалению, подвисла. Она прекрасна, но в ней много белых пятен, а пятна эти не торопятся заполняться. К сожалению Дейт и Дарвен не вытянули альтернативную реализацию РСУБД (не SQL). Я могу попробовать сделать небольшой обзор на эту тему, но это явно не влезет в коммент.
Я прекрасно понимаю, что вы говорите, но если говорить об инструментах, то эффективные инструменты есть. А если говорить о теории, то тут надо подходить шире и не ограничиваться реляционной моделью (хотя бы потому, что она ничего не утверждает про производительность)
Ответили: (12)
# Ответить
11. lar_nm (файл скачал) 06.03.2014 11:20
Все классно работает и быстро! Благодарю и уважаю.
# Ответить
12. ildarovich 06.03.2014 21:54
(10) Спасибо за информацию про стандарты и функции. Возьму на заметку.
1) 2) 3) - согласен со всем этим.
Да, эффективные инструменты есть. Решая конкретную задачу, не стал бы отметать доступные инструменты, просто порадовался, что все "летает" и пошел бы дальше. Например, в статье "Опять двойка" в случае с использованием ЗаписьXML (Ваша находка) для быстрой конкатенации строк я явно попал впросак, просто не найдя этой возможности. Но тут пока оконных функций в запросах не появилось. И не думаю, что это в приоритетах у 1С. И может подойти данный метод.
Что же касается теории - можно было бы попытаться копнуть глубже, но кто это сейчас оценит? Тем более, кажется, что такого рода приемы должны были (не стал проверять) в свое время запатентованы как схемотехнические решения для построения быстродействующих АЦП, сумматоров и прочее (В IEEE Transactions нужно покопаться). То есть теоретическим изысканиям должны предшествовать обоснования новизны, а я в ней не уверен.
# Ответить
13. Angry 07.03.2014 17:06
Интересны способ.
Но если отойти от чистой теории и спустится к тому что имеем на практике, т.е. 1С.
Надо вспомнить что для оптимизации 1С хранит итоги за месяц. Не будет ли эффективней механизм если будет опираться на эти итоги?
Ответили: (14)
# Ответить
14. ildarovich 07.03.2014 17:39
(13) Вообще Вы правы. Но ускорение, которого можно добиться таким образом, не столь значительно, как может показаться на первый взгляд. Дело в том, что всего через примерно девять (меньше трети) делений, метод выходит на уровень, на котором интервал неопределенности меньше месяца, где итоги уже не работают. Оптимизировать можно первые девять делений. Я не стал усложнять запрос ради относительно небольшого выигрыша в 30 %. Причем этот максимальный выигрыш будет достигаться только когда месяцев существенно меньше чем документов.
Но это вполне можно сделать. Нужно только добавить таблицу еще и месячных оборотов и первые деления делать по ней. В том случае, когда мы начинаем не с 17 лет, а, например, с трех лет (когда долги, по идее списываются), выигрыш будет только 20%.
...
На этом пути есть одна "засада", на которую я уже натыкался, а сейчас забыл. Итоги хранят суммы всех движений, а для работы метода нужно выделять из них только "отгрузки", а они - не всегда "приход", а иногда "расход" с минусом.
# Ответить
15. Pawlick (файл скачал) 18.03.2014 19:15
Очень интересное решение, очень.

Также нужно изучать и чаще вспоминать математику

Золотые слова, ildarovich, золотые слова...
# Ответить
16. ejik2012 01.04.2014 14:20
Подскажите, Шаг134217728 будет выглядеть так?

ВЫБРАТЬ
	Шаг.Договор,
	Шаг.Край,
	Шаг.Долг,
	ЕСТЬNULL(СУММА(Обороты.СуммаВзаиморасчетовОборот), 0) КАК ПолуСумма,
	ВЫБОР
		КОГДА Шаг.Долг > ЕСТЬNULL(СУММА(Обороты.СуммаВзаиморасчетовОборот), 0)
			ТОГДА -1
		ИНАЧЕ 0
	КОНЕЦ КАК Сдвиг
ПОМЕСТИТЬ Шаг134217728
ИЗ
	(ВЫБРАТЬ
		Шаг.Договор КАК Договор,
		Шаг.Долг + Шаг.Сдвиг * Шаг.ПолуСумма КАК Долг,
		ДОБАВИТЬКДАТЕ(Шаг.Край, СЕКУНДА, 268435456 * (Шаг.Сдвиг - 0.5) + 1) КАК Центр,
		ДОБАВИТЬКДАТЕ(Шаг.Край, СЕКУНДА, 268435456 * Шаг.Сдвиг) КАК Край
	ИЗ
		Шаг268435456 КАК Шаг) КАК Шаг
		ЛЕВОЕ СОЕДИНЕНИЕ Обороты КАК Обороты
		ПО Шаг.Договор = Обороты.Договор
			И (Обороты.Период МЕЖДУ Шаг.Центр И Шаг.Край)

СГРУППИРОВАТЬ ПО
	Шаг.Договор,
	Шаг.Край,
	Шаг.Долг
...Показать Скрыть
Ответили: (17)
# Ответить
17. ildarovich 02.04.2014 13:51
(16) Да, в точности так!
# Ответить
18. EarlyBird 04.04.2014 04:21
Коллеги, ваш интеллект потрясает, респект.
Я вообще ничего не понял из вашей дискуссии )
# Ответить
19. relanium86 28.05.2014 11:44
На базе УПП объемом порядка 80Гб отчет выполняется по 60 счету 32сек. а по накоплению итогов у меня шуршало минут 10 в среднем.
+ 1 [ ildarovich; ]
# Ответить
20. mxm2 (файл скачал) 29.05.2014 16:40
Как-будто еще одна особенность отчета есть: если в момент возникновения долга была переплата (аванс), то сумма просроченного долга считается неверно (в нее добавляется сумма аванса).
Ответили: (21)
# Ответить
21. ildarovich 02.06.2014 12:17
(20) У меня эта ситуация не воспроизводится. Но, возможно, такая ошибка была в самой первой версии размещенного отчета, которая была сразу же исправлена. Сейчас везде проверяется, что по регистратору
Обороты.СуммаВзаиморасчетовОборот > 0
Поэтому суммы аванса в отчет попасть никак не могут. Попробуйте использовать последние версии отчетов.
# Ответить
22. distorshion 01.07.2014 13:15
А есть версия кредиторской задолженности?
Ответили: (23)
# Ответить
23. ildarovich 01.07.2014 13:44
(22) distorshion, если разговор о УТ 10.3, УПП 1.3 или КА, то сделать ничего не стоит - нужно поменять знаки в трех местах. Например,
Остатки.СуммаВзаиморасчетовОстаток КАК Долг
поменять на
-Остатки.СуммаВзаиморасчетовОстаток КАК Долг
И в таком же количестве мест перевернуть условия. Например,
Остатки.СуммаВзаиморасчетовОстаток > 0
поменять на
Остатки.СуммаВзаиморасчетовОстаток < 0
Ну и протестировать, конечно.
+ 1 [ distorshion; ]
# Ответить
24. distorshion 01.07.2014 14:04
Спасибо!!!!! Мегареспект тебе добрый человек.
# Ответить
25. Rustig 03.07.2014 13:52
(0) как много я пропустил ваших статей! (январь, февраль 2014)
плюс за идею
плюс за реализацию
круто
# Ответить
26. Pawlick (файл скачал) 12.07.2014 20:17
Все таки по моему отчет имеет одну особенность.

У меня эта ситуация не воспроизводится.


Я провел рад экспериментов, и вот что выяснил:
Завожу нового контрагента (для чистоты экперимента).
Далее:
Реализация - ПКО - Возврат товаров - РКО
, где СуммаРеализации > СуммыПКО И СуммаВозврата < СуммыПКО И СуммаВозврата > СуммыРКО

В отчет по какой то причине не попадает сумма РКО (сумма возврата ДС)

Сначала я решил, что просто не учитываются суммы возвратов денежных средств покупателям (возможно потому, что "Обороты.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг")

Но потом ввел еще один такой же комплект документов:

Реализация_2 - ПКО_2 - ВозвратТоваров_2 - РКО_2,

и в отчете не учитывается уже сумма РКО_2, а сумма РКО - учитывается !

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

1. Снимаю проведение со "второго комплекта" документов (проведенными остаются только Реализация-ПКО-ВозвратТоваров-РКО). Сумма РКО в отчет не попадает;
2. Провожу Реализацию_2. Сумма РКО в отчет не попадает;
3. Провожу ПКО_2, и... ОП! Сумма РКО попала в отчет!
4. Провожу ВозвратТоваров_2: сумма РКО в отчете.
5. Провожу РКО_2: сумма РКО по прежнему в отчете, а вот суммы РКО_2 - нет!


PS. Если кинете в личку адрес почты скину Вам УТ10 в которой смоделирована ситуация.
Ответили: (27)
# Ответить
27. Pawlick (файл скачал) 15.07.2014 00:43
В(26) Pawlick,
Все таки по моему отчет имеет одну особенность.

ildarovich, все, вопрос закрыт. Ошибка не подтвердилась.
Простите бога ради за некорректную информацию и беспокойство.
Ответили: (28)
# Ответить
28. ildarovich 15.07.2014 00:49
(27) Pawlick, да не за что. - Я как раз за максимально критичное и недоверчивое отношение. Дополнительная проверка лишней никогда не бывает.
# Ответить
29. undo 29.07.2014 18:58
Я никогда не смотрел на решение таких задач со стороны математики, и поэтому офигел от написанного.
# Ответить
30. Denium79 (файл скачал) 10.10.2014 06:42
Автору огромное спасибо за отчет! Переписал его для складских остатков в своем УПП, получилась просто бомба! Потрясающее решение! Отчет по дебиторке хотелось бы для БП 2.0, может быть кто нибудь перепишет?
# Ответить
31. sam0511 (файл скачал) 22.10.2014 09:16
В обсуждении не заметил, но..
Неправильно отображается сумма долга по документам в следующей ситуации: есть предоплата, последующая отгрузка проведена двумя документами в одно время (бывает и такое...). Сумма долга распределяется на два этих документа, хотя, по идее должен отображаться одни. А в остальном супер.
Ответили: (32)
# Ответить
32. ildarovich 22.10.2014 09:43
(31) sam0511, как говорится, "это не баг - это фича". - Так и было задумано и я готов настаивать на том, что такое решение правильнее, чем отнесение оплаты на один из выбираемых случайно (на основе GUID) документов-односекундников. Потому, что пользователь не влияет на выбор оплачиваемого документа, а время у них одинаковое. Получается, что отчет при этом (при общепринятом подходе) ведет себя непредсказуемо, а этого быть не должно. Захотят поправить - передвинут нужный документ на секунду вперед.В статье об этом написано (где про ложку сахара).
Ответили: (34)
# Ответить
33. ZLENKO.PRO 23.10.2014 13:27
Скажите пожалуйста могу ли в вашем варианте получить в отчете какой документ каким был оплачен ?
Т.е. чтобы увидеть с какой реальной отсрочкой платил клиент ?
Ответили: (35) (47)
# Ответить
34. ZLENKO.PRO 23.10.2014 13:31
(32) ildarovich, " "это не баг - это фича". - Так и было задумано и я готов настаивать на том, что такое решение правильнее, чем отнесение оплаты на один из выбираемых случайно (на основе GUID) документов-односекундников."

Ну фича, не фича, но не баг так это точно. Нет никакой разницы на один или на два документа размазать. Тем более что в задаче дебиторской задолженности можно было округлить время документа до суток, а не до секунд.
# Ответить
35. ildarovich 23.10.2014 14:40
(33) ZLENKO.PRO, нет, к сожалению.
Это немного другая и чуть более сложная по математике задача. Связывание оплаты с отгрузками (или приходов товара с расходами) по ФИФО запросом. В принципе, в статье "Баттерфляй - метод быстрого расчета нарастающего итога в запросе" показано, что первую часть этой задачи тоже можно решить за время, пропорциональное числу документов. Сейчас, кстати, у меня есть более легкая версия этого запроса. А также у меня есть решение второй половины этой задачи (связывание по ФИФО запросом). То есть быстрое решение запросом задачи 7 из статьи Минимализмы. Но пока массового интереса к этой теме не видно, поэтому с публикацией не тороплюсь.
Ответили: (36)
# Ответить
36. ZLENKO.PRO 23.10.2014 15:24
(35) ildarovich, "Но пока массового интереса к этой теме не видно, поэтому с публикацией не тороплюсь."

Массовый интерес может вызвать разве что какая нить доработка документа Счет-фактура :-)
Кстати в http://infostart.ru/public/306536/ задача 7 жаль что два года назад не попалось решение.
Сломал мозг пока написал распределение оплат и отгрузок в цикле :-(
Получались проблемы с нераспределенными "хвостами"..
# Ответить
37. killovolt (файл скачал) 12.12.2014 13:24
(0) ildarovich, спасибо за идею. На основе отчета реализовал поиск не зачтенных авансов. Т.е. мне надо было по ФИФО найти документ оплаты с которого возникает аванс.
# Ответить
38. sea123 (файл скачал) 15.01.2015 15:51
Работает быстро. НО ... при различных отборах разные суммы по одному и тому же контрагенту. По документу Корректировка долга.
Ответили: (39)
# Ответить
39. ildarovich 15.01.2015 16:17
(38) sea123, если подробнее опишете ситуацию, чтобы можно было воспроизвести, то буду разбираться. - Что за отборы? Возможно, отборами вы сами исключаете документы, которые должны влиять на остаток. Вот он и меняется. Попробуйте какой-либо другой (медленный) отчет, делающий то же самое. Не будет ли такого же эффекта и там?
# Ответить
40. CheBurator 23.01.2015 22:49
Автор а не пробовали разбиение делать не фифти фифти а дветрети к одной трети и одна треь ближе к коцу периода
Такой вариант по идее должен существенно увеличить скорость
Ответили: (41)
# Ответить
41. ildarovich 24.01.2015 02:52
(40) CheBurator, нет, это не так. Метод золотого сечения и метод дихотомии довольно часто путают, но это разные методы - у каждого свои условия применения. Метод золотого сечения используется при поиске минимума (максимума) унимодальной функции. Один замер там не позволяет решить, где дальше искать - нужно обязательно два замера (располагающихся по золотому сечению), чтобы сравнить значения в двух точках и выбрать новый, меньший интервал неопределенности.
В нашем случае для определения нового интервала неопределенности достаточно одного замера - поэтому и используется дихотомия.

- Но, с другой стороны, зная закон распределения вероятностей числа дней просрочки, можно делить интервал в соответствии с ним, что действительно будет давать выигрыш! Такой вариант в голове мелькал, но потом как-то забылся на фоне того, что пришлось долго возиться с запросом (его начальный вариант вешал СКД).
Пожалуй, стоит реализовать не золотое, а "вероятностное" сечение. Спасибо, что помогли вспомнить про эту идею!
# Ответить
42. Glemar (файл скачал) 11.02.2015 11:55
Спасибо за замечательный отчет!!!
Одновременно возникла проблема выбора, поэтому прошу совета.
Отчет позволяет видеть просроченную дебиторку, не раскидывая платеж по накладным (В приходнике или Платежке). Однако, для этого необходимо проставить галочкой "ведение взаиморасчетов по документам" и "контролировать число дней задолженности" в договорах.
При этом срабатывает контроль взаиморасчетов при проведении накладных. Его конечно можно преодолеть если разрешить «Разрешить проведение...» в Дополнительных правах пользователя. Но тогда фактически реального контроля нет тк он а) необъективен, ибо опирается на несуществующие просрочки, и б) преодолевается пользователем
Два дальнейших пути (оба не нравятся):
1. Отключить "ведение взаиморасчетов по документам" в договорах. Но этого сделать система не даст, тк есть документы сформированные "под галочкой". (Хотя и можно завести новые договора)
2. Не отключать "ведение" (да, будем мучаться с проведением накладных). И убираем "контролировать число дней задолженности" из договора. Но тогда теряют смысл сей замечательный отчет по просроченной задолженности, ибо он ориентируется на это «Число дней..» при определении просрочки.
А ведь хочется иметь и контроль за проведением накладных и работающий отчет по просрочке.
Ответили: (44)
# Ответить
44. ildarovich 11.02.2015 13:21
(42) Glemar, хочу уточнить, что данный отчет работает НЕЗАВИСИМО от состояния реквизита "ведение взаиморасчетов по документам". В основном расчет на ситуацию, когда эта галочка не проставлена, то есть учет взаиморасчетов по документам не ведется. При этом есть две проблемы:
1) при снятии этой галочки пропадает видимость реквизита "число дней просрочки";
2) также не возможно запретить проведение очередной реализации при просрочке долга.
Первая проблема в данном отчете решена без изменении конфигурации. Дело в том, что хотя реквизита не видно, он в базе данных для договора тем не менее хранится. И просмотреть и поменять его значение можно с помощью данного отчета, щелкнув по соответствующему полю. То есть отчет еще обеспечивает доступ к скрытому (при отжатой галочке) полю "Допустимое число дней задолженности".
Вторую проблему можно решить только изменением конфигурации, создав аналог данного отчета для одного контрагента, который будет запускаться перед проведением реализации и рассчитывать просрочку, превышение которой может быть сигналом для отказа в проведении. Ничего сложного в этом нет - это легко сделать на базе того же запроса.

Если же в договоре галочка стоит, то просроченность долга легче определить по соответствующему регистру, обеспечив правильное соотнесение оплат с отгрузками. А данный отчет использовать как контрольный. Он будет показывать наилучший случай (для контрагента) разнесения платежей, когда первыми закрываются самые старые долги и штрафные санкции минимальны.
Ответили: (45)
# Ответить
45. Glemar (файл скачал) 11.02.2015 14:13
(44) ildarovich,
Спасибо!
2) - Действительно,доступ к полю "Допустимое число дней задолженности" творит чудеса. Реквизит сохраняется!

К сожалению у нас имеются проблемы к корректным подбором Реализаций в документах оплаты, тк отгрузка шла и идет по нескольким договорам, имеются возвратные накладные, клиенты могут сделать проплату на сумму, превышающую задолженность... Будем думать над обработкой, которая бы периодически восстанавливала корректность соотнесения оплат с отгрузками.
Либо пойдем по пути, предложенному Вами в решении "второй проблемы". Попробуем даже сделать проверку на этапе Сохранения реализации (до Проведения), чтобы Менеджер занялся просрочкой до передачи заявки на склад, а не в последний момент.
# Ответить
46. MakhoninMY 20.03.2015 10:22
Скажите пожалуйста можно ли на основе вашего решения рассчитать пени по просроченной задолженности без запроса в цикле по дням? Фактически нужно получить график просроченной задолженности по дням.
Ответили: (47)
# Ответить
47. ildarovich 23.03.2015 16:41
(46) MakhoninMY, если я правильно понял вопрос, то вы хотите то же, что и в (33). Тогда тот же ответ - нет, приведенное здесь решение только для просроченных долгов на одну конкретную дату.
В принципе, у меня в планах есть сделать отчет, связывающий оплаты с отгрузками и, таким образом, дающий возможность определить по каждому документу, насколько была задержана уже сделанная оплата. В порядке демонстрации алгоритма "быстрого связывания" нарастающих итогов. Но это пока через три-четыре уже начатых статьи, то есть минимум через столько же месяцев.
Ответили: (48)
# Ответить
48. MakhoninMY 24.03.2015 15:44
(47) ildarovich, Да, динамическое определение дат оплаты документов отгрузки было бы самым подходящим решением для расчета пени. Но формально данным запросом можно получить информацию о просроченной задолженности за каждый день расчетного периода, рассчитать пени по дням и сложить. Конечно, это не эффективно.
# Ответить
49. Glemar (файл скачал) 20.05.2015 20:52
ildarovich,
Добрый день, складывается впечатление, что расчет задолженности сопоставляет только оплаты с отгрузками, но не учитывает взаимозачетов в виде, например, Корректировок долга.
Или можно где-то настроить список документов, пронимаемых во внимание расчета??
Ответили: (50)
# Ответить
50. ildarovich 21.05.2015 13:07
(49) Glemar, тип документов никак не ограничивается - это все документы, делающие движения по регистру ВзаиморасчетыСКонтрагентами,
ГДЕ
    Обороты.СуммаВзаиморасчетовОборот > 0
Фактически сопоставления оплат с отгрузками не происходит. На сумму долга набираются последние отгрузки.
Если корректировка имела тот же знак в движении, что отгрузка, то она будет считаться "отгрузкой" и так же может посчитаться просроченной. Если корректировка имела другой знак, то она в отчет просто не попадет, повлияв на его содержание косвенно - через сумму долга.

Но вообще, если что-то непонятно, готов разбираться. Для этого мне нужно по сомнительной ситуации:
1) список движений регистра ВзаиморасчетыСКонтрагентами по конкретному договору;
2) выдача моего отчета;
3) выдача "правильного" с Вашей точки зрения отчета или мнение "что должно быть".
# Ответить
51. Vodoley 06.07.2015 14:54
1. всякий раз говорю "круто" - и собираюсь проработать и остальные статьи автора )) (приятный научный глубокий подход и остроумный стильный текст.)

2. Собственно сейчас сам мучаюсь с тем как раскидать документы.. по другим документам. (у меня сейчас не типичная задача позакрывать расходы приходами по ФИФО - но очень близкая). Есть ли возможность в 2х словах направить куда смотреть..? (пардон за наглость)
(У меня пока и тета-соединением не прорисовывается запрос, а благодаря Вашим статьям есть ощущение, что запросом разом можно сделать почти все :) и эффективно). Хотя у меня немного нетипичная проблема - под отгрузки подложить наипозднейшие но предшествующие отгрузкам поступления.. Т.е. понятие типа "аванса" нет - отгрузить виртуально то, что получим позже нельзя :). И вот тут пока не могу уловить идею как конструировать соединения, которые в итоге приведут к "закрыванию" отгрузок более ранними поступлениями. (это похоже на дебиторку - только разворачиваем ось времени в прошлое и стартуя с отгрузок и считая их "приходами", закрываем их поступлениями, полагая их расходами).
Ответили: (52)
# Ответить
52. ildarovich 06.07.2015 17:09
(51) Vodoley, если вы имеете ввиду партионный учет, то на Инфостарте было много статей на эту тему. Достаточно набрать в поиске ФИФО (FIFO). В тех статьях были примеры запросов и описание того, как они построены. Речь об оптимальности не шла, но, возможно, на ваших данных этого не потребуется.

Вообще эта задача (связь приходов с расходами) решается примерно так: все приходы по порядку складываются в столбик (как кубики). Величина секции столбика, соответствующего конкретному приходу, берется равной величине этого прихода. Все расходы также складываются в столбик рядом. Затем приходы с расходами связываются горизонтальными линиями. В комментарии http://forum.infostart.ru/forum24/topic32459/message361861/#message361861 приведен пример подобной схемы.
Если речь идет не о запросе, то функция, получающая таблицу связей приходов с расходами приведена в статье Минимализмы в разделе 7.
# Ответить
53. sea123 (файл скачал) 08.07.2015 10:53
Пытались пользоваться этим отчетом и наткнулись на такое поведение: при отсутствии отборов по контрагенту А показывает одну сумму задолженности, при отборе только по Контрагенту А - другую сумму. Причем иногда было так, что реальная задолженность по РН взаиморасчетов не совпадала с данными отчетами.
Ответили: (54)
# Ответить
54. ildarovich 08.07.2015 13:13
(53) sea123, хотелось бы больше информации об обстоятельствах появления расхождений.

Были ли у проблемного контрагента взаимозачеты между договорами, с другими контрагентами, смотрелись ли остатки в максимальном разрезе договоров или только целиком контрагента, были ли корректировки регистра по нему, с "правильным" знаком ли они делались, были ли корректировки реализации.
Вообще гибкость настроек, обеспечиваемая СКД может иногда сослужить плохую службу: можно попробовать в любом типовом отчете поставить регистратор не на последний (нижний) уровень группировки и попробовать понять, что выдает отчет. Возможно, возникает подобная ситуация, но, чтобы разобраться, нужны подробности.

Хотя бы скриншот с разворотом движений по регистратору регистра взаиморасчетов по проблемному контрагенту, скриншот результата моего отчета по нему и скриншот результата "правильного" отчета. Буду очень благодарен за эти данные.
# Ответить
55. Prometeus2011 (файл скачал) 09.07.2015 10:28
Очень бойко можно применить сей метод для построения отчета задолженности по периодам прострочки. Есть такой штатный отчет в десятой УТ "Дебиторская задолженность по периодам". Последний пакет запроса только изменить надо.
# Ответить
56. Prometeus2011 (файл скачал) 09.07.2015 14:32
Сергей, невероятно. Я вот посмотрел Ваши статьи... Мало таких людей я в жизни встречал (одного, кроме вас, если быть точно). Ну круг общения у меня, конечно, не научная элита, но все равно, чувствуется незаурядный склад ума. Это не лесть. Действительно хотелось выразить признание. А сколько времени на проработку материала ушло у Вас? Ну, в частности этого.
Ответили: (57)
# Ответить
57. ildarovich 09.07.2015 15:08
(56) Prometeus2011, спасибо, надеюсь на то, что материалы публикаций будут полезными не только в теории, но и на практике. Собственно говоря, работа с 1С мне и нравится, в основном, своей близостью к практике.
Чистого времени ушло не так уж много: неделя-две. А так, наверное, месяц-полтора заняло. Если тема интересная, то работа идет быстро. Задержка там была в том, что первая версия запроса хорошо работала в консоли, но "вешала" СКД (из-за ошибки в платформе). В итоге запрос получился еще проще.
# Ответить
58. Prometeus2011 (файл скачал) 09.07.2015 17:14
Спасибо.
# Ответить
59. Enya_06 03.08.2015 08:48
Спасибо! Алгоритм очень помог при реализации похожей задачи!
Преклоняюсь перед вами, гении!
# Ответить
60. sapsan322 (файл скачал) 27.10.2015 16:50
Спасибо. Очень круто.
Но вот сейчас мне надо отбор сделать по реквизиту регистратора, а реквизиты регистратора недоступны для отбора. Не могу понять толи я что-то не так делаю.

Может кто подскажет?
Ответили: (62)
# Ответить
61. Зеленоград 27.10.2015 17:58
Всем комментаторам в этой ветке термин "Тупой одинэсник" неприменим.
# Ответить
62. ildarovich 28.10.2015 12:40
(60) sapsan322, сомневаюсь, что в данной задаче имеет смысл делать отбор по реквизиту регистратора. Это специально не разрешено. Так вы можете "выдернуть" из цепочки взаиморасчетов отдельные документы, исказив их логику. Если интересует "проект", сделка, то эта информация должна в регистре отражаться, а к отборам по его измерениям вроде бы доступ есть. Если речь идет об ответственных (менеджерах), то объясните подробнее логику бизнес-задачи - можно будет подумать, как это сделать. Возможно, подтолкнете решение следующей задачи.
Ответили: (63)
# Ответить
63. sapsan322 (файл скачал) 28.10.2015 15:39
(62) ildarovich, Стоит задача сделать отбор по Ответственному менеджеру и ТипуЗаказа.
ТипЗаказа - это реквизит с типом перечисление и в нем имеется 3 значения: Продажа, Ремонт детали и Ремонт Автомобиля.
Попробовал сделать через сделку, и тоже не доступны измерения для отбора.
# Ответить
64. insurgut (файл скачал) 09.11.2015 17:00
С позволения автора выкладываю переделку отчета под УТ 11.1.
Ответили: (65)

Прикрепленные файлы:

ПросроченныеДолгиФИФО_УТ11.erf
# Ответить
65. ildarovich 11.11.2015 10:21
66. sapit (файл скачал) 07.12.2015 13:29
Использовал ваш алгоритм в отчете. Применить как описано в публикации не получилось из за "ложки сахара" - при реальном использовании отчета расчет по ФИФО делается по дате оплаты, а не дате отгрузки. Можно добавить к дате оплаты время из даты отгрузки, но по факту оказалось что в эту самую секунду оформлено до 20 документов отгрузки или поставки. Данные документы появляются при массовом вводе документов прошлым числом (реализации за период оформляются на одну дату), поступают из БД поставщика и т.п. И все бы ничего, но округление в такой ситуации вызывает расхождение между конечным остатком по регистру и результатом в отчете. В итоге ваш алгоритм использую для выборки оборотов с небольшим "запасом", а дальше уже обычным перебором. Пока не было времени протестировать причину, но на действительно большой БД время выполнения запроса вашего алгоритма и "стандартного" примерно одинаковое. Оставил ваш, так как в итоге все равно потребовалась промежуточная ТЗ.
Ответили: (67)
# Ответить
67. ildarovich 07.12.2015 18:06
(66) sapit,
1) выигрыш в скорости будет тем больше, чем больше отгрузок у ОДНОГО контрагента. Если на каждого контрагента отгрузок сравнительно немного, то и выигрыш не будет заметен;
2) вопрос одинакового времени легко решить, добавляя секунды ко времени ОПЛАТЫ, взятые из номера, например. Но я все же еще раз подчеркиваю. Если много отгрузок стоят на одно и то же время оплаты, то с точки зрения неоплаченности их не нужно разделять - лучше рассматривать их как одну большую отгрузку и находить общий процент неоплаченности этой отгрузки и применять затем этот процент к каждой составляющей. Погрешность округления можно исключить, отнеся копейки на последнюю отгрузку в пачке;
3) в запросе, приведенном в статье и в приложенной обработке до сих пор не исправлена небольшая неточность, которую я выявил в процессе "закадрового" общения с пользователями отчета. В предпоследнем запросе пакета вместо
ВЫБОР
        КОГДА Обороты.Период = Шаг.Край
            ТОГДА Шаг.Долг / Шаг.Сумма
        ИНАЧЕ 1
    КОНЕЦ * Обороты.СуммаВзаиморасчетовОборот КАК Долг,
...Показать Скрыть
нужно писать
ВЫБОР
        КОГДА Обороты.Период = Шаг.Край
            ТОГДА Обороты.СуммаВзаиморасчетовОборот * Шаг.Долг / Шаг.Сумма
        ИНАЧЕ Обороты.СуммаВзаиморасчетовОборот
    КОНЕЦ КАК Долг,
...Показать Скрыть
Это исключит лишние ошибки округления!
Ответили: (68)
# Ответить
68. sapit (файл скачал) 07.12.2015 22:11
(67) ildarovich, по пункту 1 -проверю. 2 -все таки много минусов. Пояснить поставщику(покупателю) что мы оплачиваем пропорционально 10 поставок невозможно. Считать отдельно что оплачено, а что нет - возврат к ведению учета по докуменам расчетов. Отчет в этом случае теряет часть функционала - можно посмотреть ситуацию по компании в целом, но на основании полученных данных решить что оплачиваем именно эту поставку становится невозможным. 3 - проверю.
# Ответить
69. angler225 (файл скачал) 16.06.2016 14:28
Спасибо, отчет помог. И что главное, его удалось доработать под нашу измененную конфигурацию (Количество дней отсрочки реквизит справочника Торговые точки) не сломав голову.
# Ответить
70. yurikmellon 21.09.2016 13:03
спасибо, попробую
# Ответить
Внимание! За постинг в данном форуме $m не начисляются.
Внимание! Для написания сообщения необходимо авторизоваться
Текст сообщения*
Прикрепить файл