Quickstart для владельцев проектов¶
Цель: за полчаса настроить сквозной приём данных от одного поставщика и принять первую валидную поставку. Пример ниже — FIBU import (немецкая Hausverwaltung, бухгалтерия). Та же структура подходит для любого домена.
Страница нарочно идёт по верхам — каждый шаг ссылается на подробное how-to. Если сначала хочется освоить терминологию, читайте Концепции.
Что нужно¶
- Org Admin пригласил вас в организацию с ролью Project Owner или выше.
- Вы знаете, в каком виде хотите получить данные на выходе — какие колонки ожидает целевая система.
- Один пример файла хотя бы от одного поставщика, чтобы можно было сквозно проверить на реальном входе.
Ссылки на консоль ниже подразумевают, что вы залогинены в свой
инстанс Expecto. API-ссылки подразумевают, что $EXPECTO_BASE_URL и
$EXPECTO_API_KEY установлены — как в Quickstart для разработчиков.
Шаг 1 — Создать Project¶
Project объединяет всё под один кейс приёма: entity, контракты, трансформеры, бизнес-правила, экспорт, поставщиков.
В консоли: Projects → Create Project. Имя — например FIBU 2026,
плюс короткое описание. Оставьте по умолчанию Approval Mode
(Dual Approval) и Session Creation (Both), если нет осознанной
причины менять.

Новый проект сразу появляется в списке:

Или через API:
curl -sS -X POST \
-H "X-API-Key: $EXPECTO_API_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "FIBU 2026", "description": "Ежемесячный приём бухгалтерии"}' \
"$EXPECTO_BASE_URL/api/projects" | jq .
Сохраните возвращённый id как PROJECT_ID.
Шаг 2 — Определить целевой Entity¶
Entity — это схема, в которой ваши данные оказываются после нормализации: целевая таблица с типами колонок и построчными правилами валидации.
В консоли: Entities → Add Entity. Назовите его Buchung и дайте
короткое описание.

Откройте entity и опишите колонки (например, konto text, betrag
decimal, buchungstext text, belegdatum date). Добавьте хотя бы одно
правило валидации, чтобы пайплайн отсекал явно битые строки.

Пример правила в expression language (что вы вводите в редактор):
len(konto) == 6 and matches(konto, '^[0-9]+$')
Сообщение:
{"en": "Konto must be 6 digits", "de": "Konto muss 6 Ziffern sein", "ru": "Konto должен быть 6-значным"}
Платформа сама компилирует это в DuckDB-запрос для поиска нарушений; см. Язык выражений (Скоро.) для полного списка операторов и встроенных функций.
То же через API. Правила вложены в свою entity, поэтому id entity идёт
в пути (экспортируй его как ENTITY_ID из созданной entity). Поле
expression — уже скомпилированный DuckDB SELECT, возвращающий
нарушающие строки:
curl -sS -X POST \
-H "X-API-Key: $EXPECTO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "konto_6_digits",
"level": "error",
"expression": "SELECT * FROM data WHERE LENGTH(TRIM(konto)) != 6 OR konto !~ '\''^[0-9]+$'\''",
"message": {"ru": "Konto должен быть 6-значным"}
}' \
"$EXPECTO_BASE_URL/api/entities/$ENTITY_ID/rules" | jq .
Шаг 3 — Написать DataContract¶
DataContract описывает, что обещает прислать конкретный поставщик — типы файлов, ожидаемые колонки, роль каждого файла. Это соглашение с поставщиком, не зависящее от того, как вы потом данные трансформируете.
В консоли: откройте вкладку Data Contracts проекта и нажмите
New Data Contract. Название — например Hausverwaltung X — FIBU v1,
задайте supplier id.

Откройте контракт и добавьте Sources — по одной на роль файла. Для FIBU обычно две:
buchungsdatei(CSV, разделитель;, немецкая кодировка) с колонкамиKonto,Betrag,Buchungstext,Belegdatum.saldendatei(CSV) сKonto,Saldo.
На странице контракта есть вкладки Sources, Revisions и Transformers; текущая ревизия сначала в статусе draft, пока вы её не активируете.

