Развиваем аналог российской 1С для Казахстана. Кейс Prosklad

Интегрировали казахстанскую ERP-систему с платежными терминалами, iiKO, r-keeper и весами. А еще долго боролись с документацией и помогли компании Prosklad выйти на новых клиентов.

Привет! Это «Софториум» — команда из Сибири с хард-подходом к разработке. Мы пишем код с нуля и работаем с легаси-проектами, чтобы помочь компаниям, у которых горят сроки или не хватает специалистов инхаус.

Мы сотрудничали с отечественными SOKOLOV, Nolim, InnTravel, «Неофармом», «Столичками». А с проектом Prosklad укрепились и на рынке Казахстана.

Prosklad — IT-компания из Алматы, которая помогает бизнесу автоматизировать складской учет. Их главный продукт — ERP-система, которая контролирует товарооборот и показывает статистику продаж. Совсем как наша 1C — только казахстанская.

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

Большая цель Prosklad — проникнуть в максимальное количество отраслей, чтобы выйти на новых клиентов и обороты. Начать клиент решил с ресторанов.

Чтобы их ERP-система стала удобной для общепита, к уже существующей функциональности нужно было подключить:

Каждая интеграция — отдельное приключение, о котором мы подробно расскажем. Располагайтесь поудобнее.

Первой нашей задачей стала интеграция платёжных терминалов с системой Prosklad и казахстанскими банками.

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

Со всеми международными доставками, таможней, на которой посылки периодически «застревали», работы затянулись на девять месяцев. Так как сроки не резиновые, параллельно мы решали другие задачи.

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

В ТЗ должны быть описаны все важные требования к системе: если не обозначить, что там-то должна быть такая-то кнопка, её и не будет. А если не продумать, какие ошибки могут возникнуть в будущем, то позднее система отвалится в любой момент.

Да, в идеальном мире полную информацию об устройствах можно найти на сайте производителя на всех языках мира. Но документация была не полная или отсутствовала, поэтому мы сели дописывать её.

Зачем вообще это делать? Представьте: на проекте работает 10 программистов. Чтобы каждому досконально разобраться в коде, нащупать его слабые места и не допустить ошибок, нужно потратить десятки часов. Проще один раз разобраться и отдать готовую инструкцию всей команде — чтобы каждый сотрудник приступил к основной задаче сразу.

Кому-то может показаться, что это лишние телодвижения и дополнительные траты. Но не будь этого процесса — проект затянулся бы еще на год-полтора, а сотрудники потратили бы месяцы, чтобы изобрести велосипед.

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

К тому же, чтобы подключить терминалы к процессинговому центру — «сердцу» банковской системы, — нужно было перепрошить устройства. Некоторые банки могли это сделать удаленно, но это занимало очень много времени. А другие и вовсе отказались нам помогать, предложив переслать терминалы обратно в Казахстан, чтобы там их и обновить.

Итог: два месяца переговоров и согласований — и мы завели платежи в систему. Подключили к Forte Bank, Halyk Bank и Jusan Bank 4 POS-терминала:

Стационарная касса — звучит как что-то ультрамассивное. Но на самом деле, это такой планшет на Android с надстройкой в виде платёжного терминала и принтера для чеков. Касса не очень большая, но и в одной руке её не удержишь. Выглядит она так:

У кассы есть приложение на Android. Нам нужно было доработать его, чтобы подготовить фундамент для дальнейших интеграций кассы с бэкендом, торговыми весами, платёжными терминалами и сторонними сервисами. Вроде не сложно, но и здесь возникли проблемы с документацией.

Мобильное приложение для кассового оборудования можно было интегрировать только с 3-мя моделями платежных терминалов из 4-х. Пока мы пытались адаптировать программное обеспечение терминала-аутсайдера, выяснилось, что между технической документацией и фактической архитектурой кассы есть расхождения. Внутрянка кассы написана на Flutter, сама интеграция — на Kotlin, а документация по интеграции и примеры использования библиотек — на Java.

Трудности перевода познавали втроём: чтобы понять логику работы библиотек, мы задавали вопросы клиенту, а он — поставщику терминалов.

Мы не знали, какие параметры передавать. Например, не были описаны параметры, которые нужны для отмены/возврата денежных средств. После того, как мы их определили, документация дополнилась дважды. И новые правки не соответствовали действительности. Например, было указано, что нужно подставлять параметр fIDt (без описания, что это за параметр), который возвращается после успешной оплаты. По факту, этот параметр всегда был пустой, а по словам специалиста банка, вообще был не нужен.

Не было возможности работать с оборудованием напрямую. Касса, которую нам прислали, была неправильно настроена, а тестовая карта, идущая в комплекте, не работала. Если с терминалами банки пошли нам навстречу, и помогли настроить их удалённо, то с кассой отказались делать это. Но решение всё-таки нашли — клиент заказал ещё одну кассу к себе в офис и подключился к нам удалённо через AnyDesk.

Оказалось, что доступ к репозиторию был временным. Репозиторий — «место», где хранится код для совместной работы. Когда нам понадобилось обратиться к нему, мы обнаружили, что срок действия доступа истёк. Мы долго запрашивали его снова, но безрезультатно. Это затруднило перенос наших наработок на тестовый стенд клиента.

Кассу всё-таки настроили и перешли к внедрению систем автоматизации общепита.

Iiko и r_keeper — это системы автоматизации работы ресторанов. Через них официанты принимают заказы и отдают их на кухню. Или, например, бронируют столики для гостей. Как уже говорили выше, Prosklad заказал у нас интеграции с ними, чтобы охватить новый сегмент рынка.

Сложности возникли, когда нужно было использовать лицензионное ПО. Пришлось связаться с дилерами r_keeper и iiko, чтобы они предоставили тестовые лицензии для работы. С другой стороны — мы пошли просить клиента, чтобы он выделил нам отдельный сервер, на который мы могли бы установить софт. Достучались и до тех, и до тех.

Речь о тех самых весах, которые стоят в супермаркетах. Их киллерфича — обращать граммы в рубли: ты кладёшь на них товар, а они показывают, сколько он стоит.

Нам нужно было интегрировать с Prosklad три модели весов: ШТРИХ-ПРИНТ М, Rongta RLS 1000/1100 и Масса-К. У каждой модели — свои драйвера, команды и системы измерения. Поэтому нам нужно было реализовать сервис для интеграции, который бы обрабатывал разные вводные, приводил их к общему знаменателю и выводил бы в интерфейс Prosklad.

Повторить трюк с удалённым подключением с весами было нельзя, поэтому каждую из моделей клиент прислал к нам в офис. Но чтобы не тратить кучу ресурсов на доставку из Казахстана, проджект-менеджер Prosklad отыскала точно такое же оборудование в Новосибирске и сэкономила на логистике. Мелочь, а приятно.

На самом деле, цель благая — не разорить клиента. Если вы дочитали до этого момента, то поняли, сколько простоев здесь было. Модель оплаты Time&Materials (T&M) как раз и предполагает, что точный объём работ на проекте сложно определить, поэтому клиент оплачивает время, затраченное специалистами, постфактум: сколько часов отработали — на такую сумму и получили счет.

Помните, что было с ТЗ? Во время работы у нас то и дело появлялись новые вводные по проекту, которые на старте мы просто не могли предусмотреть. На фиксе пришлось бы пересматривать бюджет и заново согласовывать смету — на T&M мы фиксировали часы и получали оплату за выполненные задачи.

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

А вот такой мы получили отзыв заказчика:

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

К слову, общительны мы не только на проектах. Недавно завели тг-канал, чтобы рассказывать про ребрендинг, новое позиционирование и работу с топами рынка. Подписывайтесь — будем рады с вами поболтать!

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