День добрый! Подскажите, пожалуйста, каким образом можно создать единицу измерения в товаре при создании элемента через REST - api?

Пока что делаю так, номенклатура создается, но вот как заполнить единицу измерения, ума не приложу.

POST /TradeClean/odata/standard.odata/Catalog_Номенклатура?%24format=json HTTP/1.1
Host: 127.0.0.1:8080
Content-Type: application/json

"DeletionMark": "false",
"IsFolder": "false",
"Description" : "Четвертый",
"НаименованиеПолное" : "Четвертый",
"ТипНоменклатуры" : "Товар",
"ВариантОформленияПродажи" : "РеализацияТоваровУслуг",
"Качество" : "Новый",
"ВидНоменклатуры_Key" : "41ac41f6-9d7b-11e5-90bb-5404a6815654",

Гуид единицы измерения передать?

для того чтобы передать гуид ед изм, нам нужно её создать, а создать мы её можем только имея уже гуид номенклатуры

я читал, что возможно использовать javascript в json, может ли это как - то помочь?

пока юзаю http-сервисы и там уже задаю обработичики

(2) Почему это? Чем не подходит:
POST /TradeClean/odata/standard.odata/Catalog_ЕденицаИзмерений

Генеришь уид, передаешь в номенклатуру, записываешь, создаешь справочник единиц и присваеваешь ему (установитьссылкунового) этот уид

а гуид генерится на стороне сайта получается?
как быть уверенным, что не получится дубля гуида?
либо нужно получить ответ от 1с с гуидом?

сам вариант интересный.

(6) не знаю как с функциями на стороне сайта но если генерировать например GUID функцией MSSQL сервера то вероятность пересечения ничтожная.

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

(8) тоже склоняюсь к этому варианту, как - то это выглядит надежнее, скажем так работа с элементами 1с посредством 1с, для меня более предпочтительна.

Но у заказчика основная идея вносить минимальные изменения в саму 1с.
Хотя повторюсь, мне работа через хттп-сервисы, тоже кажется более надежной и правильной.

(0) Все же проще пареной репы.
Все ровно точно так же, как и без реста.
Сначала создаем номенклатуру, потом единицу измерения, потом обновляем номенклатуру.

(9) Вы добавляете в конфигурацию новые объекты, а не изменяете типовые, это никак не повлияет на обновление программы. Зато будет надежней в работе и проще в реализации и отладке.

(11) Http надежнее реста? Для которого, кстати, конфу менять вообще не надо. Ну нихрена себе.

(12) Не, ну делайте рестом, кто ж запретит. Не запутайтесь только в идентификаторах подчиненных элементов, чтобы потом не разгребать авгиевы конюшни.

Казалось бы: можно скинуть всю инфу через http-сервис за один вызов сервера, все нормально заполнить в модуле, причем с проверками "что там нам на вход кинули то?", ан нет, рестом проще...

(13) Ну не знаю, делал - не запутался

(14) Рестом не проще, рестом лучше. Как вот я по-твоему в Почте России буду командовать, что мне нужно встроить в базу? А рест пожалуйста, нет проблем.

можно ли создать рестом элемент с заданным гуид?

(17) Не пробовал. Может быть.

(16) Везде есть свои плюсы и свои минусы, кто ж спорит. Я за доработку конфы, это дает дополнительный контроль на стороне базы-приемника.