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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 17.11.2017, 16:01   #21  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Может быть скажу крамольную вещь, но заказ на продажу - это документ. Заказ на покупку - тем более документ, поскольку его "документность" подтверждается встроенной системой контроля изменений (почему его нет в sales order - другой вопрос, есть запрос на ideas.dynamics). Смена количества в строке заказа без каких-либо подтверждающих документов имеет далекие последствия во все системе от сводного планирования до денежных средств. Поэтому пользователи AX тоже вводят данные в итоговые документы: заказы на продажу и покупку, которые от CRM opportunity на метафизическом уровне отличаются не сильно.

Последний раз редактировалось EVGL; 17.11.2017 в 16:03.
Старый 17.11.2017, 16:12   #22  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
Может быть скажу крамольную вещь,
Скажите )

Цитата:
Сообщение от EVGL Посмотреть сообщение
но заказ на продажу - это документ. Заказ на покупку - тем более документ,
конечно же нет. см галочки автосокращение при обновлении заказа и закупки. а также документацию.

см. также опцию автосуммирования заказов.
а также не поверите Реорганизации заказов.

ну и конечно заказ-контракт и его выполнение подчиненными заказами, которые должны быть удалены в конечном итоге.

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

для удаленных заказов сделали специальную фичу - перекладывать заказы в таблицу удаленных. Типа архивирование.

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

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

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

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

Цитата:
Сообщение от EVGL Посмотреть сообщение
Смена количества в строке заказа без каких-либо подтверждающих документов имеет далекие последствия во все системе от сводного планирования до денежных средств. Поэтому пользователей
Именно.
Имеет последствия - сводное планирование, график ДДС будет пересчитан )))
Еще резервы. И ожидаемые сроки поставки в последних версиях.

Поэтому в параметрах есть галочки запрещающие изменять заказ по которому уже прошла частичная разноска.

Господи, ну прочитайте же документацию.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 17.11.2017 в 16:14.
Старый 17.11.2017, 16:23   #23  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
бггг, которая появилась в очень поздних версиях
постановщиками были люди, которые уже аксапту не знали.
...
Господи, ну прочитайте же документацию.
Зашибись. Может быть, все-таки пришли постановщики с опытом реальных задач на внедрениях, а не перечитывающие документацию 3.0 ностальгики?

Лет ...надцать назад я тоже с юношеским максимализмом протаскивал каждое новое поле из заказа в документ-подтверждение. Потом перестал.

Ключевая фраза выделена жирным, после которой дальнейшая дискуссия становится невозможной.
Старый 17.11.2017, 16:26   #24  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Поддержу EVGL. В бизнесе давно нет "черновика" Заказа, есть документ Заказ. И Аксапта справедливо по ним считает и сводное и другие вещи. А все эти рудименты по сокращению, группировке и т.п. по факту на моих проектах практически не используются. А вот сколько крови пьют... когда не опытный консультант, например, начинает пользоваться суммарной обработкой, считая, что нет документа "Заказ" и можно их плодить сколько угодно. А потом мучается с реализацией нормального backlog в дистрибуторском бизнесе, сопоставлении Order с Invoice, не дай мог включая полный EDI пакет сообщений.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: EVGL (1).
Старый 17.11.2017, 16:27   #25  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
А расскажите Ритейлеру, что фигня ваш заказ - хоть сейчас удалить можно ой, все...
__________________
Ivanhoe as is..
Старый 17.11.2017, 16:28   #26  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
Зашибись. Может быть, все-таки пришли постановщики с опытом реальных задач на внедрениях, а не перечитывающие документацию 3.0 ностальгики?
нет.
теперь пришли люди которые и средства разработки в аксапте не знают. )
см. погибшие TreeNode и Dict* классы.

Цитата:
Сообщение от EVGL Посмотреть сообщение
Лет ...надцать назад я тоже с юношеским максимализмом протаскивал каждое новое поле из заказа в документ-подтверждение. Потом перестал.
да-да. именно так

