Аудио формат:

В большинстве оптовых компаний есть 1С, есть CRM, есть сайт и есть куча Excel-файлов, которые их связывают. Вопрос «сколько мы заработали на этой товарной группе в июне» превращается в неделю переписки, а ответов получается три — от отдела продаж, от бухгалтерии и из Power BI, который кто-то настроил полтора года назад.

Я построил систему, которая закрывает этот разрыв целиком: от чтения базы 1С до окна переписки с клиентом внутри корпоративного портала. Она работает в компании-дистрибьюторе больше полугода, ей пользуются около 120 сотрудников каждый день, и её данные сходятся с учётом до последнего знака.

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

Что не работает в обычной схеме

Типичная картина, которую я вижу почти в каждой компании такого размера:

• Отчёты живут в файлах. Кто-то собирает выгрузку, кладёт её в общую папку, дальше файл копируется и правится. Один такой рабочий файл, который мне показывали, весил 750 мегабайт и открывался четыре минуты.
• Одни и те же цифры считаются по-разному. В одном отчёте выручка с НДС, в другом без, в третьем внутренние перемещения между своими юрлицами посчитаны как продажи. Никто не виноват — просто правило не записано нигде, кроме головы автора.
• Часть данных не существует в принципе. Суммы доставки лежат в личном кабинете перевозчика и попадают в учёт с задержкой в месяц-два. Данные о рынке — в открытых реестрах, которые кто-то выгружает руками. Переписка с клиентом — в личном телефоне менеджера и уходит вместе с ним.
• Отчёт нельзя проверить. Он показывает число, но откуда оно взялось и почему отличается от 1С — выяснить невозможно.

Дальше начинается самое дорогое: спор о том, чьи цифры верные, занимает больше времени, чем работа с самими цифрами.

Что получилось в итоге

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

Ключевые характеристики работающей системы:

Слой 1. Как данные забираются из 1С

Проблема нечитаемой базы

Базы 1С устроены так, что таблицы в них называются нечитаемо: вместо «Контрагенты» — набор букв и цифр. Обычно компании решают это покупкой стороннего инструмента, который строит поверх базы понятные представления.

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

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

Три стратегии инкрементальной загрузки

Забирать всю базу каждый раз невозможно — это терабайт. Забирать «изменённое с прошлого раза» в 1С тоже не так просто: у разных объектов признак изменения разный. Работают три стратегии:

1. По версии данных. Справочники и документы: 1С хранит служебное поле версии, которое растёт при любой правке. Забираем всё, что больше запомненной отметки.
2. По дате. Регистры-факты: продажи, расчёты, движения склада. Берём окно последних дней с перекрытием — документ, проведённый задним числом, попадает в следующий же прогон.
3. По родителю. Строки документов: тянем не все 7,5 млн строк, а только принадлежащие шапкам, которые изменились.

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

Оркестрация и наблюдаемость

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

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

Слой 2. Хранилище

Реляционная СУБД с расширением для временных рядов. Крупные факты нарезаны по месяцам, поэтому запрос за квартал читает три куска, а не всю историю.

Модель классическая: измерения (клиенты, товары, склады, сотрудники, подразделения) и факты (продажи, расчёты, заказы, движения склада, план и факт). Но есть особенность, ради которой стоит читать этот раздел, если вы работаете с 1С.

Ключи аналитики: главная ловушка данных 1С

В 1С факт продажи не ссылается на справочник клиентов напрямую. Между ними стоит промежуточный объект — ключ аналитики учёта. Таких ключей несколько: по партнёрам (кто купил), по номенклатуре (что продали), по партиям (чей товар продали).

Что это значит на практике:

• Попытка соединить факт со справочником «в лоб» даёт пустой результат — и это ещё хороший случай, потому что ошибка видна сразу.
• Плохой случай: в справочнике клиентов есть два похожих поля — сам контрагент и партнёр (группа компаний). Для большинства записей они совпадают, поэтому подмена почти незаметна. Но не для всех: в одном отчёте такая ошибка молча теряла 10–20% поставщиков бренда, отправляя их в категорию «не определён». Отчёт не падал. Он просто был неверным.

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

Слой 3. Витрины и одна версия правды

