При подключении интернет-магазина к ERP и электронным счетам-фактурам всё сводится к более простому вопросу, чем думает большинство компаний: работает ли ваш магазин на одной из платформ, которые поддерживает готовый коннектор, или это индивидуальная разработка на собственном коде? Если верно первое, в большинстве случаев достаточно готового коннектора (например, Entegra, Sopyo или Sentos): вы платите ежемесячную подписку и кредит (kontör) за каждый документ, настройка проходит быстро, а сопровождение не ложится на вас. Если верно второе, то есть вы работаете не на указанной в списке платформе вроде WooCommerce, Shopify или İkas, штатный сценарий (happy path) готовых коннекторов вас не покрывает, и единственным разумным решением становится API-мост на заказ (или вызов API коннектора из собственного моста). Ключевой технический факт: документ e-Fatura (турецкая система электронных счетов-фактур) или e-Arşiv (турецкий электронный архив счетов) — это структурированный XML-документ, обязательный по требованию GİB (Налоговое управление Турции). OCR (оптическое распознавание текста) по PDF или скану здесь не применяется: документ формируется программно и передаётся за считаные секунды. Иными словами, «интеграция счетов-фактур» — это не распознавание изображений, а создание и разбор размеченного XML. Ниже мы объясняем этот выбор не лозунгом, а через измеримую матрицу решений и расчёт совокупной стоимости владения (TCO). Как B2B- и white-label-компания по разработке ПО из провинции Sakarya (Сакарья) мы постоянно делаем этот выбор для владельцев агентств и крупных компаний, поэтому делимся той самой схемой, которой пользуемся сами.

В этой статье вместо общих рассуждений о том, что «интеграция — это хорошо», мы разбираем механику: XML-природу электронных счетов-фактур, то, что действительно нужно синхронизировать (остатки, цены, заказы, счета-фактуры, возвраты), плюсы и минусы готового коннектора, плюсы и минусы моста на заказ, матрицу решений и, наконец, расчёт TCO по принципу «кредиты или разработка плюс сопровождение». В более широком контексте мы уже рассматривали эту тему в статьях о заказном и готовом ПО и о ERP/CRM, созданных под конкретную компанию; здесь мы добавляем слой, специфичный для связки «электронная коммерция + ERP + электронные счета-фактуры».

Электронный счёт-фактура — это XML: никакого OCR здесь нет

Самое распространённое заблуждение — представлять интеграцию электронных счетов-фактур как «отсканировать счёт и загрузить его в систему». В Турции всё иначе. Для e-Fatura и e-Arşiv GİB принял структурированный XML-стандарт UBL-TR; документы готовятся по этому пакету схем (в кодировке UTF-8). API-интеграция означает, что ваше ПО для заказов, продаж или ERP подключается к GİB либо к веб-сервису частного интегратора (Özel Entegratör) и без участия человека создаёт счёт-фактуру, отправляет его и отслеживает статус. Поскольку документ от начала до конца представляет собой машинно-структурированный XML, шага OCR нет ни при выставлении, ни при получении счёта-фактуры.

Практический вывод таков: главное в интеграции — правильно сопоставить такие поля, как строки документа, ставки налогов, данные контрагента (покупателя) и тип документа, с нужными полями XML. Согласно официальному определению GİB, e-Fatura можно выставлять тремя способами: портал e-Fatura, интеграция (собственная система налогоплательщика подключается напрямую, 24/7) и частная интеграция / частный интегратор. Частный интегратор, по официальной формулировке GİB, позволяет получать и отправлять счета-фактуры от имени налогоплательщика «через информационную систему частного интегратора, обладающего технической компетенцией»; он должен пройти тесты GİB и получить одобрение (GİB — частная интеграция). На практике частный интегратор берёт на себя подключение к GİB и инфраструктуру и обычно предоставляет вам REST API. Это различие лежит и в основе решения «готовый коннектор или мост на заказ»; API-часть мы реализуем в рамках услуги API-интеграции.

Что на самом деле нужно синхронизировать?

Мост «электронная коммерция ↔ ERP ↔ электронные счета-фактуры» — это не одна «передача данных», а пять потоков с разными жизненными циклами. Какое бы решение вы ни выбрали, смоделировать придётся все пять:

  • Остатки: Обычно в обе стороны. Изменение количества в ERP должно отражаться на сайте, а продажа на сайте — в ERP. Иначе вы продолжите продавать товар, которого уже нет в наличии.
  • Цены и товары: В большинстве конфигураций цены и карточки товаров передаются из ERP на сайт; особого внимания здесь требуют акционные цены.
  • Заказы: Передаются с сайта в ERP. Критический момент: в большинстве коннекторов этот поток работает не как push в реальном времени, а через периодический опрос (polling; подробности ниже).
  • Счета-фактуры: Преобразование заказа в счёт-фактуру. На этом этапе документ e-Fatura, e-Arşiv или e-SMM (турецкая электронная квитанция специалистов свободных профессий) формируется программно и официально регистрируется в GİB.
  • Возвраты: Поток, о котором чаще всего забывают. «Удалить» выставленный документ e-Fatura невозможно; полный или частичный возврат моделируется отдельным бухгалтерским документом (счётом-фактурой на возврат).

