В процессе адаптации и миграции кода с 1С:Бухгалтерии 2.0 на 3.0 мы часто сталкиваемся с нюансами платформы и изменениями в архитектуре типовых конфигураций. Одной из таких распространенных ситуаций является ошибка Значение не является значением объектного типа при попытке вызова метода общего модуля. Давайте вместе разберем причины возникновения этой проблемы на конкретном примере и найдем эффективное решение, а также рассмотрим важные аспекты работы с учетной политикой в БП 3.0.
Предположим, мы переносим или разрабатываем кастомный документ в 1С:Бухгалтерии 3.0, и в его обработке проведения возникает ошибка. Автор столкнулся с проблемой при попытке определить, ведется ли партионный учет, используя свой метод, который, в свою очередь, вызывает типовой метод из общего модуля УчетнаяПолитика:
&НаСервере
Функция ВедетсяПартионныйУчет(УчетнаяПолитика, Учет = "БУ") // это мой метод
СпособОценкиМПЗ = УчетнаяПолитика.СпособОценкиМПЗ(Организация, Дата); // это вызов метода тройки
В момент проведения документа система выдает ошибку:
Ошибка при выполнении обработчика - 'ОбработкаПроведения'
по причине:
Значение не является значением объектного типа (СпособОценкиМПЗ)
На первый взгляд, ситуация кажется непонятной, ведь если нажать F12 на методе СпособОценкиМПЗ, мы попадаем в соответствующий общий модуль УчетнаяПолитика. Это подтверждает, что метод существует и доступен.
Ключевым моментом здесь является директива &НаСервере, указывающая, что функция выполняется на сервере, что совершенно нормально для обработок проведения документов. Однако суть проблемы кроется глубже, в области видимости переменных и параметров.
Как выяснилось в ходе обсуждения, причина ошибки кроется в конфликте имен. В платформе 1С:Предприятие 8 локальные переменные и параметры процедур имеют приоритет над именами общих модулей. Если параметр функции назван так же, как общий модуль (в нашем случае, УчетнаяПолитика), то при попытке обращения к методу через это имя система будет искать его внутри переданного значения (параметра), а не в глобальном общем модуле. Поскольку переданный параметр, скорее всего, не является объектом, содержащим метод СпособОценкиМПЗ, возникает ошибка «Значение не является значением объектного типа».
Разберем шаги, которые мы должны предпринять для устранения этой ошибки:
ВедетсяПартионныйУчет — УчетнаяПолитика — полностью совпадает с именем общего модуля УчетнаяПолитика. Это создает неоднозначность для компилятора.ПараметрыУчетнойПолитики или НастройкиУчетнойПолитики.После переименования параметра наш код будет выглядеть следующим образом:
&НаСервере
Функция ВедетсяПартионныйУчет(НастройкиУчетнойПолитики, Учет = "БУ") // Параметр переименован
// Теперь вызов СпособОценкиМПЗ(Организация, Дата) будет идти из общего модуля УчетнаяПолитика,
// а не из одноименного параметра.
СпособОценкиМПЗ = УчетнаяПолитика.СпособОценкиМПЗ(Организация, Дата);
// ... дальнейшая логика использования СпособОценкиМПЗ
Возврат СпособОценкиМПЗ = Перечисления.СпособыОценкиМПЗ.ФИФО; // Пример использования
КонецФункции
Теперь система будет правильно интерпретировать вызов УчетнаяПолитика.СпособОценкиМПЗ как обращение к методу глобального общего модуля, и ошибка "Значение не является значением объектного типа" исчезнет. Это классический случай, когда понимание областей видимости переменных и модулей становится критически важным.
Помимо непосредственного решения проблемы с конфликтом имен, важно рассмотреть другие аспекты, связанные с переходом на БП 3.0 и работой с учетной политикой. Эти знания помогут нам избегать подобных ошибок в будущем и писать более эффективный код.
Мы должны учитывать, что в редакции 3.0, в отличие от 2.0, многие функции учетной политики вынесены в специализированные модули для лучшей модульности и производительности. Основной модуль УчетнаяПолитика часто дополняется модулями УчетнаяПолитикаПереопределяемый и УчетнаяПолитикаПовтИсп.
УчетнаяПолитикаПереопределяемый: содержит методы, которые могут быть переопределены в расширениях или при доработке конфигурации.УчетнаяПолитикаПовтИсп: содержит функции, предназначенные для повторного использования значений, часто с механизмами кэширования.ПовтИсп (повторное использование значений) критически важно для производительности, особенно при проведении документов. Если мы будем вызывать метод СпособОценкиМПЗ напрямую из обычного модуля внутри цикла проведения строк документа, это приведет к избыточным запросам к базе данных. В типовых решениях 3.0 параметры учетной политики обычно кэшируются на время транзакции, чтобы избежать многократных обращений к регистрам.В БП 3.0 механизм партионного учета стал тесно связан с функциональными опциями, что является существенным отличием от БП 2.0.
ПолучитьФункциональнуюОпцию("ВестиПартионныйУчет"). Это централизованный механизм управления функциональностью, который позволяет включать или отключать определенные возможности без изменения кода.СпособОценкиМПЗ и его влияние: Метод СпособОценкиМПЗ возвращает значение перечисления (например, ПоСредней или ФИФО). В коде 3.0 проверка на партионный учет часто сводится к анализу этого перечисления: если выбрано «ФИФО», то партионный учет включается автоматически на уровне субконто на счетах учета ТМЦ (10, 41, 43). То есть, сам факт использования ФИФО уже подразумевает ведение партионного учета.Метод СпособОценкиМПЗ(Организация, Дата) в тройке может вести себя иначе, если организация не указана или если на указанную дату в регистре сведений «Учетная политика» отсутствует запись. В версии 2.0 часто использовались прямые запросы к регистру, тогда как в 3.0 архитектура требует использования программного интерфейса (API) общего модуля, который умеет корректно обрабатывать «пустые» даты и подставлять значения по умолчанию. Мы должны всегда передавать корректные параметры Организация и Дата, соответствующие моменту проведения документа, чтобы получить актуальные настройки учетной политики.
При работе с управляемыми формами и проведением документов в 3.0, код модуля объекта документа всегда выполняется на сервере. Директивы компиляции (&НаСервере, &НаКлиенте) используются только в модулях форм или команд. Если наш кастомный метод ВедетсяПартионныйУчет находится в модуле документа, он не требует этих директив, так как весь код модуля объекта по умолчанию выполняется на сервере. Если же метод находится в общем модуле, то директивы указывают, на какой стороне он может быть вызван.
Также мы должны проверить настройки общего модуля УчетнаяПолитика. Ошибка могла быть вызвана тем, что при компиляции в режиме «Толстого клиента» или при определенных настройках прав доступа общий модуль мог быть недоступен, если у него не стоят флаги «Сервер», «Внешнее соединение» (для общих модулей, доступных через внешние соединения).
Для оптимизации производительности и упрощения кода, в актуальных версиях БП 3.0 рекомендуется использовать структуру настроек, которую возвращает метод УчетнаяПолитика.УчетнаяПолитикаОрганизации(Организация, Дата). Этот подход позволяет получить сразу весь набор параметров (способ оценки МПЗ, метод распределения расходов, применение УСН и т.д.) за один вызов, что гораздо эффективнее, чем вызывать отдельные функции для каждого параметра учета. Рассмотрим пример:
&НаСервере
Функция ВедетсяПартионныйУчет(Организация, Дата, Учет = "БУ")
// Получаем всю структуру настроек учетной политики за один вызов
СтруктураУчетнойПолитики = УчетнаяПолитика.УчетнаяПолитикаОрганизации(Организация, Дата);
// Извлекаем нужный параметр из полученной структуры
СпособОценкиМПЗ = СтруктураУчетнойПолитики.СпособОценкиМПЗ;
// Проверяем, ведется ли партионный учет (например, если выбран ФИФО)
Возврат СпособОценкиМПЗ = Перечисления.СпособыОценкиМПЗ.ФИФО;
КонецФункции
Использование этого подхода позволяет нам не только избежать потенциальных ошибок с конфликтами имен, но и значительно повысить читаемость и производительность кода, минимизируя обращения к базе данных.
Мы выяснили, что даже небольшая ошибка в наименовании параметра может привести к серьезной проблеме Значение не является значением объектного типа при взаимодействии с общими модулями. Разрешение таких конфликтов имен, а также глубокое понимание архитектуры и принципов работы 1С:Бухгалтерии 3.0, особенно в части учетной политики и партионного учета, являются ключевыми для успешной разработки и миграции. Применяя описанные подходы и рекомендации, мы сможем создавать надежный и эффективный код.