"Управление затратами" в следующей версии Dynamics AX - ваши пожелания

[EVGL]

О, я даже не обратил внимания... deep shit, stupid moron... ценный перевод, надо прямо так и в спецификацию включить.

[Logger]

Цитата:

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

О, я даже не обратил внимания... deep shit, stupid moron... ценный перевод, надо прямо так и в спецификацию включить.

Да вы чего, люди ?
Всерьез что-ли ?
Нафига такое включать ?

[Stitch_MS]

Цитата:

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

Нафига такое включать ?

Ладно-ладно, шучу . я это предложение, конечно, переделаю. Скажем, "They’d better extend the fundamental things and fundamental APPLICATION frameworks. I wish they stopped doing thing like polishing UI or moving everything to .Net and worked on those fundamental things instead". Пойдёт?

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

Кстати, коллеги, есть какие-нибудь мысли, пожелания или крепкие, но конструктивные слова, по-поводу закрытия склада?

[fed]

Цитата:

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

Да вы чего, люди ?
Всерьез что-ли ?
Нафига такое включать ?

Просто говорят что некоторые участники разработки DAX2012 считают что они сделали кайфовый продукт, с замечательной удобнейшей средой разработки, которой так не хватало любой современной ERP. Буквально таки ждут что им всем выдадут футболки с надписью "Я разработал DAX2012" и они будут гордо в них ходить еще лет 10 не снимая.Будет полезно если на них ушат холодной воды выльют. Уверен, что вменяемые люди в MDCC (которые там еще остались кстати) примерно также оценивают усилия по переводу на .net, поддержку workflow, интеграцию с OCS и все другие героические усилия этих техноклоунов. Только им корпоративная вежливость не позволяет это от своего имени всем этим дотнетчикам написать... А мне в общем пофигу, мои пути с микрософтовскими мало пересекаются, так что если на меня эти любители дотнета обидятся - то мне в общем разницы никакой...
А если наезжать будут - могу по пунктам объяснить - в каком именно гробу и почему именно я видел их замечательные нововведения и как именно они повысят затраты на имплементацию и снизят качество решений...

Кстати - да - licking the interface - неправильно. polishing the interface - более похоже на правду...

[SEKL]

Да, адекватные люди в MDCC еще остались.

По поводу впечатлений о DAX 2012 - было бы интересно услышать ваше мнение по пунктам. Что нравится, что не нравится. Пытался ли кто-то пройти через обновление данных на реальном клиенте ну и так далее.

Еще один вопрос поднятый Александром - закрытие склада. Если у кого-то есть комментарии/пожелания - пишите. В настоящий момент мы пытаемся собрать данные по текущим проблемам с данным функционалом. Есть желание серьезно поработать над этой темой в рамках следующего релиза.

[fed]

Цитата:

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

По поводу впечатлений о DAX 2012 - было бы интересно услышать ваше мнение по пунктам. Что нравится, что не нравится.

Очень надеюсь написать статейку на эту тему к новому году. (Правда не уверен что времени хватит).

По поводу закрытия склада - так там только одна принципиальная проблема осталась, упомянутая Logger'ом. Надо (точнее говоря - можно) привязать себестоимость (и мгновенную себестоимость списания, и истинную себестоимость рассчитываемую при закрытии склада) не к лоту, а к сочетанию лот+аналитика финансового склада (чтобы себестоимость не ехала при переносах). Только в таком случае, вам еще придется ограничить возможности слияния/расщепления партий в обычном журнале переноса (чтобы не получалось что 3 партии списали и 2 других партии оприходовали) и сделать какой-то специальный журнал слияния/разделения аналитик, который позволял бы только операции вида 1:n или n:1 (Но никак не n:m).

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

Наконец, говоря о проблеме корректировок складских проводок задним числом, затронутой опять таки logger'ом, надо:
1. Наконец-то написать вместо продвинутого отчета по остаткам (из Rollup7), который конечно все партнеры благополучно проигноирировали, а внятную методичку, которая объясняла бы как и почему считается финансовый остаток по номенклатуре на дату, объясняла бы что рассчитывать остаток тупым суммированием inventTrans - нельзя, а также то, что считать денежный остаток по номенклатуре можно только в разрезе подмножества финансовой складской аналитики. Я просто ни разу не видел чтобы кто-то всерьез использовал стандартные отчеты по складским запасам, все пишут свои (просто потому что нужен красивенький отчет с экспортом и в том виде, в котором его привык видеть клиент). И большая часть партнеров не обладает пониманием того как правильно себестоимость складскую считать.
2. Надо сделать специальную галочку (в складской модели наверное) "Запрет корректировки закрытых проводок" и специальный счет "корректировки прошлых периодов" (в разноске по номенклатуре). Если эта галочка установлена, то надо будет при любой попытке прогнать себестоимость через закрытую проводку, немедленно списывать данную корректировку себестоимости на счет корректировок прошлых периодов. При этом надо ОЧЕНЬ тщательно расписать в методичке, что вообще говоря, корректировка прошлых периодов является признаком проблемы с первичными данными. Либо нарушена хронология приходов и расходов, и начисление накладных расходов на открытый приход, из за нарушения хронологии, протягивается через приходы прошлых периодов, либо бухгалтерша по ошибке повесила текущие накладные расходы на накладную прошлого месяца. Причем надо понимать, что подход этот поможет только в сложных ситуациях (когда у нас циклы в графе себестоимости есть или что-то подобное). Если у меня незакрытый расход прошлого месяца сопоставился с приходом текущего (просто потому что бардак в первичке), то никакие переоценки и счета корректировок прошлых периодов - не помогут, потому что списание это сможет работать только при корректировке ПРИХОДА прошлых периодов - а у нас в этом примере у прихода все впорядке с датой, не в порядке дата у расхода...

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

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

Вот - пожалуй все. Привет AEG'у

[mazzy]

согласен, кроме одного

Цитата:

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

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

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


сейчас по принципу "зупрещать неправильный ввод" работают русские авансовые отчеты.
я понимаю, что они пытаются выставить зронологию и повторную печать...
но пользователи не готовы платить ТАКУЮ цену, пользователи не готовы отказываться от "неправильного ввода", пользователи требуют чтобы система работала хоть как-то (желательно корректно) при любом раскладе.

[fed]

Цитата:

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

согласен, кроме одного


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


сейчас по принципу "зупрещать неправильный ввод" работают русские авансовые отчеты.
я понимаю, что они пытаются выставить зронологию и повторную печать...
но пользователи не готовы платить ТАКУЮ цену, пользователи не готовы отказываться от "неправильного ввода", пользователи требуют чтобы система работала хоть как-то (желательно корректно) при любом раскладе.

Возможно я не правильно выразился, но я имел в виду что в модуле закрытия склада, вместо нынешнего корявого и бесполезного проверочного отчета (В форме закрытия склада "Закрытие->Проверка количества") нужен более продвинутый тул, который будет просто ПРЕДУПРЕЖДАТЬ пользователя что у него не сложилось с хронологичностью данных и результаты закрытия,вероятно, будут некорректными. Не хочешь тул запускать - не надо. Запустил - получи результат.
Теоретически можно даже пофантазировать что было бы, если бы этот тул позволял бы сторнировать некорректные документы и проводить их корректной датой (но это очень тяжело реализовать)...

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

[fed]

Цитата:

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

Наконец, говоря о проблеме корректировок складских проводок задним числом, затронутой опять таки logger'ом, надо:
1. Наконец-то написать вместо продвинутого отчета по остаткам (из Rollup7), который конечно все партнеры благополучно проигноирировали, а внятную методичку, которая объясняла бы как и почему считается финансовый остаток по номенклатуре на дату, объясняла бы что рассчитывать остаток тупым суммированием inventTrans - нельзя, а также то, что считать денежный остаток по номенклатуре можно только в разрезе подмножества финансовой складской аналитики. Я просто ни разу не видел чтобы кто-то всерьез использовал стандартные отчеты по складским запасам, все пишут свои (просто потому что нужен красивенький отчет с экспортом и в том виде, в котором его привык видеть клиент). И большая часть партнеров не обладает пониманием того как правильно себестоимость складскую считать.
2. Надо сделать специальную галочку (в складской модели наверное) "Запрет корректировки закрытых проводок" и специальный счет "корректировки прошлых периодов" (в разноске по номенклатуре). Если эта галочка установлена, то надо будет при любой попытке прогнать себестоимость через закрытую проводку, немедленно списывать данную корректировку себестоимости на счет корректировок прошлых периодов. При этом надо ОЧЕНЬ тщательно расписать в методичке, что вообще говоря, корректировка прошлых периодов является признаком проблемы с первичными данными. Либо нарушена хронология приходов и расходов, и начисление накладных расходов на открытый приход, из за нарушения хронологии, протягивается через приходы прошлых периодов, либо бухгалтерша по ошибке повесила текущие накладные расходы на накладную прошлого месяца. Причем надо понимать, что подход этот поможет только в сложных ситуациях (когда у нас циклы в графе себестоимости есть или что-то подобное). Если у меня незакрытый расход прошлого месяца сопоставился с приходом текущего (просто потому что бардак в первичке), то никакие переоценки и счета корректировок прошлых периодов - не помогут, потому что списание это сможет работать только при корректировке ПРИХОДА прошлых периодов - а у нас в этом примере у прихода все впорядке с датой, не в порядке дата у расхода...

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