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

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

Цитата:

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

Во-первых, не надо прикрываться пользователями. Мысль об "исходном документе" засевают консультанты.

Я бы сказал наоборот. Мысль о "черновике" засевают программисты! Просто потому, что без постоянных отсылок к заказу проще программировать.

Цитата:

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

Во-вторых, еще раз:
* заказ можно разносить частично.

Можно. Но я ни разу не видел, чтобы так делали. В смысле, частичную разноску. Обычно заказ разносят целиком. Именно по той причине, что воспринимают заказ вовсе не как "черновик", а как "исходник". Т.е. цельный и завершенный документ.

Как следствие, заказы не просто не разносят частично, но еще и дополнительный контроль на это дело навешивают, чтобы случайно частично не разнести!

Цитата:

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

В том то и дело:
заказ - черновик. Заказ - не исходный документ. Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы. И уже документы, созданные на основании заказа, являются исходными документами.

В том-то и дело, что это точка зрения программиста, который смотрит на систему "изнутри". Со стороны кода и способа хранения данных. Если же смотреть на систему из вне. Со стороны пользователя (или консультанта ). То все выглядит наоборот.

Ну, возьмем простой пример. Купили/продали некий товар. Чтобы создать накладную надо сначала сформировать заказ. Вполне логично делать отдельный заказ на каждую "бумажную накладную". Что в "бумажке", то и в заказе.

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

[sukhanchik]

Цитата:

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

Можно. Но я ни разу не видел, чтобы так делали. В смысле, частичную разноску. Обычно заказ разносят целиком. Именно по той причине, что воспринимают заказ вовсе не как "черновик", а как "исходник". Т.е. цельный и завершенный документ.

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

А теперь берем ситуацию: Клиент хочет купить у нас чего-то, согласно списку (заказу). Из, допустим 20 позиций - у нас в достаточном количестве есть только 15, еще 2 позиции есть, но в недостаточном количестве, а 3-х просто нет. Мы заинтересованы все же отгрузить клиенту весь заказ и мы знаем, что мы можем отгрузить, но просто на данный момент еще не весь заказ готов. А клиенту нужно купить у нас срочно в первую очередь именно те позиции, которые у нас есть, а остальные он покупает что называется "до кучи". Мы ему с радостью отгрузим то, что ему жизненно необходимо и пообещаем потом "довезти" и довезем. Мы также понимаем, что при нашем отказе отгрузить клиенту товар хотя бы частично - клиент может и сорваться.
Конечно эту ситуацию можно решить через отдельные заказы; через копирование заказов и т.д., воспринимая заказ на продажу, как одну накладную Торг-12. Но по факту-то это не так. По факту-то был один заказ, просто он раздробился. И дробя заказы - мы теряем связь с родительским заказом. Ну или надо кодить связку. Существующий функционал частичной отгрузки позволяет видеть в системе реальное количество именно заказов клиентов, а не "преднакладных".

А теперь возвращаемся к вопросу анализа данных. Бумажные данные - это накладные. Введенные данные - это данные от звонка / email-а клиента. Эту разницу должны понимать люди, анализирующие эти данные. Если они эту разницу не понимают или им не нужно понимать (например, никогда не может возникнуть такой ситуации в отдельно взятой компании) - то вполне логично, что тут можно опираться и на данные заказа. Их еще будет раздражать промежуточная форма разноски и вообще сам факт ввода данных не в таблице накладных .

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

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

Цитата:

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

А теперь берем ситуацию: Клиент хочет купить у нас чего-то, согласно списку (заказу). Из, допустим 20 позиций - у нас в достаточном количестве есть только 15, еще 2 позиции есть, но в недостаточном количестве, а 3-х просто нет. Мы заинтересованы все же отгрузить клиенту весь заказ и мы знаем, что мы можем отгрузить, но просто на данный момент еще не весь заказ готов. А клиенту нужно купить у нас срочно в первую очередь именно те позиции, которые у нас есть, а остальные он покупает что называется "до кучи". Мы ему с радостью отгрузим то, что ему жизненно необходимо и пообещаем потом "довезти" и довезем. Мы также понимаем, что при нашем отказе отгрузить клиенту товар хотя бы частично - клиент может и сорваться.

Конечно эту ситуацию можно решить через отдельные заказы; через копирование заказов и т.д., воспринимая заказ на продажу, как одну накладную Торг-12. Но по факту-то это не так. По факту-то был один заказ, просто он раздробился. И дробя заказы - мы теряем связь с родительским заказом. Ну или надо кодить связку. Существующий функционал частичной отгрузки позволяет видеть в системе реальное количество именно заказов клиентов, а не "преднакладных".

Описана в чистом виде организационная проблема. В смысле, выбранный способ решения. Точка зрения на проблему...

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

Т.е. здесь как раз логично делать некий "предзаказ" (Журнал), а потом его разбивать на 2 "окончательных" заказа. Вопрос даже не организации работы, а точки зрения.

Цитата:

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

А теперь возвращаемся к вопросу анализа данных. Бумажные данные - это накладные. Введенные данные - это данные от звонка / email-а клиента. Эту разницу должны понимать люди, анализирующие эти данные.

Угу. Разделение заказов на "предварительные" (журнал) и окончательные (заказ) снимает эту проблему и еще кучу сопутствующих.

[Maxim Gorbunov]

Цитата:

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

Можно. Но я ни разу не видел, чтобы так делали. В смысле, частичную разноску. Обычно заказ разносят целиком. Именно по той причине, что воспринимают заказ вовсе не как "черновик", а как "исходник". Т.е. цельный и завершенный документ.

Как следствие, заказы не просто не разносят частично, но еще и дополнительный контроль на это дело навешивают, чтобы случайно частично не разнести!

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

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

Цитата:

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

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

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

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

[Maxim Gorbunov]

Цитата:

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

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

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

[RVS]

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

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

===

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

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

==

Я - тупой (с)

[Ivanhoe]

Цитата:

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

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

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

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

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

[macklakov]

Цитата:

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

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

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