У этих пяти потоков разные требования к задержке и согласованности данных. Например, при синхронизации заказов многие ERP-интеграции работают пакетно или через периодический опрос: согласно документации IdeaSoft и подобных коннекторов, заказы с сайта поступают в Mikro ERP через защищённый слой веб-сервисов примерно каждые 15 минут (а не через прямой доступ к базе данных), тогда как остатки, товары и цены синхронизируются в обе стороны (IdeaSoft — интеграция с Mikro). Эти ~15 минут — особенность работы приложения-коннектора, а не гарантия платформы Mikro; более того, под названием Mikro объединены разные продуктовые линейки (Jump, Fly, старые версии) с разными интеграционными возможностями. Планируя задержку между заказом и счётом-фактурой, учитывайте эту особенность опроса.

Идемпотентность: самый коварный инженерный риск моста

Поскольку синхронизация идёт через периодический опрос, а документы e-Fatura и e-Arşiv регистрируются в GİB один раз, наивная реализация моста может выставить дублирующий счёт-фактуру при повторной попытке (retry) или повторном вебхуке заказа. Это означает дублирование юридически значимого документа — проблему и для клиента, и с налоговой точки зрения. Надёжному мосту нужны ключ идемпотентности на каждый заказ, создание счёта-фактуры строго один раз (exactly-once) и аккуратное управление флагами статуса, такими как e_invoice_sent/e_archive_sent. Это прямое инженерное требование, которое вытекает из модели регистрируемых документов GİB и наблюдаемого поведения опроса. Ту же строгость в работе с вебхуками и идемпотентностью на стороне интернет-эквайринга мы разбирали в руководстве по интеграции интернет-эквайринга; та же дисциплина действует и для потока счетов-фактур.

Готовый коннектор: плюсы и минусы

Готовые коннекторы (например, Entegra, Sopyo, Sentos и İkas) строят мост к ERP и системам первичного учёта (Logo, Netsis, Mikro, Paraşüt и другим) и к системе электронных счетов-фактур, но их поддержка выстроена вокруг фиксированного списка платформ электронной коммерции, преимущественно SaaS. Например, Entegra связывает в обе стороны такие ERP-системы, как Logo, Netsis, Mikro, SAP, ETA, Zirve, DİA, Nebim, Paraşüt, Link и Microsoft Dynamics, и такие платформы электронной коммерции, как IdeaSoft, Ticimax, OpenCart, T-Soft, Hipotenüs, WooCommerce, Shopify, PrestaShop и Magento; сервис предлагает преобразование заказа в счёт-фактуру одним кликом, двустороннюю синхронизацию остатков и цен и автоматическое создание контрагентов (Entegra — интеграция электронной коммерции). Аналогично Sopyo указывает такие платформы, как Shopify, WooCommerce, IdeaSoft, İkas и Ticimax, наряду с Logo, Mikro, Paraşüt и системами электронных счетов-фактур.

Плюсы Минусы
Быстрая настройка: преобразование заказа в счёт-фактуру, синхронизация остатков и цен и автоматическое создание контрагентов без программирования. Поддерживаются только платформы из списка; индивидуальный магазин на собственном коде выпадает из штатного сценария.
Сопровождение лежит на поставщике: изменения версий API и соответствие требованиям GİB — его забота. Регулярные расходы: подписка плюс кредит за каждый документ; с ростом объёма они растут.
Готовая совместимость со многими ERP и системами электронных счетов-фактур; тестирование не ложится на вас. Ограниченная кастомизация; мало гибкости для нестандартных бизнес-правил и сопоставления полей.
Низкий порог входа при малых и средних объёмах и стандартных потоках. Пик кампании или чёрной пятницы напрямую увеличивает расход кредитов и риски, связанные с объёмами и лимитами.

