gifts2017

Отчет по просроченной задолженности/задолженность по интервалам (УПП УТ 8.1, СКД)

Опубликовал Александр Медведев (anig99) в раздел Отчеты - Управленческие

Тыдыщ! Очередная вариация на актуальную тему! Некоторые изменения в описании! НОВЫЙ БЫСТРЫЙ ЗАПРОС! Добавлена версия 0.98 с исправлениями ошибок

Полная версия отчета http://infostart.ru/projects/5467/

Наконец-то наваял в удобоваримом виде сей отчет. Использую подобные отчеты давно, но изначально они были очень специализированы под меня. Переделал и объединил в СКД. В результате получил хорошую гибкость настроек и кучу плюшек .Кто скажет "нафига ещё один!" - идут лесом. В 1С отчет по интервалам использует не ту логику (хотя и гораздо быстрее за счет этого) и не подходит очень многим. Среди опубликованых здесь большая часть - платные.

 

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

Число дней просрочки берется из договора клиента (в разрезе контрагента находится минимальный срок среди всех договоров) или, если указан 0, то из параметра "Дней отсрочки по умолчанию". В конфигурацию, для которой писалась данная обработка, внесены некоторые небольшие измениния, которые позволяют указывать число дней просрочки при любых параметрах договора. Но, как говорилось выше, если срок указан равным 0, то используется значение параметра, и в неизменной конфигурации отчет тоже будет работать.

Выполнение отчета разбито на 3 этапа. На первом этапе формируется таблица контрагентов. В связи с этим при начальном формировании должны соблюдаться условие: все помеченые параметры отчета должны быть указаны (параметры, а не отбор).

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

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

Проще говоря, сформировав отчет по определенным параметрам, можно менять его порядок, группировки, иные отборы и т.д. через кнопку "Сформировать без изменений". Таким образом отчет получается быстрее. Не стоит забывать, что ключевым отбором является отбор по контрагенту и отборы касаемые списка контрагентов можно только уточнять. В противном случае данные будут неполные.

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

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

Кроме того, при двойном щелчке на контрагенте или договоре добавляется пункт "Письмо дебитора". Но получить письмо дебитора возможно только для просроченной задолженности.

 

NEW Отчет запускается и в УТ!

NEW Забыл, что отчет и кредиторку точно также показывает.

NEW Обновил обработку поменяв много мелких запросов в циклах на один большой. Здесь пока версию не выложу. Но есть отчет на основе этого запроса. Если хотите помощи в изменение отчета - пока в личку.

 

Новый отчет упрощенный. Без всяких красивостей. Но быстрый. Очень. Особенность - всё в одном запросе с оптимизированным алгоритмом нарастающих итогов.



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

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

 

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

 

ВАЖНОЕ ЗАМЕЧАНИЕ! Если у Вы думаете, что общая задолженность по моему запросу не совпадает с ведомостью по взаиморасчетам и отчетом по задолженности, то вы скорее всего ошибаетесь. Объясню почему. Дело в том, что типовые отчеты построены так, что вне зависимости какую группировку Вы выбираете (контрагент, договор и т.д.), те отборы, которые включены (например Сумма>0) действуют на нижнем уровне самого отчета, а не на выбранной группировке.

Ситуация. У контрагента есть два договора А и Б, взаиморасчеты по которым ведутся вцелом по договору(можно и по-другому, просто пример легче). По первому договору у клиента долг 100 000, по второму переплата  50 000. Теперь пробуем получить ведомость по взаиморасчетам. Выберем группировку по договорам - выйдет всё красиво и верно. Теперь выберем группировку только по контрагентам - в результате получим цифру 50 000 долга - опять верно. А теперь добавим условие сумма остатка >0 и бац!!!! Остаток - 100 000! Как! Почему! А потому, что сначала фильтруются записи, а потом строится группировка. Такая же фигня для отчета по задолженностям... Видимо, чтобы такая фигня не бросалась в глаза из отчета по взаиморасчетов убрали возможность получать отчет в разрезе документов-регистраторов.

