Комментарии
Избранное
Подписка
Сортировка:
Древо
Т.е. судя по вступлению про бэкапы, Вы выложили этот материал только по тому, что он теперь не актуален? теперь есть платформенный механизм... В статье как я понял рассказывается, о том как сделать удобное приложение с точки зрения пользователя, но нет никакого примера кода, что очень прискорбно, потому как на бумаге можно и получше вашего на фантазировать, по моему куда более важно рассказать о том как это реализовать с помощью программных механизмов 1С. Как по мне, так это "пустая" статья без исходников.
(5) я знал, что без Вас тут не обошлось ))) к сожалению, тонкости как раз нигде и не описаны, а именно они - самое интересное)))
Например, "Поэтому в приложении Boss используются для обменов фоновые задания. После каждой записи данных в базу, запускается фоновое задание, которое инициирует обмен."
Моблиьное приложение - по сути, аналог файловой базы. Значит не фоновЫЕ задания, а фоновоОЕ задание, так как в файловой базе одновременно может выполняться только ОДНО фоновое задание
Например, "Поэтому в приложении Boss используются для обменов фоновые задания. После каждой записи данных в базу, запускается фоновое задание, которое инициирует обмен."
Моблиьное приложение - по сути, аналог файловой базы. Значит не фоновЫЕ задания, а фоновоОЕ задание, так как в файловой базе одновременно может выполняться только ОДНО фоновое задание
(7) На самом деле, кстати, пуши - не панацея. Потому что что такое пуш на самом деле? По сути, на устройстве крутится служба гугл, которая раз в каком-то промежуток времени шлет запрос гугл-сервер на предмет "я ИД такой-то, есть что для меня?". И это именно так, потому что иначе как? Если бы сервер гугла иницировал обмен, то он по факту должен знать связку "ИД гугла - мак-адрес телефона в конкретной сети конкретного оператора СОСС". Чтобы послать месседж конкретному устройству, на котором авторизован в своей гугл-учетке конкретный юзер. Конечно же, он такими данными не обладает.
Поэтому, банальное
завернутое в фоновое задание - тоже самое, что пуши.
Главное, чтобы 1С могла фоново работать, а для этого надо ей это разрешить в настройках устройства.
Тестировал, такой код ни разу не "сажает батарею".
Поэтому, банальное
Пока Истина Цикл
Если НаступилоВремяОбменаДанными() Тогда
ПослатьЗапросНаНашСервер()
КонецЕсли;
КонецЦикла;завернутое в фоновое задание - тоже самое, что пуши.
Главное, чтобы 1С могла фоново работать, а для этого надо ей это разрешить в настройках устройства.
Тестировал, такой код ни разу не "сажает батарею".
(8) ну не совсем то же самое, т.к. в таком случае нам нужно с какой-то периодичностью "дергать" наш сервер и спрашивать его "есть чё для меня", и когда накапливается несколько тысяч баз по несколько устройств в базе, то как-то сервер уже будет не очень-то рад такой популярности:) А чтобы обмен происходил именно быстро с точки зрения пользователя, дергать придется еще и очень часто.
А так мы без острой необходимости к серверу не обращаемся, и перекладываем ответственност на службу гугл и пуши. А дергаем сервер, грубо говоря, в двух случаях: когда что-то записали на этом устройстве (чтобы отправить новые данные на сервер) и когда получили пуш, что на сервере появилось что-то новое с другого устройства.
А так мы без острой необходимости к серверу не обращаемся, и перекладываем ответственност на службу гугл и пуши. А дергаем сервер, грубо говоря, в двух случаях: когда что-то записали на этом устройстве (чтобы отправить новые данные на сервер) и когда получили пуш, что на сервере появилось что-то новое с другого устройства.
(2) насчет бекапов: платформенный механизм хоть и есть, но очень уж "далеко" спрятан для рядового пользователя, и особенно далеким он становится, когда после поломки базы платформа просто сообщает об ошибке и закрывается, т.е. "список приложений" в мобильном приложении 1С уже никак не достать; + он сохраняет копии на том же устройстве, и пользователю тогда нужно самостоятельно те копии доставать и переносить в облако, если он сильно обеспокоен сохранностью данных:)
Ну и когда используется синхронизация с сервером, та платформенная копия (аналог dt в настольной 1С) тоже не особо поможет, т.к. тут разве что разрывать связь с сервером и заново регистрировать восстановленную базу и подключать другие устройства.
А насчет примеров кода: в докладе ставилась цель хотя бы "на пальцах" успеть рассказать идеи и предоставить пищу для размышлений, изначально это не статья и точно не мануал:)
Но интересно, какая именно часть не до конца понятна/недостаточно подробно изложена и требует примеров кода?
Ну и когда используется синхронизация с сервером, та платформенная копия (аналог dt в настольной 1С) тоже не особо поможет, т.к. тут разве что разрывать связь с сервером и заново регистрировать восстановленную базу и подключать другие устройства.
А насчет примеров кода: в докладе ставилась цель хотя бы "на пальцах" успеть рассказать идеи и предоставить пищу для размышлений, изначально это не статья и точно не мануал:)
Но интересно, какая именно часть не до конца понятна/недостаточно подробно изложена и требует примеров кода?
(13) А не подскажете, какая функция делает выгрузку базы средствами платформы?
Полистал хелп, прочитал список изменений в 8.3.9?
О какой программной выгрузке базы идет речь?
Нашел только выгрузку журнала регистрации и выгрузку конфы в файлы xml, но это ведь не то?
Надо ведь на выходе получить dt?
Полистал хелп, прочитал список изменений в 8.3.9?
О какой программной выгрузке базы идет речь?
Нашел только выгрузку журнала регистрации и выгрузку конфы в файлы xml, но это ведь не то?
Надо ведь на выходе получить dt?
(30) речь не о программной выгрузке, а о том, что пользователь теперь может самостоятельно делать бекап, до 8.3.9 этого не было. Правда спрятали эту функцию так далеко, что пользователи ее и не находят, что в нашем случае и хорошо:) А пройти пользователю нужно вот такой путь - список приложений - меню этой базы - Изменить - Администрирование - Резервное копирование. На выходе если заглянуть в папку с бекапом - там 1CD файл с кучей служебных, вот только просто открыть такой файл на настольной платформе не получится.
Программно создать такой бекап нельзя, как и узнать, что пользователь его развернул. Поэтому чтобы перестраховаться в случае, если используете синхронизацию, нужно добавить свою какую-то проверку: например, записывать дату последней синхронизации на мобильном и на сервере для каждого устройства, и сверять эти даты.
Программно создать такой бекап нельзя, как и узнать, что пользователь его развернул. Поэтому чтобы перестраховаться в случае, если используете синхронизацию, нужно добавить свою какую-то проверку: например, записывать дату последней синхронизации на мобильном и на сервере для каждого устройства, и сверять эти даты.
Крутая статья.
"Что касается сервисов, в приложении Boss реализован мгновенный обмен: один пользователь вводит данные, а другой их получает."
Скажите, а как у Вас в центральной (стационарной базе) организован план обмена? Что "сидит" в узле плана - пользователь или устройство? Иными словами, для рассылки пушей надо хранить идентификаторы устройств GCMsg. На конкретном устройстве может быть авторизован только один пользователь или любой? К примеру, месседжинг. Пользователь ГравБух написал в чат "Бухгалтерия". Все юзеры из чата "Бухгалтерия" должны получить это сообщение. Для этого надо отобрать ИД, которым отправить пуши. Чтобы их отобрать, надо знать кто из юзеров на каком устройстве авторизован.
Надеюсь, мой вопрос понятн, хотя несколько сумбурно написал...
"Что касается сервисов, в приложении Boss реализован мгновенный обмен: один пользователь вводит данные, а другой их получает."
Скажите, а как у Вас в центральной (стационарной базе) организован план обмена? Что "сидит" в узле плана - пользователь или устройство? Иными словами, для рассылки пушей надо хранить идентификаторы устройств GCMsg. На конкретном устройстве может быть авторизован только один пользователь или любой? К примеру, месседжинг. Пользователь ГравБух написал в чат "Бухгалтерия". Все юзеры из чата "Бухгалтерия" должны получить это сообщение. Для этого надо отобрать ИД, которым отправить пуши. Чтобы их отобрать, надо знать кто из юзеров на каком устройстве авторизован.
Надеюсь, мой вопрос понятн, хотя несколько сумбурно написал...
(3) в узле плана обмена "сидит" даже не устройство, а конкретная база на конкретном устройстве - на сервере соответственно храним ИдентификаторПодписчикаДоставляемыхУведомлений этой базы (см. метод ПолучитьИдентификаторПодписчикаУведомлений() ) и какой пользователь там работает, чтобы знать какие куда отправлять данные.
(10) а когда пользователи авторизуются в программе на устройстве - связку "база на устройстве - пользователь" - обновляете, отправив данные с устройства на сервер? И связка наверняка в регистре сведений))) я также делал, собственно говоря. Насчёт нескольких тысяч мобильных пользователей - таких объёмов объёмов, честно говоря, никогда не видел. Скорее всего, при такой нагрузке сервер для обменов данными надо выносить в отдельную базу и синхронизировать с продакшном регламентном.
(12)
А я и не говоил об их связи, я имел ввиду что:
1.Отказался от планов обмена
2.Для обмена использовал свой очень сжатый формат
3.HTTP сервисы использовал для определения новых данных на сервере
(9) не очень понимаю, в чем связь плана обмена, xml и http-сервиса - это же 3 отдельных никак не связанных вещи, и уж точно не взаимозаменяемые :)
А в каком формате вы передаете данные вместо xml? json?
А в каком формате вы передаете данные вместо xml? json?
А я и не говоил об их связи, я имел ввиду что:
1.Отказался от планов обмена
2.Для обмена использовал свой очень сжатый формат
3.HTTP сервисы использовал для определения новых данных на сервере
(15)
Мне уже прям интересно - каким образов вы фиксируете удаленные объекты и регистры сведений. Жуть как интересно.
Что значит сжатый формат? Текст хорошо сжимается хранилищем значений. JSON поддерживается и на сервере и в мобильнике. Куда еще "сжатее"?
А старых? А удаленных? А измененных? А блокировки данных? А данные которые вдруг стали не доступны, или наоборот - доступны, когда по РЛС склад не доступен, а потом поменяли склад на другой в документе?
В ваших словах, как мне кажется, затаилось очень-очень узкоспециализированное решение. Которое уж никак не может претендовать на нечто "универсальное, что можно советовать всем". ИМХО
Отказался от планов обмена
Мне уже прям интересно - каким образов вы фиксируете удаленные объекты и регистры сведений. Жуть как интересно.
Для обмена использовал свой очень сжатый формат
Что значит сжатый формат? Текст хорошо сжимается хранилищем значений. JSON поддерживается и на сервере и в мобильнике. Куда еще "сжатее"?
HTTP сервисы использовал для определения новых данных на сервере
А старых? А удаленных? А измененных? А блокировки данных? А данные которые вдруг стали не доступны, или наоборот - доступны, когда по РЛС склад не доступен, а потом поменяли склад на другой в документе?
В ваших словах, как мне кажется, затаилось очень-очень узкоспециализированное решение. Которое уж никак не может претендовать на нечто "универсальное, что можно советовать всем". ИМХО
(17)
нормально их фиксируем по ObjectID, а как по вашему их фиксирует механизм РИБ?
(17)
Ну вы серьезно? Есть более сжатые форматы чем JSON. Мой формат похож на csv.
Кстати хранилищем значений сжимается в веб-сервисах, а они не приемлемо тормозят. А насчет HTTP сервисов недавно открыл вариант сжатия в хранилище и предачу по Base64, но я еще не тестировал его, думаю выйгрыш будет не большой.
(17)
RLS не требовался в реализованных решенях т.к. обмен Сервер - Терминал
(17)
Заметьте мы обсуждаем тут решение Сервер <-> Мобильная платформа.
Решение универсальное и план обмена может менять сам пользователь на лету. Так же их может существовать сколько угодно и для разных мобильных (переферийных) баз свой план.
Так же бинарные данные и картинки тоже переносятся.
Мне уже прям интересно - каким образов вы фиксируете удаленные объекты и регистры сведений. Жуть как интересно.
нормально их фиксируем по ObjectID, а как по вашему их фиксирует механизм РИБ?
(17)
Что значит сжатый формат? Текст хорошо сжимается хранилищем значений. JSON поддерживается и на сервере и в мобильнике. Куда еще "сжатее"?
Ну вы серьезно? Есть более сжатые форматы чем JSON. Мой формат похож на csv.
Кстати хранилищем значений сжимается в веб-сервисах, а они не приемлемо тормозят. А насчет HTTP сервисов недавно открыл вариант сжатия в хранилище и предачу по Base64, но я еще не тестировал его, думаю выйгрыш будет не большой.
(17)
А старых? А удаленных? А измененных? А блокировки данных? А данные которые вдруг стали не доступны, или наоборот - доступны, когда по РЛС склад не доступен, а потом поменяли склад на другой в документе?
RLS не требовался в реализованных решенях т.к. обмен Сервер - Терминал
(17)
В ваших словах, как мне кажется, затаилось очень-очень узкоспециализированное решение. Которое уж никак не может претендовать на нечто "универсальное, что можно советовать всем". ИМХО
Заметьте мы обсуждаем тут решение Сервер <-> Мобильная платформа.
Решение универсальное и план обмена может менять сам пользователь на лету. Так же их может существовать сколько угодно и для разных мобильных (переферийных) баз свой план.
Так же бинарные данные и картинки тоже переносятся.
(18)
А какой ID у регистра сведений? И это получается, что при каждом удалении/изменении регистра и т.д. - у вас вызываются обработчики которые фиксируют все это куда-то. Где потом 100% узкое место лдя блокировок, причем по всей системе в куче.
csv - это вообще не формат обмена данными, чтобы его использовать - систему надо покрывать кучей тестов, из серии, а что если разделитель попадется в наименовании. А также следить за порядком данных в нем, и вообще - csv, это уже давно частный случай JSON. Это раз, два - в csv вы выигрываете только в том, что не именуете теги, но так этогда просто массив данных того же json, но система уже сама может контролировать запрещенные символы и кучу всего другого. Два - хранилище - это арзиватор, архиватор отлично сжимает тексты, которые повторяются очень часто, а значит сжав JSON и CSV вы получите мизерный прирост, который вообще не стоит затраченных усилий. Три - json парситься платформой, а csv - мы мучаете сами, т.е. напрягаете не платформенные механизмы для парсинга, а прикладные, что всегда плохо.
Та и в целом - JSON это хороший тон.
А еще хранилище можно записать в текст и передать просто в теле запроса текстом, а можно вернуть бинарные данные.
РЛС не требовался - это понятно, но как это связано с сервером терминалом?
А я где то говорил про стационарную 1С?
Решение универсальное и план обмена может менять сам пользователь на лету. Так же их может существовать сколько угодно и для разных мобильных (переферийных) баз свой план.
Так же бинарные данные и картинки тоже переносятся.
Меня не покидает чувство, что вы просто не захотели разбираться досконально в планах обмена и прочих механизмах, потому что то о чем вы говорите - вообще никак не связано с тем, как это все делается.
P.S. Я согласен, что бывают старые проекты, которым уже 3 года, или больше, и там иногда требовалось отказаться от планов и прочей ахинеи в мобильной 1С, но это не из-за того, что по другому - круто, а из-за того, что раньше по другому просто не работало в принципе.
Сейчас же - все работает отлично. Поэтому не нужно выдумывать велосипеды :)
нормально их фиксируем по ObjectID, а как по вашему их фиксирует механизм РИБ?
А какой ID у регистра сведений? И это получается, что при каждом удалении/изменении регистра и т.д. - у вас вызываются обработчики которые фиксируют все это куда-то. Где потом 100% узкое место лдя блокировок, причем по всей системе в куче.
Ну вы серьезно? Есть более сжатые форматы чем JSON. Мой формат похож на csv.
csv - это вообще не формат обмена данными, чтобы его использовать - систему надо покрывать кучей тестов, из серии, а что если разделитель попадется в наименовании. А также следить за порядком данных в нем, и вообще - csv, это уже давно частный случай JSON. Это раз, два - в csv вы выигрываете только в том, что не именуете теги, но так этогда просто массив данных того же json, но система уже сама может контролировать запрещенные символы и кучу всего другого. Два - хранилище - это арзиватор, архиватор отлично сжимает тексты, которые повторяются очень часто, а значит сжав JSON и CSV вы получите мизерный прирост, который вообще не стоит затраченных усилий. Три - json парситься платформой, а csv - мы мучаете сами, т.е. напрягаете не платформенные механизмы для парсинга, а прикладные, что всегда плохо.
Та и в целом - JSON это хороший тон.
А насчет HTTP сервисов недавно открыл вариант сжатия в хранилище и предачу по Base64, но я еще не тестировал его, думаю выйгрыш будет не большой.
А еще хранилище можно записать в текст и передать просто в теле запроса текстом, а можно вернуть бинарные данные.
RLS не требовался в реализованных решенях т.к. обмен Сервер - Терминал
РЛС не требовался - это понятно, но как это связано с сервером терминалом?
Заметьте мы обсуждаем тут решение Сервер <-> Мобильная платформа.
А я где то говорил про стационарную 1С?
Решение универсальное и план обмена может менять сам пользователь на лету. Так же их может существовать сколько угодно и для разных мобильных (переферийных) баз свой план.
Так же бинарные данные и картинки тоже переносятся.
Меня не покидает чувство, что вы просто не захотели разбираться досконально в планах обмена и прочих механизмах, потому что то о чем вы говорите - вообще никак не связано с тем, как это все делается.
P.S. Я согласен, что бывают старые проекты, которым уже 3 года, или больше, и там иногда требовалось отказаться от планов и прочей ахинеи в мобильной 1С, но это не из-за того, что по другому - круто, а из-за того, что раньше по другому просто не работало в принципе.
Сейчас же - все работает отлично. Поэтому не нужно выдумывать велосипеды :)
(19)
Фиксируются в отдельный регистр под каждый объект, так же как и в РИБ
(19)
все спец символы контролируются тегами для HTML, в данном решении парсить данные не нужно так как они уже структурированы по колонкам, теги тоже не нужны
(19)
Я это и имел ввиду когда написал BASE64 :) Вопрос по выйгрышу остается открытым
(19)
В момент формирования пакета данных для терминала фильтрация происходит по нужным правилам
(19)
В обычных решениях 1С я везде использовать РИБ. Но в данном случае были взвешены во внимание скорость, ограничения РИБ и гибкость нужная клиентам и было принято решение сделать свой механизм.
(19)
У меня тоже все работает отлично, разница в том что я контролирую весь процесс полностью.
(19)
В мире ИТ всегда выдумываются велосипеды, благодаря этому мы имеем C++, Java. а сейчас Kotlin для мобильной разработки и кучу всяких JS-фреймворков и я считаю это прекрасно.
А какой ID у регистра сведений? И это получается, что при каждом удалении/изменении регистра и т.д. - у вас вызываются обработчики которые фиксируют все это куда-то. Где потом 100% узкое место лдя блокировок, причем по всей системе в куче.
Фиксируются в отдельный регистр под каждый объект, так же как и в РИБ
(19)
csv - это вообще не формат обмена данными
все спец символы контролируются тегами для HTML, в данном решении парсить данные не нужно так как они уже структурированы по колонкам, теги тоже не нужны
(19)
А еще хранилище можно записать в текст и передать просто в теле запроса текстом
Я это и имел ввиду когда написал BASE64 :) Вопрос по выйгрышу остается открытым
(19)
РЛС не требовался - это понятно, но как это связано с сервером терминалом?
В момент формирования пакета данных для терминала фильтрация происходит по нужным правилам
(19)
Меня не покидает чувство, что вы просто не захотели разбираться досконально в планах обмена
В обычных решениях 1С я везде использовать РИБ. Но в данном случае были взвешены во внимание скорость, ограничения РИБ и гибкость нужная клиентам и было принято решение сделать свой механизм.
(19)
Сейчас же - все работает отлично.
У меня тоже все работает отлично, разница в том что я контролирую весь процесс полностью.
(19)
Поэтому не нужно выдумывать велосипеды
В мире ИТ всегда выдумываются велосипеды, благодаря этому мы имеем C++, Java. а сейчас Kotlin для мобильной разработки и кучу всяких JS-фреймворков и я считаю это прекрасно.
(20)
Почему вы используете термин РИБ? Он тут вообще не применим, в принципе, и опять я повторюсь - вы не разобрались в механизмах. Вам никто не мешает регистрировать планами, а потом делать выборки из планов.
Если честно - я понимаю о чем вы пишите, я сам так когда делал, пока не научился делать это правильно.
Вы смотрели бесплатный курс по мобильной платформе?
В обычных решениях 1С я везде использовать РИБ. Но в данном случае были взвешены во внимание скорость, ограничения РИБ и гибкость нужная клиентам и было принято решение сделать свой механизм.
Почему вы используете термин РИБ? Он тут вообще не применим, в принципе, и опять я повторюсь - вы не разобрались в механизмах. Вам никто не мешает регистрировать планами, а потом делать выборки из планов.
Если честно - я понимаю о чем вы пишите, я сам так когда делал, пока не научился делать это правильно.
Вы смотрели бесплатный курс по мобильной платформе?
(21)
Ок, механизм распреленных баз данных используя планы обмена. Да я в курсе что можно самостоятельно регистрировать изменения в план, меня все же не устраивает этот механизм от платформы, мне нужен полный контроль.
Нет бесплатный курс не смотрел.
Почему вы используете термин РИБ? Он тут вообще не применим, в принципе, и опять я повторюсь - вы не разобрались в механизмах. Вам никто не мешает регистрировать планами, а потом делать выборки из планов.
Если честно - я понимаю о чем вы пишите, я сам ак когда делал, пока не научился делать это правильно.
Если честно - я понимаю о чем вы пишите, я сам ак когда делал, пока не научился делать это правильно.
Ок, механизм распреленных баз данных используя планы обмена. Да я в курсе что можно самостоятельно регистрировать изменения в план, меня все же не устраивает этот механизм от платформы, мне нужен полный контроль.
Нет бесплатный курс не смотрел.
(22) есть планы обмена, их задача регистрировать изменения данных, с возможностью дальнейшего переноса данных куда угодно и в каком угодно виде.
Есть РИБ - риб, это частный случай использования планов обмена, который подразумевает одно ключевое упрощение - у вас все базы входящие в риб должны быть идентичны, так как риб переносит вместе с данными и конфигурацию.
Мобильная платформа вообще не поддерживает риб и это логично.
Отсюда вопрос - зачем писать свой велосипед обмена данными, если есть стандартный.
Советую посмотреть курс, тогда большая часть вопросов отпадет сама собой.
Есть РИБ - риб, это частный случай использования планов обмена, который подразумевает одно ключевое упрощение - у вас все базы входящие в риб должны быть идентичны, так как риб переносит вместе с данными и конфигурацию.
Мобильная платформа вообще не поддерживает риб и это логично.
Отсюда вопрос - зачем писать свой велосипед обмена данными, если есть стандартный.
Советую посмотреть курс, тогда большая часть вопросов отпадет сама собой.
(23)
Посмотрел бесплатный курс... я конечно понимаю, что это своего рода реклама для полного курса, но все же просмотрев готовое решение и сам курс я сделал вывод, что как и 99% вводных курсов по всем технологиям, он имеет мало общего с реальностью.
Я никому не рекомендую читать этот вводный курс, а про полный и не знаю что сказать, спасибо вам и удачи.
оветую посмотреть курс, тогда большая часть вопросов отпадет сама собой
Посмотрел бесплатный курс... я конечно понимаю, что это своего рода реклама для полного курса, но все же просмотрев готовое решение и сам курс я сделал вывод, что как и 99% вводных курсов по всем технологиям, он имеет мало общего с реальностью.
Я никому не рекомендую читать этот вводный курс, а про полный и не знаю что сказать, спасибо вам и удачи.
(24) Как это не видите, т.е. вы считаете, что при написании заказов для торговых агентов - база мобильной должна полностью соответствовать стационарной 1С? Та еще и обновляться при каждом обновлении стационарной? Я вас правильно понял?
(25) При чем тут платный, в бесплатном курсе хорошо разобраны планы обмена, причем в платном - про них ни слова нету. Но раз вы даже из этой информации ничего не смогли вынести (где рассказано про планы, про то, почему именно они, как работать с ними, как преобразовывать данные и т.д.), то да, наверное я зря стараюсь, когда пытаюсь чтобы было по меньше велосипедов в мире 1С.
Ну ок, пусть будет так. Тогда и вам удачи :)
(25) При чем тут платный, в бесплатном курсе хорошо разобраны планы обмена, причем в платном - про них ни слова нету. Но раз вы даже из этой информации ничего не смогли вынести (где рассказано про планы, про то, почему именно они, как работать с ними, как преобразовывать данные и т.д.), то да, наверное я зря стараюсь, когда пытаюсь чтобы было по меньше велосипедов в мире 1С.
Ну ок, пусть будет так. Тогда и вам удачи :)
Добрый день Снежана,
Каким образом вы посылаете PUSH на клиентские андроид / iOS терминалы?
Какой сервис вы используете? Google или 1С или другой?
Сразу говорю что я не ваш конкурент так как работаю в другой стране и создаю узкоспециализированные решения. Заранее спасибо за ответ.
С Уважением, Василий.
Каким образом вы посылаете PUSH на клиентские андроид / iOS терминалы?
Какой сервис вы используете? Google или 1С или другой?
Сразу говорю что я не ваш конкурент так как работаю в другой стране и создаю узкоспециализированные решения. Заранее спасибо за ответ.
С Уважением, Василий.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
Открыть
|
Перенос данных КА 1.1 / УПП 1.3 => БП 3.0 (перенос остатков, документов и справочников из "1С:Комплексная автоматизация 1.1" / УПП 1.3 в "1С:Бухгалтерия 3.0")
|
Перенос данных КА 1.1 / УПП 1.3 => БП 3.0
Открыть