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

Публикация № 262300

Разработка - Практика программирования

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

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

ВВЕДЕНИЕ

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

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

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

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

Предлагаемый алгоритм по своей схеме похож на «метод Больцано-Вейерштрасса», опубликованный "группой математиков" в 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.: По просьбе автора еще одной публикации, посвященной этой теме, добавлена ссылка: Универсальный отчет "[П]: Дебиторка & Кредиторка" [УТ, УПП, КА].

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

Наименование Файл Версия Размер
[УК10.3, УПП 1.3, КА] Отчет "Неоплаченные долги ФИФО"

.erf 11,38Kb
25.05.17
311
.erf 11,38Kb 311 Скачать
[УК10.3, УПП 1.3, КА] Отчет "Просроченные долги ФИФО"

.erf 12,18Kb
25.05.17
409
.erf 12,18Kb 409 Скачать

Специальные предложения

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



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

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

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

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

СГРУППИРОВАТЬ ПО
	Шаг.Договор,
	Шаг.Край,
	Шаг.Долг
Показать
17. ildarovich 7017 02.04.14 13:51 Сейчас в теме
18. EarlyBird 6 04.04.14 04:21 Сейчас в теме
Коллеги, ваш интеллект потрясает, респект.
Я вообще ничего не понял из вашей дискуссии )
Deryni; TeMochkiN; kuzyara; jaroslav.h; Eleet; Solikamsk; Stepan_1c; olezhe; melenaspb; romankoav; relanium86; qwertyasdzxc; for_sale; bulpi; +14 Ответить
19. relanium86 14 28.05.14 11:44 Сейчас в теме
На базе УПП объемом порядка 80Гб отчет выполняется по 60 счету 32сек. а по накоплению итогов у меня шуршало минут 10 в среднем.
ildarovich; +1 Ответить
20. mxm2 1176 29.05.14 16:40 Сейчас в теме
Как-будто еще одна особенность отчета есть: если в момент возникновения долга была переплата (аванс), то сумма просроченного долга считается неверно (в нее добавляется сумма аванса).
21. ildarovich 7017 02.06.14 12:17 Сейчас в теме
(20) У меня эта ситуация не воспроизводится. Но, возможно, такая ошибка была в самой первой версии размещенного отчета, которая была сразу же исправлена. Сейчас везде проверяется, что по регистратору
Обороты.СуммаВзаиморасчетовОборот > 0
Поэтому суммы аванса в отчет попасть никак не могут. Попробуйте использовать последние версии отчетов.
22. distorshion 16 01.07.14 13:15 Сейчас в теме
А есть версия кредиторской задолженности?
23. ildarovich 7017 01.07.14 13:44 Сейчас в теме
(22) distorshion, если разговор о УТ 10.3, УПП 1.3 или КА, то сделать ничего не стоит - нужно поменять знаки в трех местах. Например,
Остатки.СуммаВзаиморасчетовОстаток КАК Долг
поменять на
-Остатки.СуммаВзаиморасчетовОстаток КАК Долг
И в таком же количестве мест перевернуть условия. Например,
Остатки.СуммаВзаиморасчетовОстаток > 0
поменять на
Остатки.СуммаВзаиморасчетовОстаток < 0
Ну и протестировать, конечно.
distorshion; +1 Ответить
107. vis_tmp 30 27.04.20 17:07 Сейчас в теме
(23)Не совсем понятно...
"ГДЕ Остатки.СуммаВзаиморасчетовОстаток > 0" есть только одном месте в самом начале, на в трёх местах.
24. distorshion 16 01.07.14 14:04 Сейчас в теме
Спасибо!!!!! Мегареспект тебе добрый человек.
25. Rustig 1478 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 7017 15.07.14 00:49 Сейчас в теме
(27) Pawlick, да не за что. - Я как раз за максимально критичное и недоверчивое отношение. Дополнительная проверка лишней никогда не бывает.
29. undo 29.07.14 18:58 Сейчас в теме
Я никогда не смотрел на решение таких задач со стороны математики, и поэтому офигел от написанного.
30. Denium79 14 10.10.14 06:42 Сейчас в теме
Автору огромное спасибо за отчет! Переписал его для складских остатков в своем УПП, получилась просто бомба! Потрясающее решение! Отчет по дебиторке хотелось бы для БП 2.0, может быть кто нибудь перепишет?
31. sam0511 8 22.10.14 09:16 Сейчас в теме
В обсуждении не заметил, но..
Неправильно отображается сумма долга по документам в следующей ситуации: есть предоплата, последующая отгрузка проведена двумя документами в одно время (бывает и такое...). Сумма долга распределяется на два этих документа, хотя, по идее должен отображаться одни. А в остальном супер.
32. ildarovich 7017 22.10.14 09:43 Сейчас в теме
(31) sam0511, как говорится, "это не баг - это фича". - Так и было задумано и я готов настаивать на том, что такое решение правильнее, чем отнесение оплаты на один из выбираемых случайно (на основе GUID) документов-односекундников. Потому, что пользователь не влияет на выбор оплачиваемого документа, а время у них одинаковое. Получается, что отчет при этом (при общепринятом подходе) ведет себя непредсказуемо, а этого быть не должно. Захотят поправить - передвинут нужный документ на секунду вперед.В статье об этом написано (где про ложку сахара).
34. ZLENKO 23.10.14 13:31 Сейчас в теме
(32) " "это не баг - это фича". - Так и было задумано и я готов настаивать на том, что такое решение правильнее, чем отнесение оплаты на один из выбираемых случайно (на основе GUID) документов-односекундников."

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

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

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

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

