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

[sukhanchik]

Цитата:

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

о_О! Аргумент.

Цитата:

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

Не поправит. После разноски заказ блокируется. Запрет на редактирование. Кстати, эта возможность предусмотрена стандартным функционалом. Правда, по желанию (можно блокировать, а можно и не блокировать)

да, галочка запрета редактирования есть.
да, заказ можно заблокировать от изменений после частичной разноски, а можно и не блокировать.
от этого он не перестает быть черновиком

мне кажется, что стоит разобраться с модальностями и различать: может/должен. и с последствиями

[Maxim Gorbunov]

Цитата:

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

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

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

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

[Maxim Gorbunov]

Цитата:

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

да, заказ можно заблокировать от изменений после частичной разноски, а можно и не блокировать.

Хм, а ты уверен, что в частично разнесённом заказе можно запретить шапку редактировать? Или ты через workflow предлагаешь это как-то настроить? Я вот что-то так сразу не нашёл такой возможности.

[EVGL]

Цитата:

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

от этого он не перестает быть черновиком

Можно софистикой сколь угодно заниматься, но опыт показывает другое. В жизни пользователям отделов продаж жизненно не хватает дополнительных статусов, блокировок и ведения истории заказа на продажу подобно тому, как это сделано теперь в закупках. Пока выкручиваемся везде докумнтом подтверждения заказа и сталкиваемся с тем, что их неудобно сравнивать, чтобы отслеживать изменения.
Другими словами, идея доступного всем сотрудникам для редактирования "черновика" противоречит требованиям бизнеса. Я еще ни одного пользователя не видел, который был бы в восторге от этой 'simplicity' в модуле продаж.

В вопросе удаления заказов и/или документов пересекаются требования бизнеса и законодательства. Народ с удовольствием удалил бы все эти счета, но первые 7 лет этого делать нельзя. Народ с удовольствием хранит заказы годами потому что
- форма работы с заказами банально удобнее формы счетов
- заказы отнюдь не всегда отгружаются целиком, см. Delivery Schedule в AX2012. В моей практике это требования выставлялось часто. Тем самым гораздо удобнее скопировать заказ с готовым графиком отгрузки, нежели пакет накладных.

[Maxim Gorbunov]

Выскажусь уж и по теме, раз сюда зашёл

По-моему, проблема в неудачном названии. Sales order должен был быть всё-таки Sales order journal. А при его разноске уже можно создавать Sales order, который документ.

Интересно, что это не очень удачное название, похоже, и самих разработчиков в заблуждение ввело. Сводное планирование, например, не смотрит, разнесён заказ или нет, а планирует под него целиком. То есть, в терминах этого обсуждения, сводное планирование планирует под данные, внесённые в черновик. Понятно, что с этим можно (и приходится) бороться с помощью типа заказа (Журнал/Открытый заказ), но так же очевидна и необходимость блокировки изменений утверждённого заказа. Если заказ уже передан в планирование, то менять его нежелательно.

[EVGL]

Точно, и этот аспект есть, что сводное планирования слишком рано кидается исполнять заказ, а работать с прогнозами и их сокращением - геморрой еще тот. Более того, в "черновике заказа" на продажу еще часто и код номенклатурный правильный не известен. Прямой поддержки этой ситуации в системе нет (кроме зачатков в процессном производстве), тоже Gap капитальный в системе.

Запрет редактирования заголовков в заказах мне тоже неизвестен. Либо я плохо знаю стандарт, либо никакой это не стандарт. Workflow вокруг заказа нет, а жизненно нужен.

[mazzy]

Цитата:

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

Хм, а ты уверен, что в частично разнесённом заказе можно запретить шапку редактировать? Или ты через workflow предлагаешь это как-то настроить? Я вот что-то так сразу не нашёл такой возможности.

не, не воклфлоу.
1. параметр был еще в 3шке. да и раньше был вроде.

2. также обратите внимание на параметры автосокращения, о которых я говорил выше.

по-русски


то же самое по-ангельски

[mazzy]

Цитата:

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

В вопросе удаления заказов и/или документов пересекаются требования бизнеса и законодательства. Народ с удовольствием удалил бы все эти счета, но первые 7 лет этого делать нельзя. Народ с удовольствием хранит заказы годами потому что
- форма работы с заказами банально удобнее формы счетов
- заказы отнюдь не всегда отгружаются целиком, см. Delivery Schedule в AX2012. В моей практике это требования выставлялось часто. Тем самым гораздо удобнее скопировать заказ с готовым графиком отгрузки, нежели пакет накладных.

вот это точно софистика

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

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

[EVGL]

Опция запрета редактирования после отгузки известна. Интересует запрет редактирования после выдачи подтвеждения заказа.

Цитата:

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

вот это точно софистика

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

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

1) Пока формально нельзя. Надеюсь, что MBS приведет функциональность модуля заказов и закупок к общему знаменателю. Тогда будет можно.

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

[Stitch_MS]

Цитата:

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

заказы - могут разноситься частично. между частичными разносками параметры заказа могут меняться

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

[Maxim Gorbunov]

Цитата:

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

не, не воклфлоу.
1. параметр был еще в 3шке. да и раньше был вроде.

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

[Maxim Gorbunov]

Цитата:

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

1) Пока формально нельзя. Надеюсь, что MBS приведет функциональность модуля заказов и закупок к общему знаменателю. Тогда будет можно.

Вот здесь не соглашусь. Концепция Journal -> Transaction полезна не только с точки зрения общности интерфейса. Как тут уже замечали, это и для быстродействия необходимо (очевидно, индексы на транзакционных таблицах делают их более пригодными для чтения данных, а в журнальные таблицы при этом данные легче вводить). Кроме того, разноска документа может быть сопряжена с некоторыми дополнительными действиями помимо создания проводок. Например, при разноске документ может быть выгружен в стороннюю систему. Если же мы будет журнальную таблицу одновременно считать и документом, то нам придётся её выгружать при изменении каждого поля.

Нет, пусть всё-таки заказ остаётся журналом, а развитие идёт в сторону документа Заказ, который нельзя будет редактировать, и из которого уже будет появляться всё остальное.

[EVGL]

Да, быстродействие - это тема, но пользователи хотят и концепция уже в закупках поломана: мы теперь encumbrance-проводки по голому Purchase Order делаем. Потому разработчики ее - закупку - и блокируют так ожесточенно после подтверждения.

[ds1678]

Цитата:

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

Выскажусь уж и по теме, раз сюда зашёл

Сводное планирование, например, не смотрит, разнесён заказ или нет, а планирует под него целиком. То есть, в терминах этого обсуждения, сводное планирование планирует под данные, внесённые в черновик. Понятно, что с этим можно (и приходится) бороться с помощью типа заказа (Журнал/Открытый заказ), но так же очевидна и необходимость блокировки изменений утверждённого заказа. Если заказ уже передан в планирование, то менять его нежелательно.

Максим, здесь вы, на мой взгляд, ошибаетесь. Сводное планирование прекрасно разбирается с тем, что заказ частично разнесен. В этом случае потребность генерит только оставшееся к поставке количество (если не было обнулено). Другой вопрос, что при настройке сокращения прогноза заказами, учитывается суммарно заказанное количество за интервал времени в ключе распределения, вне зависимости отгружено оно или нет.

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

Ну и с точки зрения плэннинга, заказ - это не столько черновик, сколько некий элемент оперативного плана, который утвержден на исполнение. То есть можно рассчитывать с высокой долей вероятности, что строка заказа на закупку придет к дате (запрошенной/подтвержденной), указанной в строке заказа на закупку. А строка заказа на продажу должна быть отгружена к дате (запрошенной/подтвержденной), указанной в строке.

[Maxim Gorbunov]

Денис, вы неправильно поняли, что я хотел сказать. Речь не о частичной разноске, а о том, что когда заказ создан, независимо от того, подтверждён он или нет, сводное планирование сразу же считает его потребностью. С этим можно бороться, используя заказы типа Журнал, но это не всегда удобно. Кроме того, после того, как тип заказа меняется с Журнал на Открытый заказ, изменения заказа не блокируются, и пользователи могут добить (что менее проблематично для планирования) или удалить (это может быть серьёзной проблемой, если предварительно составленный план уже принят к исполнению) строки заказа или изменить количества. С точки зрения планирования, выходит, что заказ действительно уже не черновик. Назовём его даже исходным документом. Проблема в том, что в этот документ можно бесконтрольно вносить изменения уже после того, как на его основании предприняты какие-то шаги.

[Ivanhoe]

Вот вот! Согласен - заказ, попавший в план хотелось бы как-то отмечать. Ну и, если отойти чуть от темы, то видеть сводный план (и его историю) и его выполнение (без навязанной маркировки).

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

Цитата:

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

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

Означает ли это, что если разнесенные заказы не удаляют, то данные можно хранить и в заказах?

Цитата:

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

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

Означает ли это, что если по бизнес-процессу частичной разноски нет, то и изменение параметров невозможно?

Т.е. означает ли это, что исходный вопрос носит скорее организационный характер, чем функциональный? Зависит от бизнес-процесса.

[Maxim Gorbunov]

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

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

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

Цитата:

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

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

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

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

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

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

Цитата:

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

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

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