1с и api запросы как реализовать

REST интерфейс

Платформа может автоматически формировать REST интерфейс для всего прикладного решения. После того, как прикладное решение опубликовано на веб-сервере, сторонние системы могут обращаться к нему через REST интерфейс с помощью HTTP запросов. Благодаря универсальности и кроссплатформенности автоматически генерируемый REST интерфейс является основным инструментом для интеграции со сторонними системами.

REST интерфейс позволяет читать данные 1С:Предприятия, изменять их, создавать новые объекты данных и удалять существующие.

Автоматический REST интерфейс может использоваться для таких задач как:

• Интеграция прикладного решения с интернет-сайтами и интернет-магазинами;
• Реализация сторонними средствами дополнительной функциональности прикладного решения без изменения его конфигурации;
• Загрузка данных в прикладное решение и выгрузка данных из него;
• Интеграция прикладного решения с корпоративными системами, возможно даже без дополнительного программирования.

Типичные операции, выполняемые через REST интерфейс это:

• Получение списка документов, справочников, записей регистра сведений и т.п., возможно с фильтром;
• Получение данных элемента справочника, документа (по ссылке), данных записи независимого регистра сведений (по ключу), данных набора записей подчинённого регистра (по регистратору);
• Редактирование данных одного элемента справочника, документа и другого ссылочного объекта;
• Создание нового элемента справочника, документа, набора записей;
• Проведение одного документа, старт бизнес-процесса.

В качестве протокола доступа платформа использует протокол OData версии 3.0. Это открытый веб-протокол для запроса и обновления данных. Он позволяет оперировать данными, используя в качестве запросов HTTP-команды. Получать ответы можно в формате Atom/XML или JSON.

В платформе реализована только серверная часть REST сервисов. То есть прикладное решение может автоматически поставлять свою функциональность через REST сервисы. Для взаимодействия со сторонними REST сервисами из «1С:Предприятия 8» (для организации клиентской части) можно использовать имеющиеся в платформе средства работы с HTTP.

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

• Мобильные: iOS, Windows Phone, Android;
• Серверные/настольные: .NET, Java, PHP, Objective-C, Ruby, JavaScript;
• Поддержка в системах управления содержимым (CMS): Drupal, Joomla.

Использовать стандартный интерфейс OData прикладного решения просто:

• В конфигураторе REST интерфейс публикуется на веб-сервере;
• После этого объекты прикладного решения становятся доступны через этот интерфейс;
• Способы аутентификации OData клиентов полностью совпадают со способами, используемыми для веб-сервисов;
• OData клиенты могут запросить через HTTP документ метаданных, описывающий доступные объекты прикладного решения;
• OData клиенты выполняют операции создания, чтения, модификации и удаления данных прикладного решения.

В REST интерфейсе доступны практически все основные объекты конфигурации: справочники, документы, константы, перечисления, планы обмена, регистры накопления, расчета, бухгалтерии и сведений, виртуальные таблицы периодического регистра сведений, регистров бухгалтерии и регистров накопления, планы счетов, видов характеристик и видов расчета, бизнес-процессы, задачи и журналы документов.

В REST интерфейсе доступны реквизиты объектов конфигурации, доступны операции создания, чтения, модификации и удаления данных, а также некоторые методы встроенного языка. Например:

• Для документа — проведение и отмена проведения;
• Для задачи — выполнение;
• Для бизнес-процесса — старт;
• Для регистра сведений — получение среза первых и среза последних;
• Для регистра накопления и регистра бухгалтерии — получение остатков, оборотов, остатков и оборотов;
• Для регистра расчета — получение данных графика, фактического периода действия, перерасчета и базы.

В случае ошибочной ситуации «1С:Предприятие 8» возвращает ответ с HTTP-статусом 4XX или 5XX. Статус 4XX говорит о неверных действиях клиента, статус 5XX — об ошибке на сервере. В случае статуса 4XX «1С:Предприятие 8» пытается помочь клиенту понять причину ошибки и может передать дополнительный внутренний код ошибки и информационное сообщение.

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