К сожалению у нас имеются проблемы к корректным подбором Реализаций в документах оплаты, тк отгрузка шла и идет по нескольким договорам, имеются возвратные накладные, клиенты могут сделать проплату на сумму, превышающую задолженность... Будем думать над обработкой, которая бы периодически восстанавливала корректность соотнесения оплат с отгрузками.
Либо пойдем по пути, предложенному Вами в решении "второй проблемы". Попробуем даже сделать проверку на этапе Сохранения реализации (до Проведения), чтобы Менеджер занялся просрочкой до передачи заявки на склад, а не в последний момент.
46. MakhoninMY 20.03.15 10:22 Сейчас в теме
Скажите пожалуйста можно ли на основе вашего решения рассчитать пени по просроченной задолженности без запроса в цикле по дням? Фактически нужно получить график просроченной задолженности по дням.
47. ildarovich 7017 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 7017 21.05.15 13:07 Сейчас в теме
(49) Glemar, тип документов никак не ограничивается - это все документы, делающие движения по регистру ВзаиморасчетыСКонтрагентами,
ГДЕ
    Обороты.СуммаВзаиморасчетовОборот > 0
Фактически сопоставления оплат с отгрузками не происходит. На сумму долга набираются последние отгрузки.
Если корректировка имела тот же знак в движении, что отгрузка, то она будет считаться "отгрузкой" и так же может посчитаться просроченной. Если корректировка имела другой знак, то она в отчет просто не попадет, повлияв на его содержание косвенно - через сумму долга.

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

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

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

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

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