Отчёты никогда не читают сырые факты. Между ними — 53 витрины, которые пересобираются ночью и хранят уже посчитанные разрезы.

Главное здесь — не производительность, а единое определение выручки. Это отдельное представление, которое отвечает на вопрос «что в этой компании считается продажей»:

• без НДС;
• без внутренних юрлиц группы (перемещение товара между своими компаниями — не продажа);
• только по разрешённым типам документов;
• без служебных складов и акционных сегментов.

Все эти правила вынесены в справочник-реестр исключений, а не зашиты в каждый запрос. Меняется в одном месте — применяется везде.

Результат сверки с учётной системой — расхождение 0,0000%. Именно это, а не количество графиков, делает отчёты рабочим инструментом: когда финансовый директор проверяет цифру в 1С и она сходится, спор заканчивается.

Продукт 1. Портал отчётов

Основное рабочее место: каталог из 47 отчётов по продажам, закупкам, складу, логистике, персоналу и сводкам для руководства.

Из чего состоит отчёт

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

• Типы колонок: текст, число, деньги, проценты, дата, месяц, ссылка на карточку, цветовые правила по значению (например, маржа ниже порога подсвечивается).
• Плитки показателей над таблицей: сумма, среднее, доля, отклонение от прошлого периода со стрелкой роста или падения.
• Фильтры: период, месяц, множественный выбор из справочника, поиск с подсказками, переключатели (например, «с НДС / без НДС»), быстрые пресеты.
• Графики: динамика по месяцам, столбцы по категориям, круговая диаграмма долей. График по датам автоматически схлопывается до месяцев и сортируется хронологически.
• Вкладки: один отчёт может показывать один и тот же предмет на разных уровнях подробности — сводка, детализация, справочник.
• Выгрузка в Excel — с теми же фильтрами, что на экране.

Сводные таблицы: конструирование разрезов

Отдельный режим — иерархическая сводная таблица, работающая как матрица в Power BI. Измерения задаются произвольным списком любой глубины: например, «филиал → менеджер → сегмент → клиент». Узлы раскрываются и сворачиваются, агрегаты пересчитываются на лету.

Тонкости, которые пришлось решать:

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

Права: кто какие строки видит

Доступ разграничивается на двух уровнях:

1. Папки — какие отчёты человек вообще видит в каталоге.
2. Область видимости — какие строки внутри отчёта. Задаётся узлами структуры предприятия из учётной системы: выдали руководителю его отдел — поддерево разворачивается само. Менеджер видит своих клиентов, руководитель — своё дерево, директор — компанию целиком.

Важная деталь реализации: учётка, заведённая автоматически из оргструктуры, создаётся выключенной, если отдел сотрудника ещё не сопоставлен узлу учётной системы. Пустая область видимости в такой системе означает «ограничений нет» — то есть автосоздание без этой защиты открыло бы новому человеку данные всей компании.

Что ещё умеет портал

• Вход из корпоративного портала без отдельного логина. Отчёты открываются вкладкой внутри CRM: система спрашивает у портала, кому принадлежит токен, находит сотрудника в оргструктуре и выдаёт ему собственный доступ с его правами.
• Карта клиентов с фильтрами и слоями: свои клиенты, клиенты без заказов, организации рынка, которых у нас нет. С карты ставится задача полевому представителю.

• Редактируемые справочники прямо в отчёте: планы продаж, признаки клиентов, загрузка прайсов поставщиков — то, что раньше жило в Excel и присылалось по почте.
• Черновики. Новый отчёт сначала виден только администратору: он работает, проходит все проверки, но пользователям не показывается ни в каталоге, ни по прямой ссылке — пока цифры не сверены с учётом вручную.
• Полнотекстовый поиск по каталогу с синонимами: «дебиторка», «долги», «просрочка» ведут к одному отчёту.

Продукт 2. Личный кабинет сотрудника

Отдельное приложение, доступное с телефона: сотрудник видит свои показатели и свои задачи, не открывая ни 1С, ни отчёты.

Что туда уезжает

Платформа отправляет в кабинет тринадцать наборов данных:

