Интерфейс odata в 1с что это

Обновлено: 07.07.2024

Начиная с версии 8.3.5 1С Предприятие умеет генерировать REST интерфейс для всей конфигурации, используя протокол OData. Это значит, что стороннее приложение может получить доступ ко всей базе 1С буквально за пару кликов.

Базы данных, которые размещаются на Платформе42, поддерживаются автоматическим REST-сервисом по протоколу OData версии 3.0. И мы подготовили для вас большую инструкцию – знакомство с OData. Чтобы не пугать вас «простыней», мы разбили ее на 11 блоков. В этой статье вы найдете краткие обзоры блоков и ссылки на подробную информацию.

Возможности и настройка

Из этой инструкции вы получите общее представление об интерфейсе OData. Тут мы рассказываем об основных возможностях протокола и о том, как настроить автоматический REST-сервис для запроса и обновления данных. Если хотите познакомиться и узнать, какие задачи можно решить при помощи OData – вам сюда.

Общие принципы работы

Здесь мы разбираем специальную терминологию OData. Рассмотрим в отдельности каждый термин из тех, которыми будем оперировать в дальнейшем, узнаем, как выполнить обращение к стандартному интерфейсу OData и подробно разберем верный URL-запрос.

Представление данных

В этой инструкции посмотрим, в каком виде стандартный интерфейс OData возвращает данные, и взглянем на соответствие между типом данных «1С:Предприятия» и типом OData. И отдельно разберем различные суффиксы, на которые могут оканчиваться имена свойств.

Правила формирования имени ресурса

Из этого текста вы узнаете, по какому принципу формируется идентификатор имени ресурса, к каким объектам можно получить доступ при помощи стандартного интерфейса OData и как уточняется имя ресурса при помощи суффикса. Возможные виды суффиксов тоже разберем.

Правила формирования условия отбора

В данном разделе мы приводим информации по различным способам формирования отбора получаемых данных, которые используются в стандартном интерфейсе OData системы «1С:Предприятие». Инструкция большая и детальная, советуем ознакомиться «с чувством, с толком, с расстановкой».

Параметры запроса

Здесь рассматриваем четыре основных параметра запроса: $count, $inlinecount, $orderby и $expand. Узнаем, что они позволяют сделать, как их правильно использовать и какие подводные камни могут встретиться на пути погружения в тему.

Способы получения описания стандартного интерфейса OData

Рассказываем при помощи каких GET-запросов можно получить сокращенное и полное описания стандартного интерфейса OData. Расскажем, каким образом формировать параметр $format при выполнении запроса, если данные получены в формате json.

Способы получения данных

А в этой инструкции расскажем, как получать и списки сущностей, и сами сущности. Эти способы получения данных отличаются URL, по которому происходит обращение к данным. Вы узнаете, чем отличается URL набора сущностей от канонического URL экземпляра сущности.

Выполнение функций и действий

Посмотрим, как формируется URL ресурса, если с сущностью или с набором сущностей связана функция (например, работа с виртуальными таблицами регистров выполняется именно через функции).

Ошибочные ситуации

Вот мы и подошли к самому интересному – к кодам ошибок, их описанию. Посмотрим, как происходит информирование об ошибках со стороны клиентского приложения и об ошибках со стороны сервера, какие коды назначаются и что с этим делать.

Примеры типовых операций

И немного практики напоследок. Рассмотрим несколько типовых операций в их практическом применении. Пошагово разберем работу с одним объектом, работу с планами обмена и другие вещи, с которыми вам наверняка придется столкнуться.

Чтобы иметь полное представление о стандартном интерфейсе OData, ознакомьтесь со всеми представленными выше инструкциями. Или сохраняйте в закладки, чтобы обращаться к этому тексту по мере необходимости.

oData одним из последних появился в инструментах интеграции поддерживаемых платформой 1С. В данной статье хотел бы показать пример его использования. О преимуществах и недостатках oData предлагаю поделиться в комментариях исходя из реального опыта использования.

Цель публикации. Дать разработчикам простой инструментарий обмена между идентичными конфигурациями.