Может кто подскажет?
62. ildarovich 7017 28.10.15 12:40 Сейчас в теме
(60) sapsan322, сомневаюсь, что в данной задаче имеет смысл делать отбор по реквизиту регистратора. Это специально не разрешено. Так вы можете "выдернуть" из цепочки взаиморасчетов отдельные документы, исказив их логику. Если интересует "проект", сделка, то эта информация должна в регистре отражаться, а к отборам по его измерениям вроде бы доступ есть. Если речь идет об ответственных (менеджерах), то объясните подробнее логику бизнес-задачи - можно будет подумать, как это сделать. Возможно, подтолкнете решение следующей задачи.
63. sapsan322 28.10.15 15:39 Сейчас в теме
(62) Стоит задача сделать отбор по Ответственному менеджеру и ТипуЗаказа.
ТипЗаказа - это реквизит с типом перечисление и в нем имеется 3 значения: Продажа, Ремонт детали и Ремонт Автомобиля.
Попробовал сделать через сделку, и тоже не доступны измерения для отбора.
97. IssakN 18 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 189 09.11.15 17:00 Сейчас в теме
С позволения автора выкладываю переделку отчета под УТ 11.1.
Прикрепленные файлы:
ПросроченныеДолгиФИФО_УТ11.erf
vis_tmp; xan333; forseil; Spacer; Volchock; ildarovich; +6 Ответить
65. ildarovich 7017 11.11.15 10:21 Сейчас в теме
66. sapit 12 07.12.15 13:29 Сейчас в теме
Использовал ваш алгоритм в отчете. Применить как описано в публикации не получилось из за "ложки сахара" - при реальном использовании отчета расчет по ФИФО делается по дате оплаты, а не дате отгрузки. Можно добавить к дате оплаты время из даты отгрузки, но по факту оказалось что в эту самую секунду оформлено до 20 документов отгрузки или поставки. Данные документы появляются при массовом вводе документов прошлым числом (реализации за период оформляются на одну дату), поступают из БД поставщика и т.п. И все бы ничего, но округление в такой ситуации вызывает расхождение между конечным остатком по регистру и результатом в отчете. В итоге ваш алгоритм использую для выборки оборотов с небольшим "запасом", а дальше уже обычным перебором. Пока не было времени протестировать причину, но на действительно большой БД время выполнения запроса вашего алгоритма и "стандартного" примерно одинаковое. Оставил ваш, так как в итоге все равно потребовалась промежуточная ТЗ.
67. ildarovich 7017 07.12.15 18:06 Сейчас в теме
(66) sapit,
1) выигрыш в скорости будет тем больше, чем больше отгрузок у ОДНОГО контрагента. Если на каждого контрагента отгрузок сравнительно немного, то и выигрыш не будет заметен;
2) вопрос одинакового времени легко решить, добавляя секунды ко времени ОПЛАТЫ, взятые из номера, например. Но я все же еще раз подчеркиваю. Если много отгрузок стоят на одно и то же время оплаты, то с точки зрения неоплаченности их не нужно разделять - лучше рассматривать их как одну большую отгрузку и находить общий процент неоплаченности этой отгрузки и применять затем этот процент к каждой составляющей. Погрешность округления можно исключить, отнеся копейки на последнюю отгрузку в пачке;
3) в запросе, приведенном в статье и в приложенной обработке до сих пор не исправлена небольшая неточность, которую я выявил в процессе "закадрового" общения с пользователями отчета. В предпоследнем запросе пакета вместо
ВЫБОР
        КОГДА Обороты.Период = Шаг.Край
            ТОГДА Шаг.Долг / Шаг.Сумма
        ИНАЧЕ 1
    КОНЕЦ * Обороты.СуммаВзаиморасчетовОборот КАК Долг,
нужно писать
ВЫБОР
        КОГДА Обороты.Период = Шаг.Край
            ТОГДА Обороты.СуммаВзаиморасчетовОборот * Шаг.Долг / Шаг.Сумма
        ИНАЧЕ Обороты.СуммаВзаиморасчетовОборот
    КОНЕЦ КАК Долг,
Это исключит лишние ошибки округления!
68. sapit 12 07.12.15 22:11 Сейчас в теме
(67) по пункту 1 -проверю. 2 -все таки много минусов. Пояснить поставщику(покупателю) что мы оплачиваем пропорционально 10 поставок невозможно. Считать отдельно что оплачено, а что нет - возврат к ведению учета по докуменам расчетов. Отчет в этом случае теряет часть функционала - можно посмотреть ситуацию по компании в целом, но на основании полученных данных решить что оплачиваем именно эту поставку становится невозможным. 3 - проверю.
73. корум 292 28.10.16 12:05 Сейчас в теме
(68) попробуйте не лепить все документы за день в одну секунду.

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

В сутках 86400 секунд, у вас что, по одному контрагенту в один день больше документов??
106. vis_tmp 30 27.04.20 15:57 Сейчас в теме
(67)
	ВЫБОР
		КОГДА РАЗНОСТЬДАТ(Обороты.Период, &Дата, ДЕНЬ) > Шаг.ДоговорКонтрагента.ДопустимоеЧислоДнейЗадолженности
			ТОГДА ВЫБОР
					КОГДА Обороты.Период = Шаг.Край
						ТОГДА Шаг.Долг / Шаг.Сумма
					ИНАЧЕ 1
				КОНЕЦ * Обороты.СуммаВзаиморасчетовОборот
		ИНАЧЕ 0
	КОНЕЦ КАК Просрочено
Показать

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

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

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


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