Для каждой source прикрепите Frictionless Table Schema с именами колонок и типами, чтобы структурные ошибки ловились ещё до трансформации.
Или через API:
curl -sS -X POST \
-H "X-API-Key: $EXPECTO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Hausverwaltung X — FIBU v1",
"supplier_id": "hv-x",
"project_id": "'"$PROJECT_ID"'"
}' \
"$EXPECTO_BASE_URL/api/data-contracts" | jq .
Сохраните id как CONTRACT_ID. Эндпоинты sources под контрактом
(/api/data-contracts/{id}/sources) позволяют завести каждую роль
файла.
До активации контракт находится в draft. Активация фиксирует его
как Revision 1 и запускает compatibility-проверку относительно всех
трансформеров, ссылающихся на него.
Шаг 4 — Собрать Transformer¶
Transformer мапит sources контракта на entity. Каждая колонка
entity получает один mapping-выражение — DuckDB-выражение, ссылающееся
на поле source, с возможностью почистить значение (TRIM, LPAD,
type cast, dictionary lookup).
В консоли: из Project'а — Transformers → New transformer. Выберите
Entity (Buchung) и DataContract revision. Затем по каждой source
role введите mapping'и для каждой целевой колонки:
| Целевая колонка (Entity) | Mapping (DuckDB-выражение по source) |
|---|---|
konto |
LPAD(TRIM("Konto"), 6, '0') |
betrag |
CAST(REPLACE("Betrag", ',', '.') AS DECIMAL(18,4)) |
buchungstext |
TRIM("Buchungstext") |
belegdatum |
STRPTIME("Belegdatum", '%d.%m.%Y') |
Активируйте трансформер, когда его mapping'и покрывают все обязательные колонки entity.
Через API трансформеры вложены в свой DataContract. Mapping'и идут в
mappings_per_role, ключ — source role:
curl -sS -X POST \
-H "X-API-Key: $EXPECTO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Buchung из Hausverwaltung X v1",
"data_contract_id": "'"$CONTRACT_ID"'",
"data_contract_revision": 1,
"entity_id": "'"$ENTITY_ID"'",
"mappings_per_role": {
"buchungsdatei": { "...": "объект RoleMapping" }
}
}' \
"$EXPECTO_BASE_URL/api/data-contracts/$CONTRACT_ID/transformers"
Шаг 5 — Настроить экспортный формат¶
На уровне Project'а выставьте output_format под ожидания
целевой системы. Встроенные: sap_v46 (SAP Interface V4.6),
zip_csv (CSV per-entity внутри zip), excel_workbook. Это и есть
то, что будет генериться при approve session.
В консоли: на вкладке Overview проекта найдите Output Format и нажмите Configure. Выберите тип формата и опции (разделитель, кодировка, строка заголовка для CSV-форматов).

Шаг 6 — Пригласить Data Provider¶
Пока вы не выдали поставщику доступ, никто не может присылать данные.
В консоли: откройте вкладку Providers проекта и пригласите поставщика. Выберите (или создайте) организацию-поставщика, затем grant'ните доступ к этому Project'у и к этому конкретному контракту. Поставщик получит письмо с приглашением и при логине увидит специализированный submission view.

Шаг 7 — Разобрать первую сессию¶
Когда поставщик загружает файлы, на вкладке Sessions проекта
появляется Session — с отслеживанием по health и стадии пайплайна.
Пайплайн прогоняет parse → transform → check автоматически (или по
триггеру — зависит от настроек Project'а).

Откройте session и посмотрите:
statusиhealth— на какой стадии и есть ли блокеры?- Tab Violations — построчный список отвергнутых строк по каждому правилу.
- Preview — трансформированные строки entity в том виде, в каком они уйдут в целевую систему.
Если всё ок — Confirm и затем Approve. Approve формирует экспортный пакет в выбранном формате.
Если что-то не так:
- Оставьте комментарий в session, поставщик увидит.
- Reject и попросите перезалить.
- Поправьте mapping в Transformer'е (создаёт новую revision) и перезапустите пайплайн против тех же файлов.
Куда двигаться дальше¶
| Если хотите… | Идите сюда |
|---|---|
| Безопасно править правила валидации | Использовать golden sessions для безопасной правки правил — Скоро. |
| Добавить reconciliation между файлами | Настроить reconciliation — Скоро. |
| Собрать transformer с dictionary lookups | Собрать Transformer — Скоро. |
| Управлять несколькими revisions контракта | Активировать revision контракта — Скоро. |
| Разобраться в доменной модели полностью | Концепции |