Скд остатки и обороты по регистратору

В данной статье описывается, по какой причине отчет, созданный при помощи системы компоновки данных, может выдавать неправильные остатки.

Отсутствие родительских полей – периодов в запросе

Данная проблема возникает например, если в запросе получают поле Регистратор, но не получают поле ПериодСекунда.

Пример неправильного запроса:

Для такого запроса система рассчитать правильные остатки не может.

Для устранения проблемы нужно обеспечить, чтобы в запросе присутствовало поле Период.

Пример правильного запроса:

Отсутствие в запросе парного поля – остатка

Данная проблема возникает когда в запросе получают только поле начального остатка или только поле конечного остатка.

Пример неправильного запроса:

Для устранения проблемы нужно обеспечить, чтобы в запросе присутствовал как начальный, так и конечный остатки.

Пример правильного запроса:

Не заполнены роли полей

Данная проблема возникает, когда у полей набора данных неправильно заполнены роли полей.

Правильно должны быть заполнены роли у полей – периодов, полей – измерений, полей остатков.

Поля – периоды должны иметь непрерывную нумерацию, начиная с 1. При этом, чем меньше номер периода, тем более точным должен быть период. Например, поле НомерСтроки является уточнением поля Регистратор, поэтому номер период поля НомерСтроки должен быть меньше, чем номер периода поля Регистратор. Аналогично и номер периода поля ПериодДень должен быть меньше, чем номер поля ПериодГод.

Пример неправильного заполнения роли периодов:

В данном примере у поля Регистратор не проставлена роль – период.

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

Пример неправильного заполнения:

В данном примере предполагается, что поле Примечание по сути измерением не является, но его отметили в схеме как измерение. Поле Склад наоборот измерением является, но его не отметили как измерение.

Поля – остатка должны иметь правильную роль остатка. Парные поля остатка должны иметь одинаковое имя группы полей остатка. Не парные остатки должны иметь различные имена групп полей остатка.

В данном примере у полей остатка не указали их роль остатка и имя группы остатков.

Читайте также:  Сброс к заводским настройкам samsung duos

Неправильная работа с реквизитами измерений

Данная проблема возникает, когда в запросе получают реквизит измерения.

Например, если в регистре имеется измерение Договор, у которого имеется реквизит Контрагент, и в запросе получается поле Договор.Контрагент.

В такой ситуации может возникнуть две проблемы:

Во-первых, в запросе получили реквизит измерения, но не получили само измерение. В этой ситуации итоги по полям остатка могут быть рассчитаны неправильно.

Пример неправильного запроса:

Если данные запроса получаются из виртуальных таблиц, то поля измерения, реквизиты которых получаются в запросе, обязательно должны получаться в самом запросе.

Пример правильного запроса:

Вторая проблема в том, что у поля – реквизита измерения может быть не указано родительское измерение. Для решения этой проблемы нужно указать родительское поле в роли поля – реквизита. Так, в приведенном выше примере, нужно у поля Контрагент указать роль Измерение и указать в качестве родительского поля поле Договор.

Использование в запросе измерений виртуальных таблиц, отсутствующих в списке выборки

Данная проблема возникает когда в запросе используется измерение виртуальной таблицы, однако данное поле не получается в списке выборки.

Пример неправильного запроса:

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

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

Пример правильного запроса:

В данном примере поле Склад добавлено в список выборки, таким образом система компоновки данных будет учитывать это измерение при расчете итогов.

Другой пример правильного запроса:

В данном примере поле Склад не используется вне параметров виртуальной таблицы.

Не использование периодичности Авто

Данная проблема возникает, когда данные получаются из виртуальной таблицы ОстаткиИОбороты с указанием периодичности, отличной от Авто, если при этом в отчет выводятся не все поля – периоды. Эта проблема родственна проблеме "Отсутствие родительских полей – периодов в запросе", описанной в начале данной статьи.

Пример запроса, который может привести к получению неправильных остатков:

Для решения проблемы лучше в запросах для настраиваемых отчетов системы компоновки данных, в виртуальных таблицах ОстаткиИОбороты, использовать периодичность Авто. Или обеспечить обязательных вывод всех полей – периодов в результат отчета.

Использование периодичности Неделя совместно с бОльшими периодичностями

Данная проблема возникает уже не на уровне схемы компоновки данных, а на уровне настроек компоновки. Например, при совместном выводе в отчет группировки по месяцу и неделе.

Решение данной проблемы – не использовать совместно с периодичностью Неделя бОльшие периодичности.

Читайте также:  Поставить автомат на ваз

Рассмотрим решение проблемы написания отчета, в котором необходимо взять остатки и обороты по регистру бухгалтерии или накопления и при этом вывести разрез по регистраторам(документам). Казалось бы эта проблема решается использованием таблицы ОстаткиИОбороты, которая позволяет нам использовать регистратор в запросе. Но при таком методе написания запроса начальные и конечные остатки не рассчитаются верно. Это произойдет потому что в запросе помимо нужной нам аналитики остатки возьмутся и по регистраторам, а это некорректно. Решается эта задача использованием объединения запросов: в первом запросе берем остатки на начало, во втором обороты с регистраторами, в третьем остатки на конец.

Пример: В запросе взять остатки и обороты по сумме, счет 62, по организации, за период, в разрезе Контрагентов, Договоров и Регистраторов.

После написания запроса в схеме компоновки данны*х в ресурсы выкидываем поля: *НачальныйОстаток, Приход, Расход и КонечныйОстаток, в группировки выносим поля: Контрагент, Договор и Регистратор. Отчет будет выводить вам верные остатки по контрагентам и договорам, а обороты еще и по регистраторам.

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

Постановка задачи

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

Как решалась задача

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

В схеме компоновки данных, я добавил единственный Набор данных – запрос с текстом, который описывает Объединение двух запросов:

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

Плюс добавил в каждый запрос поле "Раздел" (я всегда так делаю, чтобы при отладке понять из какого запроса выбираются те или иные данные) – значение этого поля текст: для первого – "1. Товары на складах", для запроса к партиям – "2. Партии товаров на складах" соответственно.

При чем, конструктор СКД определил роли полей(что измерения, а что поля начальных, конечных остатков)

Настроил ресурсы для всех полей. Здесь ничего необычного

Читайте также:  Почему нельзя хранить портреты умерших

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

Смотрю, что получается – вроде, правильно:

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

В чем проблема? Дело в том, что в СКД свой собственный механизм расчета начальных и конечных остатков(информация из видео-курса по СКД Гилева)

Алгоритм расчета итогов по полям остатка описан на ИТС https://its.1c.ru/db/v8310doc#bookmark:dev:TI000000628 (Спасибо Armando)

Упрощенно алгоритм для получения Конечных остатков таков: берем последнюю по хронологии запись в разрезе выбранных измерений и считаем, что значение поля Конечный остаток из нее и есть конечный остаток для группировки. И судя по скриншоту, получается, что последняя запись имеет конечный остаток по Товарам на складах = 0, Партии = 0 – СКД считает, что для Номенклатуры это и есть конечный остаток.

Чтобы это победить, для поля Раздел я добавил роль Измерение, и поскольку, данное поле не планируется выбирать в отчете, а СКД его будет оптимизировать и удалять из запроса – флаг Обязательное. Теперь итоги верные.

Немного красоты

Для того чтобы исключить пустые строки, сообщающие о начальном и конечном остатке на Начало/Конец периода, поле Регистратор можно в запросе заменить на выражение и поставить для этого поля галку Игнорировать значения NULL.

В конце я еще дополнил текст запроса описанием характеристик

Для конфигураций созданных из УПП 1.3 они всегда одни и те же

Выводы

Когда в одном отчете на СКД необходимо корректно показать начальные, конечные остатки нескольких разделов учета следует выполнить следующее:

  1. В наборе данных запрос используем таблицу ОстаткиИОбороты
  2. В запросе для каждого раздела учета создаем поле "Раздел". Для каждого запроса объединения, пишем туда уникальное значение. Я так и пишу текстом, например "1. Товары на складах", "2. Партии товаров на складах"
  3. В запросе выбираем все нужные поля, в т.ч. поле "Раздел"
  4. В СКД настраиваем роли для полей остатков(это СКД сделает сама)
  5. Очень важный момент! В СКД для поля "Раздел" ставим роль "Измерение" и галку "Обязательное"

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

Leave a Reply

Ваш адрес email не будет опубликован. Обязательные поля помечены *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>