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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

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

[Maxim Gorbunov]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

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

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

[Ivanhoe]

Не люблю такую категоричность, но в целом согласен про Заказы-черновики, особенно для AX до 2009. А что делать, например, с заказами типа "Контракт"? А складские журналы с русской первичкой? А ТТН (waybill), печатная форма которого тянет данные из других документов и "черновиков"? А отсутствие нормального сторнирования накладной, когда заказа уже нет?

В AX 2012 с вводом версионности ряда документов-"черновиков" парадигма несколько сместилась, мне кажется. И, например, считать ли договор - черновиком? А Заявки на покупку?

[RVS]

Блин.. вот читаю, то, что написали - умные люди.. и никак не пойму.. а зачем...

я - тупой (с)

===

О жизни, как она есть :

- Заказ есть Заказ (с большой буквы ЗЗ), пока :

- он, Заказ - не отменем клиентом (клиентв - всегда прав, да)
- пока обязательства (О!! А вЗаказе - __нет__ обязательств.. уй, ёё.. это уже вовсе другие вещи..) перед Клиентом - не выполнены.. но, кстати - это уже отдельные товарно-денежные отношения..

==

Ну, собственно.. мне лично - все понятно. Зайдите на любой сайт в инете, который что-то продает..

БП - понятен.. есть.. pecularuties.. но от этого - ни клиент, у которого БП, ни сам БП - не меняются...

==

"Все уже придумано до нас".. (с) А&BСтругацкие...

[Maxim Gorbunov]

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

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

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

[ds1678]

Цитата:

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

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

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

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

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

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

[Maxim Gorbunov]

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

[EVGL]

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

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

[EVGL]

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

[Ivanhoe]

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

[Maxim Gorbunov]

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[Maxim Gorbunov]

Цитата:

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

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

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

[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 системе реализованы.

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

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