Что делает обработка простым языком.

Итак, задача в которой я решил использовать REST-сервис (oData) был обмен документами идентичных конфигураций. В решении есть обработка реквизитов присущих только документам, с которыми мне пришлось работать, но большая часть реквизитов заполняется по универсальным правилам.

Обмен состоит из двух частей:

Часть. Получение с сервера из регистра сведений документов, запись их на клиенте, очистка записей регистра сведений сервера.
Часть. Отправка с клиента на сервер документов. Регистр присутствует и здесь, но т.к. oData никак не участвует в его обработке, то описывать его не буду.

Резюмируя, методы работы с oData в нашем решении, мы рассмотрим:

А) Получение данных из регистра по отбору измерений.

Б) Обработка полученного JSON и запись документов.

В) Удаление записи регистра сведений по ключевым измерениям.

Г) Формирование тела запроса для записи документов на сервере.

Д) Перезапись документа, если он уже есть на сервере.

Что делает обработка (ближе к коду):

Небольшая вводная перед кодом.

Про установку Интернет-сервера (Apache, или IIS) есть много статей. Публикация базы делается через одну кнопку в меню Администрирование:

И установкой флага «Публиковать стандартный интерфейс OData»:

Если у вас не пионерская платформа по использованию интерфейса oData, то нужно включить доступ на объекты базы-сервера.

Так же можно просмотреть объекты, на которые открыт доступ:

Получение данных

Первая процедура «Обработать Регистр» (Листинг 1.) получает уникальные идентификаторы нужных нам объектов.

В Адресе запроса регистр пишем, как он называется в конфигураторе, например «ЦеныВалют» после слова «InformationRegister_», это будет выглядеть так: InformationRegister_ЦеныВалют. Обращение на чтение регистра происходит с помощью Get-запроса, поэтому все передается в параметрах и может быть записано одной строкой в браузере. В частности, наш запрос можно записать строкой:

localhost/server_odata/odata/standard.odata/InformationRegister_<Ваш регистр>?$filter=<Измерение регистра> eq '<Значение>'&$format=json

В данном примере мы используем фильтр по измерению регистра, оно записывается как в конфигураторе, со значением, указанном в апострофах, это такие запятые 'сверху'. Если тип измерения – перечисление, то записываем его как в конфигураторе. Например, «filter=СтавкаНДС eq 'БезНДС'». Слово «eq» обозначает равенство.

Далее преобразуем его в массив соответствий и обращением к нужному нам измерению (Объект), получаем УИД объекта, который необходимо получить.

Далее идет процедура «ПолучитьИОбработатьСсылку(СсылкаУИД)», которая с помощью УИД получает все данные нашего объекта бит_ЗаявкаНаРасходованиеСредств. В данном случае мы используем канонический запрос с использованием GUID, который получает конкретный объект. Запрос такой:

Обращаю ваше внимание на то, что в процедуре «Обработать Регистр» мы использовали функцию «ПрочитатьJSON» без параметров «"ФункцияВостановленияЧтения",ЭтаФорма,,Реквизиты». Связано это с тем, что в первой функции мы не преобразовывали данные из JSON и получали УИД в виде строки. В процедуре «ПолучитьИОбработатьСсылку(СсылкаУИД)» мы уже работаем с ссылкой.

Далее идет создание и заполнение документа. Для удобства преобразовал полученное из JSON соответствие в структуру, предварительно удалив из него строку с ключом "odata.metadata". Код процедуры преобразования «ПолучитьСтруктуруИзСоответствия» взял из Статьи не меняя.

Отправка данных

Для отправки данных используется процедура «ЗаписатьСписаниеНаСервере». (Листинг 2)

Суть процедуры состоит в том, что мы пытаемся создать новый документ на сервере, если этого не удается, пытаемся перезаписать имеющийся.

Для начала нам нужно подготовить данные, которые мы будем передавать на сервер. Формат тот же JSON. Процедура формирования данных для отправки обратно их получению. Сначала создаем соответствие из необходимых реквизитов с нужными значениями. Откуда же взять имена ключей соответствия? Да оттуда же. Из прямого обращения к oData, например из строки браузера. Хоть мы и условились, что базы идентичны, все-таки, рекомендую получать структуру данных из базы сервера. Запрос нам уже знаком: «localhost/server_odata/odata/standard.odata/Document_СписаниеСРасчетногоСчета(guid'<СсылкаУИД>')?$format=application/json» Подставляем какой-нибудь из имеющихся УИДов базы сервера и видим имена. Секрет в том, что большая часть из них совпадают с именами реквизитов в конфигураторе. То есть, придумывать ключи и прописывать их в большинстве случаев не предется. В этом большой плюс и универсальность данных механизмов. Все описанные процедуры могут быть использованы для других объектов базы с небольшими изменениями. Но изменения все же есть.

Рассмотрим процедуру «ПолучитьСоответсвиеДокумента».

Первое, что опишем «в рукопашную» - это реквизит «Контрагент». Дело в том, что контрагент имеет составной тип, поэтому необходимо передавать информацию о типе. Так как в нашем случае Контрагент всегда имеет тип контрагент, то тип его «захардкодим»:

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

Само значение контрагента так же передается УИДом, но в ключе не пишем префикс «_Key».

Заполнение стандартных реквизитов происходит в функции «СоздатьОписанияОбязательнихРеквизитовДокумента» взятой из Статьи без изменений.

Далее создаются три списка значений для дальнейшей обработки:

СписокСсылок. Из него будут обрабатываться реквизиты ссылочного типа.
СписокПеречисленией. Из него будут обрабатываться перечисления.
СписокИсключений. Те реквизиты, которые не будут обрабатываться.

Примечание. Эти списки заполняются как для реквизитов документа, так и для реквизитов табличных частей.

Далее в процедуре «СоздатьОписанияДополнительнихРеквизитов» мы заполняем все оставшиеся реквизиты документа.

В процедуре в цикле обходятся метаданные документа. В отдельные процедуры вынесено заполнение перечислений, хотя, если сделать с ними несколько «приседаний», то, можно и их сделать универсальными.

Процедура «СоздатьОписанияТабличныхЧастей» чуть посложнее, тем, что надо обходить табличные части по отдельности и не забывать про номер строки, но принцип тот же.

Примечание. Метод Записать (Put) отрабатывает, но он не записывает реквизиты, которые были пустыми. Узнал об этом опытным путем. На сервере ставил точки останова в процедурах ПриЗаписи и ПередЗаписью. В процедуре ПередЗаписью данные были, а в процедуре ПриЗаписи – уже нет.

Обращаю внимание на строку заголовка «Заголовки.Вставить("1C_OData-DataLoadMode", Истина);». Это строка переводит флаг «ОбменДанными.Загрузка» в значение «Истина»

Вместо заключения. В чем преимущества oData. В чем недостатки (мое незнание возможностей, или ограничения сервиса)

Недостатки. Нельзя организовать сложные запросы на стороне сервера. Можно получать выборку одной таблицы с разными отборами. Нельзя написать в одном запросе имитацию соединения таблиц. Но есть вариант получить из одной таблицы по заданным отборам нужные записи и уже используя их в качестве отбора получить выборку из другой таблицы. Что на мой взгляд выглядит несколько громоздко и неоправданно. Но как вариант имеет место быть, если, например, нельзя менять конфигурацию сервера.

P.S. В качестве примера прикрепил обработку скачивания заявки с сервера и создания документа на клиенте по УИДу. Переделал под типовую файловую демо-базу.
То же самое с создание документа на стороне сервера не удалось. Ошибка на сервере в процедуре "ОбработкаЗаполнения" без расшифровки. К отладке подключиться на сервере не смог. Возможно из-за того, что база файловая. Поэтому выкладываю как есть. Если нужен строительный материал, берите.

