Если по первоначальной задаче ТС:
1. Таки основные данные организаций выделить в таблицу Контрагент или Организация. Наименование организации меняется. Не так давно, например, ЗАО поменяли на АО. В зависимости от потребностей, привязываться к дате (будет проблемы, если запросят распечатать потерянную накладную за прошлый год и там будет новое наименование контрагента). ИНН, ОГРН постоянный. КПП меняется. ОКВЭД меняется, но не уверен, что вообще эта фигня нужна. Адреса тоже меняются и тут тоже есть нюанс. Если просто для документов нужен адрес, то хранить тупо строкой и забить. Если как-то связано с выгрузкой отчётности, то там уже нужно деление на куски и сверка с КЛАДР.
2. Не знаю специфики, как я себе это представляю: заключается договор на аренду склада и прописывается, что платит фирма А, которая привозит на склад 10 мешков цемента и ведро маринованных огурцов, потом приезжает фирма Б, забирает огурцы и еще фирма В забирает цемент. Вообще не вижу смысла разносить их по разным таблицам, данные у фирм одинаковые. Нужно только хранить для конкретных ТМЦ кто привозит, кто забирает и т.п. Таблицы Договор и Поставка/Перемещение просто завести и не нужно никого ни с кем делить. А то начнётся, что будет булево поле, по которому будет видно, кто привозит, а кто забирает. У пользователя это будет выглядеть как галочка и он должен внимательно на эту фигню смотреть и при генерации отчетов и документов та же история будет.
3. У организаций может быть несколько счетов и могут меняться реквизиты каждого счета (в зависимости от задач, можно поддерживать версионность внутри счёта или просто при изменении одного реквизита заводить новую запись, а старую делать неактуальной). Сейчас, например, периодически меняют БИК и кор.счет у банков. Соответственно, у счетов есть сроки действия. Нормальные организации рассылают заранее письмо, что у их банка меняются реквизиты, т.е. должна быть возможность сразу забить новые реквизиты и дать программе использовать только актуальные реквизиты.
БИК, кор. счет, наименование банка - это по идее отдельный справочник. Наименование получателя лучше дополнительно здесь хранить, т.к. бывают лицевые счета (в основном у гос. структур счета идут как лицевые в каком-нибудь казначействе).
Еще иногда за одну организацию платит другая организация. В идеале этот момент тоже проработать. Договор с ООО "Ромашка", а деньги приходят от ООО "Букашка" с назначением платежа "Оплата за ООО "Ромашка" по письму № Г от вчера за аренду склада по договору такому-то". Это вполне обычная операция, по бухгалтерии проводится, лучше тоже предусмотреть.
4. Имя контрагента. Возможно, есть смысл сделать как в 1С и хранить два наименования. Официальное как в учредительных документах и удобное для пользователя. Мало кому интересно смотреть список из
ООО "Ромашка"
ООО Корпорация "Мелиорация"
АО "АБЫР "ВАЛГ"
ПАО "Баобао"

Организационно-правовую форму или удаляют или в конец дописывают, с кавычками и всякими словами корпорация всяко разно пользуются. Люди просто запоминают, что компания называется "Мелиорация" и неудобно вспоминать, что там еще слово корпорация есть, ОПФ непонятна какая, а может недавно сменили. Нужна ООО "Ромашка" - сразу на букву Р побежал смотреть, так удобнее, как мне кажется.

Кот МатроскинLSVНе пойму, ты тролишь или аццки тупишь ??????
Родительские документы могут быть в разных таблицах, Карл !


Паттерн subtype-supertype на этой форуме обсуждается только чуть реже чем EAV - как можно было за столько лет не разобраться в нем?
Как этот паттерн применить к задаче: в таблице нужен FK на документ или контрагента или справочник?
Мне в голову приходит только изначальное введение таблицы с хранением всех ИД и соответствующего типа/имени таблицы.
Эдакая таблица, в которой хранятся все ИД всех таблиц, соответственно, ИД уникальны в рамках базы и во всех таблицах нужно следить, чтобы ИД брались из этой таблицы, а не генерировались свои.
Можно конечно заранее выделить "супертип" для этого набора документ,контрагент,справочник, но завтра условия поменяются и схему БД перекраивать?