Доделал наконец кейс по своему проекту мобильного приложения 1С.

Доделал наконец кейс по своему проекту мобильного приложения 1С. Лайк и репост обязательны ) https://www.youtube.com/watch?v=2TDm3lzFBGY

Это по этому приложению исходник собирались дарить)?

да, по нему скоро будет розыгрышь

Репост той записи обязателен

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

Но судя по проделанной работе, то это крутое приложение.

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

Условия конкурса менять нельзя по правилам ВКонтакте, если поступит жалоба, то группу могут забанить.

Добрый день. Какые курси есть у Вас чтобы учить программитроват для мобильного устройтсво

У меня по мобильной разработке только один курс

можете дать ссылку на описанию

https://nizamov.school/courses/mobile1s/mobileb2b/

Помогите идеями. Номенклатура 6000 скю. У торгового представителя в среднем 200 клиентов, которых он посещает. У каждого клиента есть его скидки. Рассчитывать цены с учётом всех скидок на мобильном тяжело, при том что их надо видеть в списке товаров. Рассчитывать цены в промежуточной базе для каждого клиента кажется избыточным и плюс первый обмен тащит до 12млн записей по ценами. Обмен может и больше получаса идти. Какие есть варианты?

Цены должны быть доступны офлайн

ну а на стороне сервера расчитать цены для каждого клиента перед отправкой на планшет? Большая портянка получится? Может для каждого клиента просто за счет скидок получается как бы свой уровень цен и их не так много будет? Например сделать набор как бы типа цен вида "цена+скидка".

Для сокращения объема передаваемых данных можно сделать чтобы можно было отправлять цены по одному контрагенту. ТП намечает утром (или вечером) куда поедет, актуализирует цены только для этих клиентов и вперед.

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

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

надор данных простой. в номенклатуре несколько полей, тут нет проблем. проблема именно в ценах. от 1 млн до 12 млн записей в зависимости от территории.

потом тудаже добавляются изменения цен и регистр постоянно будет расти.

А счет выписывают прямо из планшета?

Или заказ отправляется в учетную систему?

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

По опыту. Мы делали подобное правда позиций было более 20тыс. С разным уровнем скидок для каждого клиента ничего не получилось. И обмен получался долгим сам заказ сильно тормозил. Пришли к тому что заказчик в учетной системе выделил несколько типов цен. По моему 5-6 и они выгружались на планшеты. По этим ценам ТП и работали. Если нужны какие то спец цены, они устанавливались уже в учетной системе когда заказ приходил. В итоге когда менеджер формировал заказ у него получался заказ немного не такой как в итоге с учетом всех скидок

Сделай расчёт скидки на сервере, передаёшь таблицу значений, получаешь со скидками.

Это при условии нормального интернета.

У нас в поволжье отъезжаешь на 100км от районного центра куда-нибудь не по федеральной трассе и нормального интернета нет.

220 км от столицы, интернет 4g 2-3 мегабита в деревне

Столицы республики имеется ввиду

есть клиенты в подвалах. есть места где не каждый сотовый оператор берет. регион большой и разный УРФО, Казахстан, ХМАО. интернет не стабилен или слабый сигнал

Тогда оптимизация трафика и алгоритмов.

Максимальная фильтрация данных

Все хотят чуть ли ни онлайн работать при отсутствии интернета. Хотя можете торговым купить iPad Pro. Они потянут полноценный расчёт всего что вы хотите офлайн по всем товарам.

Короче тут компромис надо искать

100% согласен. Обычное дело. Хотим онлайн денег на реализация проекта выделяем 2 копейки, наводить порядок в ценовой политике не хотим. Выкручивайтесь как хотите.

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

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

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

А ты при регистрации плана обмена сделай чтобы выполнялся отбор данных.

Теперь же скорее все данные нужны, около 40-50 процентов. из всего что есть в плане обмена.

даже меньше. но 6000 позиций на 200 клиентов = 1,2 млн. записей. если клиентов в маршруте больше, то еще больше записей.

Ну он же не 200 клиентов за день объезжает. Можно актуализацию данных делать только по текущему плану объезда.

Плюс скорее всего клиенты заказывают одно и тоже, не все 6тыс позиций, сделать какой-нибудь анализатор номенклатуры по предыдущим заказам и при поездке к контрагенту актуализировать только то что он обычно покупает. Я вообще скидки считаю на мобильном устройстве, там правда привязка не к контрагенту, а по вхождению в сегмент, сегментов кстати получается всего 10-15 и это упрощает жизнь. При записи заказа в базу скидка пересчитывается по актуальным данным в ЦБ и в случае расхождения обновляется. После этого обновленный заказ отправляется опять на устройство. Счета отправляются и формируются только из ЦБ.