При получении списков данных можно использовать стандартные условия фильтрации ODATA запросов. Например, получить товары, у которых цена меньше или равна 3,5 или больше 200:

GET /OData_Tests_Infobase/odata/standard.odata/Catalog_Goods?$filter=Price le 3.5 or Price gt 200

Авторы: Е.Ю. Хрусталева

1с и api запросы как реализовать

У кого-нибудь есть или кто-нибудь знает где можно посмотреть простые наглядные примеры интеграции 1С с API, чтобы понять логику как это работает для начинающего или для дебила.

какое именно апи? рест апи? или соап?
Срочно дайте человеку какой-нибудь API
например soap

(0) API — Application Programming Interface, программный интерфейс приложения. Поэтому для каждого приложения будет свой API. Тебе пример интеграции 1С и чего именно надо?

(4) Да, я понимаю что у каждого приложения свой API. Мне нужен пример чего угодно, где можно увидеть и понять как это работает и с чего начинать.

Вот тут написано про всякие API http://v8.1c.ru/metod/books/book.jsp?id=288
хочешь потренироваться — пиши клиента для реддит
https://www.reddit.com/dev/api/
(8) спасибо) теперь нужно понять с чего начинать в 1с
Ироды окаянные :))
https://wonderland.v8.1c.ru/search/index.php?tags=OData
Начни с онлайн-сервиса «морфер» и использования его АПИ в 1С

Хотя эти всякие WS могут показаться сложными. Лучше начни с какого-нибудь АПИ на хттп-сервисах. Например, Манго.

(0) Классический пример
https://habr.com/post/148658/
Ну или можно взять сервис проверки контрагента по ИНН/КПП.

Еще с геокодером Яндекса побаловаться интересно:
https://tech.yandex.ru/maps/geocoder/
(14) а есть чего нибудь примерного в 1с8 по этой темке?

(15) С каких то движков 8.3 (а может и раньше, я не следил) в структуре конфигурации появились http сервисы.
Можно сделать базу с вебсервисом, который будет допустим принимать текст запроса и в xml результат возрвращать. Опубликуй её на вебсервере вот тебе и вебсервис, который будет отвечать, api правда будет целиком на 1с, но нам же надо чтобы все было на 1с.

(16) Это и в 8.1 было
А вообще полезная штука Яндекс диск, попробуй реализовать, там не сложно, единственно нужно генерировать ключ + права дать.

Очень хорошая тема тоже интересно)

(10), (11), (12) спасибо
(13) отлично, спасибо))
(14) благодарю
попробую еще книженцию (6) по 1с приобрести
кто-нибудь учился по учебникам, есть в них толк?

(19) Я учился. Хорошо превращают неосознанное незнание в осознанное незнание. Не более того.

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

(21) делай интеграцию HTTP . интеграция по api что в ней нового ? выплюнет набор текстовых полей которые нужно разобрать

> Это и в 8.1 было

http появилось только в 8.3, и даже не с начала 8.3

(16) так оно может стучаться к веб сайтам, можно с любого веб сайта стучаться к 1С и получать rest ответ и распознавать как массив.

(23) спасибо за ссылку

//Ответ = Новый HTTPСервисОтвет(200);
//Ответ.УстановитьТелоИзСтроки(«Hello»);
//Возврат Ответ;
УстановитьПривилегированныйРежим(Истина);

date1 = Запрос.ПараметрыURL[«date1»];
date2 = Запрос.ПараметрыURL[«date2»];
guid = Запрос.ПараметрыURL[«guid»];
inn = Запрос.ПараметрыURL[«inn»];
kpp = Запрос.ПараметрыURL[«kpp»];
NameProcedure = Запрос.ПараметрыURL[«NameProcedure»];
NumberAccount = Запрос.ПараметрыURL[«NumberAccount»];
UIDaccount = Запрос.ПараметрыURL[«UIDaccount»];