Тестировал на: 1С:Предприятие 8.3 (8.3.16.1148)
Бухгалтерия предприятия КОРП + БИТ.ФИНАНС 3.0 (3.0.43.240/3.1.26.5)
Исходник работал на измененной: Бухгалтерия предприятия КОРП + БИТ.ФИНАНС 3.0 (3.0.69.35/3.1.41.3)

Эта работа является естественным продолжением моей предыдущей статьи "Практика доступа в базу 1С через протокол oData. Чтение данных" и все операции будут выполняться в той же демо-базе "Управление торговлей (базовая), редакция 10.3", к которой я предоставил доступ по OData в предыдущей статье.

OData - это протокол работы с данными поверх классического протокола URL, а чтобы сообщить серверу, что именно вам необходимо с этим элементом сделать (просто получить или изменить), используются POST, которые считают методами для отправки на сервер данных из форм.

Протокол OData подразумевает применение следующих пяти методов для работы с данными:

GET - самый популярный из методов, который предназначен для запроса данных на чтение по указанному адресу;
POST - метод для создания нового элемента данных, в качестве адреса обычно указывают только класс объектов;
PUT - метод для замены свойств элемента данных на сервере по указанному полному адресу теми свойствами, которые передаются вместе с этим запросом. Обычно в популярных реализациях этого метода передача неполного состава свойств приводит к ошибке; так же часто адресация несуществующего элемента данных приводит к его автоматическому созданию (как это было реализовано в платформе 1С посмотрим ниже);
PATCH - метод для обновления только переданных свойств элементов данных;
DELETE - метод предназначенный для удаления элементов данных.

Клиент для протокола OData

Ломать - не строить

Для начала возьмем самую простую операцию - удаление, на примере контрагента "АОЗТ Лабан" из демо базы УТ10.3. Собственно повторяем вызов строчки из выше опубликованного скриншота, но вместо метода GET воспользуемся методом DELETE. Теперь вместо ответа 200 (все хорошо), сервер нам отвечает 204 (нет содержимого) - это нормальное поведение именно для удаления.

Давайте перейдем в саму базу 1С и по журналу регистрации проверим, что же произошло:

Как мы видим, наш контрагент был успешно удален вместе со всеми своими подчиненными связанными данными. Тот факт, что для всех этих справочников в роли моего пользователя было запрещено интерактивное удаление, не имеет значения. Удаление по протоколу OData приравнивается к удалению из программного кода. Но, как видим, есть и различие - при программном удалении контрагента его подчиненные элементы остались бы в базе. Это важно и потому запоминаем: если у хоть одной роли пользователя есть право "Удаление", то у вас есть риск на безвозвратную потерю множества данных без контроля на наличие ссылок:

Кстати, повторная попытка удалить элемент с помощью метода DELETE аналогично запросу с помощью GET приведет к ошибке 404 (не найдено):

Создаем новое (или старое)

Как жаль, что контрагента "АОЗТ Лабан" постигла такая печальная участь. А можем ли мы его спасти без восстановления базы из бэкапа или без выполнения кода непосредственно в УТ?

Начну с цитаты из документации:

Для создания объекта следует воспользоваться POST-запросом с использованием URL набора сущностей, передав в теле запроса документ (в поддерживаемом формате), который содержит значения полей создаваемого объекта. Если передаваемый документ содержит свойства, отсутствующие у создаваемого объекта, то эти свойства игнорируются.

Больше ничего у нас с вами нет. Ни перечня обязательных полей. Ни перечня исключаемых полей. Ни упоминания о возможности создания объекта с нужным нам значением GUID. Поэтому начинаем свободные эксперименты!

И на этот раз у нас все получилось:

Более того, все получилось именно так как и было задумано - новый элемент был создан именно с тем GUID (а следовательно с той же ссылкой) как и ранее удаленный! Это хорошо видно на документе закупки ТК000000030 от 13.03.2007, где контрагент появился, но его договора и типа цен по прежнему нет (их можно аналогично восстановить, воспользовавшись в качестве образца для структуры подчиненные данные похожего контрагента, лишь в качестве GUID подставив правильные строки):

