При попытке скорректировать валюту взаиморасчетов в карточке договора или изменить ее программным путем разработчики и пользователи типовой конфигурации «1С:Бухгалтерия предприятия» сталкиваются с системным сообщением: «Реквизит не может быть изменен так как существуют проведенные документы». Выясним причину такого поведения платформы, проанализируем технические риски прямого изменения реквизита и разберем проверенные способы решения этой задачи.
В типовых конфигурациях в модуле объекта справочника ДоговорыКонтрагентов в процедуре ПередЗаписью заложен жесткий контроль ключевых аналитических реквизитов: ВалютаВзаиморасчетов, ВидДоговора и владельца договора. Если по данному договору уже зафиксированы движения в регистрах бухгалтерии или накопления, платформа блокирует интерактивную и программную перезапись этих полей.
Это ограничение обусловлено базовыми принципами ведения бухгалтерского учета. Валюта договора напрямую определяет выбор счетов расчетов с контрагентами в первичных документах:
60.01 / 62.01 (и субсчета авансов 60.02 / 62.02).60.21 / 62.21 (авансы 60.22 / 62.22).60.31 / 62.31.Если изменить валюту в самом договоре без корректировки счетов в существующих проводках, нарушится соответствие между аналитикой договора и признаками валютного учета на счетах регистра бухгалтерии «Хозрасчетный».
С технической точки зрения ограничение на уровне модуля объекта можно обойти, отключив выполнение встроенных алгоритмов проверки при записи объекта. Посмотрим на пример программного кода, который часто применяют для принудительного изменения реквизита:
ДоговорОбъект = ВыбранныйДоговор.ПолучитьОбъект();
ДоговорОбъект.ВалютаВзаиморасчетов = НужнаяВалюта;
ДоговорОбъект.ОбменДанными.Загрузка = Истина;
ДоговорОбъект.Записать();
Разберем, к каким последствиям приводит такой подход. Установка свойства ОбменДанными.Загрузка = Истина действительно подавляет проверки в обработчиках ПередЗаписью и позволяет сохранить элемент. Однако этот путь порождает серьезные скрытые проблемы:
Использовать свойство ОбменДанными.Загрузка = Истина для смены валюты договора допустимо только в том случае, если разработчик дополнительно программно исправит движения во всех связанных регистрах и реквизиты табличных частей первичных документов.
Часто проблема возникает не из-за ошибки в самом договоре, а из-за задвоения элементов в справочнике Валюты (например, появились две позиции «руб.» с кодами 643 и 810). Если договоры и документы ссылаются на разные элементы одной и той же валюты, правильнее всего выполнить слияние дублей на уровне справочника валют, а не договоров.
Разберем по шагам, как решить задачу штатными средствами:
Валюты.При таком подходе платформа выполнит низкоуровневую замену ссылок во всех документах, договорах и регистрах сведений без вызова валидации договоров и без необходимости снимать первичные документы с проведения.
Если речь идет о реальной смене условий взаиморасчетов с контрагентом (например, переход с валютных расчетов на рублевые), правильным с точки зрения методологии бухгалтерского учета является разделение учета по периодам.
Рассмотрим порядок действий без снятия с проведения исторических документов:
Этот способ гарантирует сохранение неизменности сданной бухгалтерской и налоговой отчетности прошлых периодов и исключает любые ошибки при последующем закрытии месяца.
Если ошибка была допущена в текущем незакрытом периоде и необходимо исправить именно исторические цепочки документов, простого изменения договора недостаточно. Потребуется изменить счета учета в самих документах.
Проанализируем алгоритм правильного исправления:
62.21 на рублевый 62.01). Для массовой корректировки рекомендуется использовать инструмент «Групповое изменение реквизитов» в разделе «Администрирование».