Dynamics 365 + 1С
Практический гайд по интеграции Dynamics 365 и 1С в Казахстане: данные, Dataverse, API, gateway, Power BI, ошибки обмена и support model.
Tugelbay Konabayev, Marketing Specialist · 8 июня 2026 г.
Эти блоки отвечают на практические вопросы без скрытого текста и без неподтвержденных обещаний по срокам, стоимости или результату.
Да, это возможный интеграционный сценарий, но его нельзя честно описывать одной кнопкой. Нужно определить, какие данные остаются в 1С, какие используются в Dynamics 365, где нужен Dataverse, как обрабатываются ошибки и кто поддерживает обмен после запуска.
Чаще всего обсуждают клиентов, контрагентов, договоры, заказы, счета, оплаты, задолженность, номенклатуру, статусы и управленческие показатели. Точный состав зависит от конфигурации 1С, D365-модуля, ролей пользователей, отчетности и правил доступа.
Dataverse может быть платформенным слоем для Dynamics 365-данных и связанных приложений Power Platform. По Microsoft Learn, Dynamics 365 apps используют Dataverse для хранения и защиты данных, а интеграция нескольких источников в Dataverse может поддерживать Power Apps, Power Automate и Power BI.
Интеграция и отчетность решают разные задачи. Синхронизация нужна для процессов, а Power BI нужен, когда руководству важно видеть согласованные показатели из 1С, Dynamics 365, Excel, CRM/ERP и других источников без ручной сборки перед каждым совещанием.
Gateway может быть релевантен, если данные 1С или соседних систем находятся в локальной сети, а их нужно использовать в Microsoft cloud services. По Microsoft Learn, on-premises data gateway работает как мост между on-premises data и Microsoft cloud services, включая Power BI, Power Apps и Power Automate.
Иногда это возможно, но near real-time не должен быть стартовым обещанием. Сначала нужно проверить бизнес-потребность, нагрузку, источник данных, ограничения 1С, API, безопасность, обработку ошибок, поддержку и стоимость владения таким режимом.
На scope влияют направления обмена, количество сущностей, качество справочников, частота обновления, правила конфликтов, API-доступ, on-prem/cloud граница, тестовые среды, безопасность, мониторинг, приемка и поддержка ошибок после запуска.
Нужны карта данных, список систем, какие сущности участвуют, кто владеет справочниками, пример ошибок или отчетов, желаемая частота обмена, роли доступа, требования к мониторингу, ответственные за приемку и граница между support и новым проектом.
Интеграция Dynamics 365 и 1С в Казахстане обычно начинается с практичного вопроса: как связать Microsoft CRM/ERP с учетными, финансовыми или операционными данными из 1С. Иногда бизнес хочет видеть финансовый факт из 1С в sales pipeline. Иногда нужен отчет, где Dynamics 365, 1С, Excel и Power BI показывают одну картину. Иногда проблема в поддержке: обмен нестабилен, статусы расходятся, справочники дублируются, пользователи не доверяют системе.
Этот гайд не обещает универсальный connector. Его задача — помочь IT, CRM owner, финансам, продажам, сервису и закупке понять архитектуру: какие данные должны обмениваться, где нужен Dataverse, когда требуется API или промежуточный слой, когда хватает Power BI, где применим gateway, кто отвечает за ошибки и когда поддержка становится отдельным проектом.
Важно разделить спрос и технические факты. Поисковая выдача показывает, что люди ищут связки Dynamics 365, Microsoft Dynamics CRM, 1С, Dataverse и Power BI. Но технические утверждения в этом гайде опираются только на официальные Microsoft Learn источники, перечисленные в разделе “Источники и границы”.
Интеграция Dynamics 365 и 1С — это настройка обмена данными между Microsoft CRM/ERP и учетной системой 1С: клиентами, сделками, финансовым фактом, справочниками и отчетами. Чаще всего её делают, когда sales pipeline в Dynamics 365 нужно увидеть рядом с фактом продаж из 1С, либо когда обмен уже работает, но нестабильно: статусы расходятся, справочники дублируются, а пользователи не доверяют данным.
Универсального «connector» между Dynamics 365 и 1С нет: архитектура зависит от того, какие данные должны обмениваться, где размещен Dataverse, когда нужен API или промежуточный слой, когда хватает Power BI и где применим gateway. Гайд опирается только на официальные Microsoft Learn источники и помогает собрать архитектуру, роли и support model без обещаний, которых техническая часть не подтверждает.
Интеграция Dynamics 365 и 1С может означать разное:
Если эти сценарии смешать, обсуждение теряется. Один говорит про отчетность, другой про синхронизацию в реальном времени, третий про ошибки. Первый шаг — назвать не технологию, а бизнес-результат: какие действия упрощаются, какие данные куда идут, кто это принимает и как понять, что обмен работает.
Данные зависят от конфигурации 1С, модулей Dynamics 365 и роли каждой системы. Для CRM-продаж обсуждают клиентов, контакты, компании, сделки, коммерческие предложения, заказы, счета, платежи, задолженность, статусы. Для сервиса — обращения, договоры, активы, SLA, историю клиента, финансовый контекст. Для финансов — номенклатуру, склады, закупки, проекты, бюджеты, документы, статьи затрат.
Список полей сам по себе решает мало. Важнее ответить:
Например, контрагент может создаваться в 1С, а в Dynamics 365 использоваться как account для sales/service context. Или наоборот: lead и account появляются в CRM, а в 1С уходят только после квалификации, договора или заказа. Оба подхода могут быть разумными, но у них разные риски, проверки и support model.
По Microsoft Learn Dynamics 365 использует Dataverse для хранения и защиты данных. Dataverse может быть платформенным слоем для Power Apps, Power Automate и Power BI при интеграции из нескольких источников. Это важный факт, но не означает, что Dataverse автоматически должен хранить весь контур 1С.
Практичнее думать ролями:
Если в архитектуре нет owner matrix, любая технология будет спорной. Команда должна заранее знать, где master-data, где read-only копия, где временный слой, где отчетность и где человеческая приемка.
Нет одного правильного варианта для всех компаний. Ниже - не техническое задание, а карта возможных подходов, которые нужно проверять на discovery.
| Сценарий | Когда подходит | Риск | Что проверить |
|---|---|---|---|
| One-way sync из 1С в D365 | 1С остается owner учетных данных, а Dynamics 365 использует их для CRM или service context. | Пользователи могут ожидать редактирование данных в D365, хотя источник находится в 1С. | Owner, поля, частота обновления, права, правила дублей и обработка ошибок. |
| Two-way sync | Обе системы должны изменять данные и влиять на процесс. | Конфликты, разные справочники, циклические обновления и сложная приемка. | Conflict rules, master-data ownership, audit trail, rollback, тестовые сценарии. |
| Power BI reporting layer | Нужна управленческая картина, а не операционная синхронизация. | Отчет покажет расхождения, но не исправит процесс владения данными. | Метрики, источники, refresh, роли доступа, владельцы показателей. |
| Middleware/API layer | Нужны правила трансформации, очереди, мониторинг, retries и контроль ошибок. | Появляется отдельный слой, который тоже нужно поддерживать. | API, форматы, логирование, безопасность, SLA ожидания, owner поддержки. |
| File/export/import staging | Нужен простой или временный обмен, а полноценный API route пока не оправдан. | Ручные действия, задержки, ошибки форматов и слабый monitoring. | Регламент, формат, контроль версий, приемка, кто исправляет файл. |
| Power Platform automation | Нужно связать заявки, уведомления, согласования или легкие приложения вокруг процесса. | Low-code слой может разрастись без governance и support model. | Environments, owners, connectors, access, lifecycle, monitoring. |
| RFP / отдельный проект | Много систем, юридических лиц, стран, ролей, интеграций и требований к приемке. | Неполное ТЗ приведет к неверной оценке и спорной ответственности. | Scope, acceptance criteria, data map, security, support, procurement route. |
Для Dataverse Microsoft Learn описывает Web API как RESTful-интерфейс OData v4, применимый в разных языках и платформах. Это дает возможность обмена через API, но не отменяет работу по маршрутизации, безопасности, обработке ошибок и тестированию.
Если 1С находится в локальной сети, нужен мост между on-premises и cloud. Microsoft Learn описывает on-premises data gateway как программное обеспечение, которое соединяет локальные данные с облачными сервисами Microsoft. Gateway не всегда обязателен — только когда сценарий действительно требует использования локальных данных в облаке Microsoft.
Промежуточный слой может понадобиться для очередей, ретраев, трансформаций, мониторинга, проверки бизнес-правил и логирования ошибок. Иногда достаточно scheduled обмена. Иногда нужна integration platform или собственный API. Иногда лучший первый шаг — не синхронизация, а Power BI-отчет, который покажет расхождения без вмешательства в операционный процесс.
Часть запросов на “интеграцию” на самом деле просят управленческую отчетность. Руководитель хочет видеть pipeline из Dynamics 365 и факт оплат из 1С в одном отчете. Это не всегда требует двухсторонней синхронизации. Часто достаточно BI-слоя: данные читаются из источников, метрики согласованы, обновление понятно, доступы установлены, пользователи видят отчет без ручной сборки.
Если основной вопрос — “почему цифры не совпадают”, начните с BI и управления данными. Нужно понять, какие показатели спорят, кто владеет формулой, какая дата используется, какие статусы включаются, какие ручные правки существуют. Для этого есть отдельный гайд: Интеграция Power BI и 1С в Казахстане.
Если данные должны влиять на действия пользователя — менять статус сделки, создавать задачи, обновлять карточку, блокировать процесс без оплаты — тогда нужен integration и workflow scope, не только отчет.
Интеграция заканчивается не в день запуска, а когда есть понятный support model. Ошибки будут: неверные справочники, отсутствующие обязательные поля, конфликты изменений, недоступные источники, сбои авторизации, изменения форматов, ручные корректировки, дубли, исключения.
До запуска определите:
Если Dynamics 365 уже используется с накопившимся backlog, начните не с нового большого проекта, а с проверки поддержки. Для этого есть отдельная страница: Поддержка и доработка Dynamics 365 CRM в Казахстане.
Scope интеграции зависит не от названия, а от решений:
Фиксированная оценка без этого будет слабой. Лучше собрать architecture brief, затем выбрать маршрут: BI слой, support review, integration discovery, Power Platform, Azure/API или RFP package.
Перед тем как обсуждать оценку, соберите короткий пакет вводных:
Этот чеклист не заменяет обследование, но резко снижает неопределенность первого разговора.
Support-сценарий подходит, если уже есть работающий Dynamics 365/CRM контур и нужно разобрать конкретные ошибки, нестабильный обмен, backlog доработок, роли доступа, отчеты, Power Automate flows или change requests. Тогда основной вопрос - что уже работает, где ломается и какие изменения можно безопасно внести в текущий support model.
Отдельный проект нужен, если меняется архитектура данных, появляется двухсторонняя синхронизация, много сущностей, несколько систем, разные владельцы, требования к monitoring, migration, security, RFP или acceptance criteria. В таком случае полезнее не называть это “доработкой”, а выделить integration discovery.
Технические факты в этом гайде ограничены официальными Microsoft Learn источниками:
Поисковая выдача использовалась как сигнал спроса: люди ищут Dynamics 365, Microsoft Dynamics CRM, 1С, Dataverse и Power BI в одном контексте. Она не используется здесь как источник технических возможностей, гарантий или продуктовых утверждений.
Гайд не является юридическим, налоговым или заключением по соответствию требованиям. Вопросы хранения, передачи и защиты данных для Казахстана и других стран региона нужно проверять отдельно под фактическую архитектуру, договоры, роли доступа и типы данных.
Нет. В большинстве сценариев 1С продолжает выполнять учетную или операционную роль, а Dynamics 365 закрывает CRM/ERP-процессы, customer context, workflow или другие бизнес-задачи. Решение о роли каждой системы принимается после карты данных и процессов.
Dataverse может быть частью архитектуры, но не всегда должен становиться единым хранилищем для всего. Нужно проверить, какие данные должны жить в Dynamics 365/Dataverse, какие остаются в 1С, какие идут в Power BI и где возникают ограничения доступа, объема и поддержки.
Если задача только в управленческой картине, а не в процессе работы пользователя, часто лучше начать с BI-слоя: согласовать метрики, источники и refresh. Синхронизация нужна, когда данные должны участвовать в действиях, workflow, карточках, уведомлениях или операционных решениях.
Real-time повышает требования к API, нагрузке, обработке ошибок, мониторингу, безопасности, ownership и support. Если бизнесу достаточно daily или scheduled refresh, near real-time может добавить сложность без соответствующей пользы.
Основные риски: конфликт изменений, дубли, разные справочники, разные правила статусов, ошибки доступа, ручные корректировки, отсутствие owner и непонятная приемка. Двухсторонний обмен требует особенно ясных правил владения данными.
Сначала отделите bug, change request, reporting issue, data quality issue и новый project scope. Если Dynamics 365 уже используется, рядом с этим гайдом полезна страница support review: она помогает разобрать backlog и понять следующий маршрут.
Используйте этот гайд как подготовку вводных: соберите карту данных, список систем, спорные показатели, backlog ошибок и требования к обмену. После этого будет проще понять, нужен ли BI-слой, support review, integration discovery или RFP-пакет.
