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

[sukhanchik]

Цитата:

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

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

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

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

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

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

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

Цитата:

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

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

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

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

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

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

Цитата:

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

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

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