черновики (заказы) - могут удаляться. Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы.

[ap]

Цитата:

Сообщение от mazzy

вынес обсуждение в отдельную тему

логика работы системы такая:
* журналы - суть черновики.
* черновик может правится пользователем в любой момент ПОКА не разнесен.
* черновик может быть удален в любой момент
* разноска журнала полностью переносит информацию из черновика в фактические таблицы (в т.ч. в таблицы журнализации)
* черновик может дать информацию об ожидаемых операциях (но не факт, что эти ожидания сбудутся), факт нужно собирать по фактически сделанным операциям.

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

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

Тоже неоднократно сталкивался с такой позицией, и всякий раз удивлялся. Как так удалять заказы? С точки зрения отчетов по продажам - да, вопросов нет, факт строится по транзакционным таблицам и таблицам документов, не по заказам. В этом смысле они не нужны.
Но! Разве бизнес должен интересовать только факт продаж? А как же отчетность happy/unhappy? А как же план-факт анализ, анализ причин неудовлетворенности спроса. Мое мнение - заказы нельзя удалять, в них бесценные знания о тех резервах развития бизнеса, которые есть у компании. Их только нужно с умом проанализировать.
Компания Амазон, как известно, выросла в гиганта веб-торговли именно засчет того, что анализировала не то, что было продано, а то что было заказано. И даже не только то, что было заказано, но и то, что клиент только планировал заказать или даже только "помыслил" заказать. А сейчас на этом уже вся индустрия держится.
А вы предлагаете заказы удалять. Не только заказы нельзя удалять, но и заказы с типом "журнал" бережно хранить, собирать в кубики и анализировать. Надо конечно предварительно процесс построить так, чтобы это реально был не случайный "мусор" а возникшая у клиента потребность в том или ином виде. Ну и я не беру сейчас в расчет ситуации, когда эти вещи в отдельной CRM системе реализованы.

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

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