При работе с Системой Компоновки Данных (СКД) в 1С, особенно при формировании отчетов по регистрам накопления, мы часто сталкиваемся с необходимостью корректного расчета начальных и конечных остатков. Ошибки в отображении этих данных, особенно при использовании группировок, могут возникать по множеству причин, и не всегда они очевидны. В данной статье мы подробно разберем ситуацию, когда нетиповой документ вызывает некорректные остатки в отчете, в то время как типовые документы работают без проблем.
Наш читатель столкнулся с проблемой в конфигурации 1С:ERP на платформе 8.3.24.1691. Он добавил новый регистр остатков, свой документ в качестве регистратора и также включил в этот регистр типовые документы. Все изменения были сделаны непосредственно в конфигурации, без расширений. Однако при формировании отчета "Остатки и обороты" по новому регистру обнаружились "кривые" данные: неправильные начальные и конечные остатки в группировках, причем это происходило только тогда, когда его собственный документ стоял в списке регистраторов первым. Типовые документы не вызывали таких проблем.
Для наглядности, наш читатель провел эксперимент: он скопировал типовой документ "Корректировка регистров" без изменений, сделал его регистратором в своем регистре, а также использовал оригинальный типовой документ. Создав идентичные движения, он обнаружил, что скопированный (хоть и нетиповой) документ показывал неправильные данные в отчете, а типовой — правильные. Это явно указывало на системную проблему.
Прежде чем перейти к глубинному анализу, давайте рассмотрим, какие шаги уже были предприняты для локализации проблемы. Эти действия являются стандартными и обязательными при возникновении подобных ситуаций:
"ЗапуститьОбновлениеИнформационнойБазы". Это позволяет убедиться, что все структуры данных актуализированы.После этих шагов наш читатель пришел к выводу, что проблема лежит глубже, чем стандартные настройки или ошибки данных.
Когда мы сталкиваемся с некорректными остатками в отчетах СКД, наш первый шаг — это анализ настроек СКД и самого запроса. Даже если автор утверждает, что все сделано по рекомендациям 1С, всегда полезно перепроверить ключевые моменты. Рассмотрим подробнее, на что следует обратить внимание.
Для корректного расчета остатков в СКД крайне важно правильно определить роли для полей, участвующих в запросе к виртуальной таблице ОстаткиИОбороты регистра накопления.
Регистратор и ПериодСекунда:
При запросе к виртуальной таблице ОстаткиИОбороты обязательно должны быть выбраны поля Регистратор и ПериодСекунда. Отсутствие этих полей или неправильное определение их ролей является одной из самых частых причин "кривых" остатков.
Для поля Период в настройках СКД должна быть установлена роль «Период». Аналогично, для поля Регистратор или ПериодСекунда должна быть установлена роль «Период», причем Период обычно является первым уровнем, а Регистратор или ПериодСекунда – вторым. Это позволяет СКД правильно строить иерархию периодов и регистраторов для агрегации данных.
Пример структуры запроса в СКД, который мы используем для получения данных регистра:
ВЫБРАТЬ
РегистрНакопления.Период,
РегистрНакопления.Регистратор,
РегистрНакопления.ПериодСекунда,
РегистрНакопления.Измерение1,
РегистрНакопления.Измерение2,
РегистрНакопления.РесурсНачальныйОстаток,
РегистрНакопления.РесурсКонечныйОстаток,
РегистрНакопления.РесурсПриход,
РегистрНакопления.РесурсРасход
ИЗ
РегистрНакопления.НашРегистр.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, Авто, Регистратор, Измерение1, Измерение2) КАК РегистрНакопления
Даже если автор утверждал, что добавил ПериодСекунда и проверял роли, это фундаментальный аспект, который всегда должен быть первым в списке проверки.
Остатки:
Для всех полей, содержащих остатки (например, КоличествоНачальныйОстаток, КоличествоКонечныйОстаток, СуммаНачальныйОстаток и т.д.), необходимо установить роль «Остатки». Это указывает СКД на то, что эти поля представляют собой остатки и должны быть агрегированы соответствующим образом.
Измерение:
Все поля, которые выступают в качестве "измерений" (то есть те, в разрезе которых мы хотим получать остатки и группировать данные), должны быть отмечены соответствующей ролью «Измерение». Если поле не помечено как измерение, оно не будет учитываться при расчете итогов, что приведет к неверным данным. И наоборот, поле, не являющееся по сути измерением, не должно быть помечено этой ролью.
Помимо ролей полей, ключевое значение имеют настройки ресурсов на соответствующей вкладке в СКД.
На вкладке Ресурсы крайне важна правильная настройка итогов. Если настройки не заданы или заданы некорректно, система может просто вывести данные, полученные запросом, без корректного агрегирования по группировкам. Для полей остатков обычно используется функция Сумма.
Если итоги станут нормальными после упрощения настроек ресурсов, это указывает на то, что проблема кроется в выражениях ресурсов или в их взаимодействии с группировками.
Важно помнить, что если в отчете используются вычисляемые поля, особенно те, которые агрегируют данные из регистратора (например, Максимум(НазначениеПлатежа)), это также может повлиять на правильность расчета остатков по измерениям, если сам регистратор не учтен должным образом в группировках или ролях.
Обсуждение на форуме также коснулось понятия "Граница" и настроек параметров периода. Хотя оно не привело к явному решению в данном случае, мы должны учитывать эти аспекты при работе с СКД:
Для параметров периода отчета (&НачалоПериода, &КонецПериода) рекомендуется использовать собственные, явно определенные параметры в СКД, а не полагаться на системные. Следует избегать использования имени параметра ПериодОтчета, так как оно может конфликтовать с системными механизмами. Это дает больший контроль над формированием границ запроса и предотвращает потенциальные коллизии.
Граница:
В запросах к виртуальным таблицам остатков и оборотов часто используется параметр Граница (например, &КонецПериода, Включая или &КонецПериода, Исключая). Неправильное его использование может приводить к смещению остатков на одну позицию. Однако в большинстве типовых случаев СКД достаточно умна, чтобы обрабатывать это корректно, если даты и роли определены правильно.
Самое важное открытие в этой ситуации было сделано автором при повторном тестировании на разных версиях платформы:
Автор создал чистую конфигурацию на платформе 8.3.24, добавил два документа и один регистр, а затем сформировал аналогичный отчет. Результат был тот же — "кривые" данные. Это подтвердило, что проблема не специфична для 1С:ERP, а является особенностью платформы 8.3.24.
Затем он взял платформу 8.3.18, создал там те же два документа, регистр и отчет. Все работало корректно. Затем, в этой же базе (созданной на 8.3.18), он создал ещё один документ-регистратор, но уже на платформе 8.3.24. После этого именно этот, последний созданный документ, стал отображаться в отчете некорректно, в то время как документы, созданные на 8.3.18, оставались "правильными".
Это наблюдение является критически важным. Оно указывает на то, что проблема, скорее всего, не в логике СКД или запроса как таковой, а в низкоуровневых метаданных объекта, или в том, как платформа 8.3.24 сохраняет и интерпретирует структуру объектов, созданных в ней. Возможно, существуют тонкие различия в служебных данных метаданных, которые влияют на поведение объектов при взаимодействии с механизмами СКД или регистров накопления.
Учитывая выявленную зависимость от версии платформы, мы можем предложить следующие шаги для углубленной диагностики:
Мы рекомендуем провести детальное сравнение структуры (метаданных) "правильного" документа (созданного на 8.3.18) и "кривого" документа (созданного на 8.3.24). Это можно сделать путем выгрузки конфигураций в XML-файлы и использования специализированных инструментов для их сравнения. Цель — выявить любые, даже самые неочевидные, различия в структуре или свойствах объектов, которые могли возникнуть при создании на разных версиях платформы.
Особое внимание следует уделить свойствам объекта метаданных, которые могут влиять на проведение, записи в регистры и взаимодействие с общими механизмами платформы.
Мы можем использовать инструменты трассировки или профилирования СКД, чтобы отследить, как именно система компоновки данных обрабатывает движения каждого типа документа (типового и нетипового). Это поможет определить, на каком этапе возникает некорректный расчет итогов — возможно, на этапе выборки данных, их агрегации или связывания.
Поскольку проблема воспроизводится на чистой конфигурации и явно связана с версией платформы при создании документа, это может быть признаком ошибки самой платформы. В таком случае, наиболее эффективным путем решения является обращение в службу поддержки 1С. Мы должны предоставить им подробное описание проблемы, шаги для её воспроизведения (включая использование разных версий платформы для создания объектов) и приложить тестовую конфигурацию, на которой проблема проявляется.
Хотя автор указал, что активность движений была намеренно отключена для сравнения, в рабочем режиме всегда следует убедиться, что для движений проблемного документа установлено свойство Активность в значение Истина, если они должны участвовать в расчете остатков. Неактивные движения не будут учитываться в регистрах накопления.
Ситуация, когда отчет СКД выдает некорректные остатки для нетипового документа, созданного на более новой версии платформы 1С, является сложной и требует глубокого анализа. Мы выяснили, что причина может крыться не только в стандартных настройках СКД или запроса, но и в более тонких взаимодействиях между объектами метаданных и версией платформы. Хотя окончательное решение в рамках данной дискуссии не было найдено, мы определили ключевые диагностические шаги, которые помогут локализовать и, возможно, решить эту проблему. В случае подтверждения платформенной ошибки, обращение в 1С станет необходимым шагом для получения официального исправления.