• оргструктура и сотрудники — с их кодами в учётной системе;
• справочник показателей — отправляется раньше значений, иначе показатель с незнакомым кодом будет отклонён;
• показатели за период — продажи, маржа, план и факт, активные клиенты;
• показатели по сегментам — те же цифры в разрезе товарных направлений;
• долги клиентов и задания по ним;
• оплаты поставщикам — почасовой снимок в течение рабочего дня;
• сроки поставок и справочник поставщиков;
• штатное расписание, производственный календарь, отсутствия сотрудников;
• типы заданий и сами задания.

Задания: работа приходит сама

Это главное отличие кабинета от «ещё одного дашборда». Задание не ставится руководителем вручную — оно рождается из данных:

• Просроченный долг. Клиент, сумма, срок просрочки, документ. Отказаться нельзя — только выполнить или перенести. Результаты: оплатил, обещал оплату, спорит по документам, не дозвонился.
• Клиент замолчал. Раньше покупал регулярно, теперь пауза дольше обычного. Результаты: дозвонился, не берёт трубку, отказ.
• Сдвиг срока поставки. Поставщик сдвинул дату — предупредить клиента, который этот товар ждёт.

У каждого задания есть приоритет, группа (финансы, продажи, снабжение) и набор допустимых действий. Ответ сотрудника возвращается обратно и становится частью аналитики: видно, какие задания выполняются, какие переносятся неделями и по каким клиентам обещания не выполняются.

Инженерные детали, которые важны на практике

• Выдача доступа отправляется мгновенно. Кабинет показывает кнопку «Отчёты» только тем, у кого доступ действительно есть. Раньше это узнавалось из почасовой выгрузки — администратор выдавал права, а кнопка появлялась «когда-нибудь потом».
• Приём идемпотентен. Повторная присылка того же пакета отвечает «уже принято», поэтому обрыв связи безопасен.
• Разделение ошибок. Обрыв сети и перегрузка приёмника повторяются автоматически; ошибка в самих данных не повторяется, а чинится — иначе система бесконечно шлёт заведомо неверный пакет.
• Недоступность кабинета не ломает работу внутри. Он живёт на внешнем сервере, и его падение не мешает ни выдаче прав, ни отчётам.

Продукт 3. Переписка с клиентами

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

Окно переписки собирает три канала в одном месте и встраивается вкладкой в корпоративный портал.

Три канала

1. Личные рабочие аккаунты в Telegram. Сотрудник подключает аккаунт по QR-коду, сессия шифруется и хранится в закрытом контуре.
2. MAX — российский мессенджер, подключается так же.
3. Открытые линии корпоративного портала — виджет сайта, сообщества в соцсетях, коннекторы. В нашем случае этот канал оказался самым нагруженным: почти две тысячи сессий и полтысячи клиентов в месяц — больше, чем в личных мессенджерах.

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

Что умеет окно

• папки со счётчиками: требуют ответа, жду клиента, передано коллеге, закрытые;
• автоматическая раздача новых обращений и передача диалога коллеге;
• автозакрытие «залежавшихся» диалогов, по которым никто не отвечает;
• статусы прочтения, реакции, ответы на конкретное сообщение;
• вложения: файлы принимаются и отдаются, хранятся во внутреннем контуре, а не в памяти контейнера;
• шаблоны ответов — часто повторяющиеся формулировки в один клик;
• полнотекстовый поиск по сообщениям, клиентам и номерам телефонов.

• собеседник опознаётся по номеру телефона и связывается с карточкой клиента: менеджер видит, кто пишет, что этот клиент покупал, есть ли у него долг и кто за него отвечает;
• если номера в CRM нет, контакт заводится автоматически, а связка запоминается — больше система его не спутает.

• оператор — свои диалоги;
• аудитор («корректор») — видит папки всех менеджеров: нужен для контроля качества переписки;
• администратор продукта — настраивает линии, раздаёт роли, назначает операторов линии, передаёт администрирование;
• доступ к открытым линиям выдаётся отделу, а не отдельным людям: у линии нет владельца, её ведёт подразделение целиком.

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

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

Правовая рамка — не формальность

Переписка сотрудника с клиентом — это тайна связи. Сбор законен только при уведомлении, подписанном до подключения аккаунта. В системе это не инструкция, а ограничение базы: пока не проставлена дата подписи, аккаунт нельзя включить технически. Тексты переписки не передаются в языковые модели ни при каких условиях.

