Всем привет!
По работам 1с-ника ежедневно можно писать статьи-мемуары: на неочевидные нюансы платформы 1С или неочевидное решение задачи можно потратить весь день экспериментов и исследований - а это уже тянет на личное Know-how.
Магия 1с-ника заключается в том, чтобы на первый взгляд нетривиальную задачу решить тривиальным способом.
Итак, задача от клиента - создать отчет в разрезе магазинов, в разрезе месяцев (июнь, июль, август и т.д.) с показателями "Продажи", "Расходы", "Прибыль". Задачу сильно упрощаю. Сам отчет был разработан давно.
Со временем отчет прирастал показателями (колонками), при этом каждый показатель по своей сути берется из отдельных таблиц (запросов), таблицы объединяются в одну общую таблицу, и таким образом создается искомый отчет - см. рис. 1.
Стрелками указаны показатели, которые получаются из отдельных виртуальных таблиц регистров накопления. Виртуальные таблицы объединяются в единый отчет - см. рис. 2.
Объединения таблиц производились по магазинам (подразделениям) и по периодам. Все периоды приводились к виду НачалоМесяца - рис. 3.
Внизу представлен запрос (набор данных) №3, который никак не хотел "объединяться" с основным запросом (набором данных) №1. Сначала присмотритесь к запросу №3 - рис. 4. В нем период записи превращается в период "месяц назад": условно говоря, июльские обороты отражаются июнем. Опускаю причины и детали - но именно в этом заключалось техническое задание - определенные расходы текущего месяца сажать в отчет предыдущим месяцем.
Если запрос №3 отдельно прогнать в консоли запросов в режиме 1С:Предприятие, то результат будет положительный - условно говоря, июльские обороты мы сможем увидеть как "июньские".
Если пробуем сформировать отчет в СКД (система компоновки данных), то июльские обороты не отражаются как "июньские".
Проблемный запрос №3 отличается от остальных таблиц тем, что мы, условно говоря, собираем июльские обороты и сажаем их как "июньские" - переопределяем поле "ПериодМесяц3". И так с каждым периодом этого показателя - обороты за текущий месяц надо сажать в отчет за предыдущий месяц.
Как бы мы ни старались использовать параметры-периоды виртуальных таблиц, которые "по умолчанию": &НачалоПериода и &КонецПериода - например, делать разные периоды для разных виртуальных таблиц - корректный отчет мы не получим - июльские обороты мы не получим в июньском периоде.
В какой-то момент пришло озарение:
Система компоновки данных при формировании отчета накладывает фильтр по одному и тому же периоду на все виртуальные таблицы.
Проведение экспериментов и тестов (метод проб и ошибок) наконец-то дали положительный результат.
Решение:
Если проблемный запрос №3 переписать через физическую таблицу, а не виртуальную, наложить отбор по периоду программно в запросе, то задача будет решена.
Сравните следующий запрос - в котором нет отборов по периоду по умолчанию, как у виртуальных таблиц. Все отборы оборотов по периоду устанавливаются программно нами.
В итоге простая задача от клиента превратилась в нетривиальную задачу для исполнителя 1с-ника из-за неочевидного нюанса платформы 1С (конкретно механизма СКД).
Неочевидное решение теперь очевидное. Когда знаешь, все просто!
Итоговое время на анализ проблемы и поиск решения заняло 6 часов. Сюда также входит постановка задачи - то ли это ошибка в запросе и тогда надо исправить ее, то ли это ограничение платформы 1С и тогда надо найти способ его обойти. Написание статьи заняло 1,5 часа.
На этом все. Всем добра!