mazzy tygra[quot Alexey Sh]И реквизиты уж точно должны быть общие. Чтобы потом не получилось, что поставщик и покупатель одна и та же фирма но с разными инн и счетами
Не факт.
Для реального учета вполне возможно, когда один клиент-поставщик предствален несколькими юр.лицамиДа, это действительно реально. Но это всего лишь означает, что справочник юрлиц должен быть иерархическим.

IgorTv mazzyХорошо, подойдем с другой стороны.

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

В какой момент надо делить на разные таблицы, в какой момент надо оставлять разные сущности в одной таблице?

Для начала предлагаю обсудить вопрос: надо ли объединять таблицы дебиторов, кредиторов и сотрудников (да, я знаю системы, где это единый справочник). А каково ваше мнение? Где находится критерий общности?

Критерий общности - некий уникальный внутренний номер адреса и тип этого адреса. В тип адреса можно зашить некие признаки типа Работник (Р), Работники поставщик услуг одновременно (РП), Покупатель (К), Покупатель и поставщик одновременно(ПК). Просто продумать кодировку.
Это основная таблица (1 ключевое поле - номер адреса, тип адреса - признак который может меняться со временем).

Далее нужно цеплять связанные с ней таблицы типа:
1. Почтовые адреса со срокоми годности (2 ключевых поля Номер адреса и Дата С),
2.Таблицу со специфическими для Покупателя данными типа Условий оплаты, отсрочки
3. и т.д.
И так, если надо, то для каждого типа адреса некий набор полей в отдельной таблице.Нет, это не тот вариант. ПМСМ, нельзя завязываться на кодировку. Организация, которая сегодня выступает в роли покупателя завтра может стать поставщиком и наоборот. Могут измениться многие другие условия.
По сути вопроса... 2 Mazzy: хорошо спросил! :) Просто так и не ответишь. Нужно ли замешивать в единый справочник юрлиц и физических лиц? Если нужно, то нужно ли в этот же справочник замешивать и собственных сотрудников? Пожалуй, тут одного на все случаи рецепта быть не может. Хотя, немного поразмыслив именно над этим вопросом, я начинаю склоняться к тому, что нужно их действительно поместить в единый справочник. Добавив дополнительный (extended) атрибуты только для записей определенного вида. Ясно, что покупатель может стать поставщиком. А вот юрлицо превратиться в физическое лицо не может. Поэтому можно добавить атрибут юрик/физик совершенно ничего не опасаясь. Сложнее с атрибутом "собственный сотрудник". Сегодняшний сотрудник завтра может перестать им быть (и наоборот). Однако, это никак не должно отразиться на оборотах по 76-му счету.
Видимо, имеет смысл говорить о "динамических атрибутах", которые могут определяться по заданным условиям и иметь разные значения на разных промежутках учетного времени. Если пойти дальше, можно говорить о "зависимых атрибутах". Например, об атрибут принадлежности сотрудника определенному подразделению или размер его оклада - эти атрибуты имеют смысл только до тех пор, пока физик одновременно является сотрудником. С третьей стороны, размер оклада может изменяться, и нужно иметь возможность отслеживать историю его изменения. Следовательно, это не просто динамический и зависимый атрибут, но еще и атрибут с версионностью. Вот такой у меня получается расклад...

ЗЫ. Ну и в дебри же мы полезли...

Как мне нравится то болото, в которое мы забрели!!! Кроме шуток...
На самом деле вопрос действительно непростой и имеющий прямое отношение к технологии разработки КИС.

Размышления вслух... Если бы я в абстрактной среде, поддерживающей принципы ООП попытался реализовать максимально грамотно и непротиворечиво все справочники, то...
1. Я создал бы класс "субъекты"
2. От класса "субьекты" наследовал бы классы "физики" и "юрики".
3. От класса "субьекты" (а не от "физиков" или "юриков" наследовал бы также классы "покупатели" и "поставщики"
4. От класса "юрики" наследовал бы класс "банки"
5. От класса "физики" наследовал бы класс "сотрудники".
Логично? Пока, вроде бы - да. И вдруг приходит неугомонный mazzy :) и заявляет "а у нас товаром зачастую бывают юрики". И начинаем мы нервно почесываться. Потому что получается, что базовым классом должен был быть не "субьекты" и не "объекты", а вообще "субьекто-объекты". А лучше всего - класс Object. О!!! Самый универсальный подход!!!
И вдруг в голову приходит, что "где-то это дежавю я уже видел"... :) Вспомнил! В C#! Там даже простые типы могут приведены к классу Object. Так, может быть, действительно в этом есть смысл!? Хммм, почему бы и нет?