14 KiB

Raw Blame History

Да, теперь картина понятная.

У тебя сейчас:

1С:Предприятие 8.3.27
Бухгалтерия предприятия, редакция 2.0
база в режиме файловая
клиент толстый
каталог базы: x:\1C\База бухгалтерии

Это значит: быстрее всего вам идти через публикацию базы на веб-сервере и включение стандартного OData/REST, а потом уже поверх этого делать свой backend. Платформа 1С умеет автоматически формировать REST-интерфейс после публикации решения на веб-сервере; через него можно получать списки документов, справочников, записей регистров, в том числе с фильтрами, а также читать/создавать/изменять объекты. 1С прямо называет автоматически генерируемый REST/OData основным инструментом интеграции со сторонними системами. (v8.1c.ru)

Что делать дальше

План на 2 этапа

Этап А — быстро получить доступ к данным без ручных выгрузок Поднимаете OData/REST.

Этап Б — сделать нормальный боевой коннектор Поверх OData делаете свой Node-сервис, который:

тянет данные по расписанию,
хранит слепки и дельты,
нормализует 1С-структуру,
отдаёт уже удобное API вашему ассистенту.

А когда станет ясно, какие именно бухгалтерские сценарии нужны, добавляете в 1С HTTP-сервисы для кастомных запросов. 1С поддерживает создание собственных HTTP-сервисов; они удобны как лёгкие RPC/REST-эндпоинты, где вы сами формируете ответ встроенным языком. (v8.1c.ru)

Практический пошаговый план

Шаг 1. Зафиксировать цель интеграции

Сразу не делать “полный двусторонний API”. На старте нужен режим:

read-only + синхронизация в вашу систему

То есть:

ничего в 1С не пишем;
только читаем;
строим внешний аналитический/операционный слой.

Это резко снижает риск.

Шаг 2. Проверить, есть ли доступ к Конфигуратору

Вот это критично.

Без Конфигуратора или 1С-разработчика, который умеет:

публиковать базу на веб-сервере,
настраивать доступ,
включать OData,
при необходимости добавлять HTTP-сервисы,

вы не поедете.

Что нужно спросить у 1С-ника

Одной фразой:

Нужно опубликовать файловую базу 1С на локальном веб-сервере и включить стандартный интерфейс OData на чтение.

Это уже предметная задача.

Шаг 3. Поднять веб-публикацию базы

REST/OData в 1С работает после публикации прикладного решения на веб-сервере. Это прямо официальный базовый принцип. (v8.1c.ru)

Что это значит practically

Ваш 1С-ник должен:

открыть Конфигуратор;
опубликовать базу на IIS или Apache;
включить публикацию стандартного интерфейса OData;
выдать вам URL.

Обычно итог выглядит концептуально так:

база была локальной файловой;
стала доступна по HTTP внутри сети, например:
- http://<server>/<base>/odata/...
- или похожий путь, который сформирует публикация.

Я сейчас не даю точный шаблон URL, потому что он зависит от имени публикации и настроек веб-сервера.

Шаг 4. Включить OData только для чтения и только для нужных сущностей

В Библиотеке стандартных подсистем у 1С есть отдельный механизм настройки доступа к данным через стандартный интерфейс OData. (v8.1c.ru)

Что открывать наружу на старте

Не всё подряд. Только:

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

То есть тот минимум, который у тебя уже руками выгружался.

Шаг 5. Проверить OData простым тестом

После публикации проверяете не “сложный сценарий”, а очень простой:

Открывается ли metadata/корень сервиса.
Возвращается ли список, например, контрагентов или документов.
Работают ли фильтры по дате.

Официально REST/OData в 1С рассчитан как раз на получение списков документов, справочников и записей регистров с фильтрами. (v8.1c.ru)

Шаг 6. Между 1С и ассистентом ставите свой backend

Вот это обязательно.

Архитектура

1С (OData) → ваш sync-service → Postgres / storage → ассистент / UI

Почему так

Потому что нельзя строить продукт так:

