Бухгалтерия, продажи и закупки спорят об одном контрагенте. Кто из них прав?

Есть компания-контрагент. И есть три отдела, каждому из которых нужен «свой» взгляд на неё.

Бухгалтерии нужен один контрагент с одним ИНН — так требует отчётность и закон. Двадцать записей на одну компанию — это ошибка учёта, которую потом разгребать аудиту.

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

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

Кто из них прав? Все трое. В этом и проблема.

Спор, который решается компромиссом, — худший исход

В большинстве систем база требует выбрать одну структуру заранее, и спор идёт вокруг того, какой компромисс выбрать.

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

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

А завтра придёт четвёртый взгляд — «арендатор склада», «участник тендера», «должник по графику» — и всё повторится заново, только теперь с перестройкой того, что уже работает.

Компромисс, устроивший всех сразу, не устраивает никого: он не устраняет три разные потребности, а смешивает их в одной записи.

Контакт в телефоне — один, ярлыков — много

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

Именно так это устроено в Интеграме. Контрагент — одна запись. А «бухгалтерский», «продажный», «закупочный» взгляд — это связи с типами: «входит в холдинг по ИНН», «заказчик → подразделение», «поставщик». Связь — как ярлык, только честнее: у неё есть направление, значение и тип, и она живёт в общем справочнике типов.

Что это даёт на практике:

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

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

Новый взгляд — это строка, а не переделка

Самое ценное проявляется потом, когда система уже работает и в ней живут данные. Понадобился четвёртый способ смотреть на контрагента?

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

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

Чего это не решает — скажем честно

Ярлыки снимают спор о связях, но не спор о самом контрагенте. Клиент и поставщик в одном лице — это один объект с двумя ролями или два объекта, связанных между собой? Финансам нужен единый баланс — значит, один. Продажам — раздельная история — значит, два. Это не техника, а договорённость, и система тут лишь даёт описать обе точки зрения сразу, не воюя.

И второе: если решено считать один ИНН тремя подразделениями, старые сделки сами не разложатся по новым карточкам. Это работа со смыслом данных, и она не становится дешевле от гибкости хранилища.

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