В практике разработки на платформе 1С:Предприятие 8.3 часто возникает потребность адаптировать типовую конфигурацию под специфические нужды бизнеса. Одна из самых распространенных задач — увеличение точности (количества знаков после запятой) или общей длины числового реквизита. Например, когда в «Управлении торговлей» для товара предусмотрено 5 знаков после запятой, а в «Бухгалтерии предприятия» — только 3. Попытка решить это через механизм расширений кажется логичной, но здесь разработчики сталкиваются с серьезными платформенными ограничениями. Давайте подробно разберем, почему это происходит, и какие обходные пути существуют на текущий момент.
Разберем фундаментальную причину этого ограничения. Механизм расширений в 1С задуман как способ дополнения функциональности без изменения структуры основной базы данных в тех местах, где это может нарушить целостность системы. Когда мы создаем реквизит в основной конфигурации, платформа жестко фиксирует его тип и длину в физической таблице базы данных (SQL). Расширение может добавлять свои собственные объекты и таблицы, но оно не имеет прав на изменение физической структуры колонок, созданных основной конфигурацией.
Проанализируем ситуацию: если бы расширение позволяло изменить Число(15, 3) на Число(15, 5), платформе пришлось бы пересоздавать колонку в SQL-таблице. Это создало бы конфликт при обновлении основной конфигурации или при попытке удалить расширение (данные, записанные с новой точностью, просто не поместились бы в старый формат). Поэтому на текущих версиях платформы (включая 8.3.23 и выше) прямое изменение длины заимствованного реквизита заблокировано.
Начиная с версии платформы 8.3.15, у разработчиков появилась возможность заимствовать в расширение ОпределяемыеТипы. Это архитектурное решение, которое активно применяется в современных решениях, таких как 1С:ERP или 1С:Комплексная автоматизация. Если реквизит «Количество» в документе имеет тип не Число, а ссылается на ОпределяемыйТип.Количество, мы можем решить задачу изящно.
Рассмотрим по шагам, как это работает:
ОпределяемыйТип, заимствуем его в расширение.Однако в 1С:Бухгалтерия Предприятия 3.0 большинство реквизитов количества по-прежнему привязаны к примитивному типу Число, поэтому данный метод там чаще всего неприменим.
Если мы не можем изменить старый реквизит, мы можем создать новый. Это трудоемкий, но рабочий метод, позволяющий сохранить конфигурацию на поддержке. Разберем алгоритм реализации этого метода:
1. Добавляем в расширение новый реквизит к нужному объекту (например, в табличную часть Товары документа РеализацияТоваровУслуг). Назовем его Количество_Расш и установим нужную нам точность Число(15, 5).
2. Модифицируем форму документа. Скрываем стандартное поле Количество и выводим вместо него наше Количество_Расш. Для пользователя это будет выглядеть бесшовно.
3. Нам необходимо обеспечить синхронизацию данных. Проанализируем пример кода для программного пересчета в расширении:
&НаСервере
Процедура Расш1_ПриЧтенииНаСервереПосле(ТекущийОбъект)
// Заполняем наше поле из основного, если оно еще не заполнено
Для Каждого Строка Из ТекущийОбъект.Товары Цикл
Если Строка.Количество_Расш = 0 Тогда
Строка.Количество_Расш = Строка.Количество;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
&НаКлиенте
Процедура Расш1_Количество_РасшПриИзменении(Элемент)
СтрокаТабличнойЧасти = Элементы.Товары.ТекущиеДанные;
// Синхронизируем со стандартным полем (с потерей точности для базы)
// и выполняем стандартные пересчеты суммы
СтрокаТабличнойЧасти.Количество = СтрокаТабличнойЧасти.Количество_Расш;
// Вызов типовой процедуры пересчета
РассчитатьСуммуТабличнойЧасти(СтрокаТабличнойЧасти);
КонецПроцедуры
Важное предостережение: основной минус этого метода заключается в том, что все механизмы проведения документа (движения по регистрам) продолжат использовать старый реквизит Количество с его ограничением в 3 знака. Чтобы система учитывала 5 знаков, вам придется перехватывать процедуру ОбработкаПроведения и переписывать логику формирования движений для всех связанных регистров. Это может быть даже сложнее, чем снятие с поддержки.
Если бизнес-задача критична и точность в 5 знаков должна сохраняться во всех отчетах и регистрах (например, в налоговом учете), придется снимать объект с поддержки. Но здесь важно понимать масштаб последствий, который мы называем «эффектом домино».
Проанализируем ситуацию на примере «Бухгалтерии предприятия». Количество хранится не только в документе. Оно транслируется в:
Если вы увеличите точность только в документе, то при проведении цифры будут округляться до 3 знаков в проводках, и смысл доработки потеряется. Следовательно, вам придется изменить тип данных в нескольких десятках объектов. Это превращает каждое последующее обновление конфигурации в кошмар для программиста, так как система сравнения/объединения будет постоянно пытаться вернуть реквизиты к типовому виду Число(15, 3).
Прежде чем приступать к программному изменению структуры базы, давайте выясним, нельзя ли решить проблему организационно. Часто требования «5 знаков после запятой» возникают из-за мелких единиц учета (например, когда учет ведется в тоннах, а отгрузки идут в граммах).
Посмотрим на пример решения:
0.00005 тонны, создадим в справочнике единиц измерения позицию кг или грамм.Этот путь является наиболее безопасным и «чистым» с точки зрения дальнейшего сопровождения программы.
Подводя итог, можно сказать: расширения — это мощный инструмент, но они не всесильны. Увеличить длину стандартного реквизита напрямую в расширении невозможно.
Если вам все же необходимо это сделать, рекомендуем придерживаться следующего порядка действий:
ОпределяемыйТип для этого поля (вероятно в ERP/КА, маловероятно в БП).Помните, что любые изменения структуры данных в основной конфигурации требуют обязательного создания резервной копии и тщательного тестирования всех алгоритмов проведения документов.