mazzyХорошо. Продолжаем развивать тему для размышления.

Возьмем... 1С. Уверен, что большинство участников держит в голове именно эту систему, когда говорят о справочнике контрагентов :)

В 1С:Бухгалтерии... да, можно получить обороты по субконто. Замечательно.
Усложняем задачу. Хотим получить больший, чем в бухгалтерии функционал.
Смотрим в УПП. Смотрим в регистры накопления...

Есть общий регистр ВзаиморасчетыСКонтрагентами и РасчетыСКонтрагентами.
Пока нормально. Но! Есть регистры ЗаказыПокупателей и ЗаказыПоставщикам!
Т.е. вопрос деления и здесь остается. Причем деления именно на два справочника. Почему два? Почему не три, не десять? Именно два?Чегой-то я не понял :(. Два - кого? Рагистра или справочника? Если два регистра , то я готов объяснить, почему. А если два справочника , то могу только повторить вопрос, в дополнение хлопнув кулаком по столу... :)

mazzyПродолжаем разговор.
Смотрим в отчет Ведомость расчета с контрагентами в демобазе УПП.

Типичный пример решения с единым справочником.
Скажите стоит ли нам ожидать денег от компании ЭКИП?
Сколько мы должны оплачивать компании ЭКИП?
Можно ли на основании этого отчета составить ПДДС?Давноооо я не играл в шашки, тьфу, в 1С... :) То есть, что это такое нарисовано - я с трудом понимаю. Кто такие УПП и ПДДС - теряюсь в догадках. Могу лишь констатировать следующий факт, который легко смоделировать в ИНФИНе.
1. Имеется единый справочник контрагентов.
2. Имеется балансовы счет учета расчетов с поставщиками - 60.
3. Имеется балансовый счет учета расчетов с покупателями - 62.
4. Имеется балансовый счет учета авансов, полученных от покупателей - 64.
5. Имеется забалансовый (вспомогательный) счет (регистр) учета Заказы покупателей - 62А.
6. Имеется забалансовый (вспомогательный) счет (регистр) учета Заказы поставщикам - 60А.
Теперь допустим, что на всех пяти счетах (регистрах) отражена одновременно информация по одному и тому же контрагенту "ЭКИП". Открыв аналитическую карточку по ВСЕМ счетам (всем регистрам) для контрагента "ЭКИП", можно увидеть, что:
1. ЭКИП перечислил ранее нам аванс, в результате у нас перед этим контрагентом имеется задолженность на сумму 20'000 рублей.
2. ЭКИП сделал нам два заказа, один из которых находится в процессе исполнения, возможность выполнения второго - изучается. Сумма по первому заказу зафиксирована - 8'000 рублей. По второму заказу контрагентом высказано условие, что сумма, на которую он согласится, не должна превышать 5'000.
3. Ожидать в ближайшее время поступления дополнительных денег от этого контрагента бессмысленно, потому что его аванс больше суммы обоих заказов.
4. Невыполненных заказов от нас ЭКИП, как поставщиком, нет.
5. Поставленного и не оплаченного нами от ЭКИП, как от поставщика, товара имеется на сумму 3'000.
6. Итого наша задолженность на текущий момент перед ЭКИП составляет 20'000 + 3'000 = 23'000 рублей.
7. Если больше ничего существенного в наших отношениях не произойдет, заказы будут выполнены и закрыты, то наша задолженность перед ЭКИП станет равной 23'000 - (8'000 + 5'000) = 10'000 рублей.

mazzyИтак, нужно ли в систему с единым справочником вводить некий статус для РАЗДЕЛЕНИЯ данных. Чтобы продавцы видели свои, а снабженцы видели свои данные.

Т.е. Нужно ли, чтобы продавцы видели только задолженность компании ЭКИП в 190.92уе и ждали платежа, а снабженцы видели только нашу задолженность 297уе. Или нужно, чтобы система автоматически зачитывала (суммировала) задолженности?

Если нужно делить, то как? (и мы снова возвращаемся к исходному вопросу :) )Имхо, АВТОМАТИЧЕСКИ - не нужно. Если у нас разные сотрудники занимаются покупками и продажами, то одни из них будут заглядывать в содержимое счетов 60 и 60А, другие - в содержимое счетов 62, 64 и 62А. Но иногда может понадобится разом посмотреть, что имеется где и в каком количестве. Например, как раз для того, чтобы уточнить сумму зачета. Вместо того, чтобы шарить по разным счетам и выписывать цифирьки на бумажку, можно увидеть их в едином отчете.