Это все превосходно, но а если у объекта множество свойств и они нам сейчас не интересны (пусть будут значения по умолчанию). Можем ли мы уменьшить размер передаваемого пакета и следовательно увеличить скорость гипотетического создания множества объектов в цикле? Для ответа на этот вопрос пойдем по пути экстремальной минимизации - попробуем создать элемент не указав ему вообще ни единого свойства!

Отлично, выходит, что нам нет нужды перечислять все значения по-умолчанию и платформа за нас все сделает сама. Но справочник - это слишком просто. Интереснее попробовать с документом, при записи которого, как мы знаем, обычно возникает ошибка платформы, если не указать дату. Попробуем на примере упомянутой выше приходной накладной:

Не то чего я ожидал, но тем не менее отличный результат! Следовательно все программно-обрабатываемые события объектов не игнорируются! Это вам не тупой прямой insert в СУБД, а процедура записи полностью идентичная программной записи из какой-нибудь обработки. Но все же, что же будет с датой? Для этого нам нужен более простой документ, который крепко не привязан к рабочим процессам в УТ, к примеру Событие:

Да, ошибка получена. Теперь лично у меня к механизму создания элементов методом POST вопросов больше не осталось. Все оказалось довольно простым и без "заморочек": можно устанавливать уникальный идентификатор новым ссылкам, отсутствуют какие-либо требования к обязательным или запрещенным свойствам в описании, лишние (не относящиеся к объекту) свойства просто игнорируются, запись в базу следует всем тем же правилам, что и обычная программная запись.

Теперь будем изменять (в хорошем смысле)

Как я уже упомянул выше, для изменения данных в базе 1С посредством OData можно использовать методы PUT и PATCH.

Давайте сразу же попробуем применить PUT в созидательной роли POST. К сожалению, тут ничего интересного мы не узнаем. В контексте коллекции мы получаем ошибку, что данный метод недопустим, а при указании произвольного GUID мы получим ошибку, что изменяемый экземпляр не найден:

А что если не указывать все реквизиты? Действительно, практика показала, что можно не указывать все реквизиты объекта и эти свойства станут заполняться значениями по умолчанию, что иногда может быть удобным. Ниже пример, где у справочника были затерты введенные вручную полное наименование и параметры прописи для валюты:

Вот и все интересное, что мы могли узнать про PUT, и потому переходим к более гибкому методу PATCH. При работе с этим методом, в отличии от его предшественника, нам для установки значения единичного реквизита больше не нужно делать предварительный GET для запроса значений всех свойств, что бы потом эти же свойства не затереть значениями по-умолчанию. Нам достаточно лишь идентификатора объекта и нового значения указанного свойства:

Теоретически, данный метод мог бы быть очень удобным для быстрого массового изменения элементов с помощью единого вызова. На пример, чтобы сменить основного менеджера для всех поставщиков, пометить на удаление документы без суммы и так далее. К сожалению, компания 1С не дала нам такую интересную возможность; для массового изменения нам доступна лишь только серия вызовов в цикле:

Итог

Не смотря на отсутствие некоторых удобств, протокол OData на платформе "1С:Предприятие 8" позволил нам совершать все базовые операции над данными. Таким образом, имея доступ в базу только по этому протоколу, можно реализовать полноценную интеграцию с некоторой внешней системой.

Статья вышла длинной не смотря на то, что были рассмотрены самые простые операции. Часть возможных интересных экспериментов была оставлена за кадром, но вы можете самостоятельно попрактиковаться. К примеру, как на счет записать набор записей по какому-нибудь из регистров? ;)

Цель публикации. Дать разработчикам простой инструментарий обмена между идентичными конфигурациями.

Что делает обработка простым языком.

Обмен состоит из двух частей:

Часть. Получение с сервера из регистра сведений документов, запись их на клиенте, очистка записей регистра сведений сервера.
Часть. Отправка с клиента на сервер документов. Регистр присутствует и здесь, но т.к. oData никак не участвует в его обработке, то описывать его не буду.

Резюмируя, методы работы с oData в нашем решении, мы рассмотрим:

А) Получение данных из регистра по отбору измерений.

Б) Обработка полученного JSON и запись документов.

В) Удаление записи регистра сведений по ключевым измерениям.

Г) Формирование тела запроса для записи документов на сервере.

Д) Перезапись документа, если он уже есть на сервере.

Что делает обработка (ближе к коду):

Небольшая вводная перед кодом.

И установкой флага «Публиковать стандартный интерфейс OData»:

Так же можно просмотреть объекты, на которые открыт доступ:

Получение данных

Первая процедура «Обработать Регистр» (Листинг 1.) получает уникальные идентификаторы нужных нам объектов.

localhost/server_odata/odata/standard.odata/InformationRegister_<Ваш регистр>?$filter=<Измерение регистра> eq '<Значение>'&$format=json

Отправка данных

Для отправки данных используется процедура «ЗаписатьСписаниеНаСервере». (Листинг 2)

Рассмотрим процедуру «ПолучитьСоответсвиеДокумента».

Само значение контрагента так же передается УИДом, но в ключе не пишем префикс «_Key».

Далее создаются три списка значений для дальнейшей обработки:

СписокСсылок. Из него будут обрабатываться реквизиты ссылочного типа.
СписокПеречисленией. Из него будут обрабатываться перечисления.
СписокИсключений. Те реквизиты, которые не будут обрабатываться.

Примечание. Эти списки заполняются как для реквизитов документа, так и для реквизитов табличных частей.

Вместо заключения. В чем преимущества oData. В чем недостатки (мое незнание возможностей, или ограничения сервиса)

Если же у вас в конфигурации отключен режим совместимости, то вы можете воспользоваться методом УстановитьСоставСтандартногоИнтерфейсаOData() который позволяет установить список публикуемых объектов.
Данная обработка реализует простой интерфейс для этого метода.

Обработка делалась для приложения Партнеры . По нажатию кнопки, она автоматически отметит объекты необходимые для работы приложения.

РедактированиеСоставаСтандартногоИнтерфейсаOData.epf

Специальные предложения

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

Сейчас, только что столкнулся.

В типовых ищите в клиенте через все функции Обработки по слову "REST"
В конфигураторе в дереве метаданных ищите по "oData"

"ищите", это когда Ctrl+F

(0) Спасибо за наводку про "СтандартногоИнтерфейсаOData()"

(2) У меня никак не проходит авторизация
Через браузер проходит а вот через сторонний сервис нет
Возможно есть какие то доп настройки

Вы чем куда подключались ?

Обработка проверяет режим совместимости и, если выбран любой другой кроме "Не использовать", то ничего дальше не делает.
На самом деле можно использовать при включенных режимах совместимости 8.3.5 и выше.
Подозреваю, что это связано с датой создания обработки) Не проходит авторизация непонятно как разобраться с ней - все настроено, а авторизации нет

Надстройку скачал - у меня не работает - выдает пустое поле - без возможности настроек

(6) у меня тоже не работает, ничего не показывает
1С:Предприятие 8.3 (8.3.16.1063)
Режим совместимости: Версия 8.3.11

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

Для тех, кому интересны подробности механизма :

1. Настройки сохраняются в специальной таблице базы - [dbo].[_ODataSettings]

2. В единственном столбце таблицы _MetadataObjectUUID хранятся ссылки - UUID объектов конфигурации, к которым разрешен доступ:

Пример - справочник Банки:

Объект конфигурации:
<Catalog uuid="5baea6ba-0bc1-4470-9f96-15cc8e9c77fa">
<InternalInfo>
<xr:GeneratedType name="CatalogObject.Банки" category="Object">

Ссылка в столбце _MetadataObjectUUID таблицы _ODataSettings : 0x9F9615CC8E9C77FA44700BC15BAEA6BA

Просмотры 74640

Загрузки 531

Рейтинг 51

Создание 21.08.14 18:28

Обновление 10.11.14 14:18

№ Публикации 297325

Конфигурация Конфигурации 1cv8

Операционная система Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Абонемент ($m)

Код открыт Не указано

См. также

Конвертация любых адресов, написанных в свободной форме, к ФИАС Промо

