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

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

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

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

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

- 4 платежных термина;

- стационарную онлайн кассу;

- r-keeper;

- iiko;

- торговые кассы;

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

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

Платёжные терминалы, или POS-терминалы — это устройства для приема к оплате банковских карт. Все мы сталкиваемся с этой штукой хотя бы раз в день: когда идем в супермаркет, покупаем одежду или обедаем в ресторане.

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

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

Сами написали ТЗ

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

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

Когда специалисты двигаются «на ощупь», они рискуют допустить много ошибок, исправлять которые будет долго и дорого. Поэтому, если у клиента нет ТЗ, мы собираем и прописываем требования самостоятельно.

Дополнили документацию на POS-терминалы

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

Документация в программировании — это четкие и подробные текстовые материалы, которые объясняют, как работает программный код, библиотека, приложение или система. Это своего рода «инструкция по эксплуатации» для разработчиков, тестировщиков и других специалистов.

Зачем вообще это делать? Представьте: на проекте работает 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 проходила по похожему сценарию: 10 строчек ТЗ, ничего не понятно. Здесь мы тоже изучили предметную часть и расширили документацию.

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

Выписали десятикилограммовые весы из Новосибирска

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

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

Это сильно помогло бы клиенту загружать информацию о стоимости товаров из системы Prosklad напрямую в весы разных моделей.

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

Фанфакт о весах: они попали в кадр, когда местное телевидение снимало сюжет про нашу команду, — вот, посмотрите:

И всё это делали по T&M. Вот почему

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

Именно благодаря оплате по T&M клиент не платил за недели и месяцы простоев нашей команды, пока терминалы шли из Казахстана, а банки согласовывали интеграции. Оплачивались только часы активной работы — когда мы уточняли задачи, исследовали и кодили.

Почему ещё на этом проекте была выгодна оплата по T&M

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

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

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

Несмотря на сложности и расстояния интегрировали казахстанскую ERP-систему с платежными терминалами, iiKO, r-keeper и весами. Рады, что смогли помочь росту и развитию системы Prosklad!