Как в 1С:Комплексная автоматизация 2.5 вести учет товаров по количеству и устранить копейки на 20 счете

В процессе эксплуатации системы 1С:Комплексная автоматизация 2.5 (КА 2.5) пользователи часто сталкиваются с двумя специфическими задачами. Первая — это необходимость ведения исключительно складского (количественного) учета без отражения стоимостных показателей в документах закупки. Вторая — возникновение труднообъяснимых погрешностей (копеек) на 20 счете, которые не закрываются регламентными операциями в конце месяца. В данной статье мы подробно разберем обе ситуации, проанализируем причины их возникновения и найдем оптимальные способы решения.

Возможность ведения учета только по количеству без указания сумм

Рассмотрим ситуацию, когда конфигурация используется исключительно для управления складом, и финансовые показатели на этапе закупки не представляют интереса для пользователя. Проанализируем архитектуру систем на базе 1С:ERP и КА 2.5: эти решения глубоко интегрированы с финансовым контуром. Это означает, что штатной функциональной опции, позволяющей просто «выключить» цены и суммы в документах Заказ поставщику или Приобретение товаров и услуг, не существует.

Выясним, почему система требует заполнения сумм:

1. Формирование себестоимости: Даже если вы не ведете полноценный бухгалтерский учет, регистры накопления (например, Стоимость товаров) ожидают данных для расчета партий и стоимостной оценки остатков.
2. Проведение документов: Поля «Цена» и «Сумма» в типовой конфигурации являются обязательными для заполнения на уровне программного кода.

Варианты решения задачи:

1. Доработка в Конфигураторе: Как было отмечено специалистами, радикальное решение возможно только путем снятия конфигурации с поддержки и изменения свойств объектов. Однако это усложнит дальнейшие обновления.
2. Минимальная цена: Если ввод сумм критически нежелателен, можно указывать во всех строках цену в 1 копейку. Это позволит документам проводиться, но стоит учитывать, что это приведет к накоплению микроскопической стоимости на балансе.
3. Настройка прав доступа: Если цель — скрыть суммы от определенных сотрудников (например, кладовщиков), целесообразно использовать механизм Профили групп доступа. В этом случае данные в системе будут, но пользователь их не увидит в интерфейсе и печатных формах.

Почему возникают «зависшие» копейки на 20 счете?

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

1. Математические округления СЛАУ: В КА 2.5 используется алгоритм решения систем линейных алгебраических уравнений для распределения затрат и расчета себестоимости. При сложных схемах выпуска (встречный выпуск, многопередельное производство) возникают неизбежные математические погрешности при делении сумм на количество.
2. Ошибки релизов: В ветках 2.5.7 и 2.5.8 разработчики вносили изменения в механизмы округления, что в ряде случаев приводило к некорректному распределению остатков.
3. Отсутствие базы распределения: Если на статью расходов упали затраты, а база для их распределения (например, объем выпуска или оплата труда) в текущем месяце отсутствует, сумма может «зависнуть».

Пошаговое решение проблемы незакрытого 20 счета

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

Шаг 1: Настройка статьи расходов для погрешностей

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

Проверим настройки на вкладке «Регламентированный учет» в карточке статьи расходов:

• Убедимся, что для статьи указан корректный счет учета (например, 20.01).
• Найдем поле, отвечающее за погрешность расчета стоимости. В ряде случаев система требует явно указать статью, на которую будут отнесены эти копейки.

Шаг 2: Указание счета прочих доходов/расходов

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

Рассмотрим логику: если сумма составляет 20 копеек, ее распределение на 10 000 единиц продукции физически невозможно без образования новых остатков. Списание на 91 счет решает эту проблему окончательно.

Шаг 3: Очистка технических регистров

Иногда пересчет месяца не помогает из-за старых записей в технических регистрах. Попробуем выполнить следующие действия:

1. Распроведем документы регламентных операций по закрытию месяца.
2. Проверим регистр Задания к распределению расчетов. Если там висят записи за прошлые периоды, их стоит проанализировать и, при необходимости, очистить.
3. Спровоцируем систему на пересчет, перепроведя любой первичный документ (например, Приобретение товаров и услуг) в начале месяца.

Использование документа «Корректировка стоимости списания»

Если автоматическое закрытие все равно оставляет копейки, проанализируем возможность ручного вмешательства. В КА 2.5 предусмотрен документ Корректировка стоимости списания товаров. Рассмотрим пример его использования:

Допустим, по счету 20.01 по определенной номенклатурной позиции или статье затрат остался дебетовый остаток 0.02 руб. при нулевом количественном остатке. В этом случае мы можем создать документ корректировки, который принудительно спишет эту стоимость на указанный счет (например, 91.02), восстановив баланс.

Пример заполнения корректировки (схематично):

// Логика заполнения корректировки
Корректировка.Организация = Объект.Организация;
Корректировка.Период = КонецМесяца(Дата);
Строка = Корректировка.Стоимость.Добавить();
Строка.Номенклатура = ТоварСКопейками;
Строка.Стоимость = 0.02;
Строка.СчетУчета = СчетаУчета.ДвадцатыйСчет;
Строка.КорСчет = СчетаУчета.ПрочиеРасходы;

Рекомендации по обновлению системы

Посмотрим на ситуацию со стороны развития платформы. Если вы используете релиз 2.5.8.287 и сталкиваетесь с массовыми ошибками округления, проанализируем целесообразность перехода на более свежие версии. Начиная с релиза 2.5.10, разработчики внесли существенные изменения в СЛАУ и механизмы распределения постатейных расходов. Практика показывает, что в четных релизах (2.5.10, 2.5.12) алгоритмы работают более стабильно в плане финансового результата, чем в переходных версиях 2.5.8 или 2.5.9.

Подведем итог: для ведения чисто количественного учета в КА 2.5 придется либо смириться с заполнением цен (хотя бы в 1 копейку), либо вносить изменения в конфигурацию. Для решения проблемы с копейками на 20 счете — используйте настройку статей расходов с направлением погрешностей на 91 счет и своевременно обновляйте программу до стабильных релизов.