Доброго дня.

Есть задача по выгрузке данных на сайт.
Документация API гласит, чтобы я передавал работы заказ-наряда в таком виде:

PackageWork {
DataType (string): тип данных ("Работы заказ-наряда"),
Id (string): Код,
Type (PackageWorkType),
StandardTime (integer): время выполнения,
Price (integer): Цена,
Quantity (integer): Количество,
DiscountPercent (integer): Процент скидки,
Sum (integer): Сумма
}

где PackageWorkType:

PackageWorkType {
DataType (string): тип данных ("Автоработы"),
Id (string): Код,
Name (string): Наименование,
StandardTime (integer): норма времени выполнения,
Code (string): код по каталогу
}


Так вот 100 раз спросил у разработчиков, что мне передавать в качестве id в PackageWork, так они 100 раз ответили "идентификатор строки табличной части". Я уточняю, может номер строки/индекс? Нет, им нужен идентификатор!
Подскажите, что они от меня хотят? У сего объекта (строкатабличнойчасти) нет никаких идентификаторов!

PS: У меня лишь одна мысль - добавить реквизит ТЧ с типом "УникальныйИдентификатор".

Правильно, в 1С у строк ТЧ никаких идентификаторов нет - их можно перемещать туда-сюда, номер строки благополучно будет меняться

Но идентификатором может являться прикладной столбик этой ТЧ, если обеспечивается его уникальность и неизменность

Мне такая ситуация тоже попалась - добавил в документ гуид.

(2) (3) Блин.. так не хотелось добавлять ещё один реквизит ТЧ, у меня итак их целый вагон... ясно, спасибо :(
Заполнять программно при добавление строки?

(4) Посмотреть как в типовых заполняется у заказаклиента.

(4) Я заполняю приЗаписи, мне этого достаточно

(6) недостаточно

если это инкрементные идентификаторы. Если uid - норм

Спасибо за нужную информацию!

(7) Ещё раз - _мне_ достаточно. Призаписи разумеется, в модуле объекта, а не формы.

(8) Чего-то инкрементным недостаточно "ПриЗаписи"?

(11) Пользователь удалил строку с максимальным идентификатором

(12) У меня, к сожалению, гуид.
А даже, если удалид в случае целой - будет дырка, никто не умрёт

(12) А как в типовых разруливают, где-то хранят максимальное значение / счетчик или отлавливают удаление строки из ТЧ (включая программное)?

(14)  хранят максимальное значение

в шапке дока

Если вместо строки табличной части использовать элемент справочника,то проблема решается очень просто,элемент заказ и подчиненные ему элементы с данными

И правда, глянул в метаданные УТ 11.3: у заказа клиента есть реквизит "МаксимальныйКодСтроки" с пояснением "Служебный реквизит для хранения максимального кода строки". Однако...
А чо он не индексируется?

(16) Элемент справочника пользователь берет и меняет на другой элемент справочника. Строка та же или новая?

(17) А чо он не индексируется?

зачем?

(19) Я хз, может там это макс. значение запросами насилуют во всей конфе )

А вообще странно, чем им номер строки не катит, ведь он тоже уникален в пределах ТЧ. В типовых он используется как вспомогательный служебный реквизит в связи с особенностями управляемого приложения.
А у меня то выгрузка на сайт! Беру ссылку на документ - сериализую в JSON - выгружаю! Id PackageWork уникален! Что им надо?!

(21) "в типовых...", - я про "код строки"


Package {
DataType (string): Тип документа ("Заказ-наряд"),
Id (string): Номер документа,
Date (string): Дата документа в формате dd.MM.yyyyy,
...
Works (Array[PackageWork]),
...
}

где PackageWork из шапки

(22) удалил и добавил новую строку. Номер строки одинаковые, а строки уже разные

(24) И? Сайт посчитает, что это та же строка и перезаполнит объект.

Я так понимаю, если не нужна обратная синхронизация (выгрузка только туда и один документ выгружается 1 раз), то передай туда произвольный гуид, не сохраняя его в базе.

(26) Да я думаю этого тоже будет достаточно, правда чем все-таки номер строки не фонтан?)

(25) если у тебя все строки сразу синхронизируются, нафига тогда нужен УИД?
Если нет, то поменяй местами строки, и у тебя будет полная ерунда

(27) отсортируют, перетасуют - номер изменится. они хотят ключ уникальности.

(28) Я хз как они парсят всю мою фигню, что я передал. Общий язык найти не можем. Накой им УИД - не понятно =\

(30) Ну передавай им номер строки. Все равно вся ТЧ каждый раз полностью передается

Номер строки можно считать валидным в период между изменениями объекта. Ваш кэп.

В старых конфигурациях использовались реквизиты строки КлючСтроки и КлючСвязи. Смысл, надеюсь, понятен? А если нет - гуглите на форуме.

(30) "100 раз спросил у разработчиков..." - лучше один раз спроси "Уникальность идентификатора строки нужна в пределах документа или в базе в целом?". Если по базе, то добавляй реквизит и заполняй его через Новый УникальныйИдентификатор()при создании строки.

(31) Не исключено, что в базе-приёмнике нет документов как таковых, а только записи, например, как в бухгалтерских проводках. Тогда становиться понятным чего они автора мучают :)

(0) номер строки передавать пробовал? Что происходит?

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

(33) "Если по базе, то добавляй реквизит и заполняй его через Новый УникальныйИдентификатор" // Склеить УИД ссылки + номер строки ТЧ кажется что вполне подойдет :) Ну, мы ж не знаем, нахера им он, что они будут с ним делать, будет ли обратная передача и все такое.
(34) Скорее всего так и есть. Но требование получать эти ИД из источника кажутся странными, если обратная передача не предполагается, а прямая передача всегда всей ТЧ целиком.

(36) там может быть на стороне той БД констрэйинт, который требует уникальности записей в каких-нибудь пределах.
Это надо у приимающей стороны просто взять и спросить, что будет, если в разных пакетах ИД строк будут одинаковые. Если ответ "ничего", то и передавать что угодно. Если "второй пакет мы не примем", тогда надо выдумывать ИДшники

Спасибо за комментарии, продолжу мучать разрабов сайта

(37) А "с писюнами вместо пальцев" это как? ))