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

25.05.17

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

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

Скачать исходный код

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

ВВЕДЕНИЕ

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

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

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

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

Предлагаемый алгоритм по своей схеме похож на «метод Больцано-Вейерштрасса», опубликованный "группой математиков" в 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%

Перенос данных из УТ 10.3 в УТ 11 / КА 2 / ERP 2. Переносятся документы, справочники и остатки

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

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

50722 45650 руб.

24.04.2015    190673    270    239    

269

"Акты сверки +" Групповая подготовка и рассылка актов сверки для Бухгалтерии 3.0.

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

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

3000 руб.

25.11.2020    22380    180    4    

160

УТ 11, КА 2, ERP 2: Настраиваемые под каждую организацию печать и подпись ответственных лиц в печатных формах (ТОРГ-12, Счёт-фактура, УПД, УКД, Заказ клиента, Акт сверки, М-15 и др.)

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

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

12000 руб.

13.03.2018    56743    184    76    

116

Автоматический зачет авансов в 1С:УНФ по ФИФО

Взаиморасчеты Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Россия Управленческий учет Платные (руб)

Знаем о взаиморасчетах в Управлении нашей фирмой все, что только можно знать. Самая большая проблема взаиморасчетов в УНФ в том, что зависают непонятные долги и предоплаты, в Пульсе бизнеса показываются неадекватные цифры, отчеты по долгам показывают не пойми что.

12000 руб.

22.07.2021    23716    25    34    

32

Дебиторская задолженность по срокам долга

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

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

15120 руб.

28.09.2012    94719    589    281    

140

Групповое формирование, согласование, печать и отправка по e-mail актов сверок взаиморасчетов (Бухгалтерия предприятия, ред. 3.0)

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

Указывайте любой период, список организаций, контрагентов, видов договоров (с покупателем, с поставщиком и др.), счетов бухгалтерского учёта, валюту, необходимость детализации по договорам, список печатных форм и форматов их сохранения, а затем формируйте, согласовывайте, контролируйте, печатайте и отправляйте по e-mail готовые акты сверок прямо из 1С: Бухгалтерия предприятия, ред. 3.0.

9000 руб.

03.04.2018    30633    64    24    

64
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
95. vendim 24 09.08.18 12:57 Сейчас в теме
Спасибо огромное! На базе приведённого автором алгоритма сделал невозможное: отчёт, который формировался часами и нередко вываливался из-за переполнения памяти на скуле, теперь формируется всего 2 минуты! Фантастика!
98. Mellow 58 16.11.18 21:07 Сейчас в теме
Добрий день!

Подскажите пожалуйста почему когда добавляеш сделку и пробееш сделать групировку по сделка суми не сходятся с стандартним отчетом "Взаиморасчети с контрагентами"
99. 028 01.02.19 13:42 Сейчас в теме
Здесь будет работать?
Управление торговым предприятием для Казахстана, редакция 2.0
100. ildarovich 7861 01.02.19 14:46 Сейчас в теме
Не знаю. У меня этой конфигурации нет и не знаю, на основе чего она написана. Если на базе УТ10, то будет.
101. 028 04.02.19 09:32 Сейчас в теме
Отчет учитывает на какую реализацию ТМЗ был сделан возврат который был сделан на основании этой реализации?
102. ildarovich 7861 04.02.19 16:36 Сейчас в теме
(101) Нет, не учитывает. Возврат, скорее всего, делает проводки не сторнированием проводок датой документа отгрузки, а записями с датой возврата. Тогда, с точки зрения отчета, возврат считается оплатой и погашает (ФИФО!) самый ранний долг.
103. Red_Devil 179 28.02.19 17:00 Сейчас в теме
а для работы с поставщиками подобный есть? Желательно одновременно и с поставщиками и покупателями
104. insurgut 207 03.07.19 14:31 Сейчас в теме
Хочу автора поблагодарить за данный алгоритм. С видоизменением его можно применить абсолютно к любой конфигурации. Нужна детализация по договору - добавил группировку. Нужно в целом по контрагенту - без проблем. Не раз выручал при решении разного рода задач, связанных с расчётом даты просрочки, а так же суммы просрочки как с учетом отсрочки, так и без.
105. insurgut 207 08.07.19 09:44 Сейчас в теме
Столкнулся с одним нюансом. А именно. Провели реализацию датой 20.08.0219. Оплат нет. Вроде как в просрочку должна выйти с огромным числом дней задолженности, но не выходит.