Текст64 = XMLСтрока(Новый ХранилищеЗначения(ТаблицаЗначений, Новый СжатиеДанных(9)));

HTTPОтвет = Новый HTTPСервисОтвет(200);

HTTPОтвет.Заголовки.Вставить(«Content-Type»,»text/html; charset=utf-8″);
HTTPОтвет.УстановитьТелоИзСтроки(Текст64);

Это база куда подключаемся

АдресСтраницы = «имя базы/hs/bank/»+ДатаНачалаСтрокой+»/»+ ДатаОкончанияСтрокой + «/» + Организация.УникальныйИдентификатор()
+ «/» + Организация.ИНН + «/» + Организация.КПП + «/» + ИмяДокумента + «/» + РасчетныйСчет.НомерСчета + «/» + РасчетныйСчет.УникальныйИдентификатор();

Хост = «имя хоста»;

HTTPСоединение = новый HTTPСоединение(Хост);

HTTPЗапрос = Новый HTTPЗапрос(АдресСтраницы);
HTTPЗапрос.Заголовки.Вставить(«Authorization», «Basic » + ЗакодироватьЛогинПароль(«имя пользователя в базе подключения», «пароль»));

КодСостояния = «код состояния — » + Результат.КодСостояния;
ОтветHTTPСтрока = Результат.ПолучитьТелоКакСтроку();

Функция ЗакодироватьЛогинПароль(Логин, Пароль)

Запись = Новый ЗаписьТекста(ВременныйФайл);
Запись.Записать(Логин + «:» + Пароль);
Запись.Закрыть();

ДвДанные = Новый ДвоичныеДанные(ВременныйФайл);
Результат = Base64Строка(ДвДанные);

Возврат Сред(Результат, 5);

получил ТЗ закодировал в строку и обратно раскодировал в ТЗ
(6) Cпасибо за ссылку! Заказал.

(15) Есть несложный кусок кода, что-то посложнее не нашел сходу. Под 8.2, на 8.3 можно без WinHttp, вроде.