Я приведу еще один пример. В нашей фирме УСЛУГИ , оказываемые нам сторонними организациями, проводятся через 76-й счет. А закупка товарно-материальных ценностей - через счет 60. Имеется вполне конкретная фирма "Гарант-сервис", которая единовременно продала нам некий программный продукт (справочно-нормативную базу данных по законодательству), но это еще не всё. Кроме этого, Гарант-сервис предоставляет услуги по сопровождению этой базы данных - регулярное ее обновление. На поставку может быть один договор, на услуги - другой. Иногда эти вещи объединяют в одном договоре. Но проводится все равно через РАЗНЫЕ СЧЕТА , причем наша бухгалтерия очень четко отслеживает, чтобы в подобных ситуациях было четко указано, сколлько стоят услуги, а сколько - сам приобретаемый продукт.
Теперь представим, что договор заключен ОДИН, и в нем фигурируют и услуги, и продукт. Как можно увидеть корректное сальдо взаиморасчетов, если учет взаиморасчетов по одному договору ведется на РАЗНЫХ счетах? В ИНФИНе увидеть это сальдо - нефига делать.

mazzy GaryaНо проводится все равно через РАЗНЫЕ СЧЕТА , причем наша бухгалтерия очень четко отслеживает, чтобы в подобных ситуациях было четко указано, сколлько стоят услуги, а сколько - сам приобретаемый продукт.
Сколько таких субсчетов должно быть?Сколько надо, столько и будет. Сколько мы хотим видеть разнородных операций, столько и заведем.

mazzyСколько групп? В твоей реплике явлно выделены две группы 62 и 60.
Почему две?Это просто в примере две. Почему? Потому что есть план счетов по ведению бухгалтерского учета и инструкция по его применению. И не только поэтому. Потому что в других регламентных документах сказано, что для взаиморасчетов, осуществляемых в валюте, имеются нюансы в законодательстве. Посему мы на каждом счете заведем дополнительные субсчета - для учета взаиморасчетов в валюте. Но если мы захотим свернуть все субсчета счета 62 в один синтетический субсчет - нет проблем. Если мы захотим увидеть обороты по одной организации, взаиморасчеты с которой производились и в рублях, и в валюте, в едином отчете - тоже нет проблем. Если у нас выявятся еще какие-то причины для группировки определенных операций на отдельных субсчетах, мы заведем еще субсчета. Тоже нет проблем.

Mazzy GaryaТеперь представим, что договор заключен ОДИН, и в нем фигурируют и услуги, и продукт. Как можно увидеть корректное сальдо взаиморасчетов, если учет взаиморасчетов по одному договору ведется на РАЗНЫХ счетах? В ИНФИНе увидеть это сальдо - нефига делать.
Свернутое - и в УПП легко.
А вот развернутое....Что понимается под словом "развернутое"? Отдельно по разным субсчетам? В ИНФИНе это видно автоматом в стандартном отчете (ничего настраивать не нужно). В нижней его части - итоговое свернутое. Можно получить развернутое (дебеты отдельно - кредиты отдельно) тоже в стандартном отчете. Можно настроить custom-отчеты, которые будут показывать развернутое сальдо только по некоторым аналитикам, группировать информацию, показывпая в разных местах отчета итоги и какие-то особо интересные подробности. И даже производить некоторый анализ и выдавать текстовые комментарии к наблюдаемой в отчете информации. Конечно, custom-отчеты нужно ручками делать. Но если в лом колупаться, то можно воспользоваться и стандартным отчетом, на ходу включая и выключая в нем фильтр по задываемым условиям (например, выбрать только некоторые счета и субсчета, а остальные опустить).

mazzyА вот в управлении производственным предприятием (УПП) - развернутое получить очень непросто. Почему?Не знаю, действительно ли это так сложно. Но если сложно, значит у разработчиков ручки кривые.

mazzyА потому что разработчики начали от единого справочника. Почему?Да нет, не поэтому. См. чуть выше.

mazzyПримерно две - хорошо сказано. :)Не "примерно", а "в примере"... :)

mazzyВ 1С:Бухгалтерии тоже просто.
До тех пор пока не хочется чего-нибудь посложнее.
Например, как по данных бухгалтерского учета определить просроченную дебитторскую задолженность? :)Заводится аналитика "просроченная/не просроченная" (субконто в понятиях 1С). Далее делать на них проводки, в том числе автоматом - дело техники.


mazzyЕсли вы объединяете дебиторов-кредиторов, то легко получаете свернутое сальдо (с учетом взаимозачетов), но надо дополнительно программировать получение развернутого. И наоборот.

Так вот, вопрос разъединять-объединять сущности решается НЕ в "каждом конкретном случае", и НЕ "по месту". И ни в коем случае НЕ по техническим соображениям (уникальность идентификаторов)

