Сказали «сделаем API-интеграцию» — как устроен процесс и чего ждут от нас?

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

Сразу зафиксируйте на бумаге, односторонняя интеграция или двусторонняя. Только заказы уходят с сайта в бухгалтерию, или остатки и цены со склада тоже должны перезаписываться обратно на сайт? При двустороннем обмене встают лимиты на запросы к API и обработка конфликтов, а это сразу растягивает разработку.

В прошлом году делали точно такую же интеграцию. Только выбивание API-лицензии и тестовых ключей у поставщика учетки заняло 9 дней. Сами разработчики отписали код за 12 дней, но из-за того, что доставка и скидки криво садились в проводки, тесты растянулись еще на 8 дней. В итоге на прод вышли ровно на 29-й день.

Чек-лист подготовки с вашей стороны: 1) Запросить у разработчиков бухгалтерии тестовую среду (sandbox) и доку. 2) Проговорить с бухгалтером и расписать регламент по отменам, возвратам и частичным доставкам. 3) До выкатки на прод прогнать минимум 15 разных сценариев тестовых заказов.

Ваша бухгалтерская программа облачная или стоит на локальном сервере у вас в офисе? Если она крутится на офисном компе понадобится статический IP и проброс портов на сервер. А это и дыра в безопасности, и если в офисе отрубится интернет, интеграция встанет; вы этот момент обсуждали?

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

edit: выше написал неправильно, извините.

Объедините команду разработчиков и техподдержку вашей бухгалтерской программы в общей почтовой рассылке или чате. Вы не обязаны разбираться в технических терминах и быть испорченным телефоном. Пусть технари напрямую сами между собой разбираются с параметрами и эндпоинтами.

На нашей первой интеграции мы зажали 12.000 TL за тестовую среду и тестили прямо на боевой базе. Программист выставил тестовый счет а реальному клиенту улетели e-arşiv fatura и SMS-уведомления. В тот день мы очень четко поняли что деньги за тестовый контур — это самая дешевая страховка.

Сохранил.

Ответ выше точно передал суть вопроса. Главное не цифра, а то, на основе чего она получена.

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

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

Интересно, есть ли те, кто делает иначе.

Поделюсь своим опытом. Доступы должны открываться на компанию, а не на личные аккаунты.

Оставлю как заметку, пригодится.

согласен.

Не упустите: Самое дешевое предложение обычно самое непродуманное.

Я бы пошел этим путем.

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

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

Хочу предупредить. Любой пункт, не зафиксированный письменно, в будущем обе стороны будут помнить по-разному.

Я бы пошел этим путем.

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

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

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

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