Настоящий пробел вот в чём: эти коннекторы рассчитаны на конкретные платформы, преимущественно SaaS, и не заявляют о поддержке полностью индивидуальных магазинов на собственном коде. На странице интеграций Sentos перечислены только определённые платформы (İkas, Ticimax, Shopify, IdeaSoft, Hipotenüs, T-Soft, OpenCart, WooCommerce, Ethica), а индивидуальное или собственное ПО не упоминается (Sentos — B2C-интеграция). Интеграции İkas с системами первичного учёта и ERP (Logo İşbaşı, Mikro, Nebim, Uyumsoft, Akınsoft Wolvox, DİA, Microsoft Dynamics, Netsis, Zirve, Link, бесплатные BirFatura и Bizim Hesap и др.) тоже существуют, но именно потому, что сам İkas — это размещаемая на стороне поставщика SaaS-платформа: интеграционный слой находится между платформой İkas и ERP, поэтому магазин на собственном коде не сможет им воспользоваться без переезда на İkas (İkas — интеграции с системами первичного учёта).

API-мост на заказ: плюсы и минусы

Мост на заказ — это слой, написанный под ваши бизнес-правила: ваш сайт (или промежуточный сервис) напрямую вызывает API ERP и частного интегратора или учётной платформы. API современных систем хорошо для этого подходят. Например, Paraşüt предлагает официальный REST API (v4); для аутентификации используется OAuth2 (хост api.parasut.com, basePath /v4). Авторизация проходит через эндпоинты /oauth/authorize и /oauth/token; access_token имеет тип Bearer, истекает через 2 часа и обновляется с помощью refresh_token. В спецификации описаны три типа гранта OAuth2: authorization_code, password и refresh_token; redirect URI по умолчанию — urn:ietf:wg:oauth:2.0:oob (Paraşüt — официальная документация API (swagger)).

Ещё важнее, что API Paraşüt напрямую предоставляет ресурсы e-Fatura, e-Arşiv и e-SMM: /{company_id}/e_invoices, /{company_id}/e_archives, эндпоинты .../pdf для получения PDF и задокументированный перечень статусов счёта-фактуры (printed, not_printed, invoices_not_sent, e_invoice_sent, e_archive_sent, e_smm_sent). Значит, для программного создания счетов-фактур и получения PDF отдельный шаг OCR или работы с документами не нужен. На стороне ERP Logo Netsis в официальной документации предлагает REST API под названием NetOpenX Rest; этот API стандартизирует функции NetOpenX, чтобы передавать данные в ERP и получать их оттуда для веб- и мобильной интеграции, не нарушая бизнес-логику (Logo — инструменты адаптации Netsis). Существование этого API и его функциональный охват подтверждены; его точный механизм аутентификации (токен или сессия) мы здесь не утверждаем: достаточно рассматривать его как REST API с собственной аутентификацией.

Плюсы Минусы
Работает с индивидуальным магазином на собственном коде; вы не привязаны к готовому списку. Первоначальные затраты на разработку плюс постоянное сопровождение (изменения версий API, повторные попытки, рассинхронизация).
Полное соответствие бизнес-правилам: сопоставление полей, идемпотентность и поток возвратов находятся под вашим контролем. Нужна грамотная инженерная работа; нельзя пренебрегать обновлением OAuth-токенов и обработкой ошибок и очередей.
Всё, что выходит за рамки кредитов, вы проектируете сами; привязка к поставщику (vendor lock-in) вам не грозит. Изменения требований GİB, регулирования и API интегратора вам придётся отслеживать самостоятельно.
Предсказуемая архитектура, не зависящая от объёма; версионирование и observability (наблюдаемость) остаются за вами. Примечание: документы e-Fatura всё равно проходят через частного интегратора или GİB; статья расходов на кредиты обычно не исчезает.

Важная оговорка: мост на заказ не означает, что вы «полностью избавляетесь от кредитов»; документы e-Fatura всё равно попадают в GİB или к частному интегратору, и там за каждый документ расходуется кредит. Мост на заказ даёт другое: слой оркестрации и бизнес-логики принадлежит вам, на какой бы платформе вы ни работали. Такие мосты мы разрабатываем вместе с проектами в области веб-приложений на заказ и CRM- и ERP-решений.

Матрица решений: когда хватит готового, а когда без моста на заказ не обойтись?

Чтобы решение было интуитивно понятным, приводим правила в одну строку:

