Какое привести обоснование того, что контрагентов не надо разделять по разным справочникам: покупатели, поставщики и т.д.? :)

Например, когда контрагент будет одновременно и тем, и другим.
Бюджет - это поставщик или покупатель?
А вообще, расскажи об этой проблеме разработчикам scala, например)

(0) на каждого контрагента - свое значение в перечислении

Банк который вам за услуги счет выставляет - это кто поставщик или покупатель? Алименты вы заплатили кому поставщику или покупателю?

на каждого контрагента- своя база

А вообще проблема надуманная. Что мешает физически держать всё в одном справочнике, а пользователю показывать список с установленным отбором

(0)Яви им чудо папок в справочнике!:-)

(0) Скажи "Я специалист! Мне виднее!"

в в бухгалтерии 6.0 так и было разделено на покупателей и поставщиков. и умный проффесор из плешки писал что это правильно.

А что, разделять религия строго запрещает?

Скажите, вопрос - стеб или нет?

Как разница сколько справочников?
Сделай им две кнопки "Поставщики" и "Покупатели"
При нажатие просто отбирай контрагентов.

В большинстве дргуих систем они почему-то разделены на Customer и Supplier. Приходит такая дурацкая мысль что они просто не нашли подходящего слова в английском языке чтобы назвать справочник где и те и другие :)

каждому контрагенту свой счет в плане счетов!

(10) это вброс какой-то вобще

(12) кстати да.. ща с такой системой мудохаюсь - данные переношу :)

Customer и Supplier разнесли по разным таблицам, а 100500 видов документов свалили в одну Documents   :)

тот еще гемор блин

(0) Эх....я бы занялся такой базой....сдельно.
Ещё и номенклатуру разделить надо.
А организации - константами, для каждой - свою.

(16) Уже разделили.
Карандаши в одном справочнике, Блокноты - в другом. :)

а что плохого в том что на одного контрагента несколько элементов?

Только то что: непорядочек. Ну да это можно пережить

(17) Предложи им еще разделить номенклатуру на закупаемую и продаваемую ;)

(10) Это не стеб.
Человек с физико-математическим образованием приказывает обосновать.

То,
что контрагент может одновременно быть покупателем, поставшиком, подрядчиком, физлицом и т.д. - не аргумент.
То, что так заведено в типовых решениях - не аргумент.

Догмат такой: таблицы раньше объединяли для экономии места, зачем сейчас экономить?

(18) Ну а как консолидированный отчет по нему получить?

(21) SQL больше 256 таблиц не переваривает в запросе.

(23) разве в 2008 это не поправили?

(12) у них просто нет 60, 62 и 76 счетов ))

(23) юзай пакет запросов :)

(0) Объясни так: "в типовой справочник один, а разделять на несколько мне лень, долго, и много где править придется (в отчетах и т.п.). Для типовой это слишком затратно". Если проект рисуется "с нуля" - тогда без разницы, сколько будет справочников.

(21) Акт сверки как будете делать?

(21) пусть этот физмат бухучет курит

(6) не взлетит

(28) акт сверки по договору, договор в типовых может быть с покупателем ИЛИ поставщиком

кстати, зачем в таблицах документов хранить организацию и контрагент, если есть договор? пусть вот подумает над таким вопросом

(31) Один договор будет для двух записей в разных справочниках?

(21) А может он сослаться на какую ни будь теоретическую базу под эту фразу - "Догмат такой: таблицы раньше объединяли для экономии места, зачем сейчас экономить?"
Чушь какая-то...
От того что информацию разделить на две таблицы, информации меньше не станет.
Посылай его к трем нормальным формам.

(24) Даже если это так - об этом говорить не обязательно ;)

(26) Чем тебе поможет пакет, если у составного типа в регистре будет более 256 таблиц цепляться? Будешь 100500 ВЫРАЗИТЬ() на каждое поле писать?

Есть вариант валить из этого странного места пока дело не дошло до регистов расчета.

(33) почему один? также два, для двух таблиц контрагентов ))

я бы еще и контрагентов с "организациями" объединил...

(38) и со складами/магазинами

(38)(39) Заводим 1 УниверсальныйСправочник и 1 УниверчальныйДокумент - и профит! :)

(17) Не нравится - отдай клиента, я им ещё договора в перечислениях нарисую, а документы через справочники реализую. Сдельно, конечно.

(0) Разделение на поставщика и покупателя:
1) требует проводить ручную работу по связыванию оных => вероятность человеческой ошибки.
2) усложняются отчеты по балансу с контрагентом и т.п.
3) как заводить юр. лица для двух справочников? Тоже 2 отдельных справочника или же 1 но с привязкой к 2-м владельцам?

(40) Садись, два ! Нужен ещё Универсальный регистр и Универсальный отчет.

(40) заводим сущность, туда кидаем и справочники и документы

(43) а главное универсальный солда.. пользователь :)

(44) Справочник нужен так как ОДИНЭС рекомендует для учета - заполнять справочники ! Элементарных вещей не знаешь, а ещё программист !

(43) Отчет внешний за отдельные деньги, регистр не нужен. Если же справочник и документ! :)

(44) 1С не поддерживает...

Аргументы?
1. Правило номер один программиста - минимум исправлений в типовой конфигурации. Все, что можно сделать внешними отчетами и обработками - нужно делать внешними. Исправление справочника контрагенты приведет к тому, что нужно переписывать ВСЕ отчеты, обработки, документы. Трудоемкость обновлений и сопровождений возрастает в десятки, если не сотни раз.
2. Понятие "Контрагент" включает в себя набор реквизитов, одинаковых для продавца и покупателя. Одно отличие - "вид контрагента" - где и указано, покупатель, продавец или "прочее" (бывает и так!) С точки зрения логики построения баз данных, их целесообразнее хранить в одном месте.
3. Внутри контрагента можно создавать много договоров, в которых и указывать - с покупателем или продавцом. В разрезе этих договоров и можно вести учет.
4. Можно рассортировать покупателей и продавцов по папкам.
5. А какие аргументы ЗА создание отдельных справочников?

(21) Для экономии места... Но если контрагент и поставщик и покупатель, хранится в разных таблицах... Не засорение ли это дискового пространства?

(39) В одной контре так и сделали - контрагенты, склады, реализаторы, сотрудники, физлица и банки были в одном справочнике.