Отправляет email-рассылки с помощью сервиса Sendsay

1С и электронная коммерция

  Все выпуски  

1С и электронная коммерция Доступ к данным V7 из других систем. Логическая структура фа




1С и электронная коммерция    Рассылка сайта Системная интеграция + 1С

Сегодня, Понедельник, 18 Августа 2008 года (5 Августа 2008 по ст.ст.)
Седмица 10-я по Пятидесятнице, Глас осьмый


Успенский пост. ш Предпразнство Преображения Господня. Мч. Евстигния (362). Сщмчч. Анфира (236) и Фавия (250), пап Римских. Мч. Понтия Римлянина (ок. 257). Мчч. Кантидия, Кантидиана и Сивела, в Египте. Прав. Нонны, матери св. Григория Богослова (374). Св. Освальда, короля и мч. (642) (Кельт. и Брит.). Прп. Иоанна (Иакова) Нямецкого, Хозевита (Рум.). Новосщмч. Симона (Шлеева), еп. Уфимского. Новомцц.: Евдокии Шиковой и послушниц Дарии Тимолиной, Дарии Сушенской и Марии Дивеевской (1919).

Доступ к данным V7 из других систем. Логическая структура файлов V7.

Любые логические построения остаются лишь сухой теорией, пока не подтверждены работающей моделью. В качестве такой модели я предлагаю программу, которая:
  • читает MMS из выбранного пользователем MD-файла (запуская прилагаемый Compound Extractor),
  • определяет версию (7.5/7.7) для правильного преобразования данных,
  • создаёт таблицы, куда помещает объекты конфигурации и их реквизиты (в том числе и внутренний идентификатор: 64- или 36-ричный).
В качестве инструментального средства используется MS Access97. Программа поставляется в виде файлов:
  • md2mdb_v2.mdb (база данных Access)
  • compound_extr.exe (консольное приложение для чтения stream'ов из MD)
Для работы с моделью понадобятся оба файла.

Немного о реализации. Access выбран по понятным причинам: распространенность, встроенные средства работы с данными, приличная поддержка SQL. Работать будет и на Access2000, на AcceessXP не проверялось. При реализации во главу угла ставилась простота переноса, как на другую версию MS Access, так в другую инструментальную среду. Отсюда эмуляция некоторых функций VB6 (Split(), Replace(), и т.п.) и некоторая потеря производительности за счет, возможно, избыточного применения SQL. Комментариев в тексте достаточно, читайте. Все вопросы – на finsoft@saravia.ru.

В качестве шаблонов используются таблицы метаклассов (_MetaClass) и их реквизитов (_MetaClassProps), описанных в главе III. Таблицу метаклассов трогать не рекомендую, а вот в таблице их реквизитов можно менять поле "OK2Convert", отвечающее за обработку того или иного реквизита, для получения более полной информации о структуре конкретного MD-файла. Результатом является таблица объектов (_MetaObjects) и их реквизитов (_metaObjectsProps).

Забегая вперед, скажу, что именно эти таблицы и используются в дальнейшем для построения таблиц/запросов выборки данных из dbf-файлов базы данных V7.

Если информация в MMS не текстовая (закрыта паролем, упакована, закриптована, и т.п.) – чтение не производится.

Определившись с данными, которые надо получить, необходимо разобраться с источником данных. Для упрощения используются DBF-версии V7, так как разница в логической структуре данных DBF и SQL-версии практически отсутствует. Кроме этого, считается, что данные не являются «распределенными» (в терминах V7). Разница в хранении «распределенных» и «нераспределенных» данных – только в добавлении ко внутреннему ID документа дополнительного реквизита.

Информационную базу V7 условно можно разделить на:

  • системные таблицы (1SUSERS, 1SSYSTEM, 1SDNLOCK, 1SUIDCTL)
  • вспомогательные таблицы бизнес-логики/интерфейса (1SCORENT, 1SACCSEL, 1SCRDOC, 1SSBSEL, 1SSTREAM, 1STOPER)
  • общие таблицы (1SBLOB, 1SCONST)
  • таблицы первичных данных/итогов (1SACCS, 1SCONST, 1SBLOB, 1SENTRY, 1SJOURN, 1SOPER, CJPROP, CJxxx, CL, DHxxx, DTxxx, etc.)
Нас будут интересовать главным образом две последние группы, причём основное внимание будет уделено именно «первичным данным» – справочникам и документам.

Справочники

Начинаем со справочников: именно в этих структурах могут храниться фактически все типы данных, кроме того, именно справочники являются базовым понятием и для некоторых других объектов (например, для видов субконто, расчётов и т.п). В описании будут встречаться ссылки на объекты метаданных и их реквизиты, приведенные в таблицах в предыдущих главах статьи.

Некоторые поля в таблицах содержат числовые значения в системе счисления, отличной от десятичной: 16/36/64-ричной. К наименованиям таких полей будет добавляться суффикс [int] (internal).

Кроме этого, в качестве сокращений будут употребляться PKey (PrimaryKey) и FKey (ForeignKey).

SCxxxx.DBF – таблица справочника, где xxx – ID объекта-справочника.

"Содержит данные справочника конкретного вида. Каждый справочник хранится в отдельном файле." [© 1С].

 

  • ID [int] – PKey таблицы, значение в 36/64-ричной системе (в зависимости от версии V7), нумеруется с единицы. Тип – Char(9). Обращение к справочнику происходит всегда именно по ID. Справочник «отдает» при этом обращении либо код, либо наименование (в зависимости от значения Sbcnts.ret_tip в MMS).
  • CODE – код справочника. Тип – всегда Char, вне зависимости от реквизита Sbcnts.kod_tip, определенного в MMS. Длина поля – Sbcnts.kod_size.
  • DESCR – наименование справочника. Тип – Char. Длина поля – Sbcnts.naim_size.
  • ISMARK – пометка на удаление. Тип – Char(1). Если запись помечена – в этом поле "*" (chr(42)). При пометке на удаление поддерживается ссылочная целостность: все подчиненные записи (как в этой, так и в других таблицах) также помечаются.
  • VERSTAMP [int] – количество изменений записи. Изменением считается любое действие "Изменить (открыть)" + действия при изменении структуры. Появилось в 7.7.
  • ISFOLDER и PARENTID [int] – поля, моделирующие иерархическую структуру справочника. Типы, соответственно, Numeric(1,0) и Char(9). ISFOLDER принимает значения 1 (признак группы) или 2 (признак элемента). PARENTID – ссылка (FKey) на ID записи о группе в этой же таблице. В 7.5 – эти поля присутствовали в любом справочнике, в 7.7 – только в тех, у которых Sbcnts.max_level>1.
  • PARENTEXT [int] – ссылка (FKey) на ID «владельца» в другом справочнике. Тип – Char(9). Владелец определяется Sbcnts.Owner_id. Поле присутствует в 7.7 в зависимости от наличия Sbcnts.Owner_id, в 7.5 – всегда.
  • SPyyy – эти поля полностью определяются подклассом Sbcnts.Params.yyy=Params.ID, тип поля соответствует Params.Type, size и dec – также определяется соответствующими реквизитами. Если Params.Type=N/S/D – в поле хранятся непосредственно значения. При строковом типе и Size=0 – строка неограниченной длины, хранится в 1SBLOB.DBF. Для остальных типов – в поле хранятся ссылки на значения из других таблиц или метаданных.

    В случае типа=B/O/T/C/A (значения которых хранятся в таблицах), в поле SPyyy хранится ссылка на соответствующую таблицу. Если на момент формирования структуры хранения известен конкретный источник данных (т.е. Params.Source_Id<>0) – поле SPyyy содержит только номер записи (PKey) соответствующей таблицы (9 знаков [int]).

    Если же на момент формирования структуры хранения Params.Source_Id=0 – например «справочник вообще» – поле SPyyy содержит, помимо 9-и байтового номера записи ещё и ID [int] соответствующего этой таблице объекта метаданных (в первых 4-х байтах).

    Значения для типов E/P/K не хранятся в таблицах, а выбираются непосредственно из метаданных по своему уникальному во всей системе ID, поэтому значением поля SPyyy является всегда является ссылка на ID [int] необходимого объекта (хотя и размещается эта ссылка не в 4-х, а в 9-и байтах).

    В случае, если Params.Type=U (значение неопределенного типа) – поле SPyyy имеет длину 23 байта и содержит в первых 2-х символах информацию о фактически хранящемся типе значения (например N для Numeric, B1 для типа B, E1 для типа E, и т.п.), в остальных символах – аналогично предыдущему (4+9).

    Любое поле SPyyy неопределенного типа (U) сопровождается полем TSPyyy типа Char(3), с назначением которого я не разобрался (похоже что оно всегда empty, если поле SPyyy пусто).

    При отсутствии значений в полях определенного типа они имеют вид "  0  0", поле неопределенного типа – "U"&space(22).

    Всё, кроме полей неопределенного типа, присутствует и в 7.5 (только разбивка полей не 4+9, а 4+8). Полей неопределенного типа, как и полей TSPyyy в 7.5 нет (хотя значения неопределенного присутствуют во многих таблицах).

    Остался нерассмотренным ещё один реквизит поля SPyyy из Sbcnts.Params: признак периодического поля (Params.pr_period). Значения полей, имеющих этот признак, хранятся в файле 1SCONST.DBF, который связан с таблицами SCxxx отношением 1:M со стороны M. Значения, имеющие структуру, описанную ранее, хранятся в поле 1SCONST.Value, номер записи справочника [int] в поле 1SCONST.OBJID, а идентификатор справочника [int] – в поле 1SCONST.ID. Об 1SCONST, однако, чуть позже.

Документы и журналы документов

Хранение документов построено немного проще, чем справочников, хотя и здесь не без фокусов: так, например, номера и даты документов хранятся не в таблицах документов, как это можно предположить, а в таблице журналов.

Поэтому рассматривать документы отдельно от журналов просто бессмысленно. Вот что пишет 1С по поводу этих таблиц: Понятно, что xxx – ID объекта-документа (вида документа).

1SJOURN.DBF

  • IDJOURNAL [int] – идентификатор журнала, ID объекта класса Journalisters, значение в 36/64-ричной системе (в зависимости от версии V7). Тип – Char(4). Определяется реквизитом Documents.Jrnl_ID. Фактически 1SJourn – это «полный журнал».
  • IDDOC [int] – PKey документа, такой же как в DHxxx и DTxxx. Тип – Char(9). IDDOC всех документов хранятся в 1SJourn.
  • IDDOCDEF [int] – ссылка на ID объекта-таблицы Documents.ID. Тип – Char(4).
  • APPCODE – возможность документа работать с компонентами: оперативный учет (1), расчет (2), бухучет (4) – и их комбинация. Для документа «Операция» APPCODE=20. Тип – Numeric(3,0). Возможно, существуют и другие значения. Возможность работы с различными компонентами определяется значениями Documents.PrTrade, Documents.PrSalary, Documents.PrAccount.
  • DATE – дата документа. Тип – Date(8).
  • TIME [int] – время документа в секундах(*10000) с 00:00:00. Тип – Char(6).
  • DNPREFIX – префикс номера документа. Тип – Char(18).
  • DOCNO – номер документа. Тип – Char. Длина поля определяется максимальным значением Documents.DocNumSize всех объектов класса Documents.
  • CLOSED – флаг закрытия/проведения документа. Тип – Numeric(1,0).
  • ACTCNT – счетчик действий (движения) для данного документа (один документ может вызывать несколько движений регистра). Похоже, что связан с полями ACTNO таблиц RAxxx и 1SCONST. Тип – Numeric(6,0).
  • ISMARK – аналогично справочникам. Тип – Сhar(1).
  • ACTCNT – ???.
  • VERSTAMP – аналогично справочникам. Тип – Сhar(6).
  • RFxxx – флаг наличия движения по регистру "xxx". Тип – Numeric(1,0).
  • SPyyy (+TSPyyy для неопределенных типов) – поля определенные, как «общие реквизиты» для всех документов (объекты класса GenJrnlFldDef). Формирование значений в этих полях аналогично SPyyy в таблицах справочников. В 1SJOURN включаются только те из GenJrnlFldDef, в которых pr_otbor=1, остальные – в DHyyy.
  • DSzzz – относится к DocumentStream.

Архив рассылки по адресу: www.anobis.ru
По вопросам размещения Ваших статей и информации в наших рассылках - пишите нам: osbekar@mail.ru
ICQ: 340597008

Подпишитесь на другие наши рассылки

Рассылки Subscribe.Ru
Секреты рекламы и создания интернет-магазинов
Скидки, подарки, призы...
1С и электронная коммерция
Серверы, сетевое оборудование, тесты, характеристики, советы
Рукопашный бой для девушек – выживание, психология, самозащита!
Милосердие. Чем ты можешь помочь ближнему.
Православные знакомства.
Здоровый образ жизни.

В избранное