На нулевом шаге имеем Край = 03.07.2002 5:11:29, в оборотах период = 20.08.0219, и по условию результирующего объединения в отчет строка не выходит. Если добавить ещё один шаг (1073741824), то Край будет где-то в 1985 году, т.е. наращивать число шагов бессмысленно в данном случае. Как обойти данный момент, чтобы документ выводился в просрочку несмотря на ошибку ввода даты документа?
108. vis_tmp 32 27.04.20 21:39 Сейчас в теме
Добрый день!
Проверял ваш отчёт в своей базе и обнаружил случай расхождения сумма в отчёте с остатками в регистре.
В верхней части картинки ваш отчёт и типовой, оба с отборами по организации и контрагенту.
Все остатки в разрезе договоров совпадают.
Но, если в вашем отчёте отбор по контрагенту снять, то суммы остатков по договорам становятся другие, не соответствующие остаткам.
Может ли это быть из-за того, что все остатки по этим договорам созданы одним и тем же документов ввода начальных остатков?
Или проблема в чём-то другом?
Прикрепленные файлы:
109. CheBurator 3119 28.04.20 02:47 Сейчас в теме
(108) Левый нижний - "Машиностроительная Асанова" - это откуда?
110. vis_tmp 32 28.04.20 06:51 Сейчас в теме
(109)Проверил ещё и универсальным отчетом по регистру - суммы остатков по контрагенту "БАНК РУССКИЙ СТАНДАРТ ЗАО" по договорам такие же, как и на прошлой картинке сверху слева и справа.
И, смотрю, в самом документе начальных остатков суммы эти же.
Договор "Машиностроительная Асанова" в остатках присутствует, но эта сумма у другого контрагента!
Какой-то сбой, мне кажется, в алгоритме?
Прикрепленные файлы:
111. ildarovich 7861 28.04.20 15:39 Сейчас в теме
(110) Одновременность движений документа "корректировка долга" является определенной проблемой для алгоритма. Могут слегка искажаться долги по документам. Но не так сильно. Да и при сложении распределенных долгов сумма измениться не должна (разве что на копейки).

Поэтому, по-моему, вряд ли здесь ошибка алгоритма. Больше похоже на косяки в базе. То есть сделать копию базы, выгрузить - загрузить, тестирование-исправление, отменить проведение, провести (по этому контрагенту) и прочие "шаманские пляски" я бы в первую очередь попробовал. Потом попробовать запрос в консоли (вне СКД), потом просмотреть временные таблицы - я бы так поотлаживался. То есть без отладки на конкретных данных больше сказать ничего не могу.
122. user817897 2 14.05.20 23:13 Сейчас в теме
(0) подскажите пожалуйста какой отчёт лучше скачать?
123. ildarovich 7861 15.05.20 14:22 Сейчас в теме
(122) Второй (просроченные долги). В нем еще подсвечиваются просроченные накладные. Если задано допустимое число дней просрочки.
124. user817897 2 15.05.20 17:04 Сейчас в теме
112. CheBurator 3119 29.04.20 03:01 Сейчас в теме
(110)
Договор "Машиностроительная Асанова" в остатках присутствует, но эта сумма у другого контрагента!


да это запросто, ручками накосячили или программно подсунули в документе где-то - Контрагент Петров в документе, а договор в документе - от сидорова.
Пройдитесь по документам этого конррагента и/или этого договора и перевыьерите контрагента - при перевыборе контрагента вставится договор контрагенрта, а не чужой.
или наоброт обеспечьте чтобы если договор в документ от васи - то и контрагент аставьте ваю. то есть приводите документ либо к договору, либо к контрагенту.
.
БЭКАП!!!
ибо могут поехать и скорее всего поедут раскладкаи долгов итд.
Ппосле исправленйи пересчитать базу надо будет
114. vis_tmp 32 29.04.20 07:33 Сейчас в теме
(112)Я проверил универсальным отчётом:
а) движения по этому контрагенту сделаны единственным документом "Корректировка записей регистров Ц--00000018 от 31.12.2013 23:59:59"
б) все договоры соответствуют своим Организации и Контрагенту

В тоже время, вместо полного документа "Корректировка записей регистров" попробовал создать новый и вручную занёс в него только строки по этому контрагенту - в этом случае ваш отчет показывает верные остатки, совпадающие с универсальным отчётом.
Прикрепленные файлы:
115. CheBurator 3119 29.04.20 10:49 Сейчас в теме
(114)
(112)Я проверил универсальным отчётом:
а) движения по этому контрагенту сделаны единственным документом "Корректировка записей регистров Ц--00000018 от 31.12.2013 23:59:59"
б) все договоры соответствуют своим Организации и Контрагенту

