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

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

что еще?

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

iscrafm,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ддддддТак же как мне сейчас пришлось добавить еще один пост, чтобы исправить опечатку
ислу на силу

Как говорится - слово не воробей...

По идее, если данные в программу вносятся на основании первичных документов, исправление которых не допускается, редактировать такие "производные" данные в программе нельзя.

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

Топик погряз в частностях :(