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

25.05.17

Учетные задачи - Взаиморасчеты

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
[УК10.3, УПП 1.3, КА] Отчет "Неоплаченные долги ФИФО"
.erf 11,38Kb
335
335 Скачать (1 SM) Купить за 1 850 руб.
[УК10.3, УПП 1.3, КА] Отчет "Просроченные долги ФИФО"
.erf 12,18Kb
436
436 Скачать (1 SM) Купить за 1 850 руб.

ВВЕДЕНИЕ

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

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

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

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

Предлагаемый алгоритм по своей схеме похож на «метод Больцано-Вейерштрасса», опубликованный "группой математиков" в 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 КАК Шаг) КАК Шаг
		ЛЕВОЕ СОЕДИНЕНИЕ Обороты КАК Обороты
		ПО Шаг.ДоговорКонтрагента = Обороты.ДоговорКонтрагента
			И (Обороты.Период = Шаг.Край)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ОБЩИЕ ВЫВОДЫ

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

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

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

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

P.S.: По просьбе автора еще одной публикации, посвященной этой теме, добавлена ссылка: Универсальный отчет "[П]: Дебиторка & Кредиторка" [УТ, УПП, КА].

ФИФО Дебиторка Отчет

См. также

SALE! 10%

Перенос данных 1C Взаиморасчеты Оптовая торговля Логистика, склад и ТМЦ Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Управленческий учет Платные (руб)

Можно проверить до покупки, оставьте заявку! Воспользовались более 268 компаний! Перенос данных из УТ 10.3 в УТ 11 | из УТ 10.3 в КА 2 | из УТ 10.3 в ERP. Предлагаем качественное и проверенное временем решение для перехода с УТ 10.3. Можно перенести начальные остатки, нормативно-справочную информацию и все возможные документы. При выгрузке можно установить отбор по периоду, организациям и складам. При выходе новых релизов конфигураций 1C оперативно выпускаем обновление переноса данных.

55778 50200 руб.

24.04.2015    194950    150    243    

280

Печатные формы Взаиморасчеты Оптовая торговля Производство готовой продукции (работ, услуг) Акт сверки Бухгалтер Пользователь Оперативный учет Управляемые формы 1С:Управление торговлей 11 Россия Бухгалтерский учет Управленческий учет Платные (руб)

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

14400 руб.

13.03.2018    60695    207    76    

120

Взаиморасчеты Email рассылки Акт сверки Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Платные (руб)

Внешняя обработка для Бухгалтерии 3.0 - позволяет автоматически формировать документы «Акт сверки расчетов» с контрагентами за выбранный период с последующей фоновой отправкой на почту контрагента.

3000 руб.

25.11.2020    24473    238    8    

205

Взаиморасчеты Бухгалтер Пользователь Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Бухгалтерский учет Управленческий учет Платные (руб)

Один из лучших вариантов отчета по дебиторской задолженности в 1С. Отображает сроки возникновения задолженности, просроченной задолженности с точностью до регистратора, а также многое другое, вне зависимости от объекта расчетов (УТ 11.3, 11.4, 11.5, КА 2.4, 2.5, ERP 2.4, 2.5), состояния флажка По документам расчета ( УТ 10, КА 1.1, УПП 1.3) в договоре. Группирует задолженность по интервалам. Имеет большое количество настроек. Не требует доработок конфигурации. Не требует перепроведения документов.

15120 руб.

28.09.2012    96981    593    283    

145

Учет доходов и расходов Взаиморасчеты БДР, БДДС Бухгалтер Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Управленческий учет Платные (руб)

Мы доработали типовой платежный календарь, добавив в него планируемые постоянные расходы. Теперь можно видеть картину денежных средств в совокупности с текущей динамикой ожидаемых поступлений и расходов. Отчет позволяет увидеть остатки денежных средств в кассе и банке, их движение в разрезе статей ДДС с возможностью выбрать любой период (день, неделя, месяц). Данный отчет подходит для всех основных конфигураций линейки продуктов 1С:Предприятие 8.3 (8.3.18.1289): 1С:Бухгалтерия предприятия, редакция 3.0 (3.0.77.95), 1С:Управление торговлей, 1С:Комплексная автоматизация 2 (2.4.11.67), Объединенное решение: Модуль 1С:CRM 3 (3.0.21.3) +1С:ERP Управление предприятием 2 (2.4.13.111). Также есть возможность адаптации отчета под другие конфигурации. Мобильное приложение работает как на Android, так и на IOS.

2880 руб.

16.03.2021    22123    13    13    

