Интеграции

Обычно решает банк. Host-to-host SFTP — самый распространённый канал для корпоративных платёжных файлов. EBICS распространён у банков в Германии, Франции и соседних странах. Банковские API подходят для балансов в реальном времени и мгновенных платежей там, где банк их предлагает. Многие компании используют несколько каналов, а интеграционный слой скрывает разницу от ERP.

Подробнее: Платёжные файлы и сверка между ERP и банкомСсылка на этот вопрос

Там, где банк предлагает оба формата, camt.053 содержит более богатые структурированные данные о назначении платежа, что делает автоматическое сопоставление надёжнее. MT940 по-прежнему широко используется и хорошо работает во многих случаях. Мы принимаем оба, приводим их к единой внутренней модели и переводим каждый банк с MT940 на camt.053, когда это удобно вам и банку.

Подробнее: Платёжные файлы и сверка между ERP и банкомСсылка на этот вопрос

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

Подробнее: Синхронизация продаж, запасов и цен между POS и ERPСсылка на этот вопрос

Схема работает с любой POS, которая может выгружать транзакции через API, события или файлы, и с ERP, такими как SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central и Odoo. Интерфейсы вашей конкретной POS и ERP мы подтверждаем в начале. Упоминание продукта не означает партнёрства с его поставщиком.

Подробнее: Синхронизация продаж, запасов и цен между POS и ERPСсылка на этот вопрос

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

Подробнее: Карточные платежиСсылка на этот вопрос

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

Подробнее: Карточные платежиСсылка на этот вопрос

Агрегатор даёт доступ ко многим банкам через один API и берёт на себя различия между ними — за плату за вызов или подключение. Прямые подключения дают больше контроля и могут подойти для небольшого числа важных банков. Многие продукты начинают с агрегатора и позже добавляют прямые подключения. Мы сравниваем варианты применительно к нужным вам банкам и странам.

Подробнее: API открытого банкингаСсылка на этот вопрос

Охват зависит от правил региона и API банков. В Европейском союзе и Великобритании охват широкий благодаря PSD2 и UK Open Banking Standard. В других регионах охват различается, и агрегаторы закрывают часть пробелов. Перед принятием решения о схеме мы проверяем охват для банков, которыми пользуются ваши клиенты.

Подробнее: API открытого банкингаСсылка на этот вопрос

Для большинства задач корпоративного казначейства — нет. Каналы host-to-host обрабатывают пакетные платёжные файлы и полные выписки по вашим собственным счетам. Открытый банкинг подходит для клиентских продуктов, балансов в реальном времени и отдельных платежей. Многие компании используют и то и другое: host-to-host для собственных платёжных реестров и открытый банкинг для своих клиентов.

Подробнее: API открытого банкингаСсылка на этот вопрос

Любой сервис с документированным API или файловым интерфейсом. Типичные примеры: CRM-платформы, перевозчики и логистические провайдеры, маркетплейсы, платформы электронных счетов и налогов, расчёт зарплаты, поставщики KYC и идентификации, а также торговые партнёры, обменивающиеся документами EDI поверх AS2. Перед обязательством по плану мы изучаем API, лимиты и тестовую среду каждого партнёра.

Подробнее: Подключение ERP к API третьих сторонСсылка на этот вопрос

Когда к одной ERP подключено несколько партнёров, платформа вроде MuleSoft, Boomi или Azure Logic Apps либо набор собственных сервисов на базе очереди сообщений держит маппинг, повторы и мониторинг в одном месте. При одном-двух партнёрах может хватить прямых подключений. Мы изложим компромиссы, включая стоимость лицензий, для вашего случая.

Подробнее: Подключение ERP к API третьих сторонСсылка на этот вопрос

Со стороны ERP: SAP ECC, S/4HANA и BTP, Oracle Fusion Cloud ERP и NetSuite, Microsoft Dynamics 365, Odoo и Sage. Для процессов и CRM: ServiceNow, Salesforce и Microsoft Power Platform. Мы также работаем с заказными и более старыми системами. Упоминание продукта не означает партнёрства с его поставщиком.

Подробнее: Внедрение и синхронизация ERP и CRMСсылка на этот вопрос

Да. Мы инвентаризируем каждый интерфейс на ECC, решаем, какие сохранить, перестроить или вывести из эксплуатации, и переносим каждый в S/4HANA или BTP вместе с тестами. Потоки переключаются по одному, поэтому бизнес не зависит от одного переключения за выходные.

Подробнее: Внедрение и синхронизация ERP и CRMСсылка на этот вопрос

Не всегда. Несколько стабильных потоков между двумя системами могут быть прямыми вызовами API. Когда несколько систем обмениваются данными или нужны сопоставление, очереди и мониторинг в одном месте, промежуточное ПО обычно окупается. Если оно у вас уже есть, мы строим на нём.

Подробнее: Внедрение и синхронизация ERP и CRMСсылка на этот вопрос

Выбирайте ту, которая подходит вашим процессам, интеграциям и пользователям. Мы сравниваем варианты с вашими требованиями, существующими лицензиями и системами, к которым CRM должна подключаться, и излагаем компромиссы письменно. Если CRM у вас уже есть, мы сначала проверяем её настройку, данные и интеграции, потому что проблемы там встречаются чаще, чем ограничения продукта.

Подробнее: Внедрение и синхронизация ERP и CRMСсылка на этот вопрос

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

