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

Отчеты - Управленческие

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

Полная версия отчета //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
888
.1247379740 31,70Kb 888 Скачать бесплатно
-
.1243850900 30,76Kb
25.09.09
529
.1243850900 30,76Kb 529 Скачать
Новый запрос
.1247023098 8,70Kb
25.09.09
504
.1247023098 8,70Kb 504 Скачать бесплатно

См. также

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

ВЫБОР
КОГДА ПериодыРегистратор.Период < УвеличениеРегистратор.Период
ТОГДА ИСТИНА
ИНАЧЕ ВЫБОР
КОГДА ПериодыРегистратор.Период = УвеличениеРегистратор.Период
ТОГДА ПериодыРегистратор.Регистратор <= УвеличениеРегистратор.Регистратор
ИНАЧЕ ЛОЖЬ
КОНЕЦ
КОНЕЦ
41. Александр Медведев (anig99) 2525 09.07.09 17:36 Сейчас в теме
(39) 1. Это особенности реализации подхода. Сегодня-завтра выведу закономерности и на примерах покажу.
2. учту. Я этот запрос мучаю для второй версии отчета.
42. Александр Медведев (anig99) 2525 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) 2525 16.07.09 06:38 Сейчас в теме
спасибо. это мой первый опыт работы с скд, поэтому отлавливать баги так было легче, но исправлю
45. Maniac (Eugeneer) 16.07.09 12:52 Сейчас в теме
Юзабельность просто на нуле. У меня вообще ничего отчеты не выводят. Настройки потыкал не помогает.
Мне тут друг показал отчет. Вообще все очень просто!!!: делаем выборку долгов по контрагентам. Потом "тупо" второй запрос по документам реализаций.
А дальше еще "тупее" бежим по первому запросу и второму и тупо по долгу выводим реализации. Какие угодно расчеты, просрочки по датам и прочему.
В итоге получаем тот же результат (а больше ничего и не надо отделу продаж, как видеть реализации за которые есть долги), а по скорости просто летает!!!!
46. Maniac (Eugeneer) 16.07.09 13:09 Сейчас в теме
Внимательно посмотрел все три отчета. Как в этой каше можно разобраться?
в Одном бесконечные выводы в виртуальные таблицы.
Кривые настройки неюзабельные. Чтобы получить отчет непонятно что нужно выбирать.
Для получения долгов нужно еще и выбирать дату начала, это шутка?
47. Александр Медведев (anig99) 2525 16.07.09 13:38 Сейчас в теме
(46) Конечная дата нужна для получения дополнительных данных (оплата за период и продажи за период) - с получением долгов никак не связано.
Во втором отчете - демонстрация запроса. Никакой гибкости не предусмотрено. Просто я пересмотрел алгоритм и переделываю основной отчет. Причем не только алгоритм, но и юзабилити, и функционал, поэтому его ещё здесь нет.
Да, там выводы в виртуальные таблицы. Но отчет структурирован, если хочешь скину в личку описание алгоритма, если ж не смог разобраться.
(45) Настройки очень просты. Если ты хоть немного разбираешься в СКД. Галочки у параметров не меняем, сами параметры менять можно. Чтобы отобрать контрагентов - задаем отбор по контрагентам (любой отбор без групповых условий). Задаем нужные группировки и вперед. Если хочешь, чтобы менеджеры не мучались, то создаешь все настройки - сохранеяшь их в xml (чтобы не потерялись) и вперед. У меня менеджеры просто нажимают кнопку.

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

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

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

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