29

Взаиморасчеты Бухгалтер Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение позволяет гибко настроить расчет и начисление пени в 1С в организации. Представлена в двух вариантах исполнения: как расширение и как обработка.

7200 руб.

18.10.2017    39128    72    46    

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



Коллеги, кто сталкивался с этой "засадой", как вы боретесь с этим? У нас ,например, есть и приход с минусом и расход с минусом.
15. Pawlick 10 18.03.14 19:15 Сейчас в теме
Очень интересное решение, очень.

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

Золотые слова, ildarovich, золотые слова...
16. degtyarev85 01.04.14 14:20 Сейчас в теме
Подскажите, Шаг134217728 будет выглядеть так?

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

СГРУППИРОВАТЬ ПО
	Шаг.Договор,
	Шаг.Край,
	Шаг.Долг
Показать
17. ildarovich 7930 02.04.14 13:51 Сейчас в теме
18. EarlyBird 7 04.04.14 04:21 Сейчас в теме
Коллеги, ваш интеллект потрясает, респект.
Я вообще ничего не понял из вашей дискуссии )
BoBaH; Andreeei; Deryni; TeMochkiN; kuzyara; jaroslav.h; Eleet; Solikamsk; Stepan_1c; olezhe; melenaspb; romankoav; relanium86; qwertyasdzxc; for_sale; bulpi; +16 Ответить
19. relanium86 14 28.05.14 11:44 Сейчас в теме
На базе УПП объемом порядка 80Гб отчет выполняется по 60 счету 32сек. а по накоплению итогов у меня шуршало минут 10 в среднем.
ildarovich; +1 Ответить
20. mxm2 1268 29.05.14 16:40 Сейчас в теме
Как-будто еще одна особенность отчета есть: если в момент возникновения долга была переплата (аванс), то сумма просроченного долга считается неверно (в нее добавляется сумма аванса).
21. ildarovich 7930 02.06.14 12:17 Сейчас в теме
(20) У меня эта ситуация не воспроизводится. Но, возможно, такая ошибка была в самой первой версии размещенного отчета, которая была сразу же исправлена. Сейчас везде проверяется, что по регистратору
Обороты.СуммаВзаиморасчетовОборот > 0
Поэтому суммы аванса в отчет попасть никак не могут. Попробуйте использовать последние версии отчетов.
22. distorshion 30 01.07.14 13:15 Сейчас в теме
А есть версия кредиторской задолженности?
23. ildarovich 7930 01.07.14 13:44 Сейчас в теме
(22) distorshion, если разговор о УТ 10.3, УПП 1.3 или КА, то сделать ничего не стоит - нужно поменять знаки в трех местах. Например,
Остатки.СуммаВзаиморасчетовОстаток КАК Долг
поменять на
-Остатки.СуммаВзаиморасчетовОстаток КАК Долг
И в таком же количестве мест перевернуть условия. Например,
Остатки.СуммаВзаиморасчетовОстаток > 0
поменять на
Остатки.СуммаВзаиморасчетовОстаток < 0
Ну и протестировать, конечно.
distorshion; +1 Ответить
107. vis_tmp 32 27.04.20 17:07 Сейчас в теме
(23)Не совсем понятно...
"ГДЕ Остатки.СуммаВзаиморасчетовОстаток > 0" есть только одном месте в самом начале, на в трёх местах.
24. distorshion 30 01.07.14 14:04 Сейчас в теме
Спасибо!!!!! Мегареспект тебе добрый человек.
25. RustIG 1747 03.07.14 13:52 Сейчас в теме
(0) как много я пропустил ваших статей! (январь, февраль 2014)
плюс за идею
плюс за реализацию
круто
26. Pawlick 10 12.07.14 20:17 Сейчас в теме
Все таки по моему отчет имеет одну особенность.

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


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

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

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

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

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

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

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

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


PS. Если кинете в личку адрес почты скину Вам УТ10 в которой смоделирована ситуация.



27. Pawlick 10 15.07.14 00:43 Сейчас в теме
В(26) Pawlick,
Все таки по моему отчет имеет одну особенность.

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

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

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

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

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

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

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

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

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

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

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

Может кто подскажет?
62. ildarovich 7930 28.10.15 12:40 Сейчас в теме
(60) sapsan322, сомневаюсь, что в данной задаче имеет смысл делать отбор по реквизиту регистратора. Это специально не разрешено. Так вы можете "выдернуть" из цепочки взаиморасчетов отдельные документы, исказив их логику. Если интересует "проект", сделка, то эта информация должна в регистре отражаться, а к отборам по его измерениям вроде бы доступ есть. Если речь идет об ответственных (менеджерах), то объясните подробнее логику бизнес-задачи - можно будет подумать, как это сделать. Возможно, подтолкнете решение следующей задачи.
63. sapsan322 28.10.15 15:39 Сейчас в теме
(62) Стоит задача сделать отбор по Ответственному менеджеру и ТипуЗаказа.
ТипЗаказа - это реквизит с типом перечисление и в нем имеется 3 значения: Продажа, Ремонт детали и Ремонт Автомобиля.
Попробовал сделать через сделку, и тоже не доступны измерения для отбора.
97. IssakN 45 09.11.18 17:35 Сейчас в теме
Добрый вечер! пробую переделать ПросроченныеДолгиФИФО_ под свою организацию но к сожалению пока не выходит. Заменен регистр на мой, переписаны все реквизиты но выводит несколько не то что необходимо. Сделал выборку по одному контрагенту - скриншоты прилагаю. ВремТаб - результат выполнения временных таблиц. без - результат выполнения последнего запроса пакета исключающий соединение с временнойтаблицей Шаг0. Буду премного благодарен за пояснение.

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

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

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

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

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

СГРУППИРОВАТЬ ПО
	Шаг.ГрупповойДоговор,
	Шаг.Край,
	Шаг.Долг
;

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

СГРУППИРОВАТЬ ПО
	Шаг.ГрупповойДоговор,
	Шаг.Край,
	Шаг.Долг
;

////////////////////////////////////////////////////////////­////////////////////
ВЫБРАТЬ РАЗРЕШЕННЫЕ
	Шаг.ГрупповойДоговор.Организация КАК Организация,
	Шаг.ГрупповойДоговор.Контрагент КАК Контрагент,
	Шаг.ГрупповойДоговор КАК ГрупповойДоговор,
	Обороты.Период КАК Период,
	Обороты.Регистратор КАК Регистратор,
	ВЫБОР
		КОГДА Обороты.Период = Шаг.Край
			ТОГДА Шаг.Долг * Обороты.СуммаОборот / Шаг.Сумма
		ИНАЧЕ Обороты.СуммаОборот
	КОНЕЦ КАК Долг,
	РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) КАК Долгота,
	60 КАК Предел,
	ВЫБОР
		КОГДА РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) > 1
			ТОГДА РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) - 1
		ИНАЧЕ 0
	КОНЕЦ КАК Задержка,
	ВЫБОР
		КОГДА РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) > 1
			ТОГДА ВЫБОР
					КОГДА Обороты.Период = Шаг.Край
						ТОГДА Шаг.Долг * Обороты.СуммаОборот / Шаг.Сумма
					ИНАЧЕ Обороты.СуммаОборот
				КОНЕЦ
		ИНАЧЕ 0
	КОНЕЦ КАК Просрочено
{ВЫБРАТЬ
	Организация.*,
	Контрагент.*,
	ГрупповойДоговор.*,
	Период,
	Регистратор.*,
	Долг,
	Долгота,
	Предел,
	Задержка,
	Просрочено}
ИЗ
	Шаг0 КАК Шаг
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.РО_ВзаиморасчетыПоГрупповымДоговорамКонтрагентов.Обороты(
				,
				&Дата,
				Регистратор,
				ГрупповойДоговор В
					(ВЫБРАТЬ
						Шаг.ГрупповойДоговор
					ИЗ
						Шаг0 КАК Шаг)) КАК Обороты
		ПО Шаг.ГрупповойДоговор = Обороты.ГрупповойДоговор
			И Шаг.Край <= Обороты.Период
ГДЕ
	Обороты.СуммаОборот > 0
{ГДЕ
	Обороты.Период,
	Обороты.Регистратор,
	(ВЫБОР
			КОГДА Обороты.Период = Шаг.Край
				ТОГДА Шаг.Долг * Обороты.СуммаОборот / Шаг.Сумма
			ИНАЧЕ Обороты.СуммаОборот
		КОНЕЦ) КАК Долг,
	(РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ)) КАК Долгота,
	(60) КАК Предел,
	(ВЫБОР
			КОГДА РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) > 1
				ТОГДА РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) - 1
			ИНАЧЕ 0
		КОНЕЦ) КАК Задержка,
	(ВЫБОР
			КОГДА РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) > 1
				ТОГДА ВЫБОР
						КОГДА Обороты.Период = Шаг.Край
							ТОГДА Шаг.Долг * Обороты.СуммаОборот / Шаг.Сумма
						ИНАЧЕ Обороты.СуммаОборот
					КОНЕЦ
			ИНАЧЕ 0
		КОНЕЦ) КАК Просрочено}
