При работе с конфигурацией 1С:Зарплата и управление персоналом 3.1 программисты часто сталкиваются с ситуацией, когда данные в базе данных «не соответствуют» тому, что отображается в пользовательском интерфейсе. Типичный пример: в документе ОтражениеЗарплатыВБухучете в колонке «Начисление» пользователь видит один элемент (например, с кодом 1030), а при выполнении запроса к табличной части НачисленнаяЗарплатаИВзносы система возвращает совершенно другой элемент (например, с кодом 1020). Разберем по шагам, почему так происходит и как правильно получать данные из этого документа.
Для начала проанализируем ситуацию. В современных версиях 1С (особенно в ЗУП 3.1) архитектура хранения данных в документах отражения стала значительно сложнее. Это связано с необходимостью поддерживать сложную аналитику для статистической отчетности (например, форма П-4) и корректного распределения затрат по источникам финансирования.
Когда мы открываем форму документа ОтражениеЗарплатыВБухучете, система выполняет программную обработку данных перед их выводом на экран. То, что мы видим в колонке «Начисление» в интерфейсе, не всегда напрямую связано с реквизитом Начисление в физической таблице базы данных. 1С использует механизм расширенной аналитики.
Выделим основные причины, по которым коды в запросе и в интерфейсе могут различаться:
Начисление может хранить агрегированный показатель, а поле расширенной аналитики — исходный.Рассмотрим структуру табличной части НачисленнаяЗарплатаИВзносы документа ОтражениеЗарплатыВБухучете. Если мы заглянем в конфигуратор или внимательно изучим схему запроса, мы увидим реквизит с префиксом РасшАналит_.
Именно в поле РасшАналит_ВидРасчета зачастую хранятся те данные, которые мы привыкли видеть в расчетных листках и которые ожидает увидеть пользователь в интерфейсе документа. Реквизит же Начисление в данном контексте служит для связи со способами отражения и может подменяться системой в процессе заполнения документа.
Проанализируем пример запроса, который может привести к ошибке. Если мы обращаемся напрямую к полю Начисление, мы рискуем получить неверные данные для управленческого анализа.
Рассмотрим типичный неправильный подход:
ВЫБРАТЬ
ТЧ.Начисление.Код КАК НачислениеКод,
ТЧ.Начисление.Наименование КАК НачислениеНаименование,
ТЧ.Сумма КАК Сумма
ИЗ
Документ.ОтражениеЗарплатыВБухучете.НачисленнаяЗарплатаИВзносы КАК ТЧ
ГДЕ
ТЧ.Ссылка = &Ссылка
Чтобы получить данные «как в интерфейсе», нам необходимо изменить запрос, обратившись к полям расширенной аналитики. Давайте проанализируем исправленный вариант запроса, который учитывает особенности архитектуры ЗУП 3.1:
ВЫБРАТЬ
ТЧ.Ссылка.Дата КАК Дата,
ТЧ.Ссылка.Номер КАК Номер,
ТЧ.НомерСтроки КАК НомерСтроки,
// Используем поле расширенной аналитики вместо стандартного Начисления
ВЫБОР
КОГДА ТЧ.РасшАналит_ВидРасчета <> ЗНАЧЕНИЕ(ПланВидовРасчета.Начисления.ПустаяСсылка)
ТОГДА ТЧ.РасшАналит_ВидРасчета
ИНАЧЕ ТЧ.Начисление
КОНЕЦ КАК РеальныйВидРасчета,
ТЧ.Сумма КАК Сумма,
ТЧ.ФизическоеЛицо КАК ФизическоеЛицо,
ТЧ.СпособОтраженияЗарплатыВБухучете КАК СпособОтражения
ИЗ
Документ.ОтражениеЗарплатыВБухучете.НачисленнаяЗарплатаИВзносы КАК ТЧ
ГДЕ
ТЧ.Ссылка.Проведен = ИСТИНА
И ТЧ.Ссылка.Организация = &Организация
И ТЧ.Ссылка.Дата МЕЖДУ &НачалоПериода И &КонецПериода
УПОРЯДОЧИТЬ ПО
НомерСтроки
В процессе обсуждения проблемы часто всплывает вопрос фильтрации данных по наименованию способа отражения или начисления. Например:
И ТЧ.СпособОтраженияЗарплатыВБухучете.Наименование В (&СписокИмен)
Выясним, почему этого следует избегать. В 1С справочники могут содержать элементы с одинаковыми наименованиями (дубли), либо наименование может быть случайно изменено пользователем. Это приведет к тому, что запрос перестанет выбирать нужные данные или выберет лишние.
Правильный подход:
Подведем итог и сформулируем правила для работы с документом ОтражениеЗарплатыВБухучете:
РасшАналит_.НачисленияУдержанияПоСотрудникам. Если вам нужна детальная аналитика по видам расчета, зачастую надежнее строить отчет на данных регистра, а не документа.Начисление может содержать результат работы алгоритма распределения, в то время как исходный вид расчета будет «спрятан» в аналитике.Таким образом, внимательный анализ структуры метаданных и использование полей РасшАналит_ВидРасчета позволяет избежать ошибок при получении данных и гарантирует соответствие отчетов тому, что бухгалтер видит в интерфейсе программы.