Цитата:
Сообщение от EVGL Посмотреть сообщение
Ключевая фраза выделена жирным, после которой дальнейшая дискуссия становится невозможной.
Абсолютно согласен.
__________________
полезное на axForum, github, vk, coub.
Старый 17.11.2017, 16:41   #27  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
В бизнесе давно нет "черновика" Заказа, есть документ Заказ.
Хочешь сказать в россии )
Здесь очень велико влияние 1С с его подходом от документа.

Сравни с Навиком. Он распространен в европе.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
И Аксапта справедливо по ним считает и сводное и другие вещи.
да. Обрати внимание что в сводном и других по ним считают ПРОГНОЗЫ! )))
и есть галочки, которые позволяют учитывать прогнозы или не учитывать. А также параметры, которые определяют вероятность прогнозов во времени.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А все эти рудименты по сокращению, группировке и т.п. по факту на моих проектах практически не используются.
В россии. Да, в россии и в странах восточной европы, где используется российская локализация не используется. Потому что в свое время разработчики забили на протаскивание полей, а постановщики ставили задачу "сделать как в 1С"

Если бы не использовались, то у меня не выпили бы столько крови на моем сейчас закрываемом хотфиксе для мексики - reaarange у них видите ли не работает )))


Автосокращение дает очень важную для работу штуку.
журнал/заказ хранит то что еще предстоит сделать.
фактические документы хранят то, что уже сделано.

при таком подходе заказ и факт можно тупо просуммировать и получить общий объем. что и используется во всяких прогнозах/планированиях.

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

собственно из-за сложностей с вычислением общего объема в россии не прижились free text invoice, регистрация приходных счетов, модуль контроля качества. )

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А вот сколько крови пьют... когда не опытный консультант, например, начинает пользоваться суммарной обработкой, считая, что нет документа "Заказ" и можно их плодить сколько угодно. А потом мучается с реализацией нормального backlog в дистрибуторском бизнесе, сопоставлении Order с Invoice, не дай мог включая полный EDI пакет сообщений.
Угу. Угу. Добавь только в российской локализации.
Да, разработчики забили на протаскивание полей.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А расскажите Ритейлеру, что фигня ваш заказ - хоть сейчас удалить можно ой, все...
А тут согласен.
Ритейл - да - это особый случай. Там текущие разработчики не знают не только Аксапту, они и бизнеса то не знают. Да, изначальное решение от Ланштайнера было вполне адекватно Навику. Но уже при портировании в Аксапту, который выполняли люди, не знающие Аксапту, получился полный пипец. А что сейчас делается... Да, о Ритейле остается только молчать.
__________________
полезное на axForum, github, vk, coub.
Старый 17.11.2017, 16:47   #28  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Россия, Россия, Россия, локализация, Россия, 1С... О чем вы говорите, вообще?
Позвольте судить о не-России людям, там находящимся. Все сказанное Ivanhoe полностью справедливо для Германии, Австрии, Швейцарии, Франции, Великобритании, США. Поскольку так построены бизнес-процессы. А процессам не интересно, где там у Аксапты галка.

P.S. Rearrange и суммарная обработка используются по опыту там где есть интерфейсы того или иного рода, и/или автоматизированная обработка

Последний раз редактировалось EVGL; 17.11.2017 в 16:55.
Старый 17.11.2017, 16:56   #29  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
Россия, Россия, Россия, локализация, Россия, 1С... О чем вы говорите, вообще?
Я говорю о функционале Аксапты.

Цитата:
Сообщение от EVGL Посмотреть сообщение
Позвольте судить о не-России людям, там находящимся. Все сказанное Ivanhoe полностью справедливо для Германии, Австрии, Швейцарии, Франции, Великобритании, США. Поскольку так построены бизнес-процессы. А процессам не интересно, где там у Аксапты галка.
Судите. Кто ж запрещает.

