Больница
хотим мобильное приложение запись на прием и справочная информация (список услуг, расписание работы, политика обработки ПД)

мобильный клиент, насколько я понимаю, отваливается сразу ибо:
"При использовании технологии мобильный клиент используется клиентская лицензия, выдаваемая сервером на время сеанса."

т.е. смотрим
"Правила лицензирования для тиражных решений
При бесплатном распространении мобильного приложения, созданного на платформе "1С:Предприятие", среди третьих лиц через магазины приложений AppStore, Google Play и Windows Store и любыми другими способами, заключение лицензионного договора с фирмой "1С" не требуется, никаких финансовых обязательств перед "1С" у разработчика не возникает."

вопросы:
1. будет ли приложение разработанное нами, "тиражным"?
2. монетизация ... запись на прием - по сути заказ услуги, и возможно он-лайн оплата её - это монетизация?

1. Будет
2. Нет.
ЗЫ. Но это неточно :)

(0) Лично я ННП. По теме : существует ограничение по количеству пользователей МП. Свыше которого нужно заключать отдельный договор с 1С.
Монетизация это не про "запись на прием - по сути заказ услуги, и возможно он-лайн оплата её". Это продажа собственно МП.

(2) До фразы "заключение лицензионного договора с фирмой "1С" не требуется" не дочитал, что ли?

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

загрузили список услуг - и по расписанию (по флагу в центральной базе) делаем синхронизацию

ок,

тогда вопрос - а взлетит/потянет?

(0) А клиентам оно нужно? Ставить какое-то левое приложение, когда есть браузер.

(0) Почитать можно здесь : https://mobile.1c.ru/lic/

(5) ну так под браузер нет приложения...
под браузер надо нанимать сторонних разработчиков с их тараканами, писать им ТЗ ...

(4) А чего б нет?
(5) Веб-клиент = лицензии. А у них тираж. То есть в полноценную веб-разработку ударяться надо.

(4) "взлетит/потянет" это зависит от вас.
Система примерно такая :
торговых около 20-и штук. Активный ассортимент примерно 1500. Всего порядка 10-и тысяч. Активных покупателей примерно 1200 штук. Действующих 4-е прайса. Покупатели, торговые и ассортимент фильтруется по областям (договорам дистрибюции). На приборе торгового фоновый обмен с офисом (при наличии инета) раз  в 20 мин. Есть возможность обмена "по требованию". Пока все "тянет".

(6) ТС оттуда и процитировал. Слово в слово.

(10) Только он цитировал для "тиражных решений". А его случай "для заказных".

(11) а поподробнее - чем тиражное от заказного отличается?

(9) Да у них все в разы примитивнее будет. Единственное - если они таки захотят онлайн-оплату запилить. Вот это отдельный квест. Не знаю даже, насколько реализуемых.
(11) Нет. У него - тираж. Во всяком случае, я так считаю.

(11) Заказные - это для своих сотрудников. А у них - для третьих лиц.

(0)
1. Нормальный вменяемый разработчик мобильных приложений на 1С стоит не дешевле чем разраб на html/css/js
2. Вы таки думаете что эту вашу хрень нельзя реализовать в виде простейшего веб-приложения?
Которое будет сильно удобнее для пользователей и выглядеть для них почти как нативное со своей иконкой в программах


ЗЫ https://habr.com/ru/company/ruvds/blog/352200/

ЗЗЫ У dns так

(15) Веб-проект нужно заказывать на стороне, закладывать в бюджет и т.п. Полный букет финансовой бюрократии. А одинэсник уже есть штатной единицей, насколько я понял.

(16) и это тоже

(16) Если захочется фон свой в МП и иконки внутри произвольно то это только через ПолеHTML.
Так что один фиг бюджет закладывать

ок, определились - нужно мобильное приложение

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

(18) Сайт бы нужен, если по-хорошему. Но тут прелесть в том, что взлететь можно очень легко и быстро своими силами. Простейший рабочий стол да несколько форм. Дешево и сердито. Любой сервис лучше, чем никакой. Только предусмотреть заранее механизмы информирования пользователя. О закрытии сервиса, например и его реинкарнации. О технических работах, о выходе новых версий и т.п.
(19) Нет. Мобильный клиент и мобильное приложение - принципиально отличаются в разработке. Нужно именно МП и начинать и продумывание всех моментов по синхронизации - во главе угла.

(19) Нифига. Начать нужно именно с плана обмена. Вернее не с него, а с определения перечня данных на мобильном устройстве. Интерфейс - дело десятое.

+ (21) Везде, во всех учебниках расписан обмен МП-ЦБ по плану обмена. На практике этого не всегда достаточно. Обмен базовыми данными конечно и обязательно с использованием планов обмена и служб регистрации изменений. Но очень часто возникает необходимость либо в одностороннем обмене, либо получить на мобильное устройство данные, которых там нет или они утяжеляют логику либо объем локальных данных. Так было например при получении в МП отчетов. СКД там просто нет. Потому обязательно нужна система обмена (и отображения на мобульном устройстве) произвольными данными.

(22) Ну у меня одна из моих самописок делает так...
Цепляется по вебсервису в центральную базу, регистрирует нужные данные для выгрузки в свой узел.
Инициирует выполнение обмена в центральной базе.
А потом выполняет обмен уже в своей базе.

(23) Я так сделал первую выгрузку данных из ЦБ на планшет. Планшет при пустой базе говорит ВЕБ-сервису выполнить начальную выгрузку для узла с кодом "имярек". Потом периодическими запросами проверяет готовность (фильтров данных дофига и начальный образ строится долго). Когда получен флаг готовности выгрузки - выполняется собственно обмен уже готовыми данными.

(4) >тогда вопрос - а взлетит/потянет?

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

МП годится для своих сотрудников, но не для неограниченного круга лиц.

Если выбор МП был сделан в надежде сэкономить на з/п Андроид разработчиков, то это ошибка.