Продукт 4. Распознавание заявок из пяти каналов

Клиент редко присылает аккуратный список артикулов. Он пишет словами: «перчатки М двадцать упаковок, салфетки десять, и что-то вместо ветоши, которую в прошлый раз брали». Менеджер тратит на превращение этого в заказ 10–20 минут.

Сервис распознавания превращает текст или фотографию счёта в позиции номенклатуры с оценкой уверенности. Он подключён к пяти точкам входа:

1. Виджет на сайте — клиент вставляет свой список сам и получает готовую корзину.

1. Бот в корпоративном портале — заявка приходит сотруднику в чат уже разобранной.

1. Личные мессенджеры — менеджер выделяет сообщения клиента прямо в окне переписки и получает позиции.
2. Открытые линии — то же самое для обращений с сайта и из соцсетей.
3. Фотография или скан счёта — снимок бумажной заявки.

Спорные позиции не выдумываются, а помечаются: «ветошь — три варианта, нужно уточнить». Цены сервис не считает принципиально — их считает учётная система по договору с конкретным клиентом.

Что из этого получается для аналитики

Раньше ни один шаг этого пути не сохранялся: воронка считалась на лету, обращения к помощнику жили в журнале сервиса до перезапуска. Теперь по каждому каналу видно:

• сколько заявок распознано и сколько позиций в них;
• сколько клиент подтвердил, а сколько удалил;
• сколько дошло до заказа и превратилось в деньги;
• сколько стоило распознавание (расход на модель по каждой заявке);
• как часто сотрудник правит распознанное и какие оценки ставит.

Последние два пункта — материал для улучшения: видно, на каких формулировках модель ошибается и окупается ли она вообще.

Продукт 5. Интеграция с сайтом

На сайт интернет-магазина уходят рассчитанные данные — то, что клиент видит в карточке товара:

• Аналоги. Если позиции нет в наличии или клиент хочет дешевле — в карточке появляются замены, рассчитанные из справочника номенклатуры.
• Сопутствующие товары («с этим товаром покупают»), посчитанные по реальным корзинам, а не по интуиции контент-менеджера.

Инженерные детали, которые экономят время при повторении:

• Каталог сайта уже́ ассортимента учёта: часть товаров сайту неизвестна, и ответ «товар не найден» для них — норма, а не сбой загрузки. Падать нужно только на сетевых ошибках.
• Обе выгрузки умеют работать вхолостую: сначала прогон с журналом и без записи, потом включение. Журнал общий, различается только свойство товара.
• Ответ сайта нужно разбирать по телу, а не по коду HTTP: частичный успех, когда нашлась половина связок, — типичная ситуация.

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

Как всё это связано между собой

Главный архитектурный принцип: ни одна пара внешних систем не связана напрямую. Всё идёт через ядро, где лежит реестр соответствий.

Зачем это нужно, проще всего показать на клиенте. В учётной системе он — код документа. В CRM — компания со своим номером. В открытых реестрах — ИНН. В мессенджере — номер телефона. На сайте — товарный идентификатор. Пока эти связки живут в головах и выгрузках, «топ-клиенты» отдела продаж и «топ-клиенты» бухгалтерии — разные списки.

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

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

Что уходит обратно во внешние системы:

Наружу система всегда ходит сама. Ни один внешний сервис не имеет доступа внутрь сети.

Продукт 6. Панель для собственника и руководителей

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

Блок «требует внимания» формируется автоматически из тех же данных: рост просрочки, отставание филиала от плана с учётом дня месяца, клиенты категории А, которые перестали покупать. Это не настраиваемые виджеты, а конкретные правила, написанные под бизнес — и в этом смысл: собственнику не нужен конструктор, ему нужен короткий список того, что пошло не так.

Как проверяется, что отчёт не врёт

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

Поэтому перед выпуском отчёт проходит четыре барьера:

