Это старая версия документа!
1. Поля 111\5 и 111\33 Во всех присланных структурах есть комментарий «Накладная: Rid, Type, Options…». По нему: 111\5 = Type — тип накладной; 111\33 = Options — опции накладной. Подписи «Options / Options1» для GDocs неверны. 111\5 (Type) → тип в интерфейсе SH5 Значение Обозначение Тип документа 0 ПН Приходная накладная 1 — Возврат от получателя 3 ВПР+ Приходная часть внутренней продажи 4 РН Расходная накладная 5 — Возврат поставщику 7 ВПР- Расходная часть внутренней продажи 8 СВ Сличительная ведомость 9 ВПР Внутренняя продажа 10 АП Акт переработки 11 ВП Внутреннее перемещение 12 К Комплектация 13 ДК Декомплектация Значит, документ №156932 от 02.09.2026 с 111\5 = 12 — это «К» (Комплектация), как и показывает интерфейс.
2. 111\33 — битовая маска Да, это битовая маска: флаги объединяются через OR. Бит Константа Значение в SH5 0x01 gdoActive Документ активен (проведён) 0x02 gdoActivatedByCntr0 Активирован стороной-отправителем 0x04 gdoActivatedByCntr1 Активирован стороной-получателем 0x08 / 0x10 gdoLockC_* (маска 0x18) Права на документ для всех, кроме создателя: 0x00 — правка разрешена, 0x08 — только активация, 0x10 — запрещено 0x20 gdoLockA_Disabled Правка запрещена всем, включая администратора 0x40 gdoLock_EnableActDel Разрешены только активация, деактивация и удаление 0x80 = 128 gdoExtFlag0 Накладная создана автоматически из заказа 0x100 gdoExtFlag1 Связь с внешней системой (ЕГАИС) 12 / 7 и 12 / 135 — один и тот же тип документа «К», отличаются только признаки: 7 = 1 + 2 + 4: документ активен и активирован обеими сторонами; 135 = 128 + 7: то же самое, плюс документ создан из заказа. Значение 7 в поле 33 не связано с типом 7 (ВПР-) в поле 5.
3. Алгоритм определения типа type_code = <path>\5 # тип документа options = <path>\33 # признаки
type_label = TYPES[type_code] # таблица из п. 1; неизвестный код → логировать, не отбрасывать
is_active = (options & 0x01) != 0 from_order = (options & 0x80) != 0 egais = (options & 0x100) != 0 От статуса тип не зависит. Активность и прочие признаки хранятся только в поле 33, а поле 5 от них не меняется. Поле 33 для определения типа не используется. От версии. В документации не сказано, зависят ли коды от версии SH5 или Web API. Справочник типов стоит держать настраиваемым, а неизвестные коды логировать. В документации нет кодов 2 и 6, а у кодов 1 и 5 нет буквенного обозначения. Внутренняя продажа. В процедурах движения и FIFO она может прийти как 3 (ВПР+) или 7 (ВПР-), а не только как 9. Справочник должен учитывать все три кода. Фильтр по типу на входе — 108 → 111\8 (tUint32, «GDoc.TypeMask»). Скорее всего, это маска вида 1 « Type. Например, только комплектации — 4096, все типы 0–13 — 0x3FFB. Это предположение: раскладку битов надо подтвердить у поддержки. 4. Смысл полей по процедурам и ссылки 111 / 111#1 Смысл полей 5 (Type) и 33 (Options) одинаков во всех процедурах. Отличается только роль документа, на который указывает ссылка. \ — переход по ссылке на связанную запись: 111\5 означает «поле 5 связанной накладной». #1 — второй экземпляр ссылки на ту же таблицу. Роли 111 и 111#1 задаются отдельно для каждой процедуры: Процедура Таблица 111 111#1 GGrpQueue 153 Накладная операции — (112#1 = остатки после операции) GDocs 111 Сама накладная (поля 5 и 33 прямо в таблице) — FifoDtl 150 Накладная в дереве себестоимости (уровень — поле 50) — GDocFifo 112 Структура не предоставлена, нужно уточнить — ExpGDocsFifo 168 Приход Расход GRemnsFifo 151 Накладная, по которой остаток лежит на подразделении Формирующая накладная (приход) В ExpGDocsFifo и GRemnsFifo роли 111 и 111#1 противоположны. Правила «#1 — всегда приход» нет. Исключения: поле 5, которое не означает тип накладной GDocs → 117\5 — тип счёта-фактуры; GDocs, входной фильтр → 107\5 (tUint8) — тип корреспондента; 112\32 (Options) и 112\60 (RecType) — признаки строки спецификации, а не документа; 105 / 105#1 внутри 111 — поставщик и получатель, к типу документа не относятся.