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

[Владимир Максимов]

Цитата:

Сообщение от Maxim Gorbunov

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

Достаточно только второго пункта. Первый уже решен на уровне стандарта. Через настройки

Цитата:

Сообщение от Maxim Gorbunov

При этом, проверять то, что логика не нарушена, вам придётся после установки каждого сервис-пака. Как программист могу вам сказать, что проверять "неконфликтность" такой логики гораздо сложнее, чем логики по протаскиванию данных из заказа в документы.

Мой опыт показывает, что функционал "вообще", а особенно "вокруг" заказов всегда очень сильно кастомизирован. Сложности при установке сервис-паков будут в любом случае. Отдельная функция, запрещающая частичную разноску вряд ли как-то существенно повлияет на сложность обновления...

[Владимир Максимов]

Цитата:

Сообщение от Maxim Gorbunov

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

На самом деле так оно и есть. Пользователям некогда делать "тонкую" настройку, для "вырезания" части товара при разноске. Чем меньше движений мышкой и клавиатурой, тем лучше

И совершенно не вызывает удивления тот факт, что мультиварку начинают использовать как обычную кастрюлю... Ну, в лучшем случае, как скороварку...

[Maxim Gorbunov]

Цитата:

Сообщение от Владимир Максимов

Отдельная функция, запрещающая частичную разноску вряд ли как-то существенно повлияет на сложность обновления...

Её реализовывать можно по-разному. Можно действительно просто проверить во время разноски, не изменили ли пользователи количество в строке и количество строк, но это достаточно глупо. Зачем давать пользователю возможность менять это количество, если такое изменение приведёт к ошибке? Если же подойти к вопросу более ответственно, чем с настроем "и так сойдёт", то нужно исключить возможность изменений при разноске. А вот тут уже объём модификаций вырастет серьёзно.

[Maxim Gorbunov]

Цитата:

Сообщение от Владимир Максимов

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

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

[RVS]

"я фигею, дорогая редакция..."

Это правда - или всерьез тут люди обсуждают - "а бывает ли частичная разноска заказа?"

===

Коллеги.. бывает, еще как - бывает.. и - кста - не бывает "частичной разноски заказа", бывает частичная отгрузка по заказу.. ну, со всеми вытекающими..

И это - нормальный, кстати, кусок нормального бузинесс-процесса...

==

Я - тупой (с)

[Ivanhoe]

Цитата:

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

Это правда - или всерьез тут люди обсуждают - "а бывает ли частичная разноска заказа?"

Я бы сказал так: из-за "общего случая" с множественными отгрузками значительно усложняется один из очень распространенных случаев 1 заказ = 1 накладная. Т.е. в идеальной системе лучше бы иметь возможность выбрать, как заказы должны обрабатываться - так, или иначе.

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

Просто MS рассказывает клиентам, какая классная "коробочная" система, а по факту в ней многие процессы не настраиваются, а программируются.

[macklakov]

Цитата:

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

Я бы сказал так: из-за "общего случая" с множественными отгрузками значительно усложняется один из очень распространенных случаев 1 заказ = 1 накладная.

Что-то не до конца понимаю, в чем сложность? Залочить заказ после разноски confirmation и остальные документы разносить минуя форму SalesEditLines совершенно незначительная модификация. Если так уж популярно, можно клиентам как бонусное "отраслевое решение" предлагать.

[Ivanhoe]

Так и предлагают. Так везде можно допилить. Мы ж вроде про стандарт говорим? Или каждый про свое "решение" тут обсуждает - можно в нем черновик удалять или нет?

P.S. указанной доработкой дело не ограничивается.

[Maxim Gorbunov]

macklakov, а дату накладной где тогда указывать? А подбирать packing slip'ы? А если нужно разрешить разноску без проверки кредитного лимита, то что делать? Нет, прятать форму SalesEditLines, по-моему, не выход.

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

[KiselevSA]

(плюну немного с высоты своей колокольни)
Многие рассматривают заказы только со стороны учетной системы и забывают про управленческую отчетность. Предположим, что мне нужно в "отчетной" базе получить OLAP отчет в разрезе, который на фиг не нужен в учетных документах. Вы скажете: "Тащите все поля в документы". А если таблица заказов у меня уже состоит из двух таблиц, т.к. полей в SalesTable уже слишком много? Тащить все? Плюс создать все поля, которые закрыты конфигурационными ключами в заказах: а вдруг потребуется включить.
(резюме: на маленьком количестве проектов (работал только на стороне клиента) запрещали удаление и редактирование проведенных заказов при любых операциях (ну кроме truncate table))

[Raven Melancholic]

Со стороны клиента могу сказать, что видел системы, в которых были подходы как "один заказ - одна накладная", так и "один заказ - много накладных".
В компании, в которой работаю сейчас, по одному заказу вполне может быть множество отгрузок. Это машиностроение, по одному заказу сроки поставки могут быть от недели до 15-20 недель. При этом клиент забирает оборудование поэтапно. Разбивать один заказ на несколько под ожидаемые отгрузки нельзя, так как заказ представляет собой план отгрузок клиенту по одному объекту (складской комплекс, стадион Сочи 2014, станция метро и т.п.), но в рамках объекта есть этапы, причем, порядок их использования заранее клиент сказать не может.
В свое время мы допустили ошибку при создании отчетности - часть данных берем из заказов. В результате в системе есть несколько десятков тысяч заказов (число строк измеряется сотнями тысяч), а смысл их существования один - нужно в нескольких отчетах, больше никаких причин их присутствия в базе нет.
Когда полностью закончим проект ОЛАП (у нас он основан не на данных DAX, а на внешнем хранилище), будем безжалостно убивать заказы, по которым больше не требуется отслеживания отгрузок.

[Rezervforall]

В сводном планировании есть запрос о подтвержденных заказах с ссылкой на номера заказов на покупку и данными утвердившего. Для меня это:
1. Спланировали, покрутили планы, скорректировали.
2. Утвердили план у руководства (в системе утвердили спланированные заказы на покупку), получили пул заказов на покупку
3. Как мне понять дальше что утвердили, как исполнили утвержденное? В системе это например частичная поставка (или перепоставка) и разноска недопоставки с параметром "Окончательная", для назначения статуса "Оприходовано" заказу на покупку и информацией по недопоставленному в заказе. Эту информацию я потом использую для расчетов (например прогнозов или KPI службы планирования или снабжения).

[ap]

Цитата:

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

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

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

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

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

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

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

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

[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 решения.

[Maxim Gorbunov]

Цитата:

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

Поэтому Quotation не включают в happy\uphappy отчетность, поскольку их нельзя считать оформившимся желанием клиента.

Сбор данных о намерениях клиентов - это, по смыслу, функция CRM-решения. Это я не применительно к Аксапте хотел заметить, а в принципе, с точки зрения дизайна систем. А если с точки зрения Аксапты, то для сбора пожеланий клиентов есть opportunities и leads.