Проблема изменения базовой единицы измерения в 1С является одной из самых сложных и рискованных задач администрирования баз данных. Система жестко блокирует редактирование этих реквизитов, если по номенклатуре уже есть «движения» (документы), поскольку базовая единица является фундаментом для всех расчетов в регистрах. Разберем подробно, почему это происходит и какими способами можно решить эту задачу, не нарушив целостность учета.
Рассмотрим внутреннюю механику работы платформы. В регистрах накопления (остатки товаров, продажи, закупки) количество товара всегда хранится в базовых единицах. Если в карточке товара «Тонны» заменить на «Килограммы» простым исправлением текста, возникнет катастрофическая ошибка. Например, если на складе числилось 2 тонны, после замены единицы система будет считать, что на остатке 2 килограмма. Стоимость при этом останется прежней, что приведет к искажению себестоимости в тысячу раз. Именно поэтому штатные средства конфигураций «Управление торговлей» или «Бухгалтерия» блокируют поле единицы измерения сразу после записи первого документа.
Этот метод наиболее корректен с точки зрения программирования, так как он физически обновляет данные во всех таблицах. Проанализируем алгоритм, предложенный опытными разработчиками:
ЕдиницыИзмерения. Если ее нет — создаем программно или вручную.БазоваяЕдиницаИзмерения и ЕдиницаХраненияОстатков. Чтобы обойти блокировку, программисты используют свойство ОбменДанными.Загрузка = Истина.ЦеныНоменклатуры, чтобы цена за 1 кг соответствовала новой реальности.Для реализации этого метода можно использовать стандартную обработку УниверсальныеПодборИОбработкаОбъектов, однако для специфического пересчета количеств потребуется написать небольшой фрагмент кода в модуле обработки.
Если документов тысячи и перепроводить их за несколько лет невозможно (например, закрыты периоды), используется метод прямой корректировки. Выясним, как это работает программно. Рассмотрим пример кода, который позволяет изменить единицу, игнорируя стандартные проверки конфигурации:
// Пример программного изменения единицы
ОбъектНоменклатура = ВыбраннаяСсылка.ПолучитьОбъект();
ОбъектНоменклатура.ОбменДанными.Загрузка = Истина;
ОбъектНоменклатура.БазоваяЕдиницаИзмерения = НоваяЕдиницаСсылка;
ОбъектНоменклатура.ЕдиницаХраненияОстатков = НоваяЕдиницаСсылка;
ОбъектНоменклатура.Записать();
Внимание: Использование ОбменДанными.Загрузка = Истина отключает только проверку в самой карточке. После этого необходимо выполнить прямой запрос к базе данных (SQL) или использовать специализированные обработки для пересчета ресурсов во всех регистрах накопления. Без этого отчеты «Ведомость по товарам на складах» покажут неверные остатки.
Если вы не являетесь программистом и не хотите рисковать целостностью базы, рассмотрим наиболее безопасный метод, который не требует написания кода:
Этот метод сохраняет историю операций в старых периодах в неизменном виде и позволяет начать «чистый» учет с новой даты.
В старых версиях системы, таких как ТиС 7.7, проблема часто усугубляется «слетающими» единицами. Проанализируем причину: это происходит из-за удаления записей в подчиненном справочнике при сохранении ссылок в основной карточке. Посмотрим на решение: необходимо восстановить соответствие идентификаторов в DBF-таблицах или через встроенный язык, проверив целостность индексов. Если вы планируете перенос из 7.7 в 8.3, лучше заранее привести единицы к нужному виду еще в старой базе, чтобы избежать трудоемкой корректировки после миграции.
Чтобы в будущем не сталкиваться с необходимостью массового пересчета остатков, рекомендуем придерживаться следующих правил:
Подводя итог, отметим, что штатных средств для «бесшовного» изменения базовой единицы с автоматическим пересчетом всех прошлых документов в 1С 10.3 и 11.x не существует. Выбор стоит между написанием сложной обработки для пересчета движений или организационным решением через создание новых карточек товаров.