Нужна помощь в большом запросе
Добрый день. Очень нужна помощь. Есть запрос, он работает.По сути отображает списания как по FIFO. Выводит сумму и количество дней непогашенной дебиторской задолженности.Запрос делался в УТ 10.3
Но, не совсем корректно работает когда контрагенты группируются по ИНН
Так как в виртуальн.табл. - DN_НеЗакрытыеРеализации группировка происходит по договору,возможно из-за этого.
Пример на фото изображён:
там где один контрагент он один только в базе с ИНН - и отчёт по ним работает идеально.
а там где не перекрывается оплата на реализацию то таких контрагентов в базе 2 и более,они сгруппированы по ИНН,
и ситуация такова,что к примеру:
вася1 с инн 12345 долг 20000
вася2 с инн 12345 долг -25000
вот они между собой не перекрываются, тут ситуация такая что все оплаты приходят на вася2, и частично идут реализации на вася2, а на вася1 только реализации
Но так как группировка по ИНН должна быть обязательна, то должно отобразиться только те реализации,которые не оплачены (с учётом хвостика,который возможно оплачен в последней неоплаченной реализации).
Варианты оплаты раскидывать на двоих по равному,не предлагать,отчёт всё равно не сгруппируется правильно.
На картинке поставил два вопроса,что эти платёжки не перекрылись...
Но, не совсем корректно работает когда контрагенты группируются по ИНН
Так как в виртуальн.табл. - DN_НеЗакрытыеРеализации группировка происходит по договору,возможно из-за этого.
Пример на фото изображён:
там где один контрагент он один только в базе с ИНН - и отчёт по ним работает идеально.
а там где не перекрывается оплата на реализацию то таких контрагентов в базе 2 и более,они сгруппированы по ИНН,
и ситуация такова,что к примеру:
вася1 с инн 12345 долг 20000
вася2 с инн 12345 долг -25000
вот они между собой не перекрываются, тут ситуация такая что все оплаты приходят на вася2, и частично идут реализации на вася2, а на вася1 только реализации
Но так как группировка по ИНН должна быть обязательна, то должно отобразиться только те реализации,которые не оплачены (с учётом хвостика,который возможно оплачен в последней неоплаченной реализации).
Варианты оплаты раскидывать на двоих по равному,не предлагать,отчёт всё равно не сгруппируется правильно.
На картинке поставил два вопроса,что эти платёжки не перекрылись...
Прикрепленные файлы:
Отчёт_деб_кред.epf
По теме из базы знаний
- История оптимизации одного большого запроса средствами MSSQL Profiler и 1С
- Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С
- Управляемая консоль отчетов – новый функциональный инструмент для работы с запросами и СКД в управляемых формах
- Как читать чужой код? Часть 3. Разбор и доработка запросов
- Когда интерфейсам 1С нужны веб-технологии
Ответы
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Совсем не используйте ссылки на контрагентов и ссылки на договора в запросе, а используйте только текст: ИННКонтрагента и НаименованиеДоговора. Сделайте связи таблиц по полям ИННКонтрагента и НаименованиеДоговора.
Затем после того как весь запрос отработает: 1) сгруппируйте суммы, получите временную таблицу; 2) Временную таблицу из пункта 1 соедините со справочником Договоров по Наименованию и ИНН владельца, возьмите ссылку на договор и ссылку на владельца, далее получите Максимум(СсылкаНаДоговор) и Максимум(СсылкаНаВладельца) сгруппировав по ВСЕМ полям временной таблицы из пункта 1
Затем после того как весь запрос отработает: 1) сгруппируйте суммы, получите временную таблицу; 2) Временную таблицу из пункта 1 соедините со справочником Договоров по Наименованию и ИНН владельца, возьмите ссылку на договор и ссылку на владельца, далее получите Максимум(СсылкаНаДоговор) и Максимум(СсылкаНаВладельца) сгруппировав по ВСЕМ полям временной таблицы из пункта 1
Вариантов "как-то выйти из положения", как обычно, много, но лично я начинаю всегда с причин возникновения ситуации.
Поэтому для начала хотелось бы понять, что является причиной появления "двойников/тройников" и т.д.
Варианты:
(а) разные КПП (филиалы);
(б) ошибки ввода данных (просто ввели ещё одного, чтобы не париться);
(в)
(г)
.....
Поэтому для начала хотелось бы понять, что является причиной появления "двойников/тройников" и т.д.
Варианты:
(а) разные КПП (филиалы);
(б) ошибки ввода данных (просто ввели ещё одного, чтобы не париться);
(в)
(г)
.....
(7)давайте пойдём дальше.
Я думаю, что сначала надо навести порядок в базе. Никакие изощрённые запросы не спасут
Я делаю всегда в такой последовательности:
1. Перекрыть возможность ввода двойников: "Перед записью" проверка на наличие хотя бы двойника по ключу "ИНН+КПП" при условии их обязательного заполнения. И -- Отказ, если ...
2. Привести в порядок уже имеющиеся данные:
(а) -- ввести КПП
(б) -- выбрать одного из двойников по ключу "ИНН+КПП" и на него "повесить" все доки. После чего "пустышек" как-нибудь пометить, например, через наименование "Бывший ИНН/КПП (не трогать!!!)", чтобы можно было найти концы. соответственно при попытке использования такого контрика запрещать либо выбор, либо запись документа.
Настоятельно рекомендую потратить время на приведение базы в порядок, без этого проблема будет нарастать "по экспоненте". Никакие запросы не спасут.
Я думаю, что сначала надо навести порядок в базе. Никакие изощрённые запросы не спасут
Я делаю всегда в такой последовательности:
1. Перекрыть возможность ввода двойников: "Перед записью" проверка на наличие хотя бы двойника по ключу "ИНН+КПП" при условии их обязательного заполнения. И -- Отказ, если ...
2. Привести в порядок уже имеющиеся данные:
(а) -- ввести КПП
(б) -- выбрать одного из двойников по ключу "ИНН+КПП" и на него "повесить" все доки. После чего "пустышек" как-нибудь пометить, например, через наименование "Бывший ИНН/КПП (не трогать!!!)", чтобы можно было найти концы. соответственно при попытке использования такого контрика запрещать либо выбор, либо запись документа.
Настоятельно рекомендую потратить время на приведение базы в порядок, без этого проблема будет нарастать "по экспоненте". Никакие запросы не спасут.