Ваши комментарии

>Для обмена через Csv методов в API нет


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

И еще вопросы


1. как осуществлять реализацию (списание) товара под клиента?
2. Большинство документов состоит из набора записей (напр-р, инвентаризация включает в себя список товаров, числящихся по базе). каким образом операции с ними происходят? Например, этим методом GET /api/v1/Docs/Inventarizaciya('{id}') можно будет получить список товаров с количеством помимо информации по самой инвентаризации? Аналогично POST /api/v1/Docs/Inventarizaciya, предусмотрена ли отправка списка товаров. Или все это делается какими-то отдельными методами?

Для файлового обмена с ТСД есть утилита XlsCsv, она позволяет из папки "На терминал" загрузить файлы в формате XLS или CSV. Есть ли аналогичные команды в JSON API, которые позволят загрузить на ТСД например "Цены.csv" и "Номенклатура.csv". И как после или во время создания сущности "Поступление" добавить к ней товары?

Это swagger видимо мудрит, не дает выполнить запрос через "Try it out!" требуя параметр "key" и "relatedKey", а запрос напрямую через браузер http://abc:9006/MobileSMARTS/api/v1/Docs/Inventarizaciya прекрасно все выводит. Для удобства было хорошо бы убрать такое ограничение из swagger...

Т.е. чтобы получить список поступлений, мне нужно указать какой то ID? 

Я же получаю список инвентаризации, поступления, зачем что то еще указывать?

И что за "relatedKey" при получении конкрентной сущности  

GET /api/v1/Docs/Inventarizaciya('{id}')?

Некоторые методы GET для получения списков сущностей требуют какой то ключ "key" - что это такое и какое значение необходимо?

Методы 

  • GET /api/v1/Docs/SborShK
  • GET /api/v1/Docs/Postuplenie
  • GET /api/v1/Docs/Inventarizaciya

Давайте конечно! Можете на почту моего акка прислать информацию

Работать с СОМ из PHP да еще и из под Windows  - совсем не хорошо. Неужели сложно реализовать универсальный веб-интерфейс посредством JSON API для работы в http(s) окружении с любыми платформами и языками программирования? Стандарт COM мог бы быть универсальным и платформо-независимым, но закрепился в основном на операционных системах семейства Microsoft Windows. А подавляющее большинство веб-сервисов работает под Linux системами. 

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



Сервис поддержки клиентов работает на платформе UserEcho