Показать
Прикрепленные файлы:
61. Зеленоград 27.10.15 17:58 Сейчас в теме
Всем комментаторам в этой ветке термин "Тупой одинэсник" неприменим.
64. insurgut 208 09.11.15 17:00 Сейчас в теме
С позволения автора выкладываю переделку отчета под УТ 11.1.
Прикрепленные файлы:
ПросроченныеДолгиФИФО_УТ11.erf
user1985542; Sergeevich; vis_tmp; xan333; forseil; Spacer; Volchock; ildarovich; +8 Ответить
65. ildarovich 7930 11.11.15 10:21 Сейчас в теме
66. sapit 82 07.12.15 13:29 Сейчас в теме
Использовал ваш алгоритм в отчете. Применить как описано в публикации не получилось из за "ложки сахара" - при реальном использовании отчета расчет по ФИФО делается по дате оплаты, а не дате отгрузки. Можно добавить к дате оплаты время из даты отгрузки, но по факту оказалось что в эту самую секунду оформлено до 20 документов отгрузки или поставки. Данные документы появляются при массовом вводе документов прошлым числом (реализации за период оформляются на одну дату), поступают из БД поставщика и т.п. И все бы ничего, но округление в такой ситуации вызывает расхождение между конечным остатком по регистру и результатом в отчете. В итоге ваш алгоритм использую для выборки оборотов с небольшим "запасом", а дальше уже обычным перебором. Пока не было времени протестировать причину, но на действительно большой БД время выполнения запроса вашего алгоритма и "стандартного" примерно одинаковое. Оставил ваш, так как в итоге все равно потребовалась промежуточная ТЗ.
67. ildarovich 7930 07.12.15 18:06 Сейчас в теме
(66) sapit,
1) выигрыш в скорости будет тем больше, чем больше отгрузок у ОДНОГО контрагента. Если на каждого контрагента отгрузок сравнительно немного, то и выигрыш не будет заметен;
2) вопрос одинакового времени легко решить, добавляя секунды ко времени ОПЛАТЫ, взятые из номера, например. Но я все же еще раз подчеркиваю. Если много отгрузок стоят на одно и то же время оплаты, то с точки зрения неоплаченности их не нужно разделять - лучше рассматривать их как одну большую отгрузку и находить общий процент неоплаченности этой отгрузки и применять затем этот процент к каждой составляющей. Погрешность округления можно исключить, отнеся копейки на последнюю отгрузку в пачке;
3) в запросе, приведенном в статье и в приложенной обработке до сих пор не исправлена небольшая неточность, которую я выявил в процессе "закадрового" общения с пользователями отчета. В предпоследнем запросе пакета вместо
ВЫБОР
        КОГДА Обороты.Период = Шаг.Край
            ТОГДА Шаг.Долг / Шаг.Сумма
        ИНАЧЕ 1
    КОНЕЦ * Обороты.СуммаВзаиморасчетовОборот КАК Долг,
нужно писать
ВЫБОР
        КОГДА Обороты.Период = Шаг.Край
            ТОГДА Обороты.СуммаВзаиморасчетовОборот * Шаг.Долг / Шаг.Сумма
        ИНАЧЕ Обороты.СуммаВзаиморасчетовОборот
    КОНЕЦ КАК Долг,
Это исключит лишние ошибки округления!
SashaSashaSashka; +1 Ответить
68. sapit 82 07.12.15 22:11 Сейчас в теме
(67) по пункту 1 -проверю. 2 -все таки много минусов. Пояснить поставщику(покупателю) что мы оплачиваем пропорционально 10 поставок невозможно. Считать отдельно что оплачено, а что нет - возврат к ведению учета по докуменам расчетов. Отчет в этом случае теряет часть функционала - можно посмотреть ситуацию по компании в целом, но на основании полученных данных решить что оплачиваем именно эту поставку становится невозможным. 3 - проверю.
73. корум 288 28.10.16 12:05 Сейчас в теме
(68) попробуйте не лепить все документы за день в одну секунду.

Вопросы поставщиков/покупателей исчезнут автоматически.

В сутках 86400 секунд, у вас что, по одному контрагенту в один день больше документов??
144. KirillLog 14.11.24 14:51 Сейчас в теме
(73)
(68) попробуйте не лепить все документы за день в одну секунду.

Вопросы поставщиков/покупателей исчезнут автоматически.

В сутках 86400 секунд, у вас что, по одному контрагенту в один день больше документов??


Ну тут видимо недопонимание есть, так что вставлю свои "пять рублей".
Распределение сумм по ФИФО по документам в данном случае происходит не по дате документа, а по дате платежа. Дату платежа указывает без времени. Соответственно, если в одни день есть несколько документов с разным временем но у них день оплаты один и тот же, то и дата платежа будет у них одинаковая (время 00:00:00). Поэтому тут не лепится все документы за день в одну секунду, а у них одинаковая дата платежа, которая указывается без времени.
145. корум 288 14.11.24 15:52 Сейчас в теме
(144) ответ на комментарий 2016 года.
Главное - выдержка!
106. vis_tmp 32 27.04.20 15:57 Сейчас в теме
(67)
	ВЫБОР
		КОГДА РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) > Шаг.ДоговорКонтрагента.ДопустимоеЧислоДнейЗадолженности
			ТОГДА ВЫБОР
					КОГДА Обороты.Период = Шаг.Край
						ТОГДА Шаг.Долг / Шаг.Сумма
					ИНАЧЕ 1
				КОНЕЦ * Обороты.СуммаВзаиморасчетовОборот
		ИНАЧЕ 0
	КОНЕЦ КАК Просрочено
Показать

И тут аналогично надо поправить?
69. angler225 126 16.06.16 14:28 Сейчас в теме
Спасибо, отчет помог. И что главное, его удалось доработать под нашу измененную конфигурацию (Количество дней отсрочки реквизит справочника Торговые точки) не сломав голову.
70. yurikmellon 6 21.09.16 13:03 Сейчас в теме
71. labirk 11 25.10.16 06:44 Сейчас в теме
Спасибо, действительно очень быстро работает!
72. Ibrogim 1327 28.10.16 10:47 Сейчас в теме
Божественно!

Думаю приспособить под расчёт прибыли по оплаченным реализациям
p.s. На Уралмаше улицу, на которой есть остановка "Веер" именуют Вейерштрасса
74. ildarovich 7930 28.10.16 12:34 Сейчас в теме
(72) Ibrogim, учтите, пожалуйста замечание в (67). Сделал "детскую" ошибку: сначала поделил, потом умножил, когда всегда для избежания потери точности нужно сначала умножать, потом делить. В этой задаче это иногда (редко) проявляется в виде копеечных расхождений. Рецепт исправления в (67).
75. Tciban 19.01.17 15:44 Сейчас в теме
Уважаемый Сергей! Применил вашу обработку к старенькой УППшечке - все летает, алгоритм великолепен. Но мне нужно рассчитывать дни просрочки и даты получения денег как дата документа + отсрочка в рабочих днях. Попробовал пару способов, описанных на инфостарте - сразу начинаются резкие тормоза, при попытке исполнить отчет без отборов так и вовсе оут оф мемори! Пожалуйста подскажите как лучше всего реализовать мою задачу! Ссылочку бы на наилучший способ прибавления рабочих дней к датам в запросе!
76. CheBurator 2712 20.01.17 14:19 Сейчас в теме
(75) сначала количество рабочих дней по производственному календарю перевести в календарные. далее штатно.
вдобавок есть толкование (встречался разное) - например 1. если календарная дата (острочка в календарных днях например) платежа попадает на нерабочий ден, то дата платежа переносится на первый рабочий день. или 2. попало на календарный нерабочий день - значит так и есть, банк не работает платеж пройдет позже. получится просрочка. поэтому платить надо думать раньше.. ;-)

для уточнения надо смотреть НПА
91. albert 568 01.11.17 12:48 Сейчас в теме
Тот же вопрос, что и в (75). Как переписать запрос для расчета просрочки по рабочим дням (точнее 2 варианта в зависимости от реквизита договора) с сохранением быстродействия?
77. nucha 97 28.01.17 00:28 Сейчас в теме
Реально быстрый отчет.
78. nucha 97 28.01.17 10:58 Сейчас в теме
(77) Оказывается этот алгоритм применяют школьники в игре угадай число. Один загадывает число до 10. Другой пытаясь его отгадать называет: 5. Первый должен ответить больше оно загаданного или меньше. Далее отгадывающий говорит: 3 если меньше 5 и 7 если больше 5 и т.д.
79. ZLENKO 398 16.05.17 10:27 Сейчас в теме
Хотел бы воссстановить историческую справедливость. Я был автором первого отчета в 2009 г. на infostart с использованием методики FIFO в запросе. Сейчас представлено бесплатное доработанное переиздание этого отчета http://infostart.ru/public/117647/ Сам отчет был написан в 2007 г. Просьба добавить в раздел "Некоторые ссылки". В качестве доказательства прилагаю скриншот :-)
Прикрепленные файлы:
81. ildarovich 7930 16.05.17 13:02 Сейчас в теме
82. ZLENKO 398 16.05.17 13:44 Сейчас в теме
80. ZLENKO 398 16.05.17 10:40 Сейчас в теме
Еще один proof link исторической справедливости прилагаю
Прикрепленные файлы:
83. German_Tagil 43 16.05.17 14:44 Сейчас в теме
Мда надо потрогать и подумать ...
84. zhry 7 25.05.17 12:36 Сейчас в теме
Здравствуйте!
Мне кажется в запросе есть ошибка в конце.
ИЗ
    Шаг0 КАК Шаг
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ВзаиморасчетыСКонтрагентами.Обороты( , &Дата,    Регистратор, ДоговорКонтрагента В (ВЫБРАТЬ Шаг.ДоговорКонтрагента ИЗ Шаг0 КАК Шаг)) КАК Обороты
        ПО Шаг.ДоговорКонтрагента = Обороты.ДоговорКонтрагента
            И Шаг.Край < = Обороты.Период


В оборотах могут вернуться документы оплаты, если они совпадают по времени с документами отгрузки. Скорее всего надо получать обороты во временную таблицу, убирать документы уменьшающие задолженности и уже потом работать с таблицей. Или я ошибаюсь?
ildarovich; +1 Ответить
85. ildarovich 7930 25.05.17 13:17 Сейчас в теме
(84) Сейчас отвечу наспех, по тексту в статье, не заглядывая в текст отчета в обработке. Наверное, вы правы. Видимо, о том же было замечание в (20). Учитывая еще (67), концовку действительно следует переписать. Но умозрительно кажется, что указанная вами неточность, должна приводить не к искажению суммы долга в строке, а к появлению в выдаче лишних строк с отрицательным долгом, которые легко убрать настройками в СКД.
Вспоминая свои тогдашние размышления, хотел для статьи написать запрос покороче, без лишних временных таблиц. А так, конечно, до временной таблицы Обороты нужно получить таблицу оборотов с регистратором, которую затем соединять с таблицей Шаг0.
86. ildarovich 7930 25.05.17 14:50 Сейчас в теме
(84) + (85) Скачал отчеты, посмотрел как в них. Все оказалось гораздо проще. Оказалось, что в статье по сравнению с отчетом не хватает условия
ГДЕ
	Обороты.СуммаВзаиморасчетовОборот > 0
То есть условие было просто пропущено не в обработках, а именно в статье.
Исправил теперь в статье, учел комментарий (67) про точность в статье и в обработках.
87. zhry 7 25.05.17 21:45 Сейчас в теме
За статью большое спасибо, я не мог решить проблему по просроченной дз. С вашей помощью вроде получается, и все гораздо проще чем кажется на первый взгляд.
88. krava_vlad 130 01.08.17 02:49 Сейчас в теме
Есть ли вариант переделанного отчета под БУ?
89. ildarovich 7930 01.08.17 11:05 Сейчас в теме
На данный момент у меня такого отчета нет, его необходимость для меня сомнительна. Вроде бы и счет 62 и 60 имеют аналитику по "документу расчета", откуда без труда можно увидеть просроченность. Да и штатный отчет имеется (ЗадолженностьПокупателейПоСрокамДолга).
В общем, укажите точно конфигурацию, для которой ищете отчет, и причины, почему типовой отчет не подходит. Если причины будут вескими, отчет можно доработать. Это не долго - достаточно переписать первый подзапрос в запросе.
90. dimaxx 42 04.08.17 11:32 Сейчас в теме
Этот же отчет, только с анализом уже оплаченных документов. Цены бы ему не было. Чтобы видеть как закрываются документы в срок или нет и в какой срок с условием отсрочки... А так да скорость поражает. Спасибо за отчет очень интересный.
92. powerpc 225 24.05.18 11:01 Сейчас в теме
Автора однозначно в лауреаты нобелевской премии!
93. evn-zorin 33 02.07.18 11:22 Сейчас в теме
У автора очень грамотные посты, интересно, чем он занимается в повседневной жизни, профессор, доктор математических наук?
Оставьте свое сообщение