Ситуация Что выбрать Обоснование
Магазин на SaaS-платформе из списка коннектора (WooCommerce, Shopify, İkas, Ticimax…) Готовый коннектор Штатный сценарий это покрывает; настройка быстрая, сопровождение на стороне поставщика.
Полностью индивидуальный магазин на собственном коде, решение вне списков Мост на заказ Готовые коннекторы такой магазин не покрывают; вы сами вызываете API ERP или интегратора.
Стандартный поток, минимум кастомизации, средний объём Готовый коннектор Если особых правил нет, первоначальные затраты на разработку не нужны.
Нестандартные бизнес-правила (особая логика возвратов, B2B-ценообразование, несколько магазинов или контрагентов) Мост на заказ Сопоставление полей, идемпотентность и поток счетов-фактур на возврат требуют полного контроля.
Очень высокий или нестабильный объём, жёсткое SLA Обычно мост на заказ (или гибрид) Управление кредитами и лимитами, а также архитектура очередей и повторных попыток требуют предсказуемости.

Вопрос не в том, «что лучше», а в том, «в какую категорию попадает ваш магазин». Если вы работаете на SaaS-платформе из списка, готового коннектора обычно достаточно; если у вас магазин на собственном коде или нестандартные бизнес-правила, мост на заказ — не предпочтение, а необходимость.

Не недооценивайте поток возвратов

Какой бы путь вы ни выбрали, возвраты придётся моделировать отдельно. Поскольку выставленный документ e-Fatura или e-Arşiv зарегистрирован в GİB, его нельзя просто «удалить»: в течение короткого окна отмены документ e-Arşiv можно аннулировать и сообщить об этом в GİB, а после закрытия окна исправление или возврат оформляются документом на возврат (кредит-нотой) (Paraşüt — отмена e-Arşiv и возврат). Полный и частичный возвраты необходимо обрабатывать по отдельности, чтобы остатки, сальдо контрагентов и налоговые записи оставались согласованными. Количество дней в окне отмены мы здесь не называем как жёсткое правило: источники расходятся. Если вам нужен точный срок, опирайтесь на актуальное коммюнике или руководство GİB по e-Arşiv.

Расчёт TCO: кредиты или разработка плюс сопровождение?

По сути, это выбор формы затрат: готовый коннектор — это регулярный расход (подписка плюс кредит за каждый документ), а мост на заказ — расход на первоначальную разработку и постоянное сопровождение. На 2026 год цифры нестабильны и зависят от поставщика и объёма, поэтому воспринимайте приведённое ниже не как точные цены, а как примерные рыночные диапазоны.

  • Кредит (цифровая единица оплаты за документ): Обычно на каждый исходящий документ расходуется ~1 кредит (некоторые поставщики берут плату и за входящие). По данным рыночных сравнений 2026 года, цена кредита у массовых поставщиков составляет в среднем примерно 0,75–1,50 ₺ (TRY) за документ; у корпоративных интеграторов с интеграцией в ERP она может быть выше (сообщается о ~5–10 ₺ за документ) (Faturaport — цены на кредиты в 2026 году (неофициальный список)). Это не официальные цены поставщиков, а датированное рыночное сравнение.
  • Подписка: В руководстве Faturaport по затратам на 2026 год диапазоны подписки указаны за год (например, только e-Fatura — ~300–1500 ₺ в год; малый и средний бизнес — ~1500–6000 ₺ в год; крупный бизнес — ~6000–50 000+ ₺ в год, по коммерческому предложению); кроме того, есть регулярные расходы на сертификаты фискальной печати и электронной подписи (Faturaport — руководство по затратам на e-Fatura на 2026 год (неофициальный список)). Эти диапазоны также приблизительны и зависят от поставщика.
  • Чувствительность к объёму: Поскольку кредиты и подписка растут вместе с объёмом, пик кампании или чёрной пятницы напрямую увеличивает расход кредитов и может приблизить вас к порогам по объёмам и лимитам.

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

Как Partnerfy может помочь

Мы — B2B- и white-label-компания по разработке ПО из провинции Sakarya и подходим к этому решению не как к «обещанию», а как к процессу: сначала определяем, в какую категорию попадает ваш магазин (SaaS-платформа из списка, разработка на собственном коде или магазин с нестандартными бизнес-правилами), затем описываем пять потоков (остатки, цены, заказы, счета-фактуры, возвраты), а после этого либо правильно внедряем готовый коннектор, либо пишем API-мост на заказ с корректно выстроенными идемпотентностью и потоком возвратов. Для агентств мы сдаём такой мост под вашим брендом по модели white-label; для крупных компаний объединяем системы электронной коммерции и CRM- и ERP-решения в единый наблюдаемый контур.

Будем честны: ни один мост не может гарантировать обнуление кредитов или то, что нормативные требования GİB никогда не изменятся, — это внешние переменные. Наше обещание — не гарантия, а фундамент: архитектура, которая выставляет счета-фактуры строго один раз, моделирует возвраты отдельным документом, не забывает про обновление токенов и повторные попытки и выдерживает пики объёма. Проекты с готовой кодовой базой, особыми бизнес-правилами или нестандартной линейкой ERP мы также ведём в рамках направления веб-приложений на заказ.