Допустим у нас есть база с адресами клиентов, и написаны они могут быть как душе угодно. С опечатками, без индексов, без разделителей, в совершенно любом формате. Вот было бы здорово иметь функцию, которая одним нажатием кнопки преобразует любую белиберду к строгому представлению адреса по ФИАС? Восстановит индекс, исправит опечатки и вернёт на 100% валидный адрес. Для всех, кто мечтательно сказал "ДА!", выкладываю данную обработку.

2 стартмани

30.06.2020 7672 68 XilDen 15

Внешняя компонента: Android tools

Несколько дополнительных функций для мобильного приложения\клиента под Android. Размер архива внешних компонент под архитектуры ARM и x86 - 230KB.

1 стартмани

12.01.2021 5959 17 KAV2 13

Панель команд текущего объекта (документа, справочника и т.д.) со следующим возможностями: Редактор реквизитов, таблиц и движений текущего объекта, Анализ прав доступа к текущему объекту, Поиск ссылок на объект с отборами, Сторно движений документа, Выгрузка/загрузка текущего объекта между базами. Реализована всплывающей панелью в форме объекта. Подключается как расширение конфигурации (*.cfe) либо отдельными обработками.

1 стартмани

01.05.2020 15296 112 sapervodichka 1

Simple UI: простой конструктор мобильных приложений для устройств на Android. Обновление от 03.11.21 - самостоятельные файлы-процессы, динамическое изменение конфигурации

Simple UI – это полностью бесплатная платформа для создания мобильных рабочих мест на Android. Конструктор позволяет создавать мобильные клиенты для учетных систем и самостоятельные приложения на телефонах, ТСД (терминалах сбора данных), планшетах, электронных киосках и других устройствах. При этом не нужно разбираться в мобильной разработке, Android SDK ведь основная цель платформы – максимально упростить процесс разработки и поддержки, сделать его визуальным, собирать приложения из готовых блоков с минимумом кода. Причем код обработчиков можно писать на языке учетной системы либо задавать логику обработки событий с помощью команд REST, SQL и визуального конструктора. Проект постоянно развивается изыскивая новые способы упрощения разработки и повышения функционала и является пожалуй самым быстрым способом как создать MVP-проект так и продакшн-систему под конкретное внедрение или тиражный продукт.Тестировалось на 1С: Предприятие 8.3 релиз 8.3.13.1865.

1 стартмани

14.11.2019 31868 331 informa1555 183

Удаление и/или копирование сохраненных в 1С настроек (например настроек печати табличных форм) Промо

Иногда нужно удалить сохраненную в 1С "покореженную" настройку или скопировать "удачную" другому пользователю.

1 стартмани

01.09.2012 66862 1378 AnryMc 46

Работа с файлами (обычная и управляемая форма)

Нужно загрузить файл с клиента на сервер или же, наоборот, файл загрузить с сервера на клиент, а впридачу все это на web-клиенте, да еще и асинхронно? Нет ничего проще, читай далее, как это сделать!

1 стартмани

10.06.2019 41589 222 Xershi 77

3 стартмани

04.05.2019 27221 91 MarkoSokolov 48

Редактор объектов информационной базы 8.3

Универсальная внешняя обработка для редактирования реквизитов и табличных частей объектов информационной базы, редактирование движений документов. Доступ ко всем реквизитам объектов, есть возможность выгрузки и загрузки данных (объекты и движения документов) через XML. Платформа 8.3, управляемые формы. Версия 1.1.0.57 от 09.10.2021

2 стартмани

23.01.2019 43299 486 ROL32 50

Мастер XML-обмена Промо

Функциональный аналог конвертации данных в кармане - комплекс обработок предназначенный для быстрой и удобной разработки обмена данными между информационными базами 1С.

5 стартмани

02.09.2015 35478 5 Lancelot-2M 17

Конструктор мобильного клиента Simple WMS Client: способ создать полноценный ТСД без мобильной разработки. Теперь новая версия - Simple UI (обновлено 14.11.2019)

Читайте также: