Сравнение с системы с одной жёсткой карточкой контрагента

Один контрагент — три способа на него смотреть: архитектура вместо компромисса

системы с одной жёсткой карточкой контрагента

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

Почти в любой компании есть контрагент, на которого смотрят с трёх сторон. Бухгалтерии нужна одна запись с одним ИНН — так требует отчётность и закон; двадцать карточек на одну компанию — ошибка учёта. Продажи видят холдинг: три завода — три реальных заказчика, у каждого свой менеджер, воронка и история переговоров; склеить их в одну карточку — менеджеры утонут в чужих сделках. Закупкам всё это без разницы: для них тот же контрагент — поставщик, с договорами, заявками и рекламациями. Кто из них прав? Все трое — в этом и проблема. Обычная база хранит сущность одной жёсткой структурой: приходится заранее выбрать, что это за запись и какие у неё поля. Одна карточка с полем «тип» обрастает чужими полями, три отдельные карточки рвут компанию на части, и холдинг приходится собирать руками. Спор решается компромиссом, а компромисс, устроивший всех сразу, не устраивает никого: он не устраняет три потребности, а смешивает их в одной записи.

Контекст

Типичная история: контрагент с холдинговой структурой и три отдела, каждому из которых нужен «свой» взгляд на него. В базе с одной жёсткой карточкой контрагента это оборачивается вот чем:

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

Как это решает Интеграм

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

компанию-контрагента заводят один раз — с одним ИНН, как того требует бухгалтерия;
подразделения холдинга связывают типом «входит в холдинг по ИНН» — бухгалтерский отчёт собирается по этому типу и ничего постороннего не задевает;
продажи видят каждое подразделение отдельным заказчиком через тип «заказчик → подразделение»: свой менеджер, своя воронка, своя история переговоров;
закупки подключают к той же записи тип «поставщик» — договоры, заявки и рекламации живут своей, третьей картиной;
в одной рабочей базе в одной таблице связей живут 418 типов, а собрать запись со всеми реквизитами занимает 0,16 мс — обычный Postgres;
когда поверх уже накопленных данных понадобился новый тип связи, больше четырёхсот связей (+402) разнесли одним проходом: ноль миграций, и ни один существующий отчёт не изменился;
когда нужен следующий взгляд — «арендатор склада», «участник тендера» — это строка в справочнике типов и отчёт поверх неё. Не пригодился — строку убрали.