AndreiКrНо как-то слишком сложно... Вы учтите, что человек, задавший вопрос только учится проектировать БД
Простейший неидеальный пример для чайников. Берем для примера поставщиков. Вводим понятие реестра поставщиков. В нем только ссылки на субъектов (справочник субъектов один на всех), которые могут быть поставщиками. Далее в реестре поставщиков добавляем "обвески" типа "блокирован", "сертифицирован", "разрешен", "минимальный срок поставки" и т.п. Эти признаки влияют только на использование субъекта как поставщика. Например, если блокирован поставщик, то он блокирован только как поставщик, но не как субъект в целом. Так понятнее будет? Аналогично делается реестр покупателей, реестр банков (впрочем, с банками все сильно сложнее ввиду наличия разнородных справочников типа БИК/BLZ и т.п., имеющих разную, подчас идиотскую, структуру) и т.п. Визуально это может быть отдельная закладка в справочнике субъектов на каждый реестр, а может быть отдельный справочник на каждый реестр, с точки зрения структуры БД это без разницы. На каждый реестр пишется регламент. Например, по умолчанию запись в реестр добавляется без признака "разрешен" и необходима процедура визирования. Или регламент блокировки записи в реестре. И т.д.

kordaНапомню, что данная схема учитывает возможность ведения учета по нескольким предприятиям
Позволю себе остаться при своем незыблемом мнении, и Вам его практически навязываю, что корректная реализация " возможности ведения учета по нескольким предприятиям " в рамках одной БД реализуется прежде всего начиная с системы разграничения прав доступа, а не подобными костылями в виде кросс-таблиц. Поэтому в рамках данного топика обсуждать множество юрлиц в одной БД вообще бессмысленно, и акцентировать внимание на этом не стоит.

andreychрасчеты с контрагентами или лицевые счета контрагентов кому как нравится
Никак не нравится. Чтобы платежные реквизиты стали лицевыми счетами, необходимо, чтобы дело происходило в банке, к тому же "лицевой счет" - сильно обобщенное понятие. А уж "расчеты с контрагентами" вообще не в тему, это никакие не расчеты. Можете назвать "расчетные счета", это более нейтрально и корректно, если не вдаваться в дебри SWIFT и его форматов, хотите - добавьте прилагательное "банковский" в сответствующем числе и падеже.

kordaлогика взаимодействия системы с Потребителем и Поставщиком должна быть одинакова в принципе?
Так не бывает в принципе. Бизнес-логика взаимодействия с поставщиками и покупателями всегда разная. Соответственно, насколько эта бизнес-логика (в части объектов, их структур и взаимосвязей) отражена в структуре БД, настолько используемая структура БД должна отличаться в части поставщиков и покупателей. Если исходить из того, что любой покупатель в любой момент теоретически может стать поставщиком, то тогда просто остаются некоторые неиспользуемые атрибуты. Если исходить из той крайности, что любые атрибуты можно натянуть на EAV, тогда это уже другой коленкор (см. 3-е предложение выше).

Можете предложить свой вариант атрибута, который есть только у поставщика или только у покупателя, а guest Вам скажет, почему Вы обгадились (используя оригинальную терминологию). Впрочем, строго доказать это для любого атрибута вряд ли представляется возможным, особенно с учетом того, что могут быть некие уникальные атрибуты, связанные со спецификой конкретного предприятия.

kordaсимметричны и то, чем они обмениваются - Деньги и Товар.
Это глупость. Симметричны они могут быть (или не быть) только в рамках конкретных договорных отношений как некие обязательства. Например, в случае договора цессии ни о какой симметрии вообще речи быть не может. Аналогично в случае договора дарения,...

stiВ нашем случае, есть, например, такой атрибут - прайс-лист, который есть у Поставщика и отсутствует у Покупателя.
Ошибаетесь. Прайс-лист есть и для покупателей, и для поставщиков. Просто по одним прайс-листам продают, а по другим покупают.

stiУ Поставщика есть прайс-лист, по которому покупают Покупатели (упрощенно).
А у Покупателя есть прайс-лист, по которому продают Поставщики (не менее упрощенно). Если не вдаваться в тонкости ценообразования, ибо сейчас это просто неважно, кто и как формирует прайс-лист, то сам по себе прайс-лист (как перечень актуальных цен на позиции номенклатуры для определенной группы контрагентов) применим как при продажах, так и при покупках. Что тут можно еще обсуждать?