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

[mazzy]

Цитата:

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

Мое мнение - заказы нельзя удалять
...так ведь?

ap, вы предельно невнимательно прочитали мое утверждение
а также предельно невнимательно прочитали ветку.

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


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

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

При всей кажущейся сложности протаскивания полей, это намного проще, нежели вылавливать (возможно изменившиеся) параметры из заказа.

[ap]

Цитата:

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

а также предельно невнимательно прочитали ветку.

там по моему все почти согласились с утверждением, что "заказы - это черновики".

Цитата:

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

вы не с тем спорите.
Вы говорите: "заказы нельзя удалять" (с точки зрения бизнеса).
Я говорю: "черновики (заказы) могут удаляться" (с функциональной точки зрения)
Обратите внимание, я не утверждал, что заказы нужно удалять

Да с этим то я как раз и не спорю. Я не согласен с другим - с первой частью формулировки в заголовке темы, что "заказы - это черновики" Заказы - это сущность со своей смысловой нагрузкой. Поэтому и не могут удаляться. Это не "черновик" для накладной, а "интерес" клиента, "желание" купить.
А со второй частью, что "факт должен быть в документах" я согласен. Про это я в самом начале написал.

[pitersky]

Цитата:

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

Заказы - это сущность со своей смысловой нагрузкой. Поэтому и не могут удаляться. Это не "черновик" для накладной, а "интерес" клиента, "желание" купить

Строго говоря, это не так. Для пожеланий клиентов есть отдельные сиэрэмные сущности типа Quotation. Заказ - это всё-таки то, что клиент уже согласен купить.

[ap]

Цитата:

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

Строго говоря, это не так. Для пожеланий клиентов есть отдельные сиэрэмные сущности типа Quotation. Заказ - это всё-таки то, что клиент уже согласен купить.

Про вариант хранения этих данных в CRM (системе/модуле) я тоже писал.

Quotation можно так классифицировать, а можно и иначе. Зависит от конкретного решения. Все таки Quotation - это "предложение". Т.е. это скорее наше желание продать клиенту, а не его желание у нас купить. ) На момент появления Quotation клиент еще может не знать, что он хочет это купить.) Он может даже еще не знать о нашем существовании. Зависит от воронки на конкретном предприятии.
Поэтому Quotation не включают в happy\uphappy отчетность, поскольку их нельзя считать оформившимся желанием клиента.
Либо это может быть уже желание купить ("а не купить ли мне.."), но еще не намерение купить ("заверните,беру").
В любом случае Quotation я бы тоже не отнес к разряду "черновиков".

[S.Kuskov]

То подходит или нет к какой-либо сущности определение "черновик", определяется не бизнесс функциями, которыми мы эту сущность наделяем, а конкретной реализацией в системе механизмов работы с этой сущностью. Я хочу сказать, то что заказы в аксапте являются черновиками это не следствие каких-либо размышлений, это фактическое свойство аксаптовских заказов. Заказы в аксапте можно изменять удалять после их обработки - следовательно заказы в аксапте это черновики (по определению если хотите).
Хорошо это или плохо? Это, как говорится, by design. Разработчики решили, вместо того чтобы бороться за целостность данных между заказом и производными документами, проще не наделять данные в заказе каким либо стратегически значимым смыслом. В результате, назначение заказа в аксапте - это предоставление оперативной информации о текущей потребности и только. Если вам нужна аналитика было-стало, то нужно придумывать какие-то новые сущности, в которые запоминать все изменения производимые в заказе. Либо не городить огород, а использовать специализированные CRM решения.