Всем привет. Надо написать клиентское приложение что бы пользователи могли пользоватьсой базой. Например собрать заказы. Но при этом они должны в режиме онлайн работать с базой. Кто сталкивался ? Рельано ли использовтаь мобильное приложение только как клиент ? Или будут проблемы с его ограничениями ? А что если просто написать УФ ? Можно будет опубликовать и открывать на планшетниках через браузеры ?

напиши УФ.

Можно. Стабильность работы на мобильном интернете при этом на твоей совести.

Лучше юзать отдельное приложение с локальной базой все-таки. А синхронизацию можно хоть ежеминутную сделать.

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

(3) Где они неактуальны? В 1С? Так клиент тут не поможет. А если в 1С актуальны, то и при синхронизации будут актуальными.

+(4) И брось это гиблое дело, пытаться удаленно 120 ТП заставить работать, только трата времени. Бери готовый продукт и не заморачивайся.

(4) Они теряют свою актуальность сразу после синхронизации

Ну после синхронизации ТП еще должер обсдуть количество с клиентом и забивать остальные товары. Итого уходит минут 10-15 до проведения документа. За это время на сервере остатки меняються.

(6)(7) Песец, а нижний предел для ежедневных остатков вообще в вашем учете не существует?

Нет не существует.

(9) Однако фигня получается. В системе утром осталось 10 единиц товара, 120 агентов поковыляли заказы собирать, и кто первый этот десяток в заказ вбил - тот и красаущег, а остальные 110 будут перед клиентами руками разводить?

Мне кажется лучше УФ. Или в мобильном приложении при проведении документа запрашивать остатки.

И так. УФ спасает ?  Кое что такое уже работает. Правда он не делает ничего крутого. Просто отчеты вытаскивает из баз. Но мне не понятно его перспетивы.

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

Маратыч, по моему ты о чем  то другом. Можешь конкретизировать по теме  ?

Когда столкнетесь с мертвыми зонами и проблемами связи - вспомните эту ветку :)

(15) Соглашусь. Делал мобильное приложение. Даже в Москве не везде стабильный интернент, я уж не говорю что у пользователей зоопарк смартов с разным качеством радиомодулей. Но в моем случае было достаточно синхронизироваться несколько раз в день в точках уверенного инета или в местах где есть wifi.

Мы собираемся стандартизировать планшетники, что бы не было проблем с радиомодулями и ОС. Все равно покупать будут за счет компании.

Тем более клиенты, к которым поедут торговые представители могут находится в подвалах, бункерах и другим местах, где сеть не работает в принципе )

(14) Конкретизирую. Как я понимаю, ваши торганы работают по пресейлу, собирая заказы с последующей доставкой "день в день" или "на следующий день". В таких случаях анализируются продажи и формируется нижний порог остатков по каждой разновидности товара, исходя из его средних продаж за какой-то долгосрочный период. Сверху на него накидывается дополнительная цифра на случай форс-мажора. Т.е. если средние продажи копыт по каждому агенту - 10 штук в день, а рогов - 20 штук в день, то остаток на начало дня должен быть не менее 1200 копыт и 2000 рогов, плюс еще процентов 10. Если актуальный остаток ниже, то вариантов несколько:
1. Весь остаток выгружается только определенной категории агентов (к примеру, работающих по категории клиентов "А" или випам). У остальных этот товар "по нулям" и продавать его они не могут.
2. Остаток попросту "замораживается" и никому из агентов этот товар не выгружается. Особенно если его ну совсем мало и даже "А"-шникам не хватит.
3. Разрешить минусовые остатки и по факту формирования заказов службой доставки (или предварительным анализом оператором за два-три часа до формирования доков) делать экстренный дозавоз товара на склад. В случае крупных оптовиков малореально.

Лучше продать товар позже, чем клиенту уже заказанный товар не привезти, как-то так.

(16) Дык я и рекомендую оффлайновый клиент с синхронизацией.

(17) Можешь еще представить ситуации (вполне реалистичную) с падением канала до центрального сервера, падением самого сервера, сгоревшим роутером/свичем и банально экскаватором с таджиками, сковырнувшим магистраль.
При этом ВСЕ 120 агентов в случае с онлайн-подключением прекращают работу, пока канал не восстановится. Вообще прекращают, они уже не могут заказы собирать. С оффлайновым клиентом они и в ус не дуют, пока проблема с сервером/каналом/экскаватором судорожно решается вашими админами.

Так мы решили эту задачу совсем по другому. У ТП будут четкие маршруты. По этому маршруту будут через GPS контролироваться. Есть отчет автозаказ. Он показывает какой магазин сколько берет ,обычно, каждый 3 дня. И какие товары.
То есть тот кто будет задавать маршрут знает кто куда и через сколько дней должен подойти. Но самое главное остатки должны быть атуальны в лубую минуту. У нас остатки часто меняються. Выгрузка с вагона или с другого склада, приход итд. Ни кто не знает когда остаток поменяться.  Здесь весомое значение имеет актальность остатков.

+(20) Я к чему это все - суммарные риски в случае с работой в онлайне перекрывают любые проблемы с актуальностью остатков, которая, к тому же, в нормальном рабочем режиме может поддерживаться в пределах десятков минут между синхронизациями.

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

(15) +1
есть такая проблема. особенно по районным центрам. поэтому только оффлайн. у нас экспедитор набирает заказ в магазине клиента, отходит на 15 метров от магазина и синхронизирует данные.
Также экспедитором объясняем что синхронизацию лучше делать стоя на одном месте, потому что во время езды связь теряется.

(0) если там где юзер 100500% будет стабильный 3Г хотя-бы - можно и на УФ, если нет - пиши мобильное приложение которое можно будет периодически синхронизировать с основной базой (но будет ряд ограничений, например не провериьть текущие остатки на складе).

Так тоже пробовали. Там одна проблема. Берешь заказ. Клиент рад. Потом берешь слова обратно. Потому что в остатке их уже нету -)

(21) Онлайн не спасет вас от неактуальных остатков, пойми наконец. Но добавит проблем с задержками.

Если у вас дневной запас не покрывает дневных заказов, то это проблема логистики а не системы заказов.

(26) Научитесь отслеживать поставки и резервировать из них, уже полегче будет.

(26) оформляешь заказ клиенту в онлайне
клиент: копыта есть?
ТП: есть
клиент: сколько стоят?
ТП: 20 руб/шт
клиент: а свежие?
ТП: только вчера привезли
Клиент: дайте 20 шт.
...
прошло 10 минут, набрали еще 10 позиций, нажимаем провести, бац, а копыт уже нет.

Спасает онлайн?

(29) спасёт. клац на позицию - и она сразу улетает в центр и резервируется

Не успел написать. Так и есть )

(27) +100500, у вас с бизнес-процессами проблема, и одной автоматизацией ее не решать, надо логистику перерабатывать.

(30) От такого больше вреда, чем пользы.

(33) обоснуй

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

(35) Вы не на актуальности остатков ее строите, а на ограниченных запасах.

(0) Тоже сейчас примерно такое используется, только не онлайн работа, а получение остатков мобильным устройством по запросу с веб-сервиса...

У нас нет ограниченных запасов. У нас есть быстро меняющиеся остатки.

(38) У вас эти быстро меняющиеся остатки способны стать в течение дня ниже плинтуса без учета среднедневных заказов. Это и есть ограниченный запас.

(30) (31) У вас стабильность работы ТП зависит от большого количества факторов:
1. Если связь у ТП пропала, курим?
2. Если связь со стороны сервера, курят все?
3. каждая строчка это транзакция, а вдруг какой-нибудь запросик тормознул систему, все курят и говорят: еще минутку строчка на сервер улетит?

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

+ диагностировать проблемы легче в пакетном режиме.
+ Стабильность! (120 курящих ТП немного будут волновать руководителя)

это я об технологии, а о бизнес-логике ранее уже ответили

(35) Что есть актуальность остатков в вашем понимании? У вас все заказанное на 100% должно быть отгружено? Нет процедур контроля ДЗ контрагента, минимальных сумм заказа и тому подобного?

(34) Появятся зависшие резервы. Весь заказ должен проходить одной транзакцией.

Ну кто сказал что ниже плинтуса ? А может выше крыши ?  Остаток поменялся . Может только что добавили приход.

(42) а чойта они зависнут?

(42) При правильной реализации это не проблема...

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

(43) Вот смотри, пришел человек принимающий заказы в точку, Клиент просит 20 штук товара. На остатке на момент заказа 10 штук, соответственно, в заказ уходит 10. Как тебе поможет, если через 5 минут после заполнения этой строки заказа будет приход этого товара?

Маратыч, а кто сказал что не может быть недостаточно ? Ни кто не может ничего сказать. Они меняются. Понимаешь ?

   ГеннадийУО, это поможет другому ТП. Он уже будет видеть не 10 штук.

(48) Понимаешь, я говорю о том, что если в бизнес-процессе не учтена ДОСТАТОЧНОСТЬ дневного запаса товаров, то у тебя неудовлетворенные клиенты будут что в онлайн-варианте, что в оффлайн. Вот только в нагрузку к онлайну ты получаешь большие, зачастую неприемлемые риски, связанные с качеством/доступностью связи и твоих сервисов в центре.

(44) Например связь глюкнет. Заказ в каком статусе остается? "Частично проведен"?

(48) Да, он перед началом ввода заказа, а не онлайн, считывает актуальные остатки, и спокойно ими пользуется...

Достаточно не достаточно. Много слов. И так не удобно работать в быстро меняющиеся условиях.

Ну получили в мобильное приложения все по 30 штук товаров в остатке. Пока они отправляют заказ их уже 20. Кто первый тот и успел.  Проблема ? Проблема !

В остатке 100 штук. Всем хватает. Все заказли по 10 штук. Пока все отправляли крупную партию куда то отправили опять.
Проблема ? Проблема !

А должно быть так. Есть остаток в данный момент есть заказ, нет и заказа нету.

(52) >И так не удобно работать в быстро меняющиеся условиях

Настоящее "не удобно" начнется тогда, когда из-за проблемы со связью все 120 ТП начнут звонить своим супервайзерам, которые тут же начнут стучать своему начальству и так вплоть до бигбоссов.

Это будет истинное неудобство.

(52) >Кто первый тот и успел.  Проблема ? Проблема !
>Пока все отправляли крупную партию куда то отправили опять.
Проблема ? Проблема !

Как онлайн решит эту проблему? Никак!

+(53) И никто потом не посмотрит на то, что из-за филигранной и красивой актуальности "секунда в секунду" ушло на десять заказов в месяц больше, когда простой в один долбаный час лишит компанию СОТНИ заказов.

так бывает не часто. Вот у меня все магазины сидят в онлайне. Иногда бывают проблемы. Тогда переходят в авариный режим. То есть пользуються локальной базой получив обмен. Наверное все таки УФ. А когда проблема с сервером или еще чего то будут переходит в авариный режим используя мобильное приложение.

(56) Ты прикалываешься, что ли? Хочешь для решения одной задачи городить двойную схему заказов? Тогда еще и операторов не забудь кучку посадить для вбивания заказов с бумажек.

У тебя вообще опыт есть по работе с крупным оптовым пресейлом?

Какие операторы ? Какие бумажки ?

(58) А вдруг с мобильного оффлайнового клиента заказы не получится загрузить? Операторы с бумажек забьют в базу, ага.

(52)  проблема у тебя ... А влюбой нормальной системе тупо считается недозаказ, и он в будущем идет в учет планирования поставок.

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

По ходу - мне быть капитаном :)
И так, все делиться на две части:
1. Офлайн часть. В неё записываются данные, которые меняются редко, например, товар, клиент, цены можно и т.д.
2. Онлайн часть. В момент проведения документа - делается проверка ОСТАТКОВ в ЦБ! и если все ок, то проводим документ.
Если нет остатков в ЦБ, то уже на момент проведения - это видно.
Кроме этого - часть оналйн инофрмации можно держать в офлайне, например делать синхронизацию остатков раз в 5 минут. При чем синхронизировать надо так - утром получаем полный пак остатков, а потом каждый раз получаем только их изменения относительно предыдущей загрузки.
Для того, что бы не тратить ресурсы ЦБ - эти данные лучше выгружать с ЦБ с шагом в пару минут и обновлять один файл, который будет подхватывать КАЖДЫЙ торговый.
Что это дает? Если я спускаюсь в подвал, и там нет инета, то я смотрю на какое время у меня остатки, если я получил обмен пять минут назад, а остатков уу меня 5000ед, при вреднем заказе в 5 штук, то я клиенту говорю, что с вероятностью в 99% - товар будет.
Если же у меня осталось 10ед на остатках, а обмен последний раз был час назад, то я клиента предупреждаю СРАЗУ, что может быть вот такая фигня, давайте подберем аналог, если этого не окажется.
Как только я вышел с подвала и пришел обмен - программа проверяет - все ли я успешно могу списать, если да, то проблем нету. Если же я вылез в минуса (и тут уже особо не волнует, даже если я документ сделал раньше кого-то, а синхронизировался позже) то программа смотрит - есть ли аналоги. Потом выводит все сообщение о том, что по такому клиенту - такие изменения, формирует мне сразу сообщение на почту со всеми изменениями (или смс, или вибер, у кого как) и отправляет данные (с моего позволения) клиенту, о том, что произошли изменения и какие. Потом я уже по горячему перезваниваю клиенту (предыдущий шаг и этот можно поменять местами) и уточняю - все ли его устраивает, если да, то формируются накладные (которые формируются ТОЛЬКО на сервере и ТОЛЬКО сервер отправляет их клиенту, что бы не было ситуации, когда торговый вешает лапшу).

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

Такая система обмена называет гибридной. И минусов у нее почти нет.

(62) 120 торг агентов это крайне много, и вероятность того, что 5 минут назад было 5000 единиц товара, а сейчас 0, есть, и она не иллюзорна. + бывает что даже в МСК ну тупо нет интернета в каком то квартале, те мобила ловит, говорить можно, а вот интернета нет. Те при заказе каждой позиции бегать в зону уверенного приема для контроля остатков? Бред. Если не будет держатся склад под хотя бы суточную потребность, коллизии будут.
У нас есть моб приложение, пользователей всего 30. Остатки там не используются, тупо ввод документов - заявок. И то ревут.И это в МСК и области, тупо бывает нет интернета. А тут 120.

Либо улучшать логистику до того, что бы она на 200% покрывала сезонную суточную потребность, либо верить что интернет будет (фантастика). Остальное - влажные фантазии. Уплюетесь.

(61) Дружище, я в трех различных компаниях FMCG успел поработать, от программиста до системного аналитика, нигде меньше сотни ТП не было, шлялись с софтом от древней хрени на Palm OS до Агент+ под ведроид. И везде, где кому-то из боссов в голову стукала моча на тему "а давайте актуальные остатки и ваще онлайн, ололо", я сначала этот самый "онлайн" организовывал супервайзерам. Таинственным образом эта дурная идея пропадала после буквально пары дней работы суперов в "онлайне". А они ВСЕГО ЛИШЬ с отчетностью работали по своим командам, понимаешь?

(62) Это обычная оффлайновая схема, только с функционалом подбора аналогов. Идея отличная, но не всегда подходит, особенно под сезонно-акционный ширпотреб вроде напитков с кодом а ля "напиши, лох, смс за двадцатку рублей, и ты, с шансом 1:100000 выиграешь какую-нибудь лопату от гнусмаса".

Далее, клиентам FMCG вообще похрену в большинстве случаев, что ты там у себя наизменял, особенно это касается категории "А". Они ведут учет СТРОГО под заказ, и если ты сам себе злобный буратино - проблемы твои, доставь товар хоть тушкой, хоть чучелом ПО ЗАКАЗУ.

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

+(66) А ТС вообще хочет напрямую с базой работать, вот в чем дело. То есть твой "онлайн" и его "онлайн" - очень разные "онлайны" :)

А что ? Идея про гибридности может и сработает. Если есть онлайн остаок, то отлично. А если нет, то довольствуйся оффлайн остатком 10 минутной давности. Ну ни у всех же будут проблемы с онлайном. Так что - это снижает количество проблем связанные с постоянным оффлайн режимом.

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

А теперь такой вопрос. Если Платформа 8,2 и редакция конфиги  2,0 , то на сколько реально эту базу синхронизировать с мобильным приложением ? Ведь мобильное приложение можно создавать тольок в платформе 8,3.

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

А чего не специализированное решение? Дорого, конечно, но мобильное приложение 1С - монстр еще тот.

(69) Проведение-то происходит на сервере, который по-любому остатки проверит. Или бывают схемы, где это не так?

(72) Не, я про проведение заказа на клиенте. В этот момент клиент цепляется к серверу, получает остатки и, если товара йок, верещит и матерится. Если все пучком, данные синхронизируются и сразу заказ проводится на сервере.

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

количество дебилов как обычно здесь радует.
1. онлайн через гпрс невозможен физически от слова ВААБЩЕ. планешт в руки и вперед проверять.
2. актуальность остатков ТОЛЬКО в момент проведения по базе. Да блин, то что у вас физически лежит на складе нефига не актуально, часть уже продана.
3. Проводить заказы, и сразу получать результат проведения можно в торговой точке только в проф решениях, типа агентоида.

120 агентов в  онлайн через гпрс...ахаха, колцентр нанимайте разгребать проблемы агентов "ваша программа не работает" :)

Дебил это ты. Не умничай. На все твои гипотзы тут уже давали ответ. Читай внимательно.

(0) Среднюю статистику по работе ТП в студию:
- количество транзакций всего в день
- среднее количество на одного ТП в день
- объем ассортимента на складе

(75) Он тут свой агентоид во всех ветках про мобильные приложения пиарит =)

(73) Какое нафиг проведение на клиенте? Проведение может быть только на сервере.

(78) Клиентские приложения, как правило, тоже могут "записывать" и "проводить" документы заказов. Это всего лишь означает, что "проведенный" документ будет синхронизироваться, а записанный черновик - нет :)

(63) вы я смотрю все в абсолютныц цифрах принимаете. Тогда в том примере пусть будет не 5000, а 100500, вам этого хватит, что бы уверено сказать, что клиенты не разгребут все под ноль в течении двух часов?
Если разгребут, то это уже лажа контроля закупок, и это не к нам.

"Те при заказе каждой позиции бегать в зону уверенного приема для контроля остатков?"
Где вы это прочитали??? Блин, друг, прочти внимательно то, что пишут другие, если ты даже не можешь прочитать текст опонента, и ответить, то я даже не знаю как ты вообще что то делаешь. И сдается твоему опыту верить вообще никак нельзя.
(66)не согласен, если идет бум, то надо прогнозирование остатков в онлайне, и сразу дозаказ поставщику.

(67) но его онлайн не реален, а моему - пофиг на качество канала.

Вот еще вариант реализации. Планшеты на винде. Ставите тонкий клиент и будет вам счастье.

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

(80) >если идет бум, то надо прогнозирование остатков в онлайне

Бум прекрасно прогнозируется, ибо сама компания его и создает. Онлайновых средств для этого не требуется, если компания работает по push-системе. А вот в pull-системе таки да, онлайн-прогноз - один из ключевых элементов.

Засада в том, что на рынке FMCG в условиях СНГ практически нереально организовать логистику pull, если своего производства нет. Ибо переколбасить поставки на "мелкие партии, но быстро"... в общем, сложно очень. И дорого обойдется из-за нестабильности и протяженности транспортных потоков.

(80) я то прекрасно прочитал, а вот Вам следовало бы прочитать.

(75) упоротость на марше. какие нах гипотезы, какие нах ответы? ж0лтый цвет тут в тему.

больные фантазии не остановить, буду продолжать наблюдения :) ничего личного, просто поржать.

(85) Агентоид, кстати - школьная поделка для ларьков.

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

(86) хрена у вас в казахстане школьники, могут грид навернуть свой, могут свой движок БД собрать и все на яве, не на 1с! Не то что русские. Семипалатинск рядом наверное, так благотворно влияет. срочно еду к вам!

(88) Бгг, что и требовалось доказать.

Школьникам, видимо, невдомек, что в Казахстане русских полным-полно.

(81) Да в связь же упирается все равно. ТС, по сути, это и предлагал.

(89) Про тонкий клиент я видимо не разглядел, видел только реализацию через браузер, которая сама по себе не устойчива из за того что ни на один браузер надёжи нет. Они ВСЕ без исключения глючат рано или поздно.

А что не так со связью? Там 3G не ловит что ли?

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

(89) перееду жить в казахстан, стану таким же умным как ты. благо казахстан в 15 км от меня.

(92) Ты, кстати, планируешь свою нетленку все-таки превратить в полноценную платформу с возможностью допиливания функционала силами клиента? С такой шнягой наперевес вполне мог бы к нам на рынок залезть.

(93) нафига еще один глючный неповоротливый монстр? мало на рынке? я уже у вас лет десять.

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

(94) Ни у одного крупного игрока, с которыми я имею и имел дело, твоей нетленки не наблюдалось.

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

И с чего это твоя платформа будет глючным неповоротливым монстром? Таки не уверен в себе при разработке чего-то сложнее грида и плоской БД?

Что то много нытиков пошло. То это то там итд. И читайте посты еще раз внимательно.

Это о чем ? Я писал выше.
"А что ? Идея про гибридности может и сработает. Если есть онлайн остаок, то отлично. А если нет, то довольствуйся оффлайн остатком 10 минутной давности. Ну ни у всех же будут проблемы с онлайном. Так что - это снижает количество проблем связанные с постоянным оффлайн режимом."

А том что буду пользоваться только плюсами онлайна и оффлайна. Приложение мобильное. И все. Что не понятного.

Контора в норме. Мы уже 2 года пользуемся демо версией Агент+. И ничего справляються. Но он как раз таки и не динамичный софт.

(97) А+ допиливать можно под себя.

(96) крупные игроки, вернее их менеджеры осваивают бюджеты. осваивать бюджеты можно на любом авне.  авно не работает без поддержки в принципе, так как поддержка это тоже освоение бюджета, не меньше, а даже больше купленных лицензий. это каждый казахстанский школьник знает.

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

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

а шо такое "динамичный софт"? я не в курсе.

Тогда удались на фиг из темы. Выучи и вернись.

(99) Продолжай заниматься ларьками дальше, бог маркетинга.

(100) 1С не плохой софт. Мобильное приложение 1С - монструозный софт и все еще в процессе рождения, по сути. Но для твоих целей, в общем-то, пойдет, только нюансы заранее лучше проработать - на моей памяти там нужной функции определения координат тупо не оказалось, когда разработчик половину функционала вкорячил :) Т.е. какой-то мелочи ВНЕЗАПНО может не быть, а костылями вроде внешних скриптов в ведроиде не особо поиграешься.

Спасибо,  Маратыч.

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

Ты что курил ? Он доступен начиная с 8,3

1с купило половину+1 а+ (Боря старый еврей), чтобы а+ на платформе 1с сбацало им конфу, чтобы был успех...Боря думал, что все дело в конфе, а оказалось в движке.  но кто же знал :)

Оооо да. Конечно во всех наших бедах виноваты евреи. Как же я забыл.

1с - "динамичный софт"?

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

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

не видел ни одну серьезную контору, где учет ведется в 1с. или 1с не особо динамична, или серьезные конторы.

(113) >не видел ни одну серьезную контору

Этого достаточно %)

1с удел ларьков, не более. из-за своей "динамичности" не в состоянии работать с нормальными объемами данных.

марс серьезная контора? москва и подмосковье ходило на моем софте, покуда сдс рожал.

(116) То-то они к CDC и свалили в конечном итоге.

И я бы не стал на "Mars" ориентироваться, у них очень неповоротливая бюрократия из-за внешнего управления и соответствующих зарубежных стандартов. Наша "Кока-кола" тем же страдает.

дебилам десять раз очевидные вещи объяснять бесполезно. марс никуда не сваливал.

(119) Ага, и работают они не на "Оптимуме" уже не первый год.

Ты и с клиентами так разговариваешь?

Кароче, вали отсюда а ? Не фиг тут рекламировать  свой софт. Тема о другом. Нам лично не фиг нужен твой софт. Понятно ?

Тупо здесь говорить что хорошо, а что плохо. "Нормальным" компаниям и твой софт на фиг не нужен, если тем более 1С их не устраиввает. Они все сидят на SAP - е !

(120) На Оптимуме, будь он не ладен :)

(123) Да в курсе я, был причастен в Ате к сему процессу как раз в 2005-2006 годах :)

(100) дело не в 1с, а в требовании, что заказ должен быть обеспечен запасом.
Сидел в одно время на шоссе энтузиастов, бывало не то что 10 минут, по 2-3 часа мобильного интернета в районе не было, телефон звонил. Вы надеетесь на каналы связи, на текущий момент, развитие мобильного интернета не позволяет на него полагаться, архитектуру приложения надо разрабатывать с учетом того, что связи может не быть больше чем 10 минут.

palsergeich, 10 минут мы тут просто брали наминально. А так есть значит актуальны остатки. НЕт то, довольствуйся тем что есть.

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

Ты не тупой, ты просто баран ! Нехочешь видеть и читать внимательно. Повторяю 3-ий раз. Если есть связь , то берем актуальный остаток. Нет значит довольствуйся тем что есть в локальной базе.

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

...тяжело быть идиотом.

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

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