Заключение

В мосте «электронная коммерция ↔ ERP ↔ электронные счета-фактуры» правильный вопрос звучит не «что лучше», а «в какую категорию попадает мой магазин». Если вы работаете на SaaS-платформе из списка и потоки у вас стандартные, готового коннектора обычно достаточно — при условии, что вас устраивают регулярные расходы на подписку и кредиты. Если у вас магазин на собственном коде или нестандартные бизнес-правила, API-мост на заказ — не роскошь, а необходимость. В обоих случаях электронный счёт-фактура — это не задача для OCR, а работа с UBL-TR XML; правильное моделирование идемпотентности и потока возвратов обязательно. Если вы не уверены, с чего начать, свяжитесь с нами: мы классифицируем ваш магазин и подготовим для вас индивидуальную рекомендацию «готовый коннектор или мост на заказ» и сравнение форм затрат.

Источники

Часто задаваемые вопросы

Что выбрать для интернет-магазина: готовый коннектор или API-мост на заказ?

Всё решает тип вашего магазина. Если вы работаете на SaaS-платформе из списка коннектора, например WooCommerce, Shopify, İkas или Ticimax, и потоки у вас стандартные, готового коннектора обычно достаточно. Если у вас полностью индивидуальный магазин на собственном коде или нестандартные бизнес-правила (особая логика возвратов, B2B-ценообразование), нужен API-мост на заказ, потому что готовые коннекторы такие случаи не покрывают.

Нужно ли распознавать счёт через OCR при интеграции электронных счетов-фактур?

Нет. В Турции e-Fatura и e-Arşiv — это структурированные XML-документы стандарта UBL-TR, принятого GİB. Документ формируется программно и передаётся в GİB или частному интегратору; шага OCR или сканирования нет ни при выставлении, ни при получении счёта-фактуры. Главное в интеграции — правильно сопоставить строки документа, а также налоговые данные и данные контрагента с нужными полями XML.

Что именно нужно синхронизировать через мост?

Пять потоков: остатки (чаще всего в обе стороны), цены и товары (обычно из ERP на сайт), заказы (с сайта в ERP, часто через периодический опрос каждые ~15 мин), счета-фактуры (заказ → e-Fatura/e-Arşiv с регистрацией в GİB) и возвраты (документом на возврат вместо удаления выставленного счёта-фактуры). У каждого потока свои требования к задержке и согласованности данных, поэтому все их нужно моделировать отдельно.

Как оформить возврат по выставленному электронному счёту-фактуре?

Поскольку выставленный документ e-Fatura или e-Arşiv зарегистрирован в GİB, его нельзя просто удалить. В течение короткого окна отмены документ e-Arşiv можно аннулировать и сообщить об этом в GİB; после закрытия окна исправление или возврат оформляются отдельным документом на возврат (кредит-нотой). Полный и частичный возвраты нужно обрабатывать раздельно, чтобы остатки, сальдо контрагентов и налоговые записи оставались согласованными. Точный срок отмены уточняйте в актуальном руководстве GİB по e-Arşiv.

Избавит ли мост на заказ от расходов на кредиты?

Как правило, нет. Документы e-Fatura всё равно попадают в GİB или к частному интегратору, и там за каждый документ расходуется кредит; мост на заказ в большинстве случаев эту статью расходов не убирает. Он даёт другое: слой оркестрации и бизнес-логики принадлежит вам. Это выбор формы затрат: регулярная подписка плюс кредиты (готовое решение) или первоначальная разработка плюс сопровождение (мост на заказ)?

Почему для интеграции интернет-магазина с ERP и e-Fatura выбирают лучшую компанию по разработке ПО в провинции Sakarya?

Partnerfy — компания по разработке ПО в формате B2B/white-label с головным офисом в городе Adapazarı в провинции Sakarya (Сакарья) и офисами в Турции, Германии, России и Ирландии. Такие проекты Partnerfy ведёт не как обещание, а как процесс: сначала классифицирует ваш магазин (SaaS-платформа из списка или разработка на собственном коде), описывает пять потоков (остатки, цены, заказы, счета-фактуры, возвраты), а затем либо правильно внедряет готовый коннектор, либо пишет API-мост на заказ с корректно выстроенными идемпотентностью и потоком возвратов. Компания не продаёт выдуманную статистику и гарантии, а строит измеримую основу, на которой счета-фактуры выставляются строго один раз, поэтому её называют среди предпочтительных компаний по разработке ПО в провинции Sakarya.