- в документе - может быть.
но в движениях документа - не обязательно! то есть изменили документ но не перепровели. на форме - норм, а в движениях - криво.

В тоже время, вместо полного документа "Корректировка записей регистров" попробовал создать новый и вручную занёс в него только строки по этому контрагенту - в этом случае ваш отчет показывает верные остатки, совпадающие с универсальным отчётом.

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

Или, как вариант, ваше расследование ситуации "неполное", отсюда не видно мне точно что и как. Вслепую по приборам лечу... ;-0
.
И да, отчет - не мой. Я просто мимо проходил.. ;-)
116. vis_tmp 32 29.04.20 12:51 Сейчас в теме
(115)
- в документе - может быть, но в движениях документа - не обязательно!

Этоже Корректировка записей регистров - там нет реквизитов, сразу записи регистра.
117. CheBurator 3119 29.04.20 16:09 Сейчас в теме
(116) хм, я не спец по 8-ке, но я ОЧЕНЬ сомневаюсь ч то в этой форме - ты ввел что-то в строку и она СРАЗУ записалась в регистр ИМЕННО так как ты ввел... может это все-таки документ? в котором "копия" структуры регистра..?
118. vis_tmp 32 29.04.20 18:22 Сейчас в теме
(117)А там не строки, а сразу набор записей регистра.
Прикрепленные файлы:
119. vis_tmp 32 30.04.20 08:12 Сейчас в теме
(112)
ручками накосячили или программно подсунули в документе где-то - Контрагент Петров в документе, а договор в документе - от сидорова

Вы были правы, в этом документе "Корректировка записей регистров" нашлись ещё записи с этими договорами, но с другим контрагентом.
Удалил их и Ваш отчет по этому контрагенту исправился.
Спасибо за наводку!
120. CheBurator 3119 30.04.20 19:27 Сейчас в теме
(119) Удалить их - это смело! Ведь вы "убили" часть информации, которая не просто так попала в корректировку регистров. Прежде чем убивать, надо было записать/запомнить контрагентов. Возможно в этих удаленных записях, имело смысл исправит договор на тот, который относится к другому контрагенту. и сверить данные в базе по этим другим контрагентам.
.
"Вы были правы, ..." - ну так о то ж. корректировка записей не просто так ведь делается из ниоткуда... Напрограммили криво заполнение, или ручками кривенько внесли...
121. vis_tmp 32 30.04.20 21:04 Сейчас в теме
(120)
Удалить их - это смело!
Не волнуйтесь - всё проверяется в копии базы.
113. CheBurator 3119 29.04.20 03:03 Сейчас в теме
прблемы по идее быть не должно. "проблема закроется сразу после документа корреатирвока в выводимом отчете. то есть
1-1=0 может показываться вотчете как -1+1=0
125. ValeriVP 1308 25.09.20 17:35 Сейчас в теме
Подскажите плиз.
У меня задача считать просрочку не от даты движения + данные договора, а от даты указанной в документе реализации.
Как это правильно сделать?
И порядок документов для ФИФО должен считаться относительно даты оплаты.
126. ildarovich 7861 29.09.20 14:40 Сейчас в теме
(125) Кажется, вы сами уже ответили на половину вопроса:
И порядок документов для ФИФО должен считаться относительно даты оплаты
Во втором запросе пакета есть поле "Период". Вот его и нужно заменить на "дату оплаты" из документа реализации. Регистратор в запросе есть, поэтому сделать это будет несложно.
Фактически мы как бы переносим момент возникновения долга с момента отгрузки на дату оплаты.

В результате приведенным пакетным запросом определится набор неоплаченных накладных. И среди них по простому правилу "дата оплаты еще неоплаченной накладной меньше текущей" можно будет найти просроченные.
ValeriVP; +1 Ответить
127. tolyan_ekb 104 26.01.21 09:20 Сейчас в теме
При формировании нужно самостоятельно рассчитывать отрезки времени в зависимости от длительности учета в базе? Если учет ведется более 20 лет, то отрезков будет больше?
128. ildarovich 7861 26.01.21 16:20 Сейчас в теме
(127) Вряд-ли это реальная потребность, но если вдруг понадобится, то потребуется изначально взять вдвое больший начальный отрезок 536870912 * 2 = 1073741824 секунд - это примерно 34 года и начинать с него.

То есть получается, что, строго говоря, не "отрезков будет больше", а вдвое больше будет начальный отрезок. Ну и на одну больше будет число итераций при сокращении интервала поиска.
129. tolyan_ekb 104 27.01.21 06:27 Сейчас в теме
(128) спасибо за ответ, про начальный отрезок я и хотел спросить.
130. sasha-progman 20.02.21 13:57 Сейчас в теме
Спасибо... тоже уперся в стандартной модели во время выполнения... Решил уже регистры дополнительные сделать и чудом наткнулся на статью....
131. evn-zorin 32 01.06.21 14:57 Сейчас в теме
подскажите, есть ли вариант данного запроса/отчёта по рабочим/календарным дням? (с возможностью выбора).
132. ildarovich 7861 02.06.21 11:11 Сейчас в теме
(131) Варианта нет. Сейчас считается по календарным дням. Теоретически календарные дни добавить несложно.
133. пользователь 09.11.21 15:30
Сообщение было скрыто модератором.
...
134. zonder2000 09.11.21 15:58 Сейчас в теме
дает ошибку Синтаксическая ошибка "="
И Шаг.Край < <<?>>= Обороты.Период

что это может означать?запрос перенес в СКД
136. olegalex 61 24.12.21 09:34 Сейчас в теме
Добрый день! А нельзя ли такой отчет для 1С Бухгалтерия предприятия 3.0 ?
137. ildarovich 7861 24.12.21 14:43 Сейчас в теме
138. r.moschenskiy 23 11.02.22 11:32 Сейчас в теме
Если был проведён документ, к примеру Платежное поручение входящее, на конец дня 09.02.2022 23:59:59, то эта сумма не попадает в отчёт за 09.02.2022. Как это можно исправить?
139. ARROW 15.05.23 17:28 Сейчас в теме
Добрый день !
а как в отчете можно вывести все документы оплачены черные а не оплачиваемые красные ?
140. Tciban 13.09.23 15:09 Сейчас в теме
Уважаемый Сергей! Начал активно использовать ваш запрос, но сегодня наткнулся на странность. вот движения взаиморасчетов по одному договору - привожу скриншот. Как мы видим везде было везде было парами оплат/отгрузка или отгрузка оплата. Ничего в одну секунду не было. Но почему то показывает как неоплаченную реализацию 00000000114 от 03.02.2023 12:00:12 если дату отчета задаем например 01.06.2023. Если задавать текущую - то все норм, не попадает в неоплаченные.

В чем может быть проблема?
В целом же я пытаюсь решить проблему поиска реализаций, оплаченных за период. Т.е. у нас есть реализации неоплаченные до начала периода, есть реализации отгруженные и оплаченные в течении заданного периода. Надо найти их и заодно определить есть ли просрочка оплаты. Как полагаете - можно ли решить проблему только запросом? Сейчас я получаю неоплаченные реализации до начала исследуемого периода и все реализации до периода и ищу для них документы оплаты двигаясь перебором движений взаиморасчетов пока не будет закрыт долг до проведения реализации+сумма реализации.
Прикрепленные файлы:
141. Tciban 14.09.23 07:53 Сейчас в теме
(140) Разобрался, видимо перепутал от усталости, прошу прощения. Вопрос про оплаченную реализацию снимается, а я еще больше укрепился в уверенности в ваших решениях!

Но по второй части все же надеюсь услышать совет :)
142. ildarovich 7861 14.09.23 14:59 Сейчас в теме
(140) Если я правильно понял вопрос, то речь идет о связывании отгрузок с оплатами в пределах заданного периода. То есть о FIFO но для денег. В (52) я отвечал на подобный вопрос и приводил ссылки. На Инфостарте много статей на эту тему, в том числе в чисто запросной технике. Но там речь идет о том, чтобы сделать как-нибудь, то есть проблема скорости для больших баз не решается.

У меня были заготовки для быстрого ФИФО, где не только нарастающий итог по отгрузкам и оплатам считается, но и делается связывание. Но запросы получаются головоломными. А так как, кроме академического, интереса не увидел, не стал публиковать.

Сейчас, после появления функции АВТОНОМЕРЗАПИСИ() и других, они, возможно, бы и упростились, но большого оправданного интереса по прежнему не вижу. Как-то фокус внимания публики переместился в другую сторону.
143. Tciban 15.09.23 09:21 Сейчас в теме
(142)Спасибо! Посмотрю в указанные вами направления :) Хотя возможно технология обработки результатов запроса перед передачей таблицы в СКД не такая уж и медленная, в моем случае за месяц отрабатывается за 25 секунд максимум, это с учетом поиска оплат для всех реализаций - неоплаченных до начала месяца и тех, что были добавлены в исследуемом периоде и возможно оплачены. В принципе неплохой результат, время выполнения вполне комфортное. Интерес выполнения одним запросом только в возможности использования функционала СКД для оптимизации путем настройки отборов и т.п.

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