При обслуживании исторических баз данных на платформе 1С:Предприятие 7.7, особенно комплексных конфигураций, мы часто прибегаем к процедуре свертки базы (обрезки истории). Это позволяет уменьшить размер базы и увеличить скорость работы. Однако, этот процесс может привести к неочевидным проблемам в учете, когда текущие операции ссылаются на документы из "обрезанного" периода. Рассмотрим подробно ситуацию, когда необходимо сделать сторнирование реализации прошлого года, движения которой были удалены при свертке, и найдем оптимальное решение.
Давайте разберем механику процесса. Пользователь выполняет свертку базы на начало текущего года (например, на 01.01.2024). Все документы 2023 года остаются в базе, но их движения по регистрам удаляются, а остатки переносятся во "Ввод остатков".
В феврале 2024 года возникает необходимость аннулировать (сторнировать) реализацию за 2023 год и перепродать этот товар. Пользователь вводит документ Сторно на основании старой реализации. И здесь происходит сбой:
Сторно проводится без ошибок.Причина кроется в архитектуре платформы 1С 7.7. Метод проведения документа Сторно работает следующим образом: он обращается к документу-основанию, считывает его текущие движения в регистрах, инвертирует знаки (умножает на -1) и записывает их датой сторнирования.
Поскольку мы выполнили свертку базы, у документа-основания 2023 года движений больше нет (они пусты). Платформа считывает "пустоту", умножает её на -1 и получает "пустоту". В итоге документ Сторно в 2024 году оказывается пустышкой.
Мы проанализировали несколько подходов к решению этой задачи. Давайте рассмотрим их от самых простых (но методологически спорных) до профессиональных.
Если строгие требования к сторнированию (именно аннулированию записи в книге продаж) отсутствуют, самым простым способом является замена документа Сторно на цепочку стандартных документов:
Минус: Это отражается в отчетности как "обратная реализация" (покупка у клиента), что может не устроить бухгалтерию, если требуется именно аннулирование первичной продажи.
Идея заключается в том, чтобы временно "оживить" старый документ. Алгоритм действий:
Ввод остатков (чтобы не задвоить суммы).Сторно в текущем периоде (теперь он "увидит" движения).Ввод остатков.Почему мы не рекомендуем этот метод: В комплексных конфигурациях 7.7 используется партионный учет (регистр ПартииНаличие). Старая реализация при проведении попытается списать партии, которых уже может не существовать в реестре партий после свертки. Это приведет к ошибкам проведения ("Не списано по партии...") или некорректной себестоимости.
Это наиболее профессиональный подход для платформы 7.7 в данной ситуации. Поскольку штатный механизм не работает, мы должны сымитировать действия системы вручную.
Суть метода заключается в использовании специальной внешней обработки или универсального документа (часто называемого "Корректировка записей регистров", "Универсальный двигатель" или UpravlenieRegistrom), который позволяет напрямую формировать записи в регистрах накопления, минуя стандартную логику проведения.
План действий:
ОстаткиТМЦ (количество товара);ПартииНаличие (себестоимость, партионный разрез);ВзаиморасчетыПокупателей (сумма долга);КнигаПродаж (НДС);Продажи (обороты).Сторно используем "Универсальный двигатель регистров" (если его нет в конфигурации, его нужно добавить или использовать внешнюю обработку, создающую операции).Расход по регистру ОстаткиТМЦ на 5 штук, мы делаем запись Приход на 5 штук. Если это регистр оборотов (например, Продажи), мы пишем сумму с минусом.Если вы программист и пишете обработку для корректировки самостоятельно, обратите внимание, что для корректного сторнирования в 7.7 важно точно соблюдать структуру измерений регистров. Особенно это касается измерения Партия в регистре ПартииНаличие.
Если в свернутой базе старой партии (документа поступления) уже нет (она свернулась в документ "Ввод Остатков"), то при ручной корректировке регистров у вас есть два пути:
Путь А (Идеальный, но сложный):
Указать в качестве партии ссылку на документ Ввод остатков, который сформировал остаток на начало года. Но это сложно вычислить, если товаров много.
Путь Б (Прагматичный): Восстановить движение с "пустой" партией или со ссылкой на старый документ (даже если его нет в остатках). Но тогда при новой реализации 1С спишет товар из "текущих" остатков (из Ввода остатков), используя метод списания FIFO/LIFO, установленный в константах. Это допустимо, если общее количество товара на складе сходится.
Если вы создаете инструмент для автоматизации этого процесса, логика кода на встроенном языке 1С 7.7 будет выглядеть примерно так (псевдокод для понимания сути):
// Создаем объект для работы с регистром
РегОстатки = СоздатьОбъект("Регистр.ОстаткиТМЦ");
// Устанавливаем привязку к документу-регистратору (наш ручной документ)
РегОстатки.ПривязатьКДокументу(ТекущийДокумент());
// Записываем движение "Приход" (возврат товара)
РегОстатки.Номенклатура = ВыбранныйТовар;
РегОстатки.Склад = ВыбранныйСклад;
РегОстатки.Количество = ВозвращаемоеКоличество;
РегОстатки.ДвижениеПриходВыполнить();
Проблема "пустого сторно" после свертки базы является классической для 1С 7.7. Стандартный документ Сторно бесполезен без движений документа-основания.
Лучшее решение: Использовать специализированный документ или обработку для ручной корректировки записей регистров. Данные для корректировки необходимо взять из архивной копии базы до момента свертки. Это гарантирует, что у вас "сойдутся" не только складские остатки, но и взаиморасчеты, и книга продаж.