В процессе эксплуатации конфигураций на платформе 1С:Предприятие 7.7 пользователи часто сталкиваются с необходимостью изменения логики учета. Типичный пример такой задачи — потребность начать учет хозяйственных операций с точностью до копеек в поле, которое ранее было настроенно как целочисленное (например, цена, сумма или количество). На первый взгляд задача кажется простой, но в старых версиях платформы она скрывает множество опасных подводных камней, способных привести к полной потере информации.
В этой статье мы подробно разберем, как устроена разрядность чисел в платформе 1С 7.7, проанализируем потенциальные риски для базы данных и программных алгоритмов, а также изучим безопасный пошаговый алгоритм внесения изменений через Конфигуратор.
Прежде чем открывать Конфигуратор и вносить изменения, рассмотрим базовые математические принципы работы платформы с числовыми типами данных. Числовой реквизит в 1С 7.7 характеризуется двумя основными параметрами:
Для понимания взаимосвязи этих параметров важно использовать простое правило: Длина целой части числа всегда равна разности общей длины и его точности. Математически это выражается формулой:
Разрядность целой части = Длина - Точность
Проанализируем пример, иллюстрирующий типичную ошибку начинающих администраторов:
10 - 2 = 8). Теперь максимальное число составит всего 99 999 999.99.Выяснив эту особенность, мы приходим к важнейшему правилу: при увеличении точности числового реквизита на N знаков необходимо одновременно увеличить его общую длину как минимум на те же N знаков. Чтобы сохранить прежний диапазон целой части (10 знаков) и добавить 2 знака после запятой для копеек, правильные параметры должны быть следующими: Длина = 12, Точность = 2 (или даже 13 и 2 для создания дополнительного запаса разрядности).
Внесение изменений в структуру метаданных живой базы данных 1С 7.7 сопряжено с тремя основными группами рисков. Проанализируем каждую из них подробнее.
1. Риск потери существующих данных при реструктуризации. Как мы разобрали выше, некорректно заданная длина реквизита приведет к усечению больших чисел. Платформа физически перезаписывает файлы таблиц базы данных (файлы с расширением .dbf или таблицы на сервере MS SQL), и вернуть обрезанные цифры без резервной копии будет невозможно.
2. Расхождение с регистрами накопления и бухгалтерии. Документы в системе 1С 7.7 практически никогда не существуют сами по себе. При проведении они создают движения в регистрах (в оперативных конфигурациях) или проводки в журнале проводок (в бухгалтерских решениях). Если мы увеличим точность реквизита документа (например, количества или суммы), но забудем изменить точность соответствующего ресурса в регистре, куда этот документ записывает данные, возникнет критический сбой логики учета. При проведении документа копейки запишутся в сам документ, но при трансляции в регистр они будут отброшены или округлены. Как результат — отчеты по регистрам перестанут сходиться с бумажными формами и журналами документов.
3. Сбои в программных алгоритмах и печатных формах. Встроенный язык 1С 7.7 чувствителен к типам данных и точности вычислений. В коде конфигурации могут содержаться жесткие условия или формулы распределения, рассчитанные исключительно на целые числа. Посмотрим на классический пример уязвимого кода проведения:
// Пример потенциально опасного алгоритма
Если ТекДок.Количество % 1 <> 0 Тогда
Предупреждение("Обнаружено дробное количество! Проведение отменено.");
СтатусВозврата(0);
Возврат;
КонецЕсли;
Если разработчик конфигурации заложил подобные проверки, появление дробных чисел заблокирует проведение документов. Кроме того, в печатных формах макетов может быть жестко прописан формат вывода чисел без дробной части. В этом случае в базе данных копейки будут присутствовать, но на печать они не выведутся, вызывая недоумение у контрагентов и бухгалтеров.
Чтобы гарантированно избежать ошибок и не нарушить стабильность работы системы, выполним процедуру изменения реквизита по строгому регламенту. Рассмотрим этот процесс по шагам.
Это абсолютно обязательный этап, пренебрежение которым может стоить всей учетной информации предприятия. Если у вас файловая база данных, полностью скопируйте папку с базой в надежное место. Если база работает на MS SQL, сделайте резервную копию (бэкап) средствами SQL Server Management Studio.
Запустите Конфигуратор и откройте конфигурацию. Перед изменением свойств реквизита мы должны выяснить, в каких программных модулях он задействован. Выберем в главном меню пункт "Поиск во всех текстах" (или нажмите комбинацию клавиш Ctrl + Shift + F). Введите точный идентификатор изменяемого реквизита. Тщательно изучите результаты поиска: обратите внимание на модули проведения документов, глобальный модуль и отчеты.
Найдите в дереве метаданных нужный документ, раскройте ветку его реквизитов (общих или табличной части) и откройте свойства интересующего нас поля. Изменим параметры следующим образом:
Если на Шаге 2 вы обнаружили, что данный реквизит передает свои значения в регистры накопления или бухгалтерии, найдите эти регистры в дереве метаданных. Откройте их свойства и аналогичным образом измените длину и точность соответствующих ресурсов, принимающих эти данные.
Перейдите к редактированию диалога (экранной формы) документа. Дважды кликните по полю ввода нашего реквизита на форме, чтобы открыть свойства элемента управления:
Запустите процесс сохранения конфигурации (клавиша F7 или синяя кнопка сохранения на панели инструментов). Платформа проанализирует изменения структуры таблиц БД и выведет диалоговое окно со списком модифицируемых объектов.
Внимательно вчитайтесь в этот список! Если напротив вашего реквизита или связанных регистров вы увидите пометку "Частичная потеря данных", немедленно прервите процесс сохранения, вернитесь к Шагу 3 и проверьте правильность расчета длины целой части числа.
После успешного сохранения запустите 1С:Предприятие в пользовательском режиме. Выполните следующие проверочные действия:
150.55). Убедитесь, что платформа позволяет ввести дробную часть.Формат():
// Пример форматирования вывода числа в макете печатной формы
ПечСумма = Формат(СуммаДокумента, "Ч15.2.");
Соблюдение этого регламента убережет вашу базу данных от фатальных ошибок округления и гарантирует корректность ведения учета после перехода на копейки.