AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.01.2014, 20:24   #41  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Владимир, это и в обратную сторону работает: если организационно принято хранить данные в заказе, то необходимо позаботиться о том, чтобы функционально было
а) невозможно удалить разнесённый заказ;
б) невозможно частично разнести заказ.
Достаточно только второго пункта. Первый уже решен на уровне стандарта. Через настройки

Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
При этом, проверять то, что логика не нарушена, вам придётся после установки каждого сервис-пака. Как программист могу вам сказать, что проверять "неконфликтность" такой логики гораздо сложнее, чем логики по протаскиванию данных из заказа в документы.
Мой опыт показывает, что функционал "вообще", а особенно "вокруг" заказов всегда очень сильно кастомизирован. Сложности при установке сервис-паков будут в любом случае. Отдельная функция, запрещающая частичную разноску вряд ли как-то существенно повлияет на сложность обновления...
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 15.01.2014, 20:29   #42  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Хехе, забавный аргумент. Мы купили мультиварку, но нам так неохота с кнопочками разбираться, поэтому мы просто в неё продукты складываем, и ставим на газовую плиту
На самом деле так оно и есть. Пользователям некогда делать "тонкую" настройку, для "вырезания" части товара при разноске. Чем меньше движений мышкой и клавиатурой, тем лучше

И совершенно не вызывает удивления тот факт, что мультиварку начинают использовать как обычную кастрюлю... Ну, в лучшем случае, как скороварку...
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 15.01.2014, 21:37   #43  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Отдельная функция, запрещающая частичную разноску вряд ли как-то существенно повлияет на сложность обновления...
Её реализовывать можно по-разному. Можно действительно просто проверить во время разноски, не изменили ли пользователи количество в строке и количество строк, но это достаточно глупо. Зачем давать пользователю возможность менять это количество, если такое изменение приведёт к ошибке? Если же подойти к вопросу более ответственно, чем с настроем "и так сойдёт", то нужно исключить возможность изменений при разноске. А вот тут уже объём модификаций вырастет серьёзно.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 15.01.2014, 21:39   #44  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Пользователям некогда делать "тонкую" настройку, для "вырезания" части товара при разноске.
Пользователям некогда, или всё же консультантам недосуг подумать о различных сценариях работы?
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 16.01.2014, 00:50   #45  
RVS is offline
RVS
Сенбернар
Аватар для RVS
Злыдни
 
696 / 130 (6) +++++
Регистрация: 27.02.2003
Адрес: Королев МО
"я фигею, дорогая редакция..."

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

===

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

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

==

Я - тупой (с)
__________________
Best Regards,
Roman
За это сообщение автора поблагодарили: mazzy (5).
Старый 16.01.2014, 14:52   #46  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от RVS Посмотреть сообщение
Это правда - или всерьез тут люди обсуждают - "а бывает ли частичная разноска заказа?"
Я бы сказал так: из-за "общего случая" с множественными отгрузками значительно усложняется один из очень распространенных случаев 1 заказ = 1 накладная. Т.е. в идеальной системе лучше бы иметь возможность выбрать, как заказы должны обрабатываться - так, или иначе.

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

Просто MS рассказывает клиентам, какая классная "коробочная" система, а по факту в ней многие процессы не настраиваются, а программируются.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: RVS (1).
Старый 16.01.2014, 15:12   #47  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Я бы сказал так: из-за "общего случая" с множественными отгрузками значительно усложняется один из очень распространенных случаев 1 заказ = 1 накладная.
Что-то не до конца понимаю, в чем сложность? Залочить заказ после разноски confirmation и остальные документы разносить минуя форму SalesEditLines совершенно незначительная модификация. Если так уж популярно, можно клиентам как бонусное "отраслевое решение" предлагать.
__________________
Isn't it nice when things just work?
Старый 16.01.2014, 15:31   #48  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Так и предлагают. Так везде можно допилить. Мы ж вроде про стандарт говорим? Или каждый про свое "решение" тут обсуждает - можно в нем черновик удалять или нет?

P.S. указанной доработкой дело не ограничивается.
__________________
Ivanhoe as is..
Старый 16.01.2014, 17:37   #49  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
macklakov, а дату накладной где тогда указывать? А подбирать packing slip'ы? А если нужно разрешить разноску без проверки кредитного лимита, то что делать? Нет, прятать форму SalesEditLines, по-моему, не выход.

Вообще-то, весь спор, как я понимаю, разгорелся из-за того, что автору не захотелось протягивать дополнительные поля из таблицы заказов в таблицы документов. А вот это действительно плёвая модификация, которую впоследствии очень легко поддерживать.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 17.01.2014, 12:02   #50  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
(плюну немного с высоты своей колокольни)
Многие рассматривают заказы только со стороны учетной системы и забывают про управленческую отчетность. Предположим, что мне нужно в "отчетной" базе получить OLAP отчет в разрезе, который на фиг не нужен в учетных документах. Вы скажете: "Тащите все поля в документы". А если таблица заказов у меня уже состоит из двух таблиц, т.к. полей в SalesTable уже слишком много? Тащить все? Плюс создать все поля, которые закрыты конфигурационными ключами в заказах: а вдруг потребуется включить.
(резюме: на маленьком количестве проектов (работал только на стороне клиента) запрещали удаление и редактирование проведенных заказов при любых операциях (ну кроме truncate table))
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании.
Старый 18.01.2014, 23:13   #51  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Со стороны клиента могу сказать, что видел системы, в которых были подходы как "один заказ - одна накладная", так и "один заказ - много накладных".
В компании, в которой работаю сейчас, по одному заказу вполне может быть множество отгрузок. Это машиностроение, по одному заказу сроки поставки могут быть от недели до 15-20 недель. При этом клиент забирает оборудование поэтапно. Разбивать один заказ на несколько под ожидаемые отгрузки нельзя, так как заказ представляет собой план отгрузок клиенту по одному объекту (складской комплекс, стадион Сочи 2014, станция метро и т.п.), но в рамках объекта есть этапы, причем, порядок их использования заранее клиент сказать не может.
В свое время мы допустили ошибку при создании отчетности - часть данных берем из заказов. В результате в системе есть несколько десятков тысяч заказов (число строк измеряется сотнями тысяч), а смысл их существования один - нужно в нескольких отчетах, больше никаких причин их присутствия в базе нет.
Когда полностью закончим проект ОЛАП (у нас он основан не на данных DAX, а на внешнем хранилище), будем безжалостно убивать заказы, по которым больше не требуется отслеживания отгрузок.

Последний раз редактировалось Raven Melancholic; 18.01.2014 в 23:18.
За это сообщение автора поблагодарили: Evgeniy_R (1).
Старый 17.02.2014, 16:39   #52  
Rezervforall is offline
Rezervforall
Участник
 
142 / 26 (1) +++
Регистрация: 09.06.2009
В сводном планировании есть запрос о подтвержденных заказах с ссылкой на номера заказов на покупку и данными утвердившего. Для меня это:
1. Спланировали, покрутили планы, скорректировали.
2. Утвердили план у руководства (в системе утвердили спланированные заказы на покупку), получили пул заказов на покупку
3. Как мне понять дальше что утвердили, как исполнили утвержденное? В системе это например частичная поставка (или перепоставка) и разноска недопоставки с параметром "Окончательная", для назначения статуса "Оприходовано" заказу на покупку и информацией по недопоставленному в заказе. Эту информацию я потом использую для расчетов (например прогнозов или KPI службы планирования или снабжения).

Последний раз редактировалось Rezervforall; 17.02.2014 в 16:42.
Старый 18.04.2014, 20:30   #53  
ap is offline
ap
Участник
Ex AND Project
 
60 / 16 (1) ++
Регистрация: 14.02.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от mazzy Посмотреть сообщение
вынес обсуждение в отдельную тему

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

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

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

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

Ну и другое дело если у вас заказ в систему заводит бухгалтер и только для того чтобы накладную разнести - тут конечно заказ беречь не зачем. Но мы ведь тут не про автоматизацию разноски накладных, а про решение бизнес задач средствами ИТ, так ведь?
Старый 18.04.2014, 20:43   #54  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ap Посмотреть сообщение
Мое мнение - заказы нельзя удалять
...так ведь?
ap, вы предельно невнимательно прочитали мое утверждение
а также предельно невнимательно прочитали ветку.

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


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

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

При всей кажущейся сложности протаскивания полей, это намного проще, нежели вылавливать (возможно изменившиеся) параметры из заказа.
Старый 18.04.2014, 21:39   #55  
ap is offline
ap
Участник
Ex AND Project
 
60 / 16 (1) ++
Регистрация: 14.02.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от mazzy Посмотреть сообщение
а также предельно невнимательно прочитали ветку.
там по моему все почти согласились с утверждением, что "заказы - это черновики".

Цитата:
Сообщение от mazzy Посмотреть сообщение
вы не с тем спорите.
Вы говорите: "заказы нельзя удалять" (с точки зрения бизнеса).
Я говорю: "черновики (заказы) могут удаляться" (с функциональной точки зрения)
Обратите внимание, я не утверждал, что заказы нужно удалять
Да с этим то я как раз и не спорю. Я не согласен с другим - с первой частью формулировки в заголовке темы, что "заказы - это черновики" Заказы - это сущность со своей смысловой нагрузкой. Поэтому и не могут удаляться. Это не "черновик" для накладной, а "интерес" клиента, "желание" купить.
А со второй частью, что "факт должен быть в документах" я согласен. Про это я в самом начале написал.
Старый 21.04.2014, 14:42   #56  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от ap Посмотреть сообщение
Заказы - это сущность со своей смысловой нагрузкой. Поэтому и не могут удаляться. Это не "черновик" для накладной, а "интерес" клиента, "желание" купить
Строго говоря, это не так. Для пожеланий клиентов есть отдельные сиэрэмные сущности типа Quotation. Заказ - это всё-таки то, что клиент уже согласен купить.
__________________
С уважением,
Вячеслав
За это сообщение автора поблагодарили: mazzy (2).
Старый 22.04.2014, 20:36   #57  
ap is offline
ap
Участник
Ex AND Project
 
60 / 16 (1) ++
Регистрация: 14.02.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от pitersky Посмотреть сообщение
Строго говоря, это не так. Для пожеланий клиентов есть отдельные сиэрэмные сущности типа Quotation. Заказ - это всё-таки то, что клиент уже согласен купить.
Про вариант хранения этих данных в CRM (системе/модуле) я тоже писал.

Quotation можно так классифицировать, а можно и иначе. Зависит от конкретного решения. Все таки Quotation - это "предложение". Т.е. это скорее наше желание продать клиенту, а не его желание у нас купить. ) На момент появления Quotation клиент еще может не знать, что он хочет это купить.) Он может даже еще не знать о нашем существовании. Зависит от воронки на конкретном предприятии.
Поэтому Quotation не включают в happy\uphappy отчетность, поскольку их нельзя считать оформившимся желанием клиента.
Либо это может быть уже желание купить ("а не купить ли мне.."), но еще не намерение купить ("заверните,беру").
В любом случае Quotation я бы тоже не отнес к разряду "черновиков".
Старый 22.04.2014, 22:12   #58  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
То подходит или нет к какой-либо сущности определение "черновик", определяется не бизнесс функциями, которыми мы эту сущность наделяем, а конкретной реализацией в системе механизмов работы с этой сущностью. Я хочу сказать, то что заказы в аксапте являются черновиками это не следствие каких-либо размышлений, это фактическое свойство аксаптовских заказов. Заказы в аксапте можно изменять удалять после их обработки - следовательно заказы в аксапте это черновики (по определению если хотите).
Хорошо это или плохо? Это, как говорится, by design. Разработчики решили, вместо того чтобы бороться за целостность данных между заказом и производными документами, проще не наделять данные в заказе каким либо стратегически значимым смыслом. В результате, назначение заказа в аксапте - это предоставление оперативной информации о текущей потребности и только. Если вам нужна аналитика было-стало, то нужно придумывать какие-то новые сущности, в которые запоминать все изменения производимые в заказе. Либо не городить огород, а использовать специализированные CRM решения.
Старый 23.04.2014, 09:35   #59  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от ap Посмотреть сообщение
Поэтому Quotation не включают в happy\uphappy отчетность, поскольку их нельзя считать оформившимся желанием клиента.
Сбор данных о намерениях клиентов - это, по смыслу, функция CRM-решения. Это я не применительно к Аксапте хотел заметить, а в принципе, с точки зрения дизайна систем. А если с точки зрения Аксапты, то для сбора пожеланий клиентов есть opportunities и leads.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Сомнение возникло в рекомендации "нужно использовать collation, который позволяет хранить в юникоде (например, Cyrilic_General_CI_AS)" VitaliyK DAX: Администрирование 10 25.09.2007 13:50
заказы: данные о компании в накладной doxlokot DAX: Функционал 5 07.02.2004 03:24
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 21:35.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.