При работе в крупных информационных базах на платформе 1С:Предприятие 8.3, особенно в конфигурациях 1С:ERP и 1С:Комплексная автоматизация 2.4, специалисты часто сталкиваются с аномальным поведением системы при выполнении регламентных операций. Одной из самых сложных проблем является "взрывной" рост количества записей в регистре накопления СебестоимостьТоваров после выполнения процедуры Закрытие месяца. Ситуация, когда документ, имеющий 100–200 исходных строк, после расчета себестоимости разрастается до 50 000 и более записей, делает невозможным оперативное завершение периода и парализует работу системы на несколько дней.
В этой статье мы подробно разберем причины возникновения таких аномалий, проанализируем ошибки аналитики учета и предложим пошаговый алгоритм решения проблемы.
Давайте разберем ситуацию, когда при расчете себестоимости программа начинает генерировать тысячи корректирующих строк. В большинстве случаев это не ошибка платформы, а результат работы механизма Партионного учета 2.0, который пытается распределить затраты в условиях некорректных настроек или данных.
Рекурсивное распределение дополнительных расходов. Рассмотрим механизм распределения. Если в системе используется СтатьяРасходов с вариантом распределения "На себестоимость товаров", программа должна четко понимать базу распределения. Проблема возникает, когда база распределения (например, стоимость или количество) включает в себя документы, которые сами являются объектами распределения этих же затрат. Система уходит в бесконечный цикл: она начисляет копейку расхода, это меняет стоимость партии, изменение стоимости требует нового пересчета распределения, и так до тех пор, пока суммы округления не будут разнесены по всем мельчайшим движениям. В результате мы видим десятки тысяч записей с копеечными суммами.
Ошибки в ключах аналитики учета номенклатуры. Проанализируем объект КлючАналитикиУчетаНоменклатуры. Это системный справочник, который объединяет склад, номенклатуру, характеристики и серии. Если в базе данных по какой-то причине (например, после некорректного обмена или программного изменения реквизитов) появились дубли аналитик, которые визуально идентичны, но имеют разные ссылки, система партионного учета начинает "дробить" движения. На каждое корректное движение программа создает сторнирующую запись по старому ключу и новую запись по актуальному. Если таких ключей много, количество записей растет в геометрической прогрессии.
Эта ошибка является классической для регистров СебестоимостьТоваров и ВыручкаИСебестоимостьПродаж. Она означает, что количественно товар списан полностью, но на остатках зависла его стоимость (как правило, из-за дополнительных расходов или корректировок).
Для исправления ситуации выполним следующие действия:
КорректировкаПриобретения или при оформлении возвратов в периодах, следующих за реализацией, если используется метод оценки Средняя за месяц.ПередачаТоваровМеждуОрганизациями не был оформлен или был оформлен после реализации, система не сможет корректно закрыть стоимость на стороне организации-продавца.Ошибка "Сформированы движения с некорректной организацией: Возврат товаров от клиента" часто вводит в заблуждение, так как визуально в документе ВозвратТоваровОтКлиента организация указана верно. Однако проблема кроется глубже — в ссылочной целостности регистров.
Рассмотрим ситуацию: возврат оформляется на основании РеализацияТоваровУслуг. Если в реализации был включен раздельный учет товаров по налогообложению НДС, а в возврате эти настройки не совпадают, либо если в цепочке документов была программно изменена организация, то 1С при выполнении фонового задания закрытия месяца может подставить в регистр ДвиженияСебестоимостьТоваров пустые ссылки или ссылки на головную организацию вместо филиала.
Для исправления попробуем следующий алгоритм:
Документ ТаможеннаяДекларацияИмпорт (ГТД) является мощным генератором записей в регистре себестоимости. Если в одной декларации указано 300 позиций номенклатуры, которые в течение месяца перемещались между пятью складами, система будет пытаться распределить пошлины и сборы на каждую партию в каждом месте хранения.
Если вы видите рост до 48 000 записей именно по ГТД, проанализируем настройку Статьи расходов, по которой отражается пошлина:
Поскольку в крупных компаниях остановка базы более чем на 20 минут невозможна, стандартное Тестирование и исправление (ТиИС) средствами 1С выполнить не получится. В этом случае воспользуемся методами обслуживания на уровне SQL и консоли заданий:
Очистка регистра Задания к расчету. Перейдем в регистр сведений ЗаданияКРасчетуСебестоимости. Часто там накапливаются тысячи записей за прошлые годы, которые заставляют систему при любом изменении текущего месяца пытаться пересчитать "хвосты" из 2018–2020 годов. Очистка старых записей (не затрагивающих текущий и прошлый месяцы) может ускорить расчет в несколько раз.
Поиск дублей аналитик через SQL. Если есть подозрение на дубли в справочнике КлючиАналитикиУчетаНоменклатуры, выполним запрос для поиска записей с одинаковым набором полей (Номенклатура, Склад, Характеристика), но разными IDRRef. После нахождения дублей необходимо воспользоваться типовой обработкой "Поиск и замена дублей", но крайне осторожно, так как эти справочники являются системными.
Использование консоли запросов для диагностики. Чтобы понять, какие именно строки раздувают регистр, выполним запрос к регистру СебестоимостьТоваров с группировкой по регистратору и количеству записей:
ВЫБРАТЬ
Себестоимость.Регистратор КАК Документ,
КОЛИЧЕСТВО(*) КАК КоличествоСтрок
ИЗ
РегистрНакопления.СебестоимостьТоваров КАК Себестоимость
ГДЕ
Себестоимость.Период МЕЖДУ &НачалоПериода И &КонецПериода
СГРУППИРОВАТЬ ПО
Себестоимость.Регистратор
УПОРЯДОЧИТЬ ПО
КоличествоСтрок УБЫВАЮЩЕ
Этот запрос позволит нам быстро выявить "виновников" и сосредоточить внимание на конкретных документах ТаможеннаяДекларацияИмпорт или РаспределениеРасходов.
Подводя итог, отметим: появление десятков тысяч лишних строк — это всегда сигнал о том, что алгоритм распределения 1С столкнулся с неопределенностью в данных. Тщательная проверка Статей расходов, заполнение Аналитики и контроль Цепочек перемещения товаров позволяют вернуть процесс закрытия месяца в штатный режим.