Являются ли таблицы логов, прав доступа справочниками. Иными словами, все, что не документ - справочник. Что вы, при разработке, понимаете под справочниками?

То есть какие признаки у справочника:
- Добавление и редактирование пользователем;
- Отсутствие логики проведения (проверка только на заполнение обязательных полей);

что еще?

Тогда в чем отличие документа от справочника? Например, Договор с контрагентом - это справочник или документ?

iscrafm,

если я правильно вас понял, то справочником вы называете интерфейс доступа к списку данных.
Однако мне кажется, сущность Город и сущность Платежное поручение нужно как-то разделять. Хотя бы с технической точки зрения, Платежное поручение может иметь логику проведения и перепроведения (если используем регистры). В то же время для Города актуальным будет только удаление (вернее пометка на удаление, деактивация).
Документ фиксирует факт хозяйственной деятельности, например Отчет о контакте менеджера с контрагентом , Приход на склад , Договор поставки . Наверно, по этому принципу следует разделять справочники и документы. Теоретически, документ может создавать справочник (скажем, если у нас добавление города является выходом бизнес-процесса. Вначале мы проводим документ "Запрос на добавление города", а затем "Утверждение запроса на добавление города" или "Отклонение...".)

Сергей Васкецов,

вы считаете это неправильным? Мне кажется, есть разница между добавлением экземпляров сущностей Номенклатура , Контрагент и Договоров. Хотя она как будто и не настолько очевидна по сравнению с разницой между тем же Платежным поручением и добавлением нового Города .

iscrafmЗамените "проведение" на "учет","разноску" и т.п. (главное чтобы позаковыристей, чтобы не сочли простецким) или выдумайте свой. Главное чтобы Вам было понятно и тем, кто будет пользоваться системой.

1с настолько популярен, что многие из их терминов стандартизировались. Плохо ли, хорошо ли - отдельный вопрос. Не думаю, что для обозначения одних и тех же сущностей стоит изобретать свой термин... В общей массе намного больше людей поймут, что значит " Провести документ" по сравнению с " Разнести документ". Я уж не говорю о том, что интерфейс такой программы будет более дружелюбным для пользователей, имеющих опыт работы с 1с.

Хотя ваша логика лично мне нравится. Добавляем экземпляр учетной единицы Город, нажимаем "Учесть", запускаем любые процессы, которые в принципе очень могут походить на процессы, запускаемые по кнопке "Учесть" в Платежном поручении. А Город, Справочник, Документ использовать как префикс к названию, опираясь на традиции...

NafДокумент - факт отражения в учете. Примеры: Поступление товаров, Заявка на подключение услуги, Приказ об увольнении.
...
Насчет того, что есть Договор вопрос довольно спорный. Но обычно это достаточно постоянная величина, потому отношу ее к справочникам.

Изменение в договоре, оформленное в виде дополнительного соглашения, которое делает движения по регистрам - уже документ?

ддддддЛюбой проведенный документ - величина постоянная.Его нельзя даже редактировать, можно только сторнировать другим документом.

А в сторнированный документ вносится какая-то отметка о его не актуальности. То есть диаграмма статусов документа получается:

Записан
Проведен
Сторнирован (вместо Отменен)
Помечен на удаление (возможен только для записанных документов).

NafНе всегда это так. Зависит от бизнес-логики.

Если не затруднит, приведите пример, который не укладывается в концепт дддддд...

Александр ГoлдунЛадно, такой справочник про города - действительно нечто фантастическое. Возьмем более приземленный и реальный пример - номенклатура на производстве. В зависимости от бизнес- и техпроцессов, запись может иметь достаточно большое количество статусов.

Вопрос в том, что назначение каждого статуса может требовать какой-то проверки, для чего запускается процедура в БД. Более того, при определенных статусах может потребоваться авто-создание каких-то экземпляров сущностей. Теоретически, определенные количественные значения из номенклатуры могут отразиться в регистрах, используемых для ускорения подсчета итогов. Соответственно, изменение статуса на более ранний могут сделать откаты. И получаем уже, что документ - это частный случай справочника :)) с той лишь разницей, что статусов у него 2 Проведен/Не проведен, а у справочника может быть несколько.

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

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

Александр Гoлдунromaro
И получаем уже, что документ - это частный случай справочника :)) с той лишь разницей, что статусов у него 2 Проведен/Не проведен,
Вы сильно заблуждаетесь, и причиной этого мне сильно кажется 1с. Выбросьте из головы навязанные оттуда догмы - вам же легче будет. Я упарился в свое время объяснять одинэсникам, почему мне не нужно для заказа на поставку понятия проведения, зато нужна развернутая диаграмма состояний с кучей возможных переходов и примерно с десятком статусов. Когда я понял, что случай клинический и объяснить им это невозможно, я просто сказал "сделайте ТАК" и дал детальное описание чего хочу.

То есть документ, справочник, лог и т.д. - это косвенное понятие, опирающееся на однотипную схему статусов. Документом мы привыкли называть то, что имеет типичную для этого вида сущностей диаграмму статусов. Так? Одним из плюсов такого подхода, как я понимаю, является простота миграции справочников в нечто большее (регистр процесса?). Например, вначале позиции номенклатуры вносил один оператор (и статусов было 2 активен/не активен), но постепенно был выработан процесс, требующий трехзвенного утверждения. Либо договора. Часть из них необходимо утверждать в бухгалтерии, другие не требуют этого.
При вашем подходе никакого деления на документы, справочники и логи не существует. Существуют только учетные записи с присущей каждой из них диаграммой состояний (статусов).
Процедуры обычно запускает событие инициирующее смену статуса?