Подробнее: Внедрение и синхронизация ERP и CRMСсылка на этот вопрос

Второй этап, интеграционная фаза, требует, чтобы системы налогоплательщиков подключались к платформе FATOORA ZATCA. Стандартные налоговые счета клирируются ZATCA до того, как попадут к покупателю, а упрощённые счета отчитываются вскоре после выставления. Каждый счёт несёт криптографическую отметку и QR-код, поэтому ERP или POS должны формировать их в требуемом формате.

Подробнее: Электронные счета, налоги и цифровые паспорта продуктовСсылка на этот вопрос

PINT-AE — спецификация ОАЭ для международного формата счетов PEPPOL, используемая в программе электронных счетов ОАЭ. Счета обмениваются в этом структурированном формате через аккредитованных поставщиков услуг и отчитываются в Федеральное налоговое управление, чья платформа EmaraTax ведёт налоги ОАЭ.

Подробнее: Электронные счета, налоги и цифровые паспорта продуктовСсылка на этот вопрос

«НДС в цифровую эпоху» (ViDA) — пакет ЕС, переводящий выставление счетов для трансграничного бизнеса на структурированные электронные счета и цифровую отчётность. Он касается любого бизнеса, который выставляет счета клиентам ЕС или имеет юрлица в ЕС, где бы ни находилась его штаб-квартира.

Подробнее: Электронные счета, налоги и цифровые паспорта продуктовСсылка на этот вопрос

Цифровой паспорт продукта (DPP) — европейская запись о материалах, происхождении, ремонтопригодности и переработке продукта, передаваемая через носитель данных, например QR-код. Он вводится поэтапно по группам продуктов. Он опирается на данные цепочки поставок, которые обычно находятся в ERP и производственных системах.

Подробнее: Электронные счета, налоги и цифровые паспорта продуктовСсылка на этот вопрос

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

Подробнее: Электронные счета, налоги и цифровые паспорта продуктовСсылка на этот вопрос

Да. Мы строим один интеграционный слой с коннектором для каждого мандата. ERP формирует один счёт, а слой форматирует, подписывает и отправляет его для каждой страны. Добавление страны становится настройкой, сопоставлением и тестами.

Подробнее: Электронные счета, налоги и цифровые паспорта продуктовСсылка на этот вопрос

ISO 20022 — международный стандарт финансовых сообщений. Его XML-сообщения несут структурированные данные, такие как полные имена, адреса и детали платежа, которых не могут передать прежние форматы SWIFT MT. Банки и платёжные системы перешли на него, поэтому платёжные файлы и выписки на его основе лучше сверяются и чаще проходят проверки на соответствие.

Подробнее: Банки, казначейство и связность ISO 20022Ссылка на этот вопрос

Мы используем pain.001 для платежей, pain.002 для статусов, camt.052, camt.053 и camt.054 для отчётов по счетам и сообщения pacs между банками. Мы также читаем выписки MT940 и MT942, которые многие банки по-прежнему отправляют. Транспорт — host-to-host SFTP, EBICS, SWIFT или банковские API. У каждого банка свой вариант каждого формата, поэтому мы строим по его руководству по внедрению.

Подробнее: Банки, казначейство и связность ISO 20022Ссылка на этот вопрос

SAP S/4HANA, Oracle Fusion Cloud ERP и NetSuite, Microsoft Dynamics 365, Odoo и Sage, а также казначейские и заказные системы. Если у ERP есть собственный модуль банковской связи, мы настраиваем и расширяем его, а не строим в обход.

Подробнее: Банки, казначейство и связность ISO 20022Ссылка на этот вопрос

Да, там где эквайер или процессинг это предлагает. ISO 8583 — скорее фреймворк, чем единый формат: каждый эквайер публикует собственную спецификацию полей и типов сообщений. Мы строим по этой спецификации, обрабатываем авторизации, отмены и служебные сообщения и тестируем каждый код ответа.

Подробнее: Платежи, агентная коммерция (AP2) и POSСсылка на этот вопрос

Agent Payments Protocol (AP2) — открытый протокол для платежей, совершаемых ИИ-агентами. Каждая покупка несёт подписанные мандаты, показывающие, что авторизовал клиент, поэтому продавцы, эмитенты и эквайеры могут ей доверять и проверять её. Если ИИ-агенты, вероятно, будут покупать у вас, мы можем подготовить ваш чекаут к AP2 наряду с текущими потоками.

Подробнее: Платежи, агентная коммерция (AP2) и POSСсылка на этот вопрос

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

Подробнее: Платежи, агентная коммерция (AP2) и POSСсылка на этот вопрос

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

Подробнее: Платежи, агентная коммерция (AP2) и POSСсылка на этот вопрос

Зависит от числа подключений и того, кто будет их эксплуатировать. Интеграционная платформа, такая как MuleSoft, Boomi или Azure Logic Apps, даёт готовые коннекторы, сопоставление и мониторинг в одном месте за лицензионную плату. Заказные сервисы дают полный контроль и отсутствие лицензии, но больше кода в поддержке. Мы сравниваем оба варианта для вашего случая.

Подробнее: Промежуточное ПО и услуги интеграции APIСсылка на этот вопрос

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

Подробнее: Промежуточное ПО и услуги интеграции APIСсылка на этот вопрос

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

Подробнее: Промежуточное ПО и услуги интеграции APIСсылка на этот вопрос