WinHttp = Новый COMОбъект(«WinHttp.WinHttpRequest.5.1»);
WinHttp.Option(2, «utf-8»);
WinHttp.Open(«POST», «https://geocode-maps.yandex.ru/1.x/»,0);
WinHttp.setRequestHeader(«Content-Language», «ru»);
WinHttp.setRequestHeader(«Content-Charset», «utf-8»);
WinHttp.setRequestHeader(«Content-type», «application/x-www-form-urlencoded; charset=utf-8»);
ПараметрыПОСТ = «geocode=» + КодированнаяСтрокаАдреса + «&key=» + ЯндексAPI;

ИспользоватьПрокси = ПараметрыСеанса.новаТекущийПользователь.ИспользоватьПрокси;
Если ИспользоватьПрокси Тогда
WinHttp.SetProxy(2, ПараметрыСеанса.новаТекущийПользователь.ПроксиАдрес);
WinHttp.SetCredentials(ПараметрыСеанса.новаТекущийПользователь.ПроксиПользователь, ПараметрыСеанса.новаТекущийПользователь.ПроксиПароль, 1);
КонецЕсли;

WinHttp.Send(ПараметрыПОСТ);
Текст = Новый ТекстовыйДокумент;
Текст.УстановитьТипФайла(КодировкаТекста.UTF8);
Текст.УстановитьТекст(WinHttp.ResponseText());
Текст.Записать(КаталогВременныхФайлов()+ВременныйФайл);

Интеграция мобильного приложения с 1С по API. Задаем правильные вопросы бизнесу. Определяем механику обмена

Довольно часто мне прилетают задачи по интеграции 1С и мобильных приложений (далее МП). И всякий раз постановка задачи выглядит одинаково. Вот, практически, типовая постановка:

«Нужно из 1С передавать в приложение данные о номенклатуре, а обратно загружать заказы»

Продвинутые клиенты или те, кто пришел от разработчиков МП добавляют:

«Будем использовать REST API».

Для клиента все выглядит очевидно и буднично: потребность сформирована – давайте делать. Логично, что тут же появляется запрос на «хотя бы примерную» оценку. На деле, конечно, все не так просто. Уже первые уточняющие вопросы, заставляют клиента задуматься о множестве нюансов, влияющих на работу будущего решения и его архитектуру.

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

Оставив в стороне базовые технические вопросы выбора способа передачи данных (HTTP|FTP) и формата их передачи (XML|JSON), сфокусируемся на вопросах бизнес-логики. Решение будем внедрять на функционале HTTP-сервисов платформы 1С.

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

Методы для работы с каталогом товаров

1. Метод для получения из 1С полного каталога товаров. Необходимо вернуть полное дерево каталогов и подкаталогов с их содержимым.
2. Метод для получения изменений по ценам в каталоге. Передаем временной срез (дату + время) и получаем номенклатурные позиции и их цены, которые изменились с этого момента.
3. Метод для получения остатка по товарам. Передаем идентификатор товара (-ов) – получаем остаток. Будет вызываться часто, при добавлении товара в корзину.

Методы для работы с клиентами (контрагентами)

1. Метод для проверки существования клиента по номеру телефона. Передаем номер телефона получаем либо статус отсутствия клиента в учетной системе, либо необходимую информацию по нему: наименование, адреса, номера телефонов и т.п.
2. Метод для добавления/обновления информации по клиенту. Передаем номер телефона и обновленные данные ФИО, адреса доставки, номера телефонов и т.п.

Методы для работы с заказами и статусами

1. Метод для передачи заказов в 1С. Передается клиент, набор позиций, их количество и стоимость. Может передаваться информация об оплате заказа и т.д. Метод возвращает ID заказа в учетной системе.
2. Метод для запроса статусов из 1С. Нужен, чтобы пользователи МП знали, в каком состоянии их заказ. Обычно это что-то типа: принят, подтвержден, в пути, доставлен. И еще есть статус оплаты: оплачен/не оплачен. Когда в 1С статус меняется, об этом должно узнать приложение.

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

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

Метод для получения из 1С полного каталога товаров

Getnomenclature (GET)

Зачастую в 1С содержится неликвидный товар, а также товар, который давно снят с продаж или просто непопулярный. Кроме этого, в 1С могут фигурировать внутренние услуги, которые не нужно видеть пользователям МП. Поэтому при проектировании этого метода полезно задать заказчику следующие вопросы:

• Весь ли товар будем показывать в мобильном приложении? По какому принципу будем делать ограничения: по товарным категориям, по отдельным номенклатурным единицам или как-то еще?
• Надо ли видеть в мобильном приложении услуги?
• Надо ли видеть товар, которого нет на остатках?
• Надо ли видеть товар, на который не установлены цены?
• Надо ли показывать в приложении единицы измерения товара?

Ответы на эти вопросы помогут вам понять, какие объекты вам нужно будет дополнительно заложить в ваше решение. Будет ли это отдельный регистр «Номенклатура МП» или же будет дополнительный флаг в справочнике «Выгрузка разрешена». А может быть потребуется реализовывать специальные механики заполнения регистров, удобные пользователям. Это актуально, когда в базе большой перечень номенклатуры и заполнить регистр для выгрузки руками нереально.

Вопрос про единицы измерения покажет, насколько сложно будет формировать заказы покупателей, если требуется передавать в МП разные единицы измерений.

Иногда, в маркетинговых или иных целях, пользователям мобильного приложения нужно показывать альтернативные наименования номенклатуры.

Тогда логично задать следующие вопросы:

• Есть ли у вас номенклатурные позиции, которые необходимо демонстрировать в приложении особым образом, например, «горячие предложения» или «товар недели»?
• Требуется ли формировать в МП альтернативные названия позиций номенклатуры для маркетинговых целей или достаточно обычного наименования?

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

Метод для получения изменений по ценам в каталоге

Getprices (GET)

В решениях 1С существует возможность задавать разные типы цен для номенклатурных позиций. Очевидно, что нам стоит узнать у заказчика, какие типы цен мы будем показывать в 1С. Это могут быть сразу все типы цен, конкретный их перечень или только один тип, например «Розничные». Кроме того, надо подумать, а может ли клиент МП купить товар со скидкой? Как будет формироваться эта скидка?

Вот список полезных вопросов для клиента:

• Какие типы цен будем отображать в МП для обычных товаров? А для акционных?
• Будут ли скидки при покупке в МП? По какому принципу назначаются скидки?
• Что делаем с товарами, на которые забыли установить цены? Скрываем?

Метод для получения остатка по товарам

Getremnants (GET)

Особенности работы с товарными запасами состоят в том, что они, во-первых, могут храниться на разных складах, во-вторых, могут быть забронированы, причем разными способами.

Все это необходимо учитывать при проектировании методов API. Здесь будет уместным задать бизнесу следующие вопросы:

• Какие склады будем использовать для передачи остатков в мобильное приложение?
• Передаем совокупный остаток или в разрезе складов?
• Передаем в МП только свободные остатки или все остатки, включая резервы?

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

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

Тут стоит определиться вот с чем:

1. Как часто будет происходить обмен информацией по остаткам? Если мы будем обновлять остатки раз в минуту, тем самым поддерживая их актуальность, то повесим систему. Если реже – пользователи МП не получат достоверной картины и могут заказать отсутствующий товар.
2. Будем ли мы показывать пользователям МП точные остатки или нам будет достаточно условных признаков типа:«Много», «Есть», «Мало», «Отсутствует»? Такой подход избавит нас от необходимости частого обмена, но в случае, если мы подберем неправильный интервал актуализации данных, то рискуем нарваться на непонимание пользователей, которые будут пытаться заказать раскупленный товар из категории «Много».

Какие подходы можно предложить бизнесу, чтобы соблюсти баланс между лояльностью пользователей МП и их удобством и не угробить систему на обменах?

Можно предложить такой алгоритм:

• Раз в сутки МП получает обновленные данные по остаткам из 1С по всем номенклатурным позициям. Такой запрос можно делать ночью, чтобы минимизировать влияние обмена на систему.
• Не показывать пользователям реальные остатки, установив числовые критерии для показа обезличенных «Много», «Есть», «Мало» или подобных им.
• При выборе конкретных товарных позиций в заказ делать в 1С запрос для подтверждения реальных остатков по ним и показывать результат в МП. Точечные запросы не потребуют той же нагрузки на систему, как полный обмен.
• Собирать статистику в МП по тем товарам, которые не оказались в наличии.

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

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

Метод для проверки существования клиента по номеру телефона

Getclient (GET)

Понятно, что никто не будет тащить в мобильное приложение клиентов из 1С. Обычно это не требуется, но все же стоит, на всякий случай, этот вопрос прояснить. Однако, перед аналитиком/программистом стоит не менее серьезный вопрос о том, как синхронизировать пользователя приложения с клиентами 1С.

Для этого следует задать следующие вопросы:

• Как мы будем сопоставлять пользователей МП с клиентами из 1С: по телефону, емэйлу, ИНН как-то еще?
• Будут ли телефоны/емэйлы пользователей МП проходить верификацию (подтверждение по СМС или «пройдите по ссылке»)?

В случае сопоставления клиентов по их номерам телефонам (самое частое и очевидное сопоставление на практике) вам, как бизнес-аналитику, следует исследовать вопрос о том, как хранятся телефоны в 1С.

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

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

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

Кроме того, следует утвердить с разработчиками МП то, в каком формате будут предоставляться телефоны. В моей практике самое лучшее сопоставление происходит, когда телефон передается без служебных символов (плюсов, скобочек, дефисов) и начинается с кода страны («7» для России), а не с «8».

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

Вопрос про верификацию контактных данных позволит вам оценить степень безопасности обмена и предупредить о рисках вашего клиента. Бывают случаи, когда бизнес не задумывается об этом и/или хочет сэкономить на услугах разработчиков. Достаточно одного аргумента, чтобы бизнес изменил свое мнение:

«Представьте, что будет, если какой-нибудь шутник под вашим телефонным номером сделает заказ на все позиции товаров в вашей системе. Они все буду забронированы и ваши отгрузки встанут. Пока разберетесь в ситуации – упустите прибыль».

Метод для добавления/обновления информации по клиенту

Getclient (PUT)

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

Такое бывает, когда условная Мария Витальевна сначала работала с нашей компанией через ООО «Звездочка», а потом перешла в «ИП Зачуханов». В этом случае она будет существовать как контактное лицо Мария Витальевна, привязанная к двум контрагентам. Не трудно догадаться, что по ее номеру телефона будут находиться сразу 2 контрагента.

Что делать? Во-первых, будучи хорошим аналитиком или программистом, предупредить об этом клиента. Во-вторых, предложить двойную идентификацию по связке телефон + емэйл. От всех подобных ситуаций это не будет панацеей, но круг поиска сузит.

В-третьих, согласовать план действий с бизнесом, ответив на главный вопрос:

Что делать в ситуациях, когда найдено несколько клиентов? На кого оформлять заказ?

Метод для передачи заказов в 1С

Addorder (POST)

Отправка сформированных заказов в 1С – кульминация нашего успеха и возросшая прибыль клиента. Что важно предусмотреть на данном этапе? Какие вопросы задать?

• Сможет ли клиент в мобильном приложении оплатить заказ? Если сможет, то нужно ли формировать документы оплаты в 1С?
• Нужно ли по результатам передачи заказа в 1С формировать реализацию? Какие-либо другие документы?
• Нужно ли ставить товар в резерв? На каком складе (-ах)? По какому принципу ставить в резерв, если складов несколько?
• От имени какой организации оформляем документы?
• Создаем ли договор для новых клиентов? Или работаем без договора (если позволяет используемая конфигурация)?
• С каким статусом приходит заказ в 1С, если используем статусную систему?
• Делаем ли какие-либо уведомления клиенту или ответственным менеджерам о появлении нового заказа в системе?

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

Метод для запроса статусов из 1С

Changestatus (POST)

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

Тут есть 2 пути:

1. Путь первый. Клиент заходит в мобильное приложение, переходит к своему заказу и видит обновленный статус. Запрос статуса от 1С происходит в момент обращения пользователя к своему заказу. Делается это для того, чтобы снизить нагрузку на систему и не тревожить ее большим количеством запросов к 1С. Кроме того, преимущества данного подхода заключаются в том, что за то время, когда пользователь не обращался к заказу, в 1С могло смениться несколько статусов, в то время как мы получаем только конечный, т.е. опять же экономим технические ресурсы и оптимизируем количество транзакций. Необходимости получать все промежуточные статусы у нас в данном случае нет.
2. Второй подход заключается в том, что мы «насильно» передаем все статусы из 1С по мере их обновления. Это бывает необходимо, когда уведомления пользователей о смене статусов происходят на стороне сервера мобильного приложения. В этом случае сервер МП должен периодически дергать наше АПИ по всем заказам с незавершенным циклом.

Это не является оптимальным решением, поэтому здесь требуется создать АПИ-метод на стороне сервера МП с тем, чтобы из 1С осуществлять подключения к нему и передавать обновленный статус в момент его изменения.

А теперь сформулируем полезные вопросы бизнесу:

• Какие статусы будет проходить заказ в 1С? Часто используемые: принят, подтвержден, в пути, доставлен.
• В какие моменты будет происходить изменение статусов? По наступлению каких событий? Например: свалился заказ в 1С – принят.Оформили отгрузку – подтвержден.Распечатали документы на доставку – в пути.Поставили галку «Доставлен» — установился статус «Доставлен».
• Будет ли 1С уведомлять мобильное приложение, если в 1С появилась информация об оплате заказа?
• Какая система будет отправлять уведомления пользователям об изменении статусов – 1С или мобильное приложение?

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

Конечно, ни перечень приведенных в статье вопросов, ни их степень освещенности не претендуют на какую-либо законченность, ибо тема интеграций столь же неисчерпаема, сколь и вариативна в своей постановке.

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

Вы – заказчик и у вас есть потребность в интеграции мобильных приложений с 1С? Создавайте проект на портале и привлекайте к решению этой задачи наших лучших разработчиков и аналитиков!

Реализация REST API в обработке 1C

Функции для обмена данными и HTTP-методы, которые выполняются в следующих функциях:

Название функции в 1С для обмена данными с Mobile SMARTS	HTTP-метод	Параметры
Общие функции
REST_API_ПодключитьсяКБазеSMARTS	GET	нет
REST_API_ПолучитьОписаниеБазы	GET	BaseInfo
REST_API_ПолучитьТокенSMARTS	GET	username = Логин password = Пароль
Работа с настройками
REST_API_ПолучитьЗначениеНастройки БазыSMARTS	GET	«CustomSettings («+ КлючНастройки + «)»
REST_API_ЗаполнитьНастройкиSMARTS	GET	CustomSettings
REST_API_ЗаписатьНастройкиSMARTS	POST	CustomSettings name = КлючНастройки value = ЗначениеНастройки
REST_API_УдалитьНастройкиSMARTS	DELETE	«CustomSettings («+ КлючНастройки + «)»
Работа со справочниками
REST_API_ВыгрузитьТаблицуНаСервер SMARTS

1. для номенклатуры — «Products/BeginUploadProducts»
2. для ячеек — «Cells/BeginUpdate»
3. для прочих сравочников — «Tables/»+ИмяТаблицыENG+
4. «/BeginOverwrite»

1. для номенклатуры — «Products/AddProductsToUpload»
2. для ячеек — «Cells»
3. для прочих справочников — «Tables/»+ИмяТаблицыENG

1. для номенклатуры — «Products/ResetUploadProducts»
2. для ячеек — «Cells/ResetUpdate»
3. для прочих справочников — «Tables/»+ИмяТаблицыENG+
4. «/ResetOverwrite»

1. для номенклатуры — «Products/EndUploadProducts»
2. для ячеек — «Cells/EndUpdate»
3. для прочих справочников — «Tables/»+ИмяТаблицыENG+»/EndOverwrite»

1. для номенклатуры — «Products/BeginUploadProducts»
2. для ячеек — «Cells/BeginUpdate»
3. для прочих сравочников — «Tables/»+ИмяТаблицыENG+
4. «/BeginOverwrite»

1. для номенклатуры — «Products/EndUploadProducts»
2. для ячеек — «Cells/EndUpdate»
3. для прочих справочников — «Tables/»+ИмяТаблицыENG+
4. «/EndOverwrite»

1. Получение реквизитов шапки документа — «DocTypes (‘» +
2. СтруктураДокумента.uni + «’)?$expand=fields»
3. Получение реквизитов табличной части документа — «DocTypes (‘» +
4. СтруктураДокумента.uni + «’)?$expand=columns»
5. Получение списка доп.таблиц, которые не определены в метаданных
6. документа, но существуют у самого экземпляра документа — «DocTypes (‘» + СтруктураДокумента.uni + «’)?$expand=tables ($expand=fields)»

1. Редактировать/добавить документ — «Docs» + данные документа
2. Выгрузить табличную часть, например, declaredItems — «Docs (‘»+idДокумента+»‘)/declaredItems»
3. Принудительное сохранение документа, когда
   все строки уже загружены — «Docs (‘»+idДокумента+»‘)/EndUpdate»

Примеры запросов и ответов, используемые при обмене между 1С и Mobile SMARTS:

10.0.0.29	— пример IP-адреса сервера Mobile SMARTS
e1fc20aa-ff42-47df-9e5b-a94ba38b8935	— пример ID базы Mobile SMARTS

REST_API_ПодключитьсяКБазеSMARTS

нет HTTP-метод: GET Код состояния: 200 Ответ сервера: