Как в 1С:Комплексная автоматизация и ERP вывести ОСВ по единицам измерения для отчетов?

При переходе на современные конфигурации, такие как 1С:Комплексная автоматизация 2 или 1С:ERP Управление предприятием, пользователи часто сталкиваются с неочевидным поведением отчетов регламентированного учета. Типичный пример — попытка вывести Оборотно-сальдовую ведомость (ОСВ) по счетам учета ТМЦ (например, 10 или 41) в альтернативных единицах измерения (например, в тоннах вместо базовых килограммов). Бухгалтеры замечают странную картину: для одной номенклатурной позиции программа как будто производит пересчет в тонны, а для другой — оставляет количество в килограммах. Давайте разберем по шагам, почему так происходит, как устроена архитектура единиц измерения в системе и какими методами можно решить эту задачу.

Выясняем причину: почему происходит «избирательный» пересчет в ОСВ

Для начала проанализируем ситуацию, которая вызывает недоумение у многих пользователей. На первый взгляд кажется, что программа ведет себя непредсказуемо: часть позиций в ОСВ отображается в «кг», а часть — в «тн», хотя для всех позиций настроена «Единица для отчетов» как «тн».

Секрет кроется в жестком правиле платформы 1С: проводки регламентированного (бухгалтерского) учета всегда совершаются строго в «Единицах хранения», которые указаны в карточке номенклатуры как основные. Бухгалтерский регистр Хозрасчетный технически не содержит полей для хранения коэффициентов пересчета и не умеет на лету конвертировать остатки при формировании стандартной ОСВ.

Мистика «выборочного пересчета» на самом деле является следствием неоднородного заполнения нормативно-справочной информации (НСИ):

1. Для «пересчитавшихся» позиций: при создании карточки номенклатуры в поле Единица хранения (базовая единица) изначально была выбрана крупная единица измерения — «тн» (тонна). При этом килограммы могли использоваться в документах как дополнительная единица или упаковка. Поскольку базовая единица хранения — тонна, ОСВ вывела остатки именно в тоннах.
2. Для «непересчитавшихся» позиций: в качестве базовой Единицы хранения были указаны «кг», а «тн» настроена как виртуальная Единица для отчетов. В этом случае ОСВ проигнорировала единицу для отчетов и вывела остатки в базовых килограммах.

Такой разнобой часто возникает при массовом переносе данных из старых систем (например, из 1С:УПП) или при ручном вводе номенклатуры разными сотрудниками без жесткого контроля стандартов ведения НСИ.

Как устроен механизм «Единица для отчетов» в 1С:КА 2 и ERP

Проанализируем назначение реквизита Единица для отчетов в современных ERP-системах. Этот реквизит является вспомогательным и предназначен исключительно для оперативного (управленческого) контура учета.

Когда вы формируете оперативные отчеты, такие как Ведомость по товарам на складах или Остатки и доступность товаров, система позволяет выбрать в настройках вариант вывода количества: «В единицах хранения» или «В единицах для отчетов». В этот момент отчет обращается к регистрам накопления, берет физический остаток в базовых единицах и на лету делит или умножает его на коэффициент, заданный в карточке номенклатуры. В бухгалтерском учете (на счетах плана счетов) этот механизм динамического пересчета не задействован из соображений производительности и методологии учета.

Рассмотрим три практических варианта решения этой проблемы, которые позволят бухгалтерам комфортно работать с отчетностью.

Вариант А. Наведение порядка в нормативно-справочной информации (НСИ)

Если для вашего предприятия методологически правильно видеть остатки по определенным группам товаров (например, металлопрокат или строительные смеси) именно в тоннах, лучшим решением будет приведение карточек номенклатуры к единому стандарту.

Необходимо, чтобы у всей однородной номенклатуры базовая Единица хранения была установлена как «тн». При этом в повседневных документах поступления, перемещения и реализации вы можете продолжать указывать килограммы. Для этого используется механизм индивидуальных или общих упаковок. Вы настраиваете упаковку «кг» с коэффициентом 0,001 по отношению к тонне. При проведении документов система автоматически пересчитает килограммы в тонны, запишет данные в регистры БУ, и в ОСВ все остатки сойдутся идеально.

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

1. Либо завести новые карточки номенклатуры с правильной единицей хранения, перенести на них остатки с помощью документов корректировки, а старые карточки пометить на удаление.
2. Либо воспользоваться специализированными обработками по изменению реквизитов (требуется монопольный доступ к базе данных и высокая квалификация администратора, так как некорректное изменение единицы измерения у проведенных документов "задним числом" может привести к искажению себестоимости в закрытых периодах).

Вариант Б. Использование оперативных отчетов вместо ОСВ

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

Рекомендуем настроить для бухгалтеров отчет Ведомость по товарам на складах (раздел Склад и доставка — Отчеты по складу) следующим образом:

1. Откройте отчет и перейдите в панель настроек.
2. В поле выбора показателей для вывода количества укажите вариант «В единицах для отчетов».
3. Настройте группировки по складам, номенклатуре или группам номенклатуры.
4. Сохраните этот вариант отчета под понятным названием (например, «Остатки товаров в тоннах для бухгалтерии»), чтобы пользователям не приходилось настраивать его заново каждый раз.

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

Вариант В. Доработка стандартного отчета ОСВ через СКД

Если бухгалтерия категорически отказывается работать в других отчетах и требует именно классическую ОСВ по счетам с пересчитанным количеством, можно прибегнуть к доработке отчета. Поскольку современные отчеты в 1С построены на базе Системы компоновки данных (СКД), разработчик может изменить схему компоновки без снятия конфигурации с поддержки.

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

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

ВЫБРАТЬ
    ХозрасчетныйОстатки.Субконто1 КАК Номенклатура,
    ХозрасчетныйОстатки.Организация КАК Организация,
    ХозрасчетныйОстатки.Счет КАК Счет,
    ХозрасчетныйОстатки.КоличествоОстаток КАК КоличествоВЕдиницахХранения,
    
    // Выполняем пересчет количества в единицу для отчетов, если она задана
    ВЫБОР
        КОГДА ХозрасчетныйОстатки.Субконто1.ЕдиницаДляОтчетов <> ЗНАЧЕНИЕ(Справочник.УпаковкиЕдиницыИзмерения.ПустаяСсылка)
            ТОГДА ХозрасчетныйОстатки.КоличествоОстаток * (ХозрасчетныйОстатки.Субконто1.ЕдиницаИзмерения.Коэффициент / ХозрасчетныйОстатки.Субконто1.ЕдиницаДляОтчетов.Коэффициент)
        ИНАЧЕ ХозрасчетныйОстатки.КоличествоОстаток
    КОНЕЦ КАК КоличествоВЕдиницахОтчетов,
    
    // Получаем представление единицы измерения для вывода в колонку
    ВЫБОР
        КОГДА ХозрасчетныйОстатки.Субконто1.ЕдиницаДляОтчетов <> ЗНАЧЕНИЕ(Справочник.УпаковкиЕдиницыИзмерения.ПустаяСсылка)
            ТОГДА ХозрасчетныйОстатки.Субконто1.ЕдиницаДляОтчетов
        ИНАЧЕ ХозрасчетныйОстатки.Субконто1.ЕдиницаИзмерения
    КОНЕЦ КАК ЕдиницаИзмеренияВывода
ИЗ
    РегистрБухгалтерии.Хозрасчетный.Остатки(&Период, Счет В ИЕРАРХИИ (&СчетУчета), , ) КАК ХозрасчетныйОстатки

При таком подходе в схеме компоновки данных создается новое вычисляемое поле. Бухгалтеры в настройках ОСВ смогут добавлять на вкладку «Поля и сортировки» колонку Количество в единицах отчетов и выводить ее рядом со стандартными суммами и базовым количеством. Это решает проблему отображения данных без внесения деструктивных изменений в исторические документы системы.