1. Сверка конфигурации со схемой хранилища. Все колонки, фильтры и графики, объявленные в отчёте, существуют в витрине. Ловится до деплоя, а не при первом открытии.
2. Инварианты данных. Автоматические проверки по всем отчётам сразу: сумма равна сумме строк; страницы не пересекаются и порядок воспроизводим; итоги сводной сходятся с итогами таблицы; колонка разграничения заполнена; строки с пустыми значениями в разрезе не исчезают из выборки; все ручки отчёта и выгрузка живы.
3. Живой браузер. Настоящий Chromium открывает каталог, поиск и несколько отчётов и роняет деплой на любой ошибке в консоли. Нужен потому, что серверные проверки дёргают API и фронтенд не видят по устройству: однажды правка плиток уронила каждую страницу отчёта, а обе серверные проверки остались зелёными.
4. Режим черновика. Отчёт работает, прошёл все проверки, виден администратору — но пользователям не показывается, пока человек не сверит цифры с учётной системой вручную.

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

Что это дало компании

Три эффекта, которые видно в работе.

Несколько конкретных находок, которые окупили разработку:

• Переплаты клиентов не учитывались в просрочке. Отчёт выбрасывал отрицательные остатки по отдельным заказам, и клиент, который компании фактически ничего не должен, числился в просрочке — менеджер шёл разговаривать с ним о долге. После того как переплата стала гасить долги того же клиента, как в акте сверки, ложная просрочка исчезла у двенадцати клиентов, суммарно около 286 тысяч рублей.
• Продажи в разрезе поставщика считались пропорцией. Раньше их оценивали по доле в закупках, и с учётом они не сходились. Теперь берётся фактический поставщик каждой проданной партии. Попутно нашлась ошибка связывания, из-за которой 10–20% поставщиков молча уходили в «не определён».
• Отпуска вносились дважды. Кадровик заполнял график в портале руками, повторяя то, что уже внёс в кадровый учёт. Теперь данные едут автоматически.

Сколько это стоит содержать

Вся платформа живёт на одном офисном сервере: 32 гигабайта памяти, около двадцати служб в контейнерах, хранилище 44 гигабайта.

• Лицензий за пользователя нет. Всё ПО — свободное: СУБД, оркестратор, панели наблюдения. Коммерческие BI-системы считают деньги за каждого пользователя, и при сотне сотрудников это ежегодная статья, растущая вместе с компанией. Здесь добавить сотрудника — значит выдать доступ, а не купить место.
• Основная статья — разработка и сопровождение. Отчёт выпускается не тогда, когда «показывает данные», а когда его цифры сверены. Это работа, и её нужно закладывать.
• Инфраструктура минимальна. Отдельный сервер под аналитику нужен, но это обычная машина, а не кластер.

Как это внедряется в другой компании

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

Порядок работ

1. Доступ к базе учётной системы — лучше к реплике, а не к боевой базе.
2. Генерация представлений — база становится читаемой за один прогон.
3. Развёртывание стека и первичная загрузка — хранилище, конвейеры, первые факты.
4. Определение выручки и сверка с учётом — самый важный этап (см. ниже).
5. Первые 5–7 отчётов, закрывающих реальную боль, а не «чтобы было».
6. Права по оргструктуре и интеграции — вход из вашего портала, кабинет, обмены.

Где проекты обычно застревают

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

Поэтому первый этап любого внедрения — не установка ПО, а разговор с финансистом и главным бухгалтером.

Что стоит проверить до начала

• На чём работает ваша 1С. Генератор представлений работает с базами на Microsoft SQL Server. Если у вас PostgreSQL, путь получения читаемых данных будет другим, и это влияет на срок и цену. Это первый вопрос, который я задаю.
• Кто обслуживает вашу учётную систему. Прямое чтение базы — обычная практика, но согласовать её с подрядчиком лучше письменно и заранее.
• Есть ли человек с вашей стороны, который может ответить на вопрос «что считается продажей» и имеет право это решение принять.
• Персональные данные. Кадровый контур и переписка с клиентами — отдельные правовые режимы, их рамку нужно выстроить до сбора данных, а не после.

Я построил эту систему целиком: от чтения базы 1С до окна переписки внутри корпоративного портала, включая загрузку, хранилище, движок отчётов, разграничение доступа, интеграции с CRM, кабинетом, сайтом и мессенджерами, а также контур проверки качества данных.