ссылка про процессы в вашем представлении: Два invoice, один с нулевым количеством
Цитата:
Сообщение от EVGL Посмотреть сообщение
На моем текущем проекте делаем именно так.
))))
__________________
полезное на axForum, github, vk, coub.
Старый 17.11.2017, 17:12   #30  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Хм. Я не объяснял детально почему делаем "именно так" на данном проекте. Хотя нет, объяснял, но был очевидно не понят:
  • невозможно отмотать назад WHS, немыслимо заставить людей вбивать заново палеты (два раза!). Я заставлял, и учил, и переучивал, и пере-переучивал, а не надо было, поскольку вероятность сделать ошибку и потери в производительности недопустимо высоки.
  • невозможно вернуть и забыть инвойс, который уехал в машине, и нельзя не выставить его. Так работает отгрузка в России: один заказ - одна накладная - один счет - одна машина, но точно так же она работает и в Вене, поскольку везде теперь Make-to-order и Industry 4.0
  • потому как процесс должен быть завершен, заказ должен быть закрыт и забыт: это повышает производительность.
  • принципиально кредит-ноты [в AX] не решают задачу неправильной цены, когда клиент товар не возвращает и всем доволен, кроме документа и задолженности
Поэтому приходится строить костыли.
Старый 17.11.2017, 17:48   #31  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Ладно - я пожалуй чуть-чуть подробнее по теме выскажусь:
  1. Заявленная фича сделана Microsoft для демонстрации на продажах.
  2. Опасность фичи состоит в том что она легко может спровоцировать легкое отношение пользователей к проектированию системы. Вместо более или менее правильного дизайна, на проектах будет случаться зоопарк случайно добавленных полей.
  3. Нейтрализовать опасность фичи, можно в том случае, если Микрософт по умолчанию, запретит использование этой фичи для всех форм и всех пользователей. Тогда внедренцы могут разрешить использование только на неключевых формах (типа DocuRef) и для более или менее разумных пользователей. Но я очень опасаюсь что в Микрософт об этом как раз не подумали.
  4. Поиск и репортинг были бы полезными добавлениями. Но только в том случае, если предыдущий пункт выполнен. В противном случае - мы опять таки получим зоопарк похожих отчетов сделанных на разных полях, добавленными в разное время разными энтузиастами...

Последний раз редактировалось fed; 17.11.2017 в 17:54.
За это сообщение автора поблагодарили: EVGL (1), gl00mie (2).
Старый 21.11.2017, 10:37   #32  
potential is offline
potential
Участник
 
84 / 35 (2) +++
Регистрация: 13.04.2012
Адрес: Санкт-Петербург
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
... когда не опытный консультант, например, начинает пользоваться суммарной обработкой, считая, что нет документа "Заказ" и можно их плодить сколько угодно. А потом мучается с реализацией нормального backlog в дистрибуторском бизнесе, сопоставлении Order с Invoice, не дай мог включая полный EDI пакет сообщений.
А может консультант наоборот мегаопытный
Иностранные поставщики в своих SAP-ах формируют инвойсы с их аналогом суммарной обработки без зазрения совести. (Можно наблюдать EDI инвойсы в которых номера исходных закупок в шапках отсутствуют а проставлены в строках)
Старый 21.11.2017, 10:50   #33  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от potential Посмотреть сообщение
А может консультант наоборот мегаопытный
Иностранные поставщики в своих SAP-ах формируют инвойсы с их аналогом суммарной обработки без зазрения совести. (Можно наблюдать EDI инвойсы в которых номера исходных закупок в шапках отсутствуют а проставлены в строках)
Так и в Аксапте можно, если знать подводные камни технической реализации. Про статусы шапок и строк в заказах. Про ссылки и данные в шапках и строках накладных. Про ссылки и данные в проводках.
__________________
Ivanhoe as is..
Старый 07.01.2018, 09:34   #34  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Custom fields
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: ax_mct (3).
Старый 07.01.2018, 22:30   #35  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Vadik Посмотреть сообщение
Присоединяюсь к комментарию ниже. Система достигла такого уровня совершенства что программисты не нужны.

Цитата:
Fsaetre 1 day ago
Probably the one feature that has the most impact on user experience and process development since the release of AX7. Amazing.
Мелко-мягкое программирование.
Надувные бассейны в каждый дом! Почувствуйте что море вам по колено!

Ну вот есть у нас DEV/TEST/PROD. Пользователи добавили в PROD эти поля.
Деплоймент этой таблицы из TEST на PROD - убиваем эти поля, разве нет?

Фича тем не менее хорошая но в концепции когда DEV/TEST нет в принципе, а есть облачный PROD и только и кроме как таких изменений ничего не надо. И то по сути подменяет то что часто нужно через Document management.
Старый 07.01.2018, 22:54   #36  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от ax_mct Посмотреть сообщение

Ну вот есть у нас DEV/TEST/PROD. Пользователи добавили в PROD эти поля.
Деплоймент этой таблицы из TEST на PROD - убиваем эти поля, разве нет?
Этой это какой? Эти поля работают как обычный table extension, просто создается он в рантайме. Т.е. почему деплоймент таблици должен убивать поля в ее экстеншене?
Старый 07.01.2018, 23:15   #37  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от skuull Посмотреть сообщение
Этой это какой? Эти поля работают как обычный table extension, просто создается он в рантайме. Т.е. почему деплоймент таблици должен убивать поля в ее экстеншене?
Ага, справедливо

Но пусть это Table1Ext таблица что связана по RecId с Table1.
Предположим что она существует и в TEST и в PROD.
То есть добавили одно такое поле, обновили TEST и имеем Table1Ext таблицу c полем Field1 и в TEST и в PROD.
После этого пользователи добавили Field2 в PROD.

Получается что ни при каких обстоятельствах мы не должны импортировать в PROD эту table extension так как версии могут отличаться в силу (прямого) UI программирования в PROD.
Понятно что это конкретная таблица именно для UI расширений которую программист трогать не должен. Но это все равно неудобно для деплоймента и выравнивания инстансов так как изменения рождаются не на том конце.

Другое дело что не проблема когда программирования как такового нет и нет цепочки деплоймента, а есть только такое псевдо-программирование на одном единственном PROD.
Старый 08.01.2018, 10:31   #38  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Ага, справедливо

Но пусть это Table1Ext таблица что связана по RecId с Table1.
Эээ, это не тот extension который просто левая табличка со связью 1 к 1 по RecId, это еще 1 поле в базе данных в той самое таблице, тут о них пишут для тех кто не в курсе. Деплоить в классическом смысле его невозможно потому что это код который создаеться в рантайме и когда вы создаете в UI FIeld1 в БД получите Field1_Custom. Из этогго следует - не создавайте поля которые заканчиваються на _Custom и будет вам счастье.
Старый 08.01.2018, 14:26   #39  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Супер-фича. Теперь не придется объяснять людям от Dynamics CRM или Oracle eBS почему поле в AX стоит 3 дня разработки.
Старый 08.01.2018, 15:06   #40  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от skuull Посмотреть сообщение
Эээ, это не тот extension который просто левая табличка со связью 1 к 1 по RecId, это еще 1 поле в базе данных в той самое таблице, тут о них пишут для тех кто не в курсе. Деплоить в классическом смысле его невозможно потому что это код который создаеться в рантайме и когда вы создаете в UI FIeld1 в БД получите Field1_Custom. Из этогго следует - не создавайте поля которые заканчиваються на _Custom и будет вам счастье.
Ну вот в некой таблице прямо на PROD появляется Field1_Custom.
DEV и TEST об этом не знают. Переносим разработку с данной таблицей которая по сути имеет другую версию в PROD.
В AX7 "умный" мерджинг и одаренная синхронизация с DB? Конфликтов не будет?
Я не в курсе, просто интересно.
Теги
d365o

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
kurthatlevik: A Practical Guide for Dynamics 365 Iterative Implementation Blog bot DAX Blogs 0 15.09.2017 01:21
kurthatlevik: New Microsoft Dynamics AX – A guide for using retail sales prices and discounts Blog bot DAX Blogs 0 01.12.2015 18:12
kurthatlevik: Dynamics AX 2012 – Great share on retail Blog bot DAX Blogs 0 28.10.2015 20:11
kurthatlevik: Turn your Dynamics AX WMS from ‘Where’s My Stuff’ to an actual ‘Warehouse Management System’ Blog bot DAX Blogs 0 21.11.2013 19:11
amer-ax: It was a great day! Blog bot DAX Blogs 3 29.12.2012 01:02
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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