Вопрос разъединять-объединять решается на основании анализа требований - какой функционал требуется чаще ! Если в основном требуется функционал для работы с развернутым сальдо (отдельно покупатели, отдельно поставщики), то дебиторов и кредиторов удобнее разделить. А функции для взаиморасчетов допрограммировать дополнительно.Всё примерно так, как ты и говоришь. Реализуется тот функционал, который нужен чаще . А тот, который ТОЖЕ НУЖЕН, но режже , зачастую вообще не воплощается в жизнь. Когда же этот самый редкий случай накоец произошел, то высняется, что система под него не приспособлена.
Единый справочник МОЖЕТ позволить делать из него выборки по разным условиям. Можно добавить условия, поля-атрибуты и т.д. и т.п. потом, позже, когда в них возникнет необходимость. Можно динамически определять принадлежность контрагента к "покупателям" и к "поставщикам" в зависимости от того, из каких счетов на них фактически были ссылки. Но объединить необъединяемое то, что изначально было разъединено - это не хухры-мухры. Не веришь? Могу выслать базу данных с таблицами поставщиков и покупателей, над объединением которых я в свое время голову ломал. Попробуй свои силы... :)

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

Поэтому и присутствуют несколько ОТДЕЛЬНЫХ справочников. Дебиторы-кредиторы-бизнесотношения-рабочие центры и т.п.Просто так было проще сделать, вот и всё.

2 saasa. Это, как бы, интуитивно ясно, с одной стороны. С другой стороны, постановка задачи обычно ставится на той картине бизнеса, которая имеет быть сейчас. А через пару лет может выясниться, что все нужно было делать по-другому. И, что самое интересное, оказывается, был выход два года назад. Можно было сделать так, чтобы сегодня не переделывать. И этот выход - в объединении всего, что только можно объединить.

Я приведу пример из своей практики. Был холдинг, в который входило несколько юрлиц. В каждом юрлице был свой главбух, работали они относительно автономно, каждое из них занималось отдельным видом бизнеса. Общие у них были только владельцы. Консолидация производилась только сведением данных нескольких балансов в один (уже с балансов, а не с какой-либо первичной информации). Когда приобретали учетную систему, решили учет для каждого юрлица сделать автономным. Так действительно было проще, причем существенно проще. Меньше всяких заморочек, меньше завязок между бухгалтерами. Кто-то колупает еще позапрошлый месяц, кто-то работает день-в-день. Но постепенно холдинг видоизменялся. Некоторые виды бизнеса постепенно расползлись по нескольким юрлицам. Понадобилось на оперативном уровне координировать работу этих юрлиц. Понадобилось видеть, например, сколько конкретного вида товара находится ВООБЩЕ В ХОЛДИНГЕ, у всех юрлиц одновременно, причем не только в суммовом, но и в количественном выражении, с отслеживанием статусов прохождения разных фаз и т.д. и т.п. Понадобилось видеть картину взаиморасчетов с контрагентами ПО ХОЛДИНГУ ВЦЕЛОМ... И вот вызывает тебя высшее руководство и говорит:
- Гхммм... Мы тут подумали, и решили, что учет по холдингу должен вестись в единой базе данных. Нужно объединить базы данных всех двенадцати юрлиц в одну.
- !!! 8(
- Вас что-то смущает?
- Я просто думаю, как это можно сделать. У каждого юрлица около полутора десятков разнородных справочников только по предприятиям (у кого-то комиссионеры свалены в одну кучу с покупателями, у кого-то валютные контрагенты отделены от рублевых и т.д. и т.п.). 12 юрлиц * 15 справочников = 180 справочников контрагентов, которые между собой требуется состыковать. У каждого юрлица свои справочники товаров и продукции, свои справочники материалов. У кажого юрлица свой справочник сотрудников, а некоторые сотрудники холдинга числятся одновременно сотрудниками нескольких юрлиц - и по ним тоже нужно видеть общую картину (по зарплате, например). Батюшки светы!!! Проще внедрить несколько ERP-систем на заводах масштаба Автоваза, нежели объединить всё это хозяйство в одну базу... Тут человеческой жизни не хватит!

Разумеется, можно было сразу все юрлица запихать в единую базу данных на этапе первоначального внедрения. Но при этом повысились бы требования к исполнителям-юзерам. Может быть, где-то кто-то вынужден был бы видеть не только "свою" информацию, но и ту, которую ввели другие пользователи. Больше телодвижений по контролю информации, более жесткие требования к срокам ее отражения в системе, к составу информации (может понадобиться заполнять те поля, которые пользователь раньше не заполнял). Разумеется, всё это в некоторой степени напрягает. Вот и стоит вопрос - что важнее, решить сегодняшнюю задачу наиболее легким способом, но при этом загнать себя в угол назавтра, либо все-таки несколько напрячься сегодня, чтобы завтра иметь пространство для маневра. Так что этот вопрос не совсем "сугубо индивидуальный", имхо. Но отчасти и методолический.