UI каждый раз бьёт прямо в 1С;
ассистент напрямую лезет в 1С;
куча запросов летит в боевую бухгалтерскую базу.

Это будет и хрупко, и больно.

Что делает sync-service

хранит last_sync_at
тянет данные пачками
складывает сырые JSON/таблицы
нормализует в свои сущности
считает дельты
строит витрины:
- документы
- движения
- контрагенты
- объяснение суммы
- хвосты
- изменения за день

Шаг 7. Не делать realtime на старте

Это важно.

На старте не нужен “живой поток каждую секунду”. Нужен режим:

раз в 5 минут,
или раз в 15 минут,
или по кнопке “обновить”.

У 1С всё есть для интеграции и синхронизации по расписанию, и БСП отдельно поддерживает синхронизацию по требованию и в автоматическом режиме по расписанию. (v8.1c.ru)

Для бухгалтерии этого обычно достаточно.

Шаг 8. После OData — добавить HTTP-сервисы под умные сценарии

Когда базовый доступ заработает, вы быстро упрётесь в то, что OData даёт “сырые объекты”, а вам нужны бизнес-запросы:

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

Вот под это уже делаются HTTP-сервисы внутри 1С, потому что 1С позволяет создавать произвольные HTTP-сервисы и самим формировать тело ответа. (v8.1c.ru)

Что конкретно делать тебе сейчас

Вот совсем без воды.

Прямо сейчас

Составь и передай 1С-разработчику такой список задач:

ТЗ-минимум

Опубликовать файловую базу 1С на локальном веб-сервере.
Включить стандартный REST/OData-интерфейс.
Настроить отдельного пользователя только на чтение для интеграции.
Ограничить опубликованные сущности стартовым списком:
- контрагенты
- договоры контрагентов
- номенклатура
- статьи затрат
- статьи ДДС
- документы покупателей
- документы поставщиков
- банковские документы
- кассовые документы
- проводки / регистры бухучёта, если доступны через публикацию
Отдать тестовый URL и учётку для проверки из внешней системы.

ТЗ-второй очереди

Добавить HTTP-сервисы под кастомные выборки:
- изменения за период,
- дельта после последней синхронизации,
- список незакрытых хвостов,
- проводки, повлиявшие на сумму,
- документы закрытия месяца.

Что будете делать вы в Node.DC

Первая версия коннектора

Делаете сервис с 4 методами:

syncReferenceData() тянет справочники
syncDocuments(from, to) тянет документы по периоду
syncAccountingMovements(from, to) тянет движения/проводки
getDelta(since) тянет только изменения с момента последней синхронизации

В хранилище

Минимум такие таблицы:

onec_counterparties
onec_contracts
onec_items
onec_cashflow_articles
onec_cost_articles
onec_documents_raw
onec_postings_raw
onec_sync_log

Какой результат должен быть через 1–2 дня работы

Не “полный AI для бухгалтерии”.

А вот такой checkpoint:

Должно заработать

автоматически читаем из 1С контрагентов;
автоматически читаем документы за день/месяц;
автоматически читаем проводки/движения;
без ручных Excel;
данные падают в ваше хранилище;
можно сделать первый экран:
- “что изменилось с последнего sync”
- “какие документы/движения добавились”
- “какие контрагенты/суммы затронуты”

Если этого нет — дальше думать про ассистента рано.

Самая короткая стратегия

Что не делать

не строить ассистента поверх ручных выгрузок;
не лезть сразу в онтологию и сложные смыслы;
не пытаться “читать SQL-таблицы 1С в лоб”.

Что делать

публикация базы,
OData,
read-only пользователь,
sync-service,
своё хранилище,
потом HTTP-сервисы под умные кейсы.

Твой следующий практический ход

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

Если хочешь, я следующим сообщением соберу тебе готовое короткое ТЗ для 1С-разработчика — буквально списком, что именно ему нужно сделать, без лишней теории.

14 KiB Raw Blame History Unescape Escape