CS-CS.Net: Лаборатория Электрошамана

Общая структура метаданных в Конфигурации 1С 7.7 и файлов DBF на компьютере

Как вы знаете, моя CS CRM-система (все посты про неё — по тэгу «CRM») построена на базе быстрой и удобной для простого программирования 1С 7.7. Я веду в ней информацию о клиентах, заказах, материалах, проектирую щиты, учитываю оборудование по заводским номерам и даже планирую контент на YouTube-каналы.

Плюсы старой 1Ски в том, что она хранит данные в обычных файлах, которые проще бэкапить или редактировать (сделать глобальную замену системных данных, например).

Моя система постоянно развивается, и я добавляю туда новые функции или данные. Системное ядро 1Ски нумерует все объекты конфигурации базы (метаданные) подряд по возрастанию. Из-за этого названия файлов могут идти не по порядку или перескакивать по нумерации, что мне не нравится.

Я придумал, как благодаря определённым программам, которые лежат в открытых источниках, вручную редактировать метаданные, добавляя объекты со своими внутренними ID, не портя их нумерацию. И вот про это я вам и расскажу.

1. Краткий экскурс в структуру метаданных 1С 7.7. Термины и Инструменты.

Метаданные — это всё, что находится в Конфигурации 1Ски: Константы, Перечисления, Справочники, Документы, Журналы документов и расчётов, Нумераторы, Последовательности, Регистры и разные системные объекты. Как программисты мы работаем с ними по имени — идентификатору, а ядро 1Ски работает с ними по внутреннему ID.

Этот внутренний ID — порядковый номер, который всегда увеличивается на +1 при добавлении нового объекта метаданных в Конфигурацию. При создании пустой Конфигурации в ней будут некоторые системные объекты, которые получат свои внутренние ID, и поэтому диапазон рабочих ID начнётся с примерно 15-20ти.

Этот системный ID используется для обозначения имён и полей таблиц с данными (DBF или SQL), и поэтому мы видим что-то типа SC3726.Dbf вместо справочника «Сотрудники»: это значит, что его порядковый номер ID равен 3726. Точно так же внутри DBF-таблицы поле SP1215 будет означать какой-то реквизит с порядковым номером ID равным 1215.

Иногда этот внутренний ID записывается в 36-ричном формате (для преобразования между десятичным и 36-ричном в 1Ске есть скрытые функции _StrToID() и _IDToStr()) и используется внутри полей 1Ски для ссылки на тип элемента. Например, если у вас есть реквизит типа «Документ» (без указания конкретного типа), то данные будут записаны как «XXXX YYYYYY», где «XXXX» — это 36-ричный ID объекта из Конфигурации, а «YYYYYY» — его собственный порядковый номер.

Пример такой записи есть в таблице Журналов Документов («1SJourN.Dbf») в полях «IDJOURNAL», «IDDDOCDEF» и создаваемом нами реквизите «ДокументОснование».

Напомню вам основные таблицы и поля в них (даю информацию про метаданные):

• 1SBloB.Dbf — Все строковые реквизиты неограниченной длины. Поле «FIELDID» содержит 36-ричный ID объекта метаданных (реквизита), для которого сохраняется строка. Поэтому, если вы изменили ID реквизита — его надо поменять тут;
• 1SConst.Dbf — Все Константы и Периодические реквизиты. Поле «ID» содержит 36-ричный ID объекта метаданных (реквизита);
• 1SJourN.Dbf — Все Журналы документов. Здесь есть несколько полей для отслеживания метаданных:
  • «IDJOURNAL» — 36-ричный ID Журнала документов;
  • «IDDOCDEF» — 36-ричный ID Документа;
  • «RFx» — Флаг изменения документов регистра с ID номер x (в десятичной системе);
  • «SPx» — Реквизит с ID номер x (Общий или тот, по которому установлен отбор);
  • «DSx» — Флаг того, что документ принадлежит к Последовательности документов с ID номер x.
• SCx.Dbf — Справочник с ID номер x. Внутри него будут поля SPx, которые обозначают его реквизиты;
• DHx.Dbf, DTx.Dbf — Документ с ID номер x (Шапка и Табличная часть). Внутри него будут поля SPx, которые обозначают его реквизиты;
• RAx.Dbf, RGx.Dbf — Регистр с ID номер x (Движения и Итоги). Внутри него будут поля SPx, которые обозначают его реквизиты.

Таким образом, если мы хотим глобально покопаться во внтренних ID, нам надо найти все упоминания этого внутреннего ID в именах таблиц с данными или их полей. Если ссылки на этот внутренний ID хранятся в самих данных (например, ID Константы, Периодического реквизита или Строки неограниченной длины) — то придётся выискивать их ещё и в самих записях таблиц с данными.

Какими программами я пользуюсь?

• ToDo List от AbstractSpoon (ссылка на сайт) — очень простая и удобная программа для ведения структуры разных ToDo дел по мелким проектам. Я веду в ней записи про доработку своей CS CRM (ниже покажу скриншот);
• KLS Backup (пост-обзор про неё) — для резервного копирования всех данных, которые изменяю;
• wDBFView — древняя программа для быстрого просмотра и редактирования DBF-файлов 1Ски. НЕ глючит;
• wDDView — древняя программа для просмотра словаря данных (Файл «.DD»), чтобы быстро выкопать основные ID объектов метаданных и то, в каких DBF-таблицах и полях они хранятся;
• GComp — древняя утилита для того, чтобы декомпилировать .MD-файл Конфигурации на составные части и интерпретировать их в виде текста, а потом скомпилировать всё обратно;
• DBF Commander — простенькая программа, которая может редактировать структуру DBF-файла: изменять имена, добавлять или удалять поля в таблицу. Часто подглючивает, работать надо осторожно.

2. Всратая нумерация ID объектов подряд по возрастанию.

Как кто-то давно меня обозвал на сайте — я Властный Перфекционист. Мне очень нравится, когда мои данные хранятся красиво, удобно и функционально. И вот при разработке своей базы меня начали подбешивать имена файлов DBF-таблиц (как вы знаете из прошлого раздела, они создаются по внутренним ID).

Вот, посмотрите на эту дичь:

Файлы DBF таблиц 1С 7.7 нумеруются странно: с пропусками в именах

Вон как номера идут: DH223, DH237, DH248, …, DH1670, DH1926, DH2392. И это было бы не так некрасиво и страшно, как то, что дальше эти номера продолжают увеличиваться, когда я дорабатываю свою базу.

Вот как выглядит внутренняя нумерация объектов в Конфигурации (метаданных). Они всего лишь нумеруются в том порядке, в котором их добавляли в базу.

Решил я добавить учёт устройств (оборудования), и номера ID увеличились:

Структура нумерации метаданных (объектов) в 1С: номера идут в порядке добавления в базу

Особенно обратите внимание на нижнюю часть скриншота со значениями ID 4240..4246. Там видно, что я решил добавить ещё одно значение в перечисление «СтатусУстройства» — «Маркировка», и оно добавилось с другим ID, так как до этого в Конфигурацию были добавлены другие объекты.

Ну а так как моя база постоянно дорабатывается, то иногда я могу наплодить разных ненужных реквизитов, а потом удалить их. И у меня остаются дыры в нумерации:

Пропуски в нумерации метаданных из-за удаления ненужных объектов

Вопрос, который я себе поставил, звучал так: Можно ли использовать эти «дыры» для того, чтобы создавать новые объекты Конфигурации?

После опытов выяснилось, что МОЖНО. И про эту технологию я вам и расскажу.

Как раз вчера я проектировал щит, где в ОВЕНской ПРке все цепи управления будут не на 24V, а на 230V, и мне нужно было добавить в перечиление «ТипСигналаИО» новые значения. А заодно в документы Плана IO и Плана Регистров (я не доделал этот функционал, расскажу про него тогда, когда сделаю) добавить реквизиты «КраткиеКолонки».

Вот мои задачи в ToDo List:

Задачи для добавления метаданных в CS CRM (ToDo List)

Начинаем заниматься!

3. Общий алгоритм добавления или изменения ID в метаданных (Конфигурации).

Я опишу здесь шаги, которыми пользуюсь в своей технологии:

• Находим ID мест, которые будем менять — например, нужный справочник или документ;
• Определяем по ним, в каких DBF-файлах будут сделаны изменения (добавление полей или изменение данных в таблице Строк, Журналов, Констант);
• Удаляем индексы (.CDX) для этих DBF-файлов;
• Подбираем новые ID для добавляемых объектов (я использую XLS-Файл, где прописываю все объекты и где у меня есть свободные «дырки» в нумерации);
• Делаем резервную копию всей базы;
• Декомпилируем .MD-файл конфигурации;
• В ОбъектахМетаданных находим нужное место (справочник, документ) и добавляем туда наши новые объекты с выбранными новыми ID;
• В подпапках объектов находим (или создаём) нужный объект, заполняя его свойства или добавляя реквизиты. Я часть добавляю новые реквизиты как Строку длиной в 1 символ, а потом в Свойствах объекта в Конфигурации штатными средствами 1Ски меняю тип на нужный.
  Добавлять новые элементы лучше в конец (потом в Конфигураторе их можно передвинуть куда надо), так как их расположение влияет на расположение полей в DBF-файлах. Мне проще добавлять новые поля в конец DBF-файла, чем искать его точное расположение.
• Удаляем файлы .DD и .MD;
• Компилируем .MD-файл конфигурации, проверяя то, что в нём нет ошибок. В этот момент проверяется уникальность всех ID объектов, в том числе и тех новых, которые мы добавили.

Если мы добавляли значения, которые НЕ влияют на DBF-файлы — новые Строки неограниченной длины, Константы или Перечисления, то после этого можно запускать штатный Конфигуратор, выбрать нужный формат базы данных (при удалении .DD-файла он заново о нём спросит) и работать.

Если же мы добавляли или удаляли какие-то реквизиты или нам требуется менять данные, то вооружаемся DBF-редакторами и продолжаем:

• Копируем нужные DBF-файлы в другую папку (чтобы не испортить исходные);
• Не забываем удалить индексы (.CDX) для этих файлов;
• Формируем названия полей SPx для новых реквизитов по их ID (в голове или временном файлике);
• Изменяем структуру DBF-файлов, добавляя туда новые поля SPx. Вот здесь-то и удобно описывать новые реквизиты как Строку длиной 1 символ и добавлять их в конец DBF-файла!
• Заменяем старый файл изменённым;
• Запускаем конфигуратор и там меняем тип наших добавленных реквизитов на нужный. В этот момент будет выполнено формирование нового словаря данных (.DD) и сверка DBF-файлов с ним. Если какое-то поле будет не найдено или будет стоять не на том месте, где должно быть (например, при добавлении нового регистра надо править таблицу Журналов для ссылки на него) — нужно будет найти причину ошибки и поправить её.

Если в DBF-файле не было никаких данных (например, вы создали справочник, не успели наполнить его данными, а потом решили добавить туда ещё реквизитов) — то всё будет ещё проще. Просто удалите DBF-файл! 1Ска потом создаст его с нуля с нужными реквизитами!

Дополнительные мысли:

• ID можно назначать любые. Они не должны идти подряд даже внутри самого объекта (например, Справочник и его ФормыСписков). Можно создать справочники с ID 100, 101, 102, 103, а их реквизиты начать нумеровать с 5000. Если бы я знал про это заранее, я бы тогда вообще уложился бы в трёхзначные номера файлов, вау!
• Таким образом (через декомпиляцию-компиляцию) можно скопировать какие-то объекты целиком. Документ и все его экранные и печатные формы. Или справочник.
• Ещё таким образом можно отсортировать внутренние объекты Конфигурации. Например, в Графах Отбора документов реквизиты для отбора вставляются в том порядке, как мы их добавляли. А мы можем расставить так, как надо нам (я так и сделал).
• ПРОБЛЕМА: штатная длина поля строки в DBF-файле — это 254 символа. 1Ска каким-то хитрым образом поддерживает поля длиной до 999 символов (и я этим активно пользуюсь для хранения данных), но многие DBF-редакторы не смогут отредактировать файл, если в нём есть поля такой длины.
  Поэтому я вынужден выгружать информацию из DBFки в файл, уменьшать 1Ской длину полей, редактировать их, а потом загружать информацию обратно.

4. Пример: Добавляем новые элементы в Перечисление (простой).

Сначала сделаем простое действие, для которого не нужно редактировать DBF-файлы — добавим новые элементы в Перечисление.

Декомпилируем .MD-файл при помощи GComp:

Программа GComp для декомпиляции MD-файла 1С 7.7

После этого мы получаем всю нашу структуру метаданных в виде папок и файлов описаний объектов:

Структура декомпилированного MD-файла 1С: все объекты доступны для редактирования в текстовом формате

Самый главный файл для нас — это «ОбъектыМетаданных.txt». В нём указаны все объекты и их внутренние ID:

Список объектов метаданных (декомпилированный)

Для удобства объекты отсортированы так же, как они расположены в дереве Конфигурации, и поэтому в этом файле легко ориентироваться.

Именно этот файл я выгрузил в Эксель и добавил туда ячейки-пропуски («дыры»).

Берём наш XLS-файл и находим нужно место для добавления новых объектов. Мне повезло: я нашёл «дыру» на 4 элемента, как мне и надо было:

Новые объекты метаданных имеют ID из свободных, ранее удалённых

Я придумал новым элементам перечисления идентификаторы, а ID взял из своего XLS-файла.

Вносим эту информацию в файл «ОбъектыМетаданных.txt»:

Новые объекты добавлены в общий список всех метаданных

А дальше нам надо зайти в папку нашего перечисления и найти там файл «Структура.mdp»:

Находим в папках нужное нам Перечисление и готовимся его редактировать

Он представляет собой описание всех свойств нашего объекта и его элементов:

Структура Перечисления 1С 7.7 (описаны все его элементы)

Как я уже говорил, я добавляю новые элементы в конец, чтобы было проще редактировать файлы и не сделить за точным расположением объектов. Ещё я не заполняю их подробные свойства: это проще сделать через Конфигурацию 1Ски.

Я скопировал один из элементов перечисления, очистил его свойства и приготовил к копированию для новых элементов:

Копируем поля для добавления пустого элемента Перечисления

А теперь копируем его (в моём случае 4 раза) и вносим туда идентификаторы наших новых элементов:

Вставляем новые значения Перечисления, которые мы добавили в метаданные

После этого останется скомпилировать нашу Конфигурацию. Всё должно пройти без ошибок.

Программа GComp для обратной компиляции MD-файла 1С 7.7

Далее мы запускаем Конфигуратор с удалённым файлом .MD и видим окно выбора вида базы данных. Моя база — на DBF-файлах, что мы и выбираем:

Запуск Конфигуратора 1С 7.7 после удаления файла словаря (.DD)

После этого нам остаётся развернуть дерево Конфигурации, найти там наше перечисление, расставить новые элементы в нужном порядке и задать им нужные свойства:

Новые элементы Перечисления добавлены. Задаём им свойства в Конфигураторе

Дальше мы сохраняем конфигурацию и получаем готовый результат:

Новые элементы Перечисления доступны для выбора в Документе (как обычно)

5. Пример: Добавляем новые реквизиты в Шапку Документов (сложный).

А сейчас рассмотрим более сложный пример, где мне придётся редактировать DBF-файл документа, так как там уже есть данные.

Мне нужно добавить в два документа реквизит «КраткиеКолонки». Я снова нашёл у себя свободные места ровно под эти два реквизита и внёс их в файл метаданных:

Добавление новых реквизитов Документов в метаданные

Дальше мы идём в структуру этих документов и добавляем туда наши новые реквизиты.

Ещё раз обращу внимание вот на что: проще добавлять реквизит как Строку длиной в 1 символ, так как такое же поле нужно будет добавить в DBF-файл. Так как в некоторых случаях 1Ска хранит сложные типы значений в каком-то своём формате, проще работать со строкой, а потом поменять тип реквизита прямо в Конфигураторе 1с штатными средствами.

Добавлять новые реквизиты надо внимательно, так как в случае документа у нас есть Атрибуты Шапки и Атрибуты Табличной Части. Мне нужна шапка:

Место расположения реквизитов Шапки Документа

И здесь я обращу внимание на то, что я всегда добавляю новые реквизиты в конец списка, так как мне проще добавить новое поле в конец DBF-файла, чем выяснять, где точно оно должно располагаться.

Поэтому я свой новый реквизит поставил именно в конец списка реквизитов Шапки:

Добавляем новый реквизит (в виде строки длиной 1 символ) в КОНЕЦ Шапки Документа

Дальше я снова скомпилировал .MD-файл (всё прошло успешно), и начал редактировать DBF-файлы, отобрав нужные по тому же списку метаданных:

Копируем DBF-файлы Шапок Документов для их редактирования (ручного добавления полей)

Один из файлов не содержал данных (не было ещё ни одного документа такого вида), и я просто удалил его.

А вот второй содержит данные, потому что я успел создать один документ:

Один из DBF-файлов содержит данные, и в него надо добавить новое поле реквизита

Нам придётся изменять его структуру. Для этого я открываю его в DBF Commander, захожу в меню «File -> Structure…»:

Команда редактирования структуры DBF-файла

Открывается окно, где можно отредактировать структуру нашего файла. Я уже добавил туда новое поле «SP2558», где содержится ID моего нового реквизита:

Окно редактирования структуры DBF-файла (добавлено новое поле)

После этого мы сохраняем изменения структуры, и… Оказывается, что этот редактор немного не так составляет заголовок DBF-файла, из-за чего 1Ска его не видит.

Я открываю изменённый файл в редакторе wDBFView и упаковываю таблицу (меню «Edit -> Pack Table»), после чего заголовок DBF-файла корректно обновляется.

Упаковка отредактированного DBF-файла через wDBFView

После этого, наконец-то, можно снова запустить 1Ску в режиме Конфигуратора и задать нужный порядок и нужные свойства наших новых реквизитов, а потом пользоваться ими:

Новый реквизит Шапки добавлен в Документы (задаём его свойства)

Таким способом я добавил уже около 1000 новых объектов в свою Конфигурацию, а номер последнего из них так и остался равным 4253! Это значит, что файлы с возрастающими именами не будут больше плодиться!

Проекту исполнилось 16 лет! Поддержать проект материально, проспонсировать проекты Автора или сделать ему подарок можно на этой странице: "Донаты и Спонсорство, Список Желаний".