Своя CRM для инженерной компании: как мы вдвое сократили цикл сделки

[nurix]

Пункт про OData без $orderby прямо узнал. У меня в боте похожее было с рассылкой: обычная постраничная выборка тихо теряла получателей, потому что рассылка сама меняла статусы пользователей и список сдвигался. Никаких ошибок, всё "сходится", просто часть людей ничего не получила. Вылечил курсором по id. Так что совет сверять уникальные ключи, а не число строк, очень в тему.

По гонке на остатках: а не рассматривали атомарный UPDATE вместо FOR UPDATE? Что-то вроде UPDATE stock SET qty = qty - :n WHERE id = :id AND qty >= :n и проверка, что затронута одна строка. Читать перед записью вообще не нужно, и блокировка держится минимально. Хотя если перед списанием там ещё какая-то логика, то FOR UPDATE, наверное, честнее.

И вопрос про пуши: раз в минуту собирать "Мой день" для каждого сотрудника не тяжело по базе? Или при 12 ролях и небольшом штате это вообще незаметно, и о событийной модели думать рано?

[Nurikenov]

Спасибо, хороший пример, и ваш случай даже коварнее. У нас в 1С данные во время чтения не менялись, просто без $orderby нет порядка. У вас список уезжал из-под курсора, а тут сортировка не спасёт, только курсор. Мы сами, кстати, всё ещё читаем через $skip. Удаление в 1С посреди прохода даст пропуск, правда только до следующего прохода. Попробуем курсор по Ref_Key.

[EkaterinaKrp]

А почему отказались оптимизировать CRM в текущей архитектуре?

У меня был похожий проект (по условиям), но мы хорошо проработали лиды и воронку в Б24, завязали бизнес-процессы (по созданию и согласованию договоров с запуском согласований в 1С:ДО) внутри воронки, определенные события в воронке запускали интеграцию с 1С:ERP, а оттуда уже тащили документы и статусы производства в т.ч., которые двигали воронку + также автоматом отправляли все менеджерам и клиентам.

[Nurikenov]

Ваша схема рабочая, и для вашего случая правильная. Разница в том, что у вас была 1С:ERP: спецификации, производство и его статусы жили там, а Б24 был лицом к клиенту и менеджеру. Воронку двигали документы из ERP.

У нас 1С бухгалтерская, производственного контура в ней нет. Расчёт узла под этаж, его состав до фитинга, потребность снабжения по деталям, резервы под договор, отгрузки партиями по графику — всему этому не было места ни в Б24, ни в нашей 1С. Калькулятор и так уже был отдельным самописным приложением. Так что выбор был не «допилить Б24 или написать своё», а куда положить калькулятор, спецификацию, закуп и склад. Альтернатива своей базе — внедрять ERP. Это отдельный большой проект, и калькулятор под наши узлы пришлось бы писать всё равно.

В Б24 это класть не стали. Роботы и смарт-процессы хорошо двигают стадии и запускают согласования. Но нам нужен замороженный снимок расчёта на тысячи строк, из которого читают КП, закуп и сборка, и остатки, которые нельзя списать дважды. Держать такое ядро в чужой системе мы не захотели.

А вот уведомления о передачах в Б24 сделать можно даже нужно но из Б24 мы уходим поэтапно, а не рывком.