Как же проверить данные? Нужно не задавать отборов на сумму, а получить отчет сгруппированый как нужно и кинуть его в ексель или calc чтобы убрать суммы меньше 0. Ну или написать свой отчет с  нужными группировками  (:

 

Исправил первый вариант отчета.

         Неправильно  считались корректировки долга на взаимозачеты уменьшая срок долга

         В качестве даты долга использовалась дата регистратора, что не всегда верно.

         Неправильно формировались интервалы долга


Пожайлуста, пишите о найденных ошибках и недочетах, так как нет возможности проверять на различных наборах данных

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

Наименование Файл Версия Размер Кол. Скачив.
Версия 0.98
.1247379740 31,70Kb
28.12.09
819
.1247379740 31,70Kb 819 Бесплатно
-
.1243850900 30,76Kb
25.09.09
528
.1243850900 30,76Kb 528 Скачать
Новый запрос
.1247023098 8,70Kb
25.09.09
432
.1247023098 8,70Kb 432 Бесплатно

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Сhe Burashka (CheBurator) 01.06.09 14:28
скриншоты!
> Число дней просрочки берется из договора клиента
не знаю как в 8-ке, в 7-ке это поле используется для заполнения ДОКУМЕНТОВ ПО УМОЛЧАНИЮ. так что имхо брать из справочников - неверно...
2. Александр Медведев (anig99) 01.06.09 15:21
Мда... Логика..."Я не знаю, но на всякая случай минус поставлю...". В 8ке в договоре есть галочка "Контролировать число дней задолженности. Рядом с ним есть поле - число дней задолженности.
3. Сергей Ожерельев (Поручик) 01.06.09 15:58
Да, логика. Не читал, но осуждаю.
(1) Если не знаешь, так действительно, чего лезть. Данный параметр договора используется и в документах, при проведении, если чо.
4. Александр Медведев (anig99) 01.06.09 16:07
Единственное, что может быть - Че неправильно понял фразу "если указан 0, то из параметра "Дней отсрочки по умолчанию".". В данном случае "Дней отсрочки по умолчанию" - это параметр самого отчета, а не справочника Договоры... Просто описалово выдрал из хэлпа. В контексте самого отчета понятнее.
5. Сhe Burashka (CheBurator) 01.06.09 17:15
(2) А скажите мне всезнающие люди. При изменении параметра "задолженности/отсрочки" В ДОГОВОРЕ - все данные отчета поплывут или нет?
6. Сhe Burashka (CheBurator) 01.06.09 17:18
Непонятливым объясняю.
Минус влеплен за неподобающее оформление разработки на данной странице. Отсутствие скриншотов существенно затроудняет анализ и выбор требуемой разработки пользователями. Думайте не только о себе, плиз...
.
вдогонку (2) > Данный параметр договора используется и в документах, при проведении, если чо.
- очень сомневаюсь. Использование ПРИ ПРОВЕДЕНИИ документа данных, не сохраняемых в реквизитах документа - признак дурного тона программирования 1С... так что убедительная просьба знающему УТ человеку разъяснить. каким образом этот параметр договора влияет на проведение документа.. плиз..
Alien_job; Stеls; +2 Ответить 1
7. Владимир Гришин (braynt) 01.06.09 18:43
КонтролироватьЧислоДнейЗадолженности реквизит объекта. При оперативном проведении документа "Реализация товаров и услуг", при установленном флаге Контролировать число дней задолженности происходит контроль числа дней задолжности.
8. Сергей Лунев (luns) 01.06.09 19:26
Сhe Burashka ты не прав... поставлю плюс для равновесия...
9. Александр Медведев (anig99) 01.06.09 19:59
(6) тогда нужно ваять бота, который будет на 80% опубликованых обработок "-" вешать...нетути там скриншотов. А выбор обработки осложняет не отсутсвие скриншотов, а кривые/нестандартизированые интерфейсы. У СКД интерфейс кривой, зато стандартный.
(6) (вторая половина) вообще не в ту степь. Как указано в (7) реквизит создан 1С (вот такой у них дурной тон (: ). Создан для остановки отгрузки при превышении числа дней задолженности. На содержательную часть проведения документа не влияет - просто не дает проводить оперативно. Вся доработка конфы заключалась только в том, что это реквизит в договоре сделать не только запретительным, но и справочным (не отменяя запретительную функцию). Просто была отменены условия видимости/невидимости этого поля и его обнуления.
(5) поплывут, но отчет по просроченной задолженности требуется для оперативного анализа. И если даже в фирме заведено так, что изменяются условия УЖЕ заключенного договора (тут, кстати, вообще куча всякой гадости вылезает), а не правильным заключением дополнительных соглашений, то оперативная составляющая отчета тут не повредиться, а продолжит выполнять свою функцию. А если уж так хочется стабильности и независимости, то есть отчет по интервалам, но там уж "одна норма" на всех.
10. Александр Медведев (anig99) 01.06.09 20:01
Поплывут - изменится распределение просроченная/непросроченная задолженность.
11. Александр Медведев (anig99) 01.06.09 20:09
И ещё раз касательно (7). Число дней задолженности именно тот показатель, который требуется для данного отчета. Если в организации используется 2 даты - "дата предупреждения" и "дата запрета", то дата предупреждения или хранится в дополнительном реквизите, или держится в голове. В первом случае я не телепат и пусть кто там дополнительные поля ваял, то отчет и подправит (все открыто и понятно). А во втором - или отчет по интервалам, или добавка 1 строчки с обнулением в код отчета.
12. Сhe Burashka (CheBurator) 01.06.09 20:37
Господа, скажите, плиз, есть в документе заявка/отгрузка реквизит типа "дата оплаты"...???
13. Александр Медведев (anig99) 01.06.09 21:03
В заявке есть 2 реквизита Отгрузка и Оплата...а в отгрузке...точнее реализации товаров и услуг и реализации отгруженных товаров таких параметров и не было (токо что ещё раз проверил... не... точно нет (% ). Весь смысл этого отчета получить задолженность вне зависимости от ведения расчетов по заказам/сделкам и ошибок закрытия заказов/сделок... Если в организации правильно ведется учет по сделкам, то этот отчет не нужен, достаточно стандартных средств 1с. Должен напомнить, что много уже говорилось о "идеальном" предприятии 1с и реальности. Актуальный и достоверный отчет по логике 1с требует ежечасного контроля над взаиморасчетами.
14. Сергей Ожерельев (Поручик) 02.06.09 10:38
>>>> Актуальный и достоверный отчет по логике 1с требует ежечасного контроля над взаиморасчетами.
И здесь подписываюсь. Особенно если несколько элементов договоров, и необходимо
следить за правильной расстановкой в платёжных, отгрузочных доках.
15. Сергей Ожерельев (Поручик) 02.06.09 10:42
Сам отчёт пока не юзал, сейчас нет возможности, типа не читал, но одобряю. Но за идею плюс. По возможности посмотрю работу.
18. Александр Медведев (anig99) 10.06.09 13:20
(16) Календарные дни. Традиционно используем только календарные, поэтому писать алгоритм расчета банковских дней только как "плюшки", не хотелось. Если очень нужно, подскажи алгоритм, добавлю.
Количество дней в случае уровня отчет по контрагенту берется минимальное. Сейчас уже запамятовал, из всех договоров, или только из тех по которым есть долг.
(17) Долг расчитывается по алгоритму схожему с FIFO. Подробнее. Находится общая сумма долга (по контрагенту, договору, сделке). С конечной даты в обратном порядке перебираются все документы взаиморасчетов. Документы увеличивающие задолженность уменьшают сумма нераспределенной задолженности и так до нуля. Попутно заполняются данные сумма долга, сумма просроченного долга, оплата (оплата не привязана к документу реализации, нужна справочно, чтобы видеть что по клиенту есть движения) и т.д. В результате имее таблицу с документами, которую передаем в СКД. Таким образом, мы не зависим от распределений сумм средствами 1с.
19. Александр Медведев (anig99) 10.06.09 13:24
возвраты в этом случае - уменьшают задолженность.
21. Z-z-z (ZLENKO) 12.06.09 11:46
(20) Я в своем отчете по просроченной задолженности недавно реализовал расчет отсрочки по календарным либо рабочим дням и разбиение суммы документа на предоплату и отсрочку по % предоплаты в договоре - кому надо - обращайтесь.
23. Z-z-z (ZLENKO) 12.06.09 15:59
25. Z-z-z (ZLENKO) 12.06.09 17:18
(24) :-) Вообще то у меня ник "Z", но тут на инфостарте надо было минимум 3 символа - пришлось дополнить. Позднее придумал такой вариант "Z-z-z" - мне он показался более прикольным.
26. looxxx Пристайко (looxxx) 25.06.09 15:48
как настроить отчет чтобы показывал группировку по дням, неделям или месяцам?
27. Александр Медведев (anig99) 25.06.09 16:17
А что именно? Просроченный долг или интервалы?
28. MariP Назарова (MariP) 29.06.09 11:19
ПЛЮС!!!
Есть клиенты с разными отсрочками, поэтому очень пригодится отчет.
СПАСИБО
29. macsol (macsol) 29.06.09 12:30
Протестировал твою обработку. делал так: создал переменную счетчик, и при каждой команде Запрос.Выполнить(), увеличивал её на 1.
Результат 2 248 ( и возможно я еще не все запросы обложил счетчиком).
Это не иначе как изнасилованием сервера не назовешь. Впечатление жуткое. Все эти данные можно получить с помощью одного запроса и нескольких строчек кода.
Я изменил свою обработку, посмотри.
30. Александр Медведев (anig99) 29.06.09 14:24
Количество запросов равно количеству контрагентов(договоров). Можно заменить и на 1 запрос, но тогда придется хранить ВСЮ таблицу взаиморасчетов для этих контрагентов в виде таблицы значений и оттуда уже выбирать нужное. Вопрос только что же всё-таки лучше: 1 большой запрос или много маленьких. Между прочим, мой код открыт - можно модифицировать в сторону уменьшения кол-ва запросов.
Кроме того, показателей всё-таки у меня поболе, чем в твоей. Но это не минус тебе.
31. macsol (macsol) 29.06.09 16:52
(30) По запросам. Один большой - выполняется 1.5 секунды. Если сунуть туда отборы меньше.Напомню что база данных предназначается не для разработчика а для бухгалтеров, по этому при программировании необходимо понимать что ты не один. Если все начнут писать запросы в циклах, мы за день всем заводом будем проводить один документ.
ВСЯ таблица взаиморасчетов - хранится в оперативке, у меня окромная база, а результат запроса всего 9000 строк(если без отборов). Для клиентской машины средней производительности - как два пальца ... (Опять же стоит подумать о других пользователях и не перегружать их машины)
На мой взгляд, в реализации этой задачи, ты изначально пошел не тем путем, поэтому (это только мое мнение) проще заново сделать чем модифицировать.
А код я закрыл, потому что в предыдущем случае ты не нашел в нем ничего нового и интересного..
32. Александр Медведев (anig99) 29.06.09 17:42
(: Посмотрим (: Весь код писался именно под легкость модификации.
33. macsol (macsol) 03.07.09 14:35
Почитал твою тему на форуме. Если получится ускорить отчет с помощью маленьких простых запросов, напиши плиз, хочется посмотреть и сравнить. Я выложил вторую версию отчета, куда воткнул отборы. Некоторое ускорение есть, но это предел. Быстрее он уже не станет.
34. Александр Медведев (anig99) 03.07.09 16:51
Я пошел в другом направлении. Всё в одном запросе. Через пакетные запросы. В чистом виде пока быстрее, чем у тебя.
35. macsol (macsol) 06.07.09 21:04
(34) Ты пошел в моем направлении :)
36. looxxx Пристайко (looxxx) 07.07.09 15:43
37. Александр Медведев (anig99) 07.07.09 15:53
(36) Там участвуют два основных параметра связанных с датой - число дней просроченной задолженности (и его производные) и дата регистратора. Какой именно параметр группировать в периоды? Или чтобы было - вот этот долг возник в таком-то месяце, это в таком-то и т.д.? Можно добавить поле, которое вычисляет дату возникновения долга и группировать по нему с периодом в месяц, день и т.д. Просто не возникало задач по группировке просроченной задолженности по периодам вообще, поэтому точное описание требуется.
38. macsol (macsol) 09.07.09 15:09
Как ты считаешь нарастающий итог, если несколько документов по одному договору проведены в одной секунде? Я на этом голову сломал.
39. macsol (macsol) 09.07.09 15:55
Плюс я поставил за смену подхода.
Есть недоработки
1 Проверяй запрос ( остаток на дату отчета у некоторых контрагентов не сходится с ведомостью по взаиморасчетам и с остатком по регистру "В-ты с к-ми" на дату.
2 Желательно получать данные в разрезе организаций, потому как часто в одной базе несколько организаций.
40. Александр Медведев (anig99) 09.07.09 17:31
(38) Дополнительной проверкой по ссылке.

ВЫБОР
КОГДА ПериодыРегистратор.Период < УвеличениеРегистратор.Период
ТОГДА ИСТИНА
ИНАЧЕ ВЫБОР
КОГДА ПериодыРегистратор.Период = УвеличениеРегистратор.Период
ТОГДА ПериодыРегистратор.Регистратор <= УвеличениеРегистратор.Регистратор
ИНАЧЕ ЛОЖЬ
КОНЕЦ
КОНЕЦ
41. Александр Медведев (anig99) 09.07.09 17:36
(39) 1. Это особенности реализации подхода. Сегодня-завтра выведу закономерности и на примерах покажу.
2. учту. Я этот запрос мучаю для второй версии отчета.
42. Александр Медведев (anig99) 10.07.09 09:24
ВАЖНОЕ ЗАМЕЧАНИЕ! Если у Вы думаете, что общая задолженность по моему запросу не совпадает с ведомостью по взаиморасчетам и отчетом по задолженности, то вы скорее всего ошибаетесь. Объясню почему. Дело в том, что типовые отчеты построены так, что вне зависимости какую группировку Вы выбираете (контрагент, договор и т.д.), те отборы, которые включены (например Сумма>0) действуют на нижнем уровне самого отчета, а не на выбранной группировке.

Ситуация. У контрагента есть два договора А и Б, взаиморасчеты по которым ведутся вцелом по договору(можно и по-другому, просто пример легче). По первому договору у клиента долг 100 000, по второму переплата 50 000. Теперь пробуем получить ведомость по взаиморасчетам. Выберем группировку по договорам - выйдет всё красиво и верно. Теперь выберем группировку только по контрагентам - в результате получим цифру 50 000 долга - опять верно. А теперь добавим условие сумма остатка >0 и бац!!!! Остаток - 100 000! Как! Почему! А потому, что сначала фильтруются записи, а потом строится группировка. Такая же фигня для отчета по задолженностям... Видимо, чтобы такая фигня не бросалась в глаза из отчета по взаиморасчетов убрали возможность получать отчет в разрезе документов-регистраторов.

Как же проверить данные? Нужно не задавать отборов на сумму, а получить отчет сгруппированый как нужно и кинуть его в ексель или calc чтобы убрать суммы меньше 0. Ну или написать свой отчет с нужными группировками (:
43. Валерыч (Valerich) 16.07.09 04:14
плюсанул.
Маленький совет
вместо

стр1.ВидСравнения=стр.ВидСравнения;
стр1.Использование=стр.Использование;
стр1.ЛевоеЗначение=стр.ЛевоеЗначение;
стр1.ПравоеЗначение=стр.ПравоеЗначение;
стр1.Представление=стр.Представление;
стр1.Применение=стр.Применение;
стр1.РежимОтображения=стр.РежимОтображения;

и т.д. проще использовать ЗаполнитьЗначенияСвойств( Стр1, Стр ) - больше шансов, что ничего не пропустишь :)
44. Александр Медведев (anig99) 16.07.09 06:38
спасибо. это мой первый опыт работы с скд, поэтому отлавливать баги так было легче, но исправлю
45. Maniac (Eugeneer) 16.07.09 12:52
Юзабельность просто на нуле. У меня вообще ничего отчеты не выводят. Настройки потыкал не помогает.
Мне тут друг показал отчет. Вообще все очень просто!!!: делаем выборку долгов по контрагентам. Потом "тупо" второй запрос по документам реализаций.
А дальше еще "тупее" бежим по первому запросу и второму и тупо по долгу выводим реализации. Какие угодно расчеты, просрочки по датам и прочему.
В итоге получаем тот же результат (а больше ничего и не надо отделу продаж, как видеть реализации за которые есть долги), а по скорости просто летает!!!!
46. Maniac (Eugeneer) 16.07.09 13:09
Внимательно посмотрел все три отчета. Как в этой каше можно разобраться?
в Одном бесконечные выводы в виртуальные таблицы.
Кривые настройки неюзабельные. Чтобы получить отчет непонятно что нужно выбирать.
Для получения долгов нужно еще и выбирать дату начала, это шутка?
47. Александр Медведев (anig99) 16.07.09 13:38
(46) Конечная дата нужна для получения дополнительных данных (оплата за период и продажи за период) - с получением долгов никак не связано.
Во втором отчете - демонстрация запроса. Никакой гибкости не предусмотрено. Просто я пересмотрел алгоритм и переделываю основной отчет. Причем не только алгоритм, но и юзабилити, и функционал, поэтому его ещё здесь нет.
Да, там выводы в виртуальные таблицы. Но отчет структурирован, если хочешь скину в личку описание алгоритма, если ж не смог разобраться.
(45) Настройки очень просты. Если ты хоть немного разбираешься в СКД. Галочки у параметров не меняем, сами параметры менять можно. Чтобы отобрать контрагентов - задаем отбор по контрагентам (любой отбор без групповых условий). Задаем нужные группировки и вперед. Если хочешь, чтобы менеджеры не мучались, то создаешь все настройки - сохранеяшь их в xml (чтобы не потерялись) и вперед. У меня менеджеры просто нажимают кнопку.

(45) описал мой первый алгоритм. Второй быстрее.
48. Z-z-z (ZLENKO) 20.07.09 14:06
(46) (47) Вот поэтому я и пользуюсь для написания отчетов платформой универсального отчета, а не СКД - настройки универсального отчета понятные, привычные пользователям и очень "гибкие".
49. Александр Медведев (anig99) 20.07.09 14:23
(48) На самом деле почти одинаковые что универсальный, что СКД. Только расположение элементов разное (можно поправить). Те кто РАЗБИРАЕТСЯ в универсальном, разберется и в СКД. А кто запоминает - будет дальше тренировать память. С другой стороны, я сейчас в СКД вынес основные настройки на закладку формы. А остальное... тут сидят такие, что и в универсальном не разберуться. Поэтому готовлю инструкцию по использованию СКД.
50. Z-z-z (ZLENKO) 20.07.09 16:25
(34) А по сравнению с моим отчетом у Вас быстрее ?
51. Александр Медведев (anig99) 20.07.09 16:41
(50) на моей базе УПП - мой отчет намного быстрее... даже по 1 клиенту. Брал демо отчет
52. Z-z-z (ZLENKO) 20.07.09 17:06
(51) Хм.. а в цифрах "намного" как выражается ?
53. Z-z-z (ZLENKO) 20.07.09 17:14
Посмотрел новый запрос - суть не "вкурил", но количество создаваемых временных таблиц впечатлило.
54. Александр Медведев (anig99) 20.07.09 17:20
(52) минут 10 твой отчет точно получается.
(53) как раз эти временные таблицы и оптимизируют расчеты.
55. Z-z-z (ZLENKO) 20.07.09 17:24
(54) что то тут не то... по всем контрагентам (на реальных базах за 2 года работы компаний) я не видел чтобы больше 30 секунд строился. Сколько документов по контрагенту ?
56. Александр Медведев (anig99) 20.07.09 17:46
(55) база больше 3 лет. сколько документов не знаю. позже погоняю ещё отчет - ща сервера заняты
57. Алексей (Alex_will) 29.07.09 12:23
доработаю под БП....такое же надо...но толкового на сайте не нашел
58. Z-z-z (ZLENKO) 03.08.09 15:58
(57) Чем мой отчет не устраивает ? При желании его можно переделать под БП.
59. Алексей (Alex_will) 04.08.09 08:08
(58) я ж написал что "доработаю под БП". не нашел готовый под БП
60. Юлия Бойко (Yul_kat) 11.08.09 11:22
А как сделать отбот по организации?
61. Юлия Бойко (Yul_kat) 11.08.09 11:22
62. Александр Медведев (anig99) 11.08.09 12:22
(60). В какой именно обработке? В принципе, ни в одной из этих не предусморен учет нескольких организаций, но доработать их можно. Но реализованы они по разному, поэтому и нужно знать версию.
Кроме того, есть платная версия, где организации учтены и есть много чего ещё.
Можно в личку.
63. Дмитрий Мурин (murin) 16.09.09 10:21
Пользуюсь этим отчетом, неплохой отчет. Плюс поставил. Добавлял группировку по договорам (после контрагентов) и делал отбор по "виду договора" - выходит ошибка :(, а если добавляю группировку "виду договора" в верхний уровень, то отбор работает.
64. Александр Медведев (anig99) 16.09.09 11:24
(63)Отчет бесплатный и узкоспециализированый. Проблема скорее всего в неправильной отработке предварительного отбора.
65. Александр Медведев (anig99) 16.09.09 11:31
(63) попробуйте "Новый запрос".
66. Ярослав Радкевич (WKBAPKA) 23.01.10 19:15
а как насчет "развернуть по иерархии"... задача простая, нужно вывести контрагентов, договора контрагентов, сделки и документы расчета + регистраторы по которым есть долг и разбросать этот долг между текущей просроченной и лояльной с учетом итогов по иерархии... что то в ваших реализациях я этого не увидел...
67. Александр Медведев (anig99) 25.01.10 13:07
68. Антон Караульщиков (Ant-1905) 19.11.10 13:11
спасибо, понравился отчетик! ;)
69. Ярослав Радкевич (WKBAPKA) 27.01.11 18:53
а если использовать простой алгоритм... делаем запрос по долгам и группируем по дням. опосля чего используем следующую формулу, отсчитываем количество дней отсрочки и смотрим, если остаток на конец больше чем остаток на начало + кво дней отсрочки за который могла быть отгрузка, значит просроченная дебеторская задолженность все же есть... т.е. идея такая, что остаток на конец всегда должен стремиться к нулю! немного сумбурно, но приблизительно идея понятна?
70. Александр Медведев (anig99) 27.01.11 20:56
(69) идею пока не вкурил. можно поподробнее формулу на языке математики или алгоритм.
71. Ярослав Радкевич (WKBAPKA) 28.01.11 09:49
2(70): допустим есть договор с отсрочкой платежа в 7 дней. отгрузили товар. через 7 дней товар должен быть оплачен. соответственно через 7 дней долг должен равняться нулю. Но так как в этот период могут быть еще отгрузки, а также оплаты, то сумма долга на конец должна быть меньше суммы долга на начало (т.е. конец период - 7 дней) + отгруженный товар за этот период, что означает, что в этот период было уменьшение долга, т.е. он не вырос. Если сумма долга больше - это и есть просроченный долг. Правда тут не подсчитать количество дней просрочки, вернее можно, но нужно ли !
72. Ярослав Радкевич (WKBAPKA) 28.01.11 09:51
соответственно если на конец есть остаток, а за период не было отгрузок и остаток на конец = остатку на начало, то тоже считается просроченным долгом, т.к. за этот период отсрочки долг не уменьшился
73. Александр Медведев (anig99) 28.01.11 10:56
(72) Ага. Тогда 4 замечания:
1. Таким способом можно получить только сумму просроченного долга, но никак не его структуру и свойства.
2. Алгоритм проверки можно сократить. В Вашем случае получаем Сумма долга на дату -7дней, сумма отгрузки и сумма долга на текущую дату. Можно обойтись суммой долга на дату -7дней и суммой оплаты за этот период. Т.е. Просроченный долг = СуммаДолга[-7д] - СуммаОплатыЗаПериод[7д]
3. Без кодинга такой подход можно реализовать только в рамках СКД - параметрическая связь НаборовДанных (как в отчете по продажам в определенных ценах)
4. Алгоритм невозможно модернизировать для случаев, когда количество дней просрочки устанавливается для каждого документа разные
74. Ярослав Радкевич (WKBAPKA) 28.01.11 15:41
2(3): без кодинга действительно нельзя. Зато одним запросом.
по поводу п.4 как раз этот алгоритм и применяется когда количество дней просрочки либо в договоре либо в документе могут быть разные.

по понкту 2, не можем. Особенно, если отсрочка устанавливается для каждого документа,а платежи не разносятся по документам!

можно также высчитать и глубину долга...
75. Ярослав Радкевич (WKBAPKA) 28.01.11 15:46
т.е. я хотел сказать, что разница между началом и концом показывает нам увеличение/уменьшение долга... а это могут быть как проплаты, так и возвраты и т.п. без кодирования не обойтись как раз потому, что для каждого договора могут быть разные условия отсрочки, и делать на каждого клиента запрос можно было бы, помещая во временную таблицу, только вот как быстро это будет работать?
76. ivan ivanov (ivan07) 15.11.11 19:46
Отчет пригодился нашим бухам, Спасибо большое
78. Евгений Билык (evgeniy.bilyk) 16.03.12 02:06
Спасибо, полезный отчет, пригодился
79. Виталий Змиевский (francisco) 02.04.12 16:55
Попробуем, должно быть не плохо.
80. Сергей Саньков (volga1) 21.05.12 12:50
Возможно посчитать просрочку по такой схеме с помощью запроса?
Пример:
период 01.04.2012 по 20.05.2012
Контрагент (Число дней допустимое 14)
Сумма долга начало -100р
Реализация №1 от (01.04.2012) 200р просрочено 21день
Реализация №2 от (05.05.2012) 150р не просрочено
Приходник №1 от (05.05.2012) -150р
ВозвратТовара №1 от (06.05.2012) -100р

получается только к концу периода просроченные реализации видно а как в течении периода просроченные реализации видеть как здесь

этот пример за период не показывает просрочку по фифо, нужно чтобы Реализация №1 показывалась как просроченная(хотя и оплачена но с опозданием на 21день).
Какой должен быть алгоритм запроса?
Прикрепленные файлы:
81. Александр Медведев (anig99) 21.05.12 13:17
(80) я это сделал объединяя отчеты за каждый день периода (программно) в одну таблицу.
82. Сергей Саньков (volga1) 21.05.12 13:36
(81) anig99,
Вы предлагаете не запросом это реализовать, то есть запросом не реально?
83. Александр Медведев (anig99) 21.05.12 13:56
(82) мой запрос основывается на регистре взаиморасчеты с контрагентами, который не подразумевает закрытие по документам расчета. По нему можно узнать остатки и движения, но не какой документ и когда был оплачен. Запрос действует из предположения, что документы закрываются по фифо, но сам расчет фифо не производит, а только получает однозначно ещё не закрытые по оплате документы. Получать данные о долгах в разрезе периода можно только имея информацию о том, когда реализация была оплачена. Это возможно 2 способами:
1. написать простой отчет по регистру взаиморасчеты по документам расчетов, но для этого регистр нужно всегда держать в порядке
2. получить неоплаченные долги за каждый день периода и уже эти данные объединить в 1 таблицу, которую можно проанализировать дальше.
84. Сергей Саньков (volga1) 21.05.12 14:32
(83) anig99,
1.(взаиморасчеты по документам расчетов) - не приемлемо т.к. договоры не учитываются, контрагент может покупатель и поставщик одновременно быть, даже число дней на контрагента прописал.
2 вариант попробую.
Ваше мнение - если в регистр (взаиморасчеты с контрагентами) добавить ресурс или вообще новый регистр создать и документами в него расчет делать а после для отчета данные брать из него?
85. Александр Медведев (anig99) 21.05.12 14:51
(84) зачем что-то дописывать в конфе? Напишите обработку, которая будет рассчитывать взаиморасчеты по fifo и писать их в регистр взаиморасчеты по документам расчетов. Т.е. у Вас будет отключен основной механизм движения по этому регистру, но Ваша обработка будет писать туда данные как нам нужно по fifo с привязкой по документам. При ручном перепроведении этого документа движения пропадут и таким образом можно будет вычислять период, с которого нужно делать перерасчет (граница последовательности). Если же менять конфу, то можно точно также обойтись этим же регистром и подпиской на событие запись документа. Тогда движения не будут пропадать при ручном перепроведении, но надо будет где-нибудь хранить границу последовательности.
86. Сергей Саньков (volga1) 25.05.12 20:06
(85) anig99,

Сделал (просрочка в течении периода просроченные не оплаченные и просроченные оплаченные реализации видно)
87. Мария Шекалова (mari0210) 04.09.12 11:00
надо для бюджета((((((кредиторскую и дебиторскую просроченную задолженность в разрезе договоров....очень надо....не могу найти...
89. Ламия 06.01.13 19:28
90. Василий Пупкин (zforall) 05.12.13 08:43
Отличный отчет. Только я не могу почему-то настроить вывод по договорам контрагента. Подскажите, пожалуйста как расположить группировки чтобы увидеть данные по договорам.
91. Александр Медведев (anig99) 05.12.13 09:14
(90) чтобы заработало по договорам нужно указать в настройках, которые на закладке отдельное, группировка: по договорам (выпадающий список). Это сформирует исходные данные для отчета в разрезе договоров, а не контрагента. После этого нужно в настройках, которая по кнопке сверху (открывается отдельное окно) добавить в группировку внешнего вида отчета Договор контрагента.
92. Василий Пупкин (zforall) 16.12.13 11:31
Подскажите в каком направление надо рыть чтобы отчет считал не по календарным а по банковским дням. Заранее спасибо.
93. Александр Медведев (anig99) 16.12.13 14:27
(92) в этом отчете нет такой настройки. В более поздних вариантах, которые я не публиковал, есть привязка к производственному календарю, что и дает банковские дни.
94. Василий Пупкин (zforall) 17.12.13 02:50
И как же можно получить для тестирования неопубликованный вариант? :)
95. Александр Медведев (anig99) 19.12.13 11:31
(94) попробую на выходных выслать. Скиньте почту в личку.
96. Александр (mr_AntA) 29.11.16 17:26
Можно ли переделать так, чтобы показывал не только долги, но и переплаты?
97. Александр Медведев (anig99) 30.11.16 09:47
(96) Вообще - можно. Через какое-то время буду писать такой отчет. Когда точно - не скажу, но до нового года, скорее всего
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа