17.11.2017, 16:01 | #21 |
Banned
|
Может быть скажу крамольную вещь, но заказ на продажу - это документ. Заказ на покупку - тем более документ, поскольку его "документность" подтверждается встроенной системой контроля изменений (почему его нет в sales order - другой вопрос, есть запрос на ideas.dynamics). Смена количества в строке заказа без каких-либо подтверждающих документов имеет далекие последствия во все системе от сводного планирования до денежных средств. Поэтому пользователи AX тоже вводят данные в итоговые документы: заказы на продажу и покупку, которые от CRM opportunity на метафизическом уровне отличаются не сильно.
Последний раз редактировалось EVGL; 17.11.2017 в 16:03. |
|
17.11.2017, 16:12 | #22 |
Участник
|
Скажите )
Цитата:
см. также опцию автосуммирования заказов. а также не поверите Реорганизации заказов. ну и конечно заказ-контракт и его выполнение подчиненными заказами, которые должны быть удалены в конечном итоге. любой заказ, как и журнал - в аксапте черновик. изначально информация переносилась в фактические документы (инвойсы, packing slipы и прочие), а исходный черновик удалялся. Изначально это был штатный режим работы. В Навике он и остался штатным. для удаленных заказов сделали специальную фичу - перекладывать заказы в таблицу удаленных. Типа архивирование. Цитата:
постановщиками были люди, которые уже аксапту не знали. вообще трактовать заказ как документ повелось с российской локализации. на мой взгляд, на такую трактовку очень сильно повлияла 1С со своим документом и очень ограниченными проводками. да, это в русской локализации добавили поля в заказ которые "забыли" протянуть через SalesParmTable в документы. и при формировании книг продаж и покупок нужно было обращаться к заказу. что с учетом функции автосуммирования, реорганизации и автоудаления давало предельно глючный результат. Цитата:
Имеет последствия - сводное планирование, график ДДС будет пересчитан ))) Еще резервы. И ожидаемые сроки поставки в последних версиях. Поэтому в параметрах есть галочки запрещающие изменять заказ по которому уже прошла частичная разноска. Господи, ну прочитайте же документацию. Последний раз редактировалось mazzy; 17.11.2017 в 16:14. |
|
17.11.2017, 16:23 | #23 |
Banned
|
Цитата:
Лет ...надцать назад я тоже с юношеским максимализмом протаскивал каждое новое поле из заказа в документ-подтверждение. Потом перестал. Ключевая фраза выделена жирным, после которой дальнейшая дискуссия становится невозможной. |
|
17.11.2017, 16:26 | #24 |
Участник
|
Поддержу EVGL. В бизнесе давно нет "черновика" Заказа, есть документ Заказ. И Аксапта справедливо по ним считает и сводное и другие вещи. А все эти рудименты по сокращению, группировке и т.п. по факту на моих проектах практически не используются. А вот сколько крови пьют... когда не опытный консультант, например, начинает пользоваться суммарной обработкой, считая, что нет документа "Заказ" и можно их плодить сколько угодно. А потом мучается с реализацией нормального backlog в дистрибуторском бизнесе, сопоставлении Order с Invoice, не дай мог включая полный EDI пакет сообщений.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: EVGL (1). |
17.11.2017, 16:27 | #25 |
Участник
|
А расскажите Ритейлеру, что фигня ваш заказ - хоть сейчас удалить можно ой, все...
__________________
Ivanhoe as is.. |
|
17.11.2017, 16:28 | #26 |
Участник
|
Цитата:
теперь пришли люди которые и средства разработки в аксапте не знают. ) см. погибшие TreeNode и Dict* классы. Цитата:
Абсолютно согласен. |
|
17.11.2017, 16:41 | #27 |
Участник
|
Хочешь сказать в россии )
Здесь очень велико влияние 1С с его подходом от документа. Сравни с Навиком. Он распространен в европе. да. Обрати внимание что в сводном и других по ним считают ПРОГНОЗЫ! ))) и есть галочки, которые позволяют учитывать прогнозы или не учитывать. А также параметры, которые определяют вероятность прогнозов во времени. Цитата:
Если бы не использовались, то у меня не выпили бы столько крови на моем сейчас закрываемом хотфиксе для мексики - reaarange у них видите ли не работает ))) Автосокращение дает очень важную для работу штуку. журнал/заказ хранит то что еще предстоит сделать. фактические документы хранят то, что уже сделано. при таком подходе заказ и факт можно тупо просуммировать и получить общий объем. что и используется во всяких прогнозах/планированиях. если же в черовиках продолжать хранить проведенные данные, то для расчета общих объемов нужно вычесть из заказов сделанное по заказам. что превращается в нетривиальную задачу, если факт генерируется не только заказами. собственно из-за сложностей с вычислением общего объема в россии не прижились free text invoice, регистрация приходных счетов, модуль контроля качества. ) Цитата:
Сообщение от Ivanhoe
А вот сколько крови пьют... когда не опытный консультант, например, начинает пользоваться суммарной обработкой, считая, что нет документа "Заказ" и можно их плодить сколько угодно. А потом мучается с реализацией нормального backlog в дистрибуторском бизнесе, сопоставлении Order с Invoice, не дай мог включая полный EDI пакет сообщений.
Да, разработчики забили на протаскивание полей. Цитата:
Ритейл - да - это особый случай. Там текущие разработчики не знают не только Аксапту, они и бизнеса то не знают. Да, изначальное решение от Ланштайнера было вполне адекватно Навику. Но уже при портировании в Аксапту, который выполняли люди, не знающие Аксапту, получился полный пипец. А что сейчас делается... Да, о Ритейле остается только молчать. |
|
17.11.2017, 16:47 | #28 |
Banned
|
Россия, Россия, Россия, локализация, Россия, 1С... О чем вы говорите, вообще?
Позвольте судить о не-России людям, там находящимся. Все сказанное Ivanhoe полностью справедливо для Германии, Австрии, Швейцарии, Франции, Великобритании, США. Поскольку так построены бизнес-процессы. А процессам не интересно, где там у Аксапты галка. P.S. Rearrange и суммарная обработка используются по опыту там где есть интерфейсы того или иного рода, и/или автоматизированная обработка Последний раз редактировалось EVGL; 17.11.2017 в 16:55. |
|
17.11.2017, 16:56 | #29 |
Участник
|
Цитата:
Цитата:
ссылка про процессы в вашем представлении: Два invoice, один с нулевым количеством )))) |
|
17.11.2017, 17:12 | #30 |
Banned
|
Хм. Я не объяснял детально почему делаем "именно так" на данном проекте. Хотя нет, объяснял, но был очевидно не понят:
|
|
17.11.2017, 17:48 | #31 |
Moderator
|
Ладно - я пожалуй чуть-чуть подробнее по теме выскажусь:
Последний раз редактировалось fed; 17.11.2017 в 17:54. |
|
|
За это сообщение автора поблагодарили: EVGL (1), gl00mie (2). |
21.11.2017, 10:37 | #32 |
Участник
|
Цитата:
Сообщение от Ivanhoe
... когда не опытный консультант, например, начинает пользоваться суммарной обработкой, считая, что нет документа "Заказ" и можно их плодить сколько угодно. А потом мучается с реализацией нормального backlog в дистрибуторском бизнесе, сопоставлении Order с Invoice, не дай мог включая полный EDI пакет сообщений.
Иностранные поставщики в своих SAP-ах формируют инвойсы с их аналогом суммарной обработки без зазрения совести. (Можно наблюдать EDI инвойсы в которых номера исходных закупок в шапках отсутствуют а проставлены в строках) |
|
21.11.2017, 10:50 | #33 |
Участник
|
Так и в Аксапте можно, если знать подводные камни технической реализации. Про статусы шапок и строк в заказах. Про ссылки и данные в шапках и строках накладных. Про ссылки и данные в проводках.
__________________
Ivanhoe as is.. |
|
07.01.2018, 09:34 | #34 |
Модератор
|
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: ax_mct (3). |
07.01.2018, 22:30 | #35 |
Banned
|
Присоединяюсь к комментарию ниже. Система достигла такого уровня совершенства что программисты не нужны.
Цитата:
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 |
Участник
|
Этой это какой? Эти поля работают как обычный table extension, просто создается он в рантайме. Т.е. почему деплоймент таблици должен убивать поля в ее экстеншене?
|
|
07.01.2018, 23:15 | #37 |
Banned
|
Цитата:
Но пусть это 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 |
Участник
|
Цитата:
|
|
08.01.2018, 14:26 | #39 |
Banned
|
Супер-фича. Теперь не придется объяснять людям от Dynamics CRM или Oracle eBS почему поле в AX стоит 3 дня разработки.
|
|
08.01.2018, 15:06 | #40 |
Banned
|
Цитата:
Сообщение от skuull
Эээ, это не тот extension который просто левая табличка со связью 1 к 1 по RecId, это еще 1 поле в базе данных в той самое таблице, тут о них пишут для тех кто не в курсе. Деплоить в классическом смысле его невозможно потому что это код который создаеться в рантайме и когда вы создаете в UI FIeld1 в БД получите Field1_Custom. Из этогго следует - не создавайте поля которые заканчиваються на _Custom и будет вам счастье.
DEV и TEST об этом не знают. Переносим разработку с данной таблицей которая по сути имеет другую версию в PROD. В AX7 "умный" мерджинг и одаренная синхронизация с DB? Конфликтов не будет? Я не в курсе, просто интересно. |
|
Теги |
d365o |
|
|