Подскажите пожалуйста почему когда добавляеш сделку и пробееш сделать групировку по сделка суми не сходятся с стандартним отчетом "Взаиморасчети с контрагентами"
Оставьте свое сообщение

См. также

Безопасная работа с транзакциями во встроенном языке Промо

Практика программирования v8 1cv8.cf Абонемент ($m)

Разбираемся с опасностями использования транзакций во встроенном языке 1С. Познаем ошибку "В данной транзакции уже происходили ошибки". Учимся защищаться от них.

1 стартмани

25.03.2019    29999    10    tormozit    44    

Списание (корректировка) задолженности контрагентов УНФ 1.6

Закрытие периода Дебиторская и кредиторская задолженность Обработка документов Дебиторская и кредиторская задолженность v8 УНФ Украина БУ Абонемент ($m)

Обнуление задолженности контрагентов в конфигурации "Управление небольшой (нашей) фирмой" версии 1.6 с помощью документа "Корректировка регистров".

1 стартмани

24.07.2019    18569    12    DMon    1    

Вам нравятся запросы в 1С?

Практика программирования Разработка v8 v8::Запросы 1cv8.cf Абонемент ($m)

Речь не только о том, что простейший запрос с "легальным" оформлением растянется на пол-экрана, речь еще обо всем, что нужно написать "в нагрузку" к тексту запроса. Все эти "Новый Запрос", "УстановитьПараметр" и последующие пляски с обработкой результата... Пора с этим заканчивать!

1 стартмани

03.07.2019    17172    4    m-rv    86    

Сравнение pdf-файлов актов сверки

Универсальные обработки Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность v8 v8::БУ БП2.0 Россия БУ Абонемент ($m)

Обработка сравнивает два pdf-файла, в которых находятся стандартные печатные формы актов сверки, и показывает на экране совпадающие и/или отличающиеся по суммам документы взаиморасчетов.

1 стартмани

19.12.2018    15408    6    Torin99    2    

Универсальный отчет "[П]: Дебиторка & Кредиторка" [УТ, УПП, КА] Промо

Финансовые Управленческие Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность v8 КА1 УТ10 УПП1 Украина Россия УУ Абонемент ($m)

Уникальные возможности Универсального отчета ! Готовое решение по постановке управленческого учета дебиторской и кредиторской задолженности: - отсроченная и просроченная задолженность; - платежный календарь (поставщики и покупатели); - структура задолженности по интервалам; - структура задолженности по срокам. В настоящее время достаточно распространенной формой отгрузки товаров является отсрочка оплаты. Компания получает отсрочку оплаты от поставщика и предоставляет отсрочку покупателям. Таким образом у компании возникает необходимость организовать учет отсроченной кредиторской и дебиторской задолженностей. Типовые конфигурации 1С: ПРЕДПРИЯТИЕ 8 предоставляют возможность вести такой учет только при условии, что в договоре контрагента установлено «Вести по документам расчетов с контрагентами». Такая детализация ведения взаиморасчетов удобна далеко не всем компаниям. Не забываем "плюсовать" и писать комментарии :-)

5 стартмани

17.02.2012    57974    317    ZLENKO    100    

Работа с публикациями "Инфостарт"

Практика программирования О сообществе WEB v8 УУ Абонемент ($m)

Работа с рублевыми публикациями на сайте "Инфостарт": ведение клиентов, заказов, обновление файлов публикации, рассылка обновлений.

1 стартмани

13.09.2018    18725    12    RocKeR_13    16    

Позиционирование в помещении с помощью нейросети по сигналу Wi-Fi. Интерактивная карта склада в 1С с показом позиции

Инструментарий разработчика Практика программирования v8 Абонемент ($m)

Данная публикация содержит в себе редактор и интерактивную карту склада или иного помещения, на которой в реальном времени отображается позиция устройства, координаты которого вычисляются по уровням сигнала нескольких роутеров Wi-Fi. В статье и приложенным к ней разработкам предлагаются инструменты и методика для реализации вычисления точной геопозиции внутри помещений с помощью нейронной сети. Конфигурация написана на релизе 1С:Предприятие 8.3.12.1412, клиентское приложение имеет минимальный уровень совместимости SDK -16.

5 стартмани

09.08.2018    25293    25    informa1555    26    

Работа с данными выбора

Практика программирования Работа с интерфейсом v8 Россия Абонемент ($m)

В управляемом интерфейсе заложена мощная возможность описывать связи реквизитов формы через параметры. Установка параметров связей позволяет ограничить выбор данных так, чтобы целостность данных была обеспечена на этапе ввода. Однако без дополнительного программирования задать можно только самые простые связи. Такие условия связи, как зависимость от реквизита через точку или зависимость через дополнительное отношение, заданное в регистре сведений - уже задать без программирования не получится.

1 стартмани

17.07.2018    39029    17    kalyaka    16    

Нечеткий поиск одним запросом Промо

Практика программирования v8 1cv8.cf Абонемент ($m)

Использование механизма полнотекстового поиска в 1С не всегда оправдано, т.к. построение индекса и поддержание его в актуальном состоянии может значительно нагружать систему. Предлагаемая реализация нечеткого поиска методом N-грамм выполняется одним запросом, что позволяет производить поиск в любой таблице и не требует предварительного построения индекса.

1 стартмани

28.12.2015    24966    66    vasvl123    9    

ВСТАВИТЬ В Справочник.Номенклатура (Код, Наименование) ЗНАЧЕНИЯ ("001", "Новый товар")

Практика программирования v8 v8::Запросы 1cv8.cf Абонемент ($m)

Вас не обманывают ваши глаза, это запрос на изменение данных! И это работает без прямого доступа к БД, регистрации и смс.

1 стартмани

01.06.2018    27493    86    m-rv    57    

БСП: Дополнительная обработка (Регламенты), примеры от простого к сложному

Практика программирования БСП (Библиотека стандартных подсистем) v8 1cv8.cf Абонемент ($m)

Очень много попадается странных решений, которые можно решить через БСП:Дополнительные отчеты и обработки. Я бы вообще БСП из-за этой подсистемы переименовал в «Большое Спасибо Программистам». Поработаем с подсистемой в части написания регламентных заданий.

1 стартмани

10.05.2018    40879    33    dsdred    36    

Как выполнить отчет на СКД через COM и получить данные отчета?

Практика программирования v8 УПП1 Россия Абонемент ($m)

Для чего это нужно. Например, нужно в одной базе получить какой-либо показатель из другой базы. Этот показатель вычисляется в каком-либо сложном отчете, который написан на СКД. Можно, конечно, "скопипастить" текст запроса из другой базы, немного подправить его и выполнять в том же COM подключении. Но с этим теряется гибкость: если отчет изменился, то нужно помнить о том, что где-то есть его "немного модифицированная" копия. В статье будет рассмотрен пример получения данных из базы ЗУП.

2 стартмани

08.05.2018    25585    8    wowik    3    

Как нарисовать граф на 1С Промо

Практика программирования v8 Абонемент ($m)

Описывается реализация на языке запросов 1С метода расположения вершин графа на плоскости, основанного на использовании электромеханической аналогии. При этом вершины графа представляются одноименными электрическими зарядами, дуги - пружинками. Силы взаимодействия вершин в этой системе переводят их из случайного начального в нужное конечное положение. Приведена обработка рисования графов "ГрафОграф", реализующая данный подход, показывающая также динамику процесса. Граф можно задать списком ребер вручную, выбрать из нескольких предопределенных примеров или сформировать по данным информационной базы.

1 стартмани

09.08.2013    68677    206    ildarovich    117    

Расчет просроченной задолженности по ФИФО по банковским дням

Управленческие Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность v8::ОУ УТ10 УУ Абонемент ($m)

Очень быстрый расчет просроченной задолженности по ФИФО. Без ведения учета по документа расчетов. Для корректной работы должен быть заполнен регламентный календарь.

1 стартмани

28.04.2018    5869    13    MihasMSK    6    

Работа со схемой запроса

Инструментарий разработчика Практика программирования v8 v8::Запросы Абонемент ($m)

Стандартом взаимодействия с реляционной базой данных стал язык SQL. Приемником SQL в 1С является язык запросов. Язык запросов, также как и SQL, является структурированным. Составляющие структуры запроса отвечают на разные вопросы о том, какие данные требуется получить и какие манипуляции с множествами данных необходимо произвести при получении. В простых случаях текст запроса можно написать вручную, однако в сложных случаях, а также при программном формировании, - лучше воспользоваться объектной моделью запроса и использовать объект "Схема запроса". В статье дается описание объектной модели и особенностей работы с ней, а также приводится решение, упрощающее взаимодействие с объектом "Схема запроса".

1 стартмани

24.04.2018    40804    85    kalyaka    34    

Заполняем по шаблону (по умолчанию)

Практика программирования v8 v8::УФ 1cv8.cf Абонемент ($m)

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

1 стартмани

08.02.2018    25335    19    mvxyz    17    

Бесплатная проверка контрагентов в ФНС (общий модуль с алгоритмом). На примере выводим статус в список справочника контрагентов

Практика программирования v8 1cv8.cf Абонемент ($m)

Если вам интересно проверить контрагенте в ФНС, вам поможет данная публикация. Весь алгоритм работы строится на основе данных, полученных с сервиса http://npchk.nalog.ru совершенно бесплатно.

1 стартмани

01.02.2018    33020    54    rpgshnik    48    

Расширение возможностей печати: Вывод произвольного нижнего и верхнего колонтитула

Печатные формы документов Практика программирования Универсальные функции v8 1cv8.cf Абонемент ($m)

Расширяем функционал вывода нижнего / верхнего колонтитула. Стандартно 1С имеет достаточно ограничений по выводу и наполнению колонтитулов содержимым, взять хотя бы такие, как вывод только текста и отсутствие ограничения на номер конечной страницы. А при разработке кода сталкиваешься с тем, что свой блок с нижним колонтитулом нужно прижимать к низу страницы. Казалось бы быстро решаемый вопрос, но и в нем есть нюансы. Сейчас я расскажу о том, как решалась эта задача. UPD 15.02.2018. Добавлен вывод верхнего колонтитула; Вывод колонтитулов на первой и последней странице управляется параметрами; Научился считать страницы: Добавлено заполнение переменных аналогичных стандартным из колонтитулов; Задаются форматы даты и времени. Ограничения прежние: 1. Повторно сформировать табличный документ после смены параметров страницы интерактивно.; 2. Передавать данные для более плотной печати как можно более мелко нарезанными кусками.

1 стартмани

29.12.2017    36352    27    agent00mouse    0    

Печатная форма, сделанная как расширение конфигурации для БП 3.0. Новые возможности БСП

Практика программирования Универсальные печатные формы v8 БП3.0 Абонемент ($m)

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

1 стартмани

06.12.2017    24743    49    kwazi    6    

Задолженность по срокам оплаты для БП ред.3

Бухгалтерские Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность v8::БУ БП3.0 Россия БУ Абонемент ($m)

Собираем задолженность по сроку оплату для договоров без ведения учета по партиям (по данным бухгалтерского учета).

1 стартмани

17.10.2017    6961    14    Benefactor88    0    

Расширения конфигураций 1С: учимся перехватывать методы

Практика программирования v8 v8::УФ 1cv8.cf Абонемент ($m)

В этой статье я на примерах разберу некоторые механизмы расширений конфигураций 1С. А именно «перехваты» методов модуля объекта и «перехваты» событий формы и элементов формы. Данная статья написана с учебными целями, чтобы показать, как при помощи расширений конфигурации можно делать такие доработки, ради которых раньше приходилось снимать конфигурацию с поддержки.

1 стартмани

30.05.2017    115793    13    signum2009    46    

Многопоточность. Универсальный «Менеджер потоков» (фреймворк) с отслеживанием зависимости объектов

Практика программирования Математика и алгоритмы Универсальные функции Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Абонемент ($m)

Восстановление партий, расчет зарплаты, пакетное формирование документов или отчетов - теперь все это стало доступнее. * Есть желание повысить скорость работы медленных алгоритмов! Но... * Нет времени думать о реализации многопоточности? * о запуске и остановке потоков? * о поддержании потоков в рабочем состоянии? * о передаче данных в потоки и как получить ответ из потока? * об организации последовательности? Тогда ЭТО - то что надо!!!

26.05.2017    47215    15    DarkAn    86    

Упрощение работы с актами сверки в УТ/КА/УПП - вывод номеров счетов в документе и печатной форме

Обработка документов Печатные формы документов Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность v8 КА1 УТ10 УПП1 БУ УУ Абонемент ($m)

Обычно акт сверки с клиентами содержат информацию о документах реализации товаров (накладных) и выполненных платежах. Но платежи делаются на основании счетов, номера которых отсутствуют в актах, что затрудняет собственно сверку. Данная обработка находит соответствующие расходным накладным счета/заказы, показывает их в форме документа и выводит в печатную форму акта.

2 стартмани

12.05.2017    26217    4    denmax    2    

СКД. Использование встроенного макета, разделителя страниц

Практика программирования v8::СКД 1cv8.cf Абонемент ($m)

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

1 стартмани

31.03.2017    13854    16    Vin_Tik    0    

Простой способ индексирования интервалов

Практика программирования v8 Абонемент ($m)

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

1 стартмани

28.09.2016    38043    38    ildarovich    22    

1С: Предприятие + корпоративный чат, как наладить оперативные уведомления за 10 минут

Практика программирования v8 Абонемент ($m)

Как сделать автоматические уведомления о разных событиях из 1С в корпоративный чат MyChat для сотрудников компании

1 стартмани

14.08.2016    44605    36    Demanoidos    60    

Задолженность по срокам оплаты

Управленческие Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность v8 БП2.0 УПП1 Россия БУ УУ Абонемент ($m)

Собираем задолженность по сроку оплату для договоров без ведения взаиморасчетов "по расчетным документам" по данным бухгалтерского учета

1 стартмани

23.06.2016    9380    17    Benefactor88    1    

Хранение файлов в томах на диске (для УПП 1.3)

Практика программирования v8 УПП1 Абонемент ($m)

Доработка типовой УПП 1.3 в плане хранения присоединенных файлов вне базы данных

2 стартмани

05.06.2016    52972    7    wowik    29    

Остатки на каждый день в запросе

Практика программирования Учет ТМЦ Учет ТМЦ v8 1cv8.cf УУ Абонемент ($m)

Запрос формирует остатки товаров на каждый день в пределах выбранного периода.

1 стартмани

26.04.2016    51520    19    arakelyan    18    

Выполнение JavaScript кода из 1С в объекте Поле HTML Документа (HTML 5) и вызов события в 1С ПриНажатии

Практика программирования v8 1cv8.cf Россия Абонемент ($m)

Пример выполнения JS кода из 1С в Поле HTML Документа под управляемыми формами, с удобным получением результата в 1С(С помощью вызова привязанного события ПриНажатии к элементу ПолеHTMLДокумента)

1 стартмани

22.03.2016    74258    150    igo1    52    

Количество дней недели (понедельников/вторников/...) в заданном диапазоне одним запросом

Практика программирования v8 Абонемент ($m)

При реализации периодического авто-заполнения маршрутных листов по графику (недельному) необходимо было просчитать стоимость всего периода, с условием выездов только по определенным дням. Заморачиваться с обходом результата не хотелось. Пришлось написать "Небольшой" запрос.

1 стартмани

03.03.2016    16493    1    Alexander.Shvets    5    

Простые радости жизни программиста 1С: выбор типа значения

Работа с интерфейсом Практика программирования v8 1cv8.cf Абонемент ($m)

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

1 стартмани

17.02.2016    45929    49    yuraos    17    

Яндекс.Деньги "Благотворительность"

Инструментарий разработчика Практика программирования v8 1cv8.cf Абонемент ($m)

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

1 стартмани

16.02.2016    21521    8    Tatitutu    5    

Формирование актов сверки взаиморасчётов и групповая печать

Обработка документов Пакетная печать Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность v8 БП2.0 БУ Абонемент ($m)

Обработка позволяет сформировать новые акты сверки и распечатать за период разом на принтере

3 стартмани

15.01.2016    32147    38    gortol    4    

Мастер рассылки e-mail 2.2 для управляемых форм

Практика программирования Email v8 v8::УФ ERP2 БП3.0 УТ11 Абонемент ($m)

Для пользователей: переделанный из старый разработки под 8.2 с использованием библиотеки Мастер рассылки e-mail 2.2 (ERP, УТ, БП) (Только управляемые формы), который теперь может запускаться под любой версией платформы с разрешенными или запрещенными модальными/синхронными вызовами в конфигурации. Также удобный выбор e-mail и их владельцев с помощью отбора динамического списка по любым критериям и галочки исключения.

1 стартмани

29.12.2015    35380    19    milkers    4    

Акт сверки с номерами счетов-фактур, начальными остатками по договорам и заполнением по головному контрагенту [Расширение]

Обработка документов Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность v8 БП3.0 Россия БУ Абонемент ($m)

Акт сверки взаиморасчетов (БП 3.0): - Вывод начальных и конечных остатков по договорам в печатную форму; - Вывод валютной суммы для договоров в условных единицах; - Заполнение данных счетов-фактур или УПД; - Заполнение данных по головному контрагенту и всем обособленным подразделениям; - Заполнение представителя организации из ответственных лиц; - Факсимильная подпись и печать. Не требует снятия с поддержки и подходит для базовых конфигураций

1 стартмани

15.12.2015    54327    95    mrXoxot    40    

Передача больших пакетов через веб-сервисы

Практика программирования Администрирование данных 1С Внешние источники данных v8 Абонемент ($m)

Реализация механизма передачи больших пакетов через веб-сервисы. С его помощью передать файл размером в несколько гигабайт не составит проблем.

1 стартмани

06.12.2015    53080    47    YPermitin    19    

Быстрое определение интервалов в запросе

Практика программирования v8 Абонемент ($m)

В статье описывается новый метод определения интервалов между данными различных записей в запросе. В отличие от общеизвестного метода, время работы предлагаемого метода зависит от объема данных ЛИНЕЙНО. Это обеспечивает ему значительный выигрыш по быстродействию на больших объемах данных. В качестве иллюстрации возможностей метода приведен отчет, показывающий гистограмму распределения времени между продажами.

1 стартмани

01.10.2015    47703    32    ildarovich    41    

Полезные приемы при работе с Excel из 1С (Версия 3.1)

Практика программирования Разработка внешних компонент Загрузка и выгрузка в Excel v8 1cv8.cf Абонемент ($m)

Программисту 1С часто приходится работать с таблицами Excel из 1С. Я постарался собрать небольшой FAQ и набор функций для работы с файлами Excel. Надеюсь, кому-то будет полезна данная статья.

1 стартмани

22.09.2015    178678    429    Zerocl    65    

УПП. Реализация товаров в у.е. Формирование рублевых сумм проводок и регистров накопления с учетом ранее поступивших авансов : сразу при проведении документа

Дебиторская и кредиторская задолженность Закрытие периода Обработка документов Дебиторская и кредиторская задолженность Закрытие периода v8 УПП1 Россия БУ НУ Налог на прибыль НДС Абонемент ($m)

Договор с покупателем ведется в условных единицах. Вид взаиморасчетов : по договору. Ведем взаиморасчеты в разрезе документов расчетов. Ранее поступил аванс на 2 000 EUR. Курс был 45 руб Теперь производим отгрузку на 5 000 EUR. Курс изменился и стал : 60 руб. Проводки по отгрузке формируются с учетом ранее поступившего аванса. Сумма реализации должна составить : 2 000 х 45 + 3 000 х 60 = 90 000 + 180 000 = 270 000 руб.е В типовой реализации проведение дает сумму по реализации 270 000 только для регистра накопления "Взаиморасчеты с контрагентами по документам расчетов" После внесения доработок в обработку проведения (процедура "Движения Регистров") данные по другим регистрам тоже выходят на сумму с учетом поступившего ранее аванса. Проверено для вариантов настройки программы: 1.Валюта упр.учета - Рубли 2.Валюта упр.учета НЕ Рубли

2 стартмани

08.09.2015    36137    18    Designer1C    9    

Code First и Linq to EF на примере 1С версии 7.7 и 8.3 часть I

Практика программирования v8 Абонемент ($m)

Данный проект является чисто исследовательским примером использования Code First и Linq to EF на примере 1С версии 7.7. Так как сам я программист 1С, то мне всегда было интересно, как можно перенести модель объектов 1С на компилируемые языки, и использовать мощь Linq to EF. С появлением Code First давно хотел прикрутить, но все как-то руки не доходили, и вот, наконец ..

1 стартмани

28.08.2015    21393    3    Serginio    2