> ## Documentation Index > Fetch the complete documentation index at: https://docs.1unic.com/odatav4/llms.txt > Use this file to discover all available pages before exploring further. # Создание, изменение, удаление > POST, PATCH, PUT и DELETE: формат тела, ответы, бизнес-логика и права Оба сервиса (`odata` и `odatat`) принимают `POST`, `PUT`, `PATCH`, `MERGE` (то же, что `PATCH`) и `DELETE`. Запись идёт объектной моделью 1С с бизнес-логикой конфигурации, так же как при записи из формы. ## Методы | Запрос | Что делает | Ответ | | - | - | - | | `POST Набор` | Новый объект: элемент или группа (`"IsFolder": true`), документ, план, задача. Новый объект сначала заполняется значениями по умолчанию (`ОбработкаЗаполнения`) | `201`, `Location`, объект с `@odata.etag` | | `PATCH Набор(ключ)` | Меняет только переданные поля. Переданная табличная часть заменяется целиком, `[]` её очищает | `200` и объект | | `PUT Набор(ключ)` | Полная замена: непереданные поля получают пустые значения, непереданные табличные части очищаются | `200` и объект | | `DELETE Набор(ключ)` | Ставит пометку удаления. Физическое удаление включается настройкой, см. ниже | `204` | | `PATCH`/`PUT Constant_X` | Значение константы (`Value`). Адрес — `Constant_X`, `Constant_X(0)` или `Constant_X(SurrogateKey=0)` | `200` | | `POST`/`PATCH`/`PUT`/`DELETE` независимого регистра сведений | Запись по периоду и измерениям. В теле `PATCH`/`PUT` ключ не меняется | как у объектов | Проведение документов описано на странице [Проведение](/odatav4/write/posting), наборы движений регистров — на странице [Наборы движений](/odatav4/write/record-sets). Только для чтения (`405` с заголовком `Allow`): * строки регистров, подчинённых регистратору (`…_RecordType`): наборы движений пишутся целиком через регистратор; * журналы документов; * наборы табличных частей: строки пишутся через объект-владелец; * результаты виртуальных таблиц. ## Пример ```http Создание theme={null} POST /base/hs/odata/v4/Catalog_Номенклатура HTTP/1.1 Content-Type: application/json Authorization: Basic … { "Description": "Кабель ВВГ 3х2,5", "Parent_Key": "5c1b1b38-7a7c-11e6-80d9-005056b6e1a1", "ЕдиницаИзмерения_Key": "1b2f8c12-7a7c-11e6-80d9-005056b6e1a1" } ``` ```http Изменение theme={null} PATCH /base/hs/odata/v4/Catalog_Номенклатура(guid'0f1e9c66-…') HTTP/1.1 Content-Type: application/json If-Match: W/"AAAAAAAAB4k=" { "Description": "Кабель ВВГнг 3х2,5" } ``` ```http Документ с табличной частью theme={null} POST /base/hs/odata/v4/Document_РеализацияТоваровУслуг HTTP/1.1 Content-Type: application/json { "Date": "2026-10-01T12:00:00", "Контрагент_Key": "7d3a…", "Товары": [ { "Номенклатура_Key": "0f1e…", "Количество": 2, "Цена": 150 }, { "Номенклатура_Key": "1a2b…", "Количество": 1, "Цена": 990 } ] } ``` ## Тело запроса JSON-объект, имена свойств — как в `$metadata`. * **Ссылки** — `Имя_Key` с GUID или `Имя@odata.bind`: `"Parent@odata.bind": "Catalog_Склады(guid'…')"`. Форма OData v4 `Catalog_Склады(…)` и полный адрес тоже принимаются. * **Составные поля** — пара `Имя` и `Имя_Type`. Тип: `StandardODATA.Catalog_X`, `Edm.String`, `Edm.Decimal`, `Edm.Boolean`, `Edm.DateTimeOffset`, `StandardODATA.Undefined` или перечисление. * **Перечисления** — имя значения. * **Даты** с часовым поясом переводятся в местное время базы, без пояса — пишутся как есть. * **Табличные части** — массивы объектов. `LineNumber` в строке необязателен. Неизвестные свойства, аннотации и поля только для чтения пропускаются, как у `standard.odata`. Это `DataVersion`, `Predefined`, `PredefinedDataName`, `Posted`, `LineNumber`, а при изменении ещё `Ref_Key` и `IsFolder`. Чтобы неизвестное свойство давало ошибку `400` с его именем (строгий OData v4), включите флажок «Отвергать неизвестные свойства» на вкладке «Запись» настроек. | Ошибка | Ответ | | - | - | | Значение неверного типа или длиннее поля | `400` «Свойство X: …» | | Испорченный JSON | `400` | | `Content-Type` не JSON | `415` | | Повтор `Ref_Key` или ключа записи регистра | `409` | ## Ответ Ответ на создание и изменение содержит записанный объект. К нему применяются `$select`, `$expand` и `$format`, другие параметры запроса дают `400`. Заголовок `Prefer: return=minimal` даёт `204` без тела и с `Preference-Applied`. У создания в таком ответе есть ещё `Location` и `OData-EntityId`. Действия (`Post`, `Unpost`) выполняются только методом `POST`. Метод, не применимый к ресурсу, получает `405` с заголовком `Allow`. ## Бизнес-логика Запись идёт с `ОбменДанными.Загрузка = Ложь`, поэтому срабатывают `ПередЗаписью`, `ОбработкаПроведения` и подписки на события конфигурации. * Один запрос — одна транзакция с управляемой блокировкой объекта. Любая ошибка откатывает всё. * Перед записью вызывается `ПроверитьЗаполнение()`. Проверку выключает флажок «Проверять заполнение перед записью» на вкладке «Запись». По умолчанию он включён, это строже, чем у `standard.odata`. * Проведённый документ после `PATCH`/`PUT` перепроводится, как кнопка «Записать» в форме 1С. * Пометка удаления проведённого документа снимает проведение. Ошибка записи — `400`. Отдельные коды: `403` при нарушении прав, `412`, если объект изменён другим сеансом, `409` при конфликте блокировок. Сообщения пользователю (`Сообщить`, ошибки проверки заполнения) приходят в `error.details`, а `target` указывает поле: ```json theme={null} { "error": { "code": "BadRequest", "message": "Объект Document_РеализацияТоваровУслуг не записан: не пройдена проверка заполнения", "details": [ { "code": "Message", "message": "Поле \"Организация\" не заполнено", "target": "Организация_Key" }, { "code": "Message", "message": "Не заполнена цена", "target": "Товары[0]/Цена" } ] } } ``` Сырой текст исключения платформы или обработчика записи клиенту не отдаётся: в нём бывают тексты запросов и данные, которые профиль скрывает. Подробность с `"code": "Exception"` несёт постоянный текст. Сам текст исключения, стек и модуль пишутся в журнал регистрации, событие `OData4.Запись`. Флажок «Подробные ошибки записи клиенту» отдаёт текст причины в ответе. Включайте его только на время отладки. ## Удаление По умолчанию `DELETE` ставит пометку удаления (у `standard.odata` объект удаляется). Режим выбирается на вкладке «Удаление» в поле «Режим DELETE». * **Пометка удаления** — по умолчанию. * **Физическое удаление по праву профиля.** Без профиля объект удаляется при праве 1С «Удаление». С профилем нужны ещё права профиля «Физическое удаление» и «Удаление». В остальных случаях ставится пометка. Если на объект ссылаются другие объекты, ответ — `409`, а объект остаётся. Субъект без профиля видит число и виды ссылающихся объектов (те, что пользователь может читать). Субъект с профилем видит только виды, которые профиль разрешает читать, без числа. Физическое удаление необратимо: удалённое восстанавливается только из резервной копии. В конфигурациях на БСП однажды проведённый документ обычно так не удалить: на него ссылаются служебные записи проведения. Помеченные объекты с проверкой ссылок удаляет обработка «Удаление помеченных объектов». На вкладке «Удаление» есть чек-лист. Он показывает включённый режим, профили с правом физического удаления и учётки с правом 1С «Удаление» на объекты состава. ## Права 1. **Профиль**, если он есть у субъекта, проверяет операцию: `Добавление`, `Изменение`, `Удаление`, `ФизическоеУдаление`, `Проведение`, `ОтменаПроведения`. Отказ — `403` «Операция «Изменение» над набором Catalog\_X запрещена профилем». 2. **Права 1С** пользователя или служебной учётки проверяются до бизнес-логики. Нарушение — `403`, обработчики не запускаются. Дополнительные требования: * запись требует права «Чтение»: закрытый набор отвечает `404`; * изменение `DeletionMark` требует права «Удаление»; * изменение проведённого документа требует права «Проведение». Отборы строк профиля действуют и на запись. Невидимый объект — `404`. Объект, который после записи выходит за отборы, — `403` и откат. Поля, исключённые профилем, не записываются. Профиль может исключать колонки табличной части. Тогда скрытые значения сопоставляются по `LineNumber` из тела: * строка с прежним номером получает свои скрытые значения; * строка без номера или с новым номером получает пустые; * повтор номера — `400`; * если в объекте строки есть, а ни у одной строки тела номера нет, — `400` «…передайте LineNumber строк», данные не меняются. `PUT` без такой табличной части её не очищает. Роли расширения OData4 прав на объекты конфигурации не дают. Права на запись выдают роли конфигурации пользователю или служебной учётке. Подробнее — в разделе [Модель доступа](/odatav4/security/overview). ## Сознательные отличия от standard.odata `DELETE` ставит пометку, ETag и `If-Match` работают, `Prefer: return=minimal` учитывается. Испорченный JSON, дубль ключа и ошибки проведения возвращаются кодами 4xx, а не `200` или `500`. Полный список — на странице [Отличия от standard.odata](/odatav4/reference/differences). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.