При работе с типовыми конфигурациями «1С:Предприятие 8.3», такими как «1С:Комплексная автоматизация 2», «1С:ERP» или «1С:Управление торговлей 11», пользователи и администраторы часто сталкиваются со странным поведением системы при попытке настроить числовой дополнительный реквизит. Вроде бы мы указываем корректную длину и точность, но система выдает ошибку: «длина целой части числа превышает максимально возможную». На первый взгляд это кажется багом платформы, но на самом деле за этим стоит строгая архитектурная логика «Библиотеки стандартных подсистем» (БСП). Рассмотрим эту ситуацию подробно и разберем механизмы, которые приводят к такому результату.
Прежде всего, проанализируем, как 1С хранит значения дополнительных реквизитов. В отличие от обычных реквизитов объектов, которые создаются как отдельные колонки в таблицах базы данных, дополнительные реквизиты — это записи в табличных частях (обычно с именем ДополнительныеРеквизиты) или в специальных регистрах. Сами определения этих реквизитов хранятся в Плане видов характеристик (ПВХ) ДополнительныеРеквизитыИСведения.
Для хранения числовых данных в ПВХ или табличной части предусмотрен один общий реквизит (обычно он называется Значение). Тип этого реквизита в Конфигураторе задан жестко. В современных версиях БСП для числа чаще всего установлено Число(17, 5). Это означает, что любое число, которое вы хотите сохранить как «доп. реквизит», должно физически поместиться в это «бутылочное горлышко».
Выясним причину ошибки, вспомнив, как 1С интерпретирует параметры типа Число(Длина, Точность). Многие пользователи ошибочно полагают, что «Длина» — это количество знаков до запятой. На самом деле:
Длина - Точность.Посмотрим на пример из метаданных системы. Если разработчиками 1С задан тип Число(17, 5), то максимально допустимая длина целой части составляет: 17 - 5 = 12 знаков. Это константа, выше которой система прыгнуть не может без изменения конфигурации.
Проанализируем ситуацию, описанную в обсуждении. Пользователь пытается создать реквизит с типом Число(15, 2). Кажется, что 15 меньше 17, и всё должно работать. Однако посчитаем длину целой части для этого нового типа: 15 - 2 = 13 знаков.
Теперь сравним:
Система 1С выполняет проверку в программном модуле (обычно это УправлениеСвойствамиСлужебный) и видит, что данные могут быть потеряны или просто не поместятся в отведенное поле. Именно в этот момент и генерируется ошибка «длина целой части числа превышает максимально возможную».
Разберем по шагам, какие типы пройдут проверку, а какие — нет, если в метаданных заложено Число(17, 5) (базовая целая часть = 12):
Число(15, 3): 15 - 3 = 12. Проходит (12 <= 12).Число(14, 2): 14 - 2 = 12. Проходит (12 <= 12).Число(12, 0): 12 - 0 = 12. Проходит (12 <= 12).Число(15, 2): 15 - 2 = 13. Ошибка (13 > 12).Число(17, 4): 17 - 4 = 13. Ошибка (13 > 12).Число(10, 0): 10 - 0 = 10. Проходит (10 <= 12).Как мы видим, ограничение работает «в обратном порядке» относительно точности. Чем меньше знаков после запятой вы хотите оставить, тем меньше должна быть общая длина числа, чтобы не превысить лимит целой части в 12 разрядов.
Рассмотрим несколько вариантов решения данной задачи в зависимости от ваших прав доступа и потребностей бизнеса.
Если вам не критично иметь именно 15 знаков в общей длине, попробуйте уменьшить ее так, чтобы разница соответствовала лимиту метаданных. Если вам нужно 2 знака после запятой, максимально возможная общая длина будет 14 (так как 14 - 2 = 12).
Если бизнес-логика требует хранения чисел с 13 или более знаками в целой части (например, очень большие суммы или специфические артикулы), придется вносить изменения в метаданные. Посмотрим, как это сделать правильно:
ДополнительныеРеквизитыИСведения.Тип значения. Вам нужно изменить описание типов для этого объекта.Значение в табличных частях объектов, где используются доп. реквизиты (например, в справочнике Номенклатура, Контрагенты и т.д.), и в самом ПВХ.Важно: Помните, что изменение типа данных в существующих реквизитах может привести к длительной реструктуризации таблиц базы данных, особенно если в системе накоплено много данных. Выполняйте такие действия только после создания резервной копии.
Если вы разработчик и хотите программно понять, какой лимит установлен в вашей базе, можно выполнить следующий код в консоли кода:
// Получаем метаданные типа значения доп. реквизитов
ТипХранения = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.ТипЗначения;
Для Каждого Тип Из ТипХранения.Типы() Цикл
Описание = Новый ОписаниеТипов(Тип);
Квалификаторы = Описание.КвалификаторыЧисла;
Если Квалификаторы <> Неопределено Тогда
Сообщить("Общая длина: " + Квалификаторы.Длина);
Сообщить("Точность: " + Квалификаторы.Точность);
Сообщить("Макс. целая часть: " + (Квалификаторы.Длина - Квалификаторы.Точность));
КонецЕсли;
КонецЦикла;
Подведем итоги нашего анализа. Ошибка «длина целой части числа превышает максимально возможную» — это не баг платформы 8.3.21 или любой другой версии, а контроль целостности данных со стороны БСП. Система просто не дает вам создать настройку, которую она не сможет физически сохранить в общую базу данных без потери точности или разрядов. Чтобы избежать этой ошибки, всегда следите за тем, чтобы разница между общей длиной и точностью вашего нового реквизита не превышала аналогичную разницу в базовом типе Число, определенном в конфигурации (обычно это 12 знаков).