10.10.2011, 23:19
|
#41 |
|
Участник
|
в этом случае саповская идеология контроллинга с заведением БЕ-независимой controlling area попадает в яблочко...
|
|
|
|
11.10.2011, 01:19
|
#42 |
|
Участник
|
Спасибо всем высказавшимся. Вот черновик. Поскольку человек я не обученный профессиональному переводу и не имевший дела с русским функционалом, прошу меня проверить на случай если я чего-то недопонял, переврал или тупо неграмотно написал.
============================================================== EVGL: According to IFRS, material and labor consumption should be considered when calculating production costs. However, in Russian and Turkish accounting, it is also accepted to include worker salaries, amortization of machines, electricity etc. to production costs. For now, the only way to do that in AX is by using "allocation + cost adjustment", in "semi-manual mode". It should be possible to include transportation and other costs to the cost of raw materials, and that feature should be integrated to the kernel. This feature is implemented in the Russian localization higher than AX2009 RU4, and the solution is good enough: "accounting distribution". This is a must in all accounting standards, from London to Vladivostok (Russia's largest port city on the Pacific Ocean). Our consultant specialized in Austrian finance was fascinated by this feature. Well, this one is not quite related to costs, but posting of picking lists in AX does not follow the Western accounting standards. Both "Debit Balance - Credit Balance" and "Debit Costs - Credit Balance" postings are not good enough, so auditors ask questions. I suppose, your analysts are aware about this problem, but do nothing to resolve the issue. There is no way to assign single material consumption to multiple production orders based on some sort of "distribution base". Say, we pour a bag of polyethylene to a machine, but we don't know for sure how many kilograms have been consumed for production order #3 in a group of 5 orders of the same type. And the most fatal flaw is that there is no way to make several byproducts based on one production order (except in the Process module). Costs are not distributed; it is not possible to account for that in master planning. This modification is so complex that there are hardly any partners that would dare to solve this problem. There is a "waxwork" of that in the Russian localization, but it is only a "waxwork". (A comment left to this post by another user: I have nothing to add to that. All major functional holes would get closed.) ============================================================== Raven Melancholic: I cannot tell what could be a technical must-have in this module. But from my point of view, what is needed in Russia is: 1. documentation that would explain how CERTAIN enterprise problems could be solved; 2. translated documentation, that would use terminology well-established in Russia; 3. publication of business cases, in Russian of course. All in all, one should not forget that documentation about development in AX may be published in English, but when we are talking about consultants, finance and operation people, the documentation must be translated to the local language, if you want to promote your module in the region. Terminology and examples should consider the well-established preferences in the region. ============================================================== Logger: Calculation of cost amounts (say, when posting inventory movement journals) is buggy under certain conditions. To be honest, there is no cost calculation per inventory dimension in AX. Costs may become mixed for different dimension values – regardless of settings – when moving inventory, filling return lots or marking. --------------- I would also consider improving inventory reconciliation functionality. The biggest problem for finance analysts is that it is possible to use the current system date when adjusting a posting from a previous period. To my experience, the average finance analyst or accountant have difficulties with understanding this. They just don't get it. As a result, after each inventory closing, questions arise as to why inventory doesn't reconcile to ledger. It would be nice to have something intuitive enough to most of the users. I can't propose anything concrete so far. ============================================================== fed: As I see it, you have 2 possible paths of development. -------------- The first approach is to keep maintaining compatibility with the old versions and don't implement subsidiary accounts for cost accounts. In that case I agree with EVGL. What we are missing is an extensible mechanism of cost distribution, to which I would be able to add new distribution bases and distribution objects in an easy way. Say, it would be possible to create a new distribution object “a truck with a cargo” and a new base “kilogram per kilometer”, and then create the second level for the distribution object “goods in the truck”, with a new base “cubic meters of the cargo”. Again, I don't expect a new transportation module from you; I just need a mechanism that would allow me to easily integrate my own transportation module to the standard cost distribution logic. -------------- Another approach is more systematic, but incompatible with the old versions. You could create a cost hierarchy table, a cost posting table and a new account type in the ledger journal - "Costs". But this approach is rather dangerous because: 1. The cost hierarchy will need to be created dynamically. That is, if there is a "transportation costs" branch, then there should be possibility to assign costs to both the transportation in general and the certain purchase. So far, I can’t imagine the right way to implement that. 2. You will need to implement a predefined hierarchy of costs (in order to link each module to the certain place in the hierarchy). Existence of the predefined hierarchy will make the system less flexible, so it will not fit to all customer requirements. Traditionally, documentation is shitty, as it describes checkboxes rather than the economic model, so I am quite sure that the partners will not be able to understand this model, and they will do all sorts of stupid things at each implementation. In other words, if you want to use predefined models - go on. But those models should better be well documented... 3. Of course, the rewritten functionality will be full of bugs in the very beginning (which is inevitable). Considering the quality of the support and difficulty to register bugs in it - the bugs fixing process (I am talking about stupid bugs in the code and not bugs in the design) may become quite lengthy. -------------- Personally, I still believe the #2 is possible, but I would NOT recommend you to consider it without keeping in mind the channel of sell/support/partners/documentation. I hope you remember what road is paved with good intentions... -------------- … Axapta has its own way. The Dynamics AX team should try building an application framework that would be easy to extend, rather than try to make a product for direct implementation at the clients. Today, we see the opposite: they either extend the kernel (which is useless for real implementations) or make attempts to slap together some end-user functionality, which lacks both extensibility and common sense. For example, Workflow or purchase requisitions. It is much easier to make something from scratch ourselves than to figure out how that miserable crap works. They’d better extend the fundamental things and fundamental APPLICATION frameworks. I wish that all of them who break into licking the interface or moving everything to .Net were given to the Bing team (which is in such a deep shit that plus-minus 100-200 morons would not make it worse). More than that – the attempts to copy functionality from competitors without comprehending it and understanding Axapta ended up in the new GL architecture, which is actually copied, as I understand, from the Oracle E-Business Suite. ============================================================== mazzy: I wish there were storage overheads, i.e. amounts appeared just because of storing goods. Today the only way to do that is by doing cost adjustment on open receipts, which is not entirely correct, as there may be un-invoiced and un-settled issues. ============================================================== ppson: 1. Implement “Process in Work” module 2. Make the costing module separate from the General Ledger; integrate cost accounting and distribution with purchasing/orders/inventory module/production/product builder/GL journals, so it would be possible to plan and collect costs in WIP/items per cost group at any operation – when purchasing, producing, handling inventory and selling. Cost transactions should be collected from this module, and not from GL. ============================================================== |
|
|
|
11.10.2011, 09:46
|
#43 |
|
Moderator
|
Хотя к качеству перевода претензий нету, но я пожалуй свою часть чуть-чуть подправлю (просто они явно наш форум не читают и контекст не понимают).
As I see it, you have 2 possible paths of development. -------------- The first approach is to keep maintaining compatibility with the old versions and don't implement subsidiary accounts for cost accounts. In that case I agree with EVGL. What we are missing is an extensible mechanism of cost distribution, to which I would be able to add new distribution bases and distribution objects in an easy way. Say, it would be possible to create a new distribution object “a truck with a cargo” and a new base “kilogram per kilometer”, and then create the second level for the distribution object “goods in the truck”, with a new base “cubic meters of the cargo”. Again, I don't expect a new transportation module from you; I just need a mechanism that would allow me to easily integrate my own transportation module to the standard cost distribution logic. -------------- Another approach is more systematic, but incompatible with the old versions. You could create a cost hierarchy table, a cost posting table and a new account type in the ledger journal - "Costs". But this approach might be rather dangerous because: 1. The cost hierarchy will need to be created dynamically. That is, if there is a "transportation costs" branch, then there should be possibility to assign costs to both the transportation in general and the certain purchase. So far, I can’t imagine the right way to implement that. 2. You will need to implement a predefined hierarchy of costs (in order to link each module to the certain place in the hierarchy). Existence of the predefined hierarchy will make the system less flexible, so it will not fit to all customer requirements. Traditionally, documentation is shitty, as it describes checkboxes rather than the economic model, so I am quite sure that the partners will not be able to understand this model, and they will do all sorts of stupid things at each implementation. In other words, if you want to use predefined models - go on. But those models should better be well documented... 3. Of course, the rewritten functionality will be full of bugs in the very beginning (which is inevitable). Considering the quality of the support and difficulty to register bugs in it - the bugs fixing process (I am talking about stupid bugs in the code and not bugs in the design) may become quite lengthy. -------------- Personally, I still believe the #2 is possible, but I would NOT recommend you to consider it without keeping in mind the state of sales channel/support channel/partners management channel/documentation development practice. I hope you remember what road is paved with good intentions... -------------- … Axapta has its own way. The Dynamics AX team should try building an application framework that would be easy to extend, rather than try to make a product for direct implementation at the clients. Today, we see the opposite: they either extend the kernel (which is useless for real life implementations) or make attempts to slap together some end-user functionality, which lacks both extensibility and common sense. For example, Workflow or purchase requisitions. It is much easier to make something from scratch ourselves than to figure out how that miserable crap works. They’d better extend the fundamental things and fundamental APPLICATION frameworks. I wish that all of them who break into licking the interface or moving everything to .Net were given to the Bing team (which is in such a deep shit that plus-minus 100-200 morons would not make it worse). More than that – the attempts to copy functionality from competitors without comprehending it and understanding Axapta's approach ended up in the ill-fated new GL architecture, which is actually copied, as I understand, from the Oracle E-Business Suite. Последний раз редактировалось fed; 11.10.2011 в 10:39. |
|
|
|
11.10.2011, 10:10
|
#44 |
|
Участник
|
Цитата:
Сообщение от Stitch_MS
Спасибо всем высказавшимся. Вот черновик.
|
|
|
|
11.10.2011, 10:17
|
#45 |
|
Модератор
|
Цитата:
Сообщение от Мирослав Лянцевич
позиционирование объясняется происхождением...
САП воплощение немецкой школы учета, для которой учет - точная наука... Акса - американская система, в которой учет это проявление психологии... Отсюда отсутствие конкретных объектов и шаблонов... С Уважением, Георгий |
|
|
|
11.10.2011, 10:54
|
#46 |
|
Moderator
|
Цитата:
Сообщение от Raven Melancholic
Мое сообщение можно не вписывать. Я, ошибочно, решил, что речь идет о модуле COSCosting.
Пожалуй это тоже можно перевести и включить в описание ситуации 
Последний раз редактировалось fed; 11.10.2011 в 11:02. |
|
|
|
11.10.2011, 11:41
|
#47 |
|
Пенсионер
|
А мне нравится 2-я идея fed по учету косвенных затрат, а если строить не одно дерево из МВЗ, а несколько и использовать принцип весовых коэффицентов для тех МВЗ в которых затруднена фиксация затрат, то ИМХО получится интересная система.
__________________
 Законы природы еще никто не отменял!А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ |
|
|
|
11.10.2011, 12:24
|
#48 |
|
Участник
|
Цитата:
Сообщение от fed
Пожалуй это тоже можно перевести и включить в описание ситуации
Насчет поправок в черновик - тоже сделаем. Я буду ждать новых предложений до завтра, а завтра разошлю окончательный перевод нашей команде. |
|
|
|
11.10.2011, 16:23
|
#49 |
|
Участник
|
На счет поправок в черновик - по-моему, грубовато получилось про Bing:
Цитата:
Сообщение от Stitch_MS
I wish that all of them who break into licking the interface or moving everything to .Net were given to the Bing team (which is in such a deep shit that plus-minus 100-200 morons would not make it worse).
|
|
|
|
11.10.2011, 16:30
|
#50 |
|
Banned
|
О, я даже не обратил внимания... deep shit, stupid moron... ценный перевод, надо прямо так и в спецификацию включить.
|
|
|
|
11.10.2011, 16:40
|
#51 |
|
Участник
|
Цитата:
Сообщение от EVGL
О, я даже не обратил внимания... deep shit, stupid moron... ценный перевод, надо прямо так и в спецификацию включить.
Всерьез что-ли ? Нафига такое включать ? |
|
|
|
11.10.2011, 17:43
|
#52 |
|
Участник
|
Цитата:
Сообщение от 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 - человек подуставший от таких вещей, вот и хочется ему высказаться как можно более выразительно. Кстати, коллеги, есть какие-нибудь мысли, пожелания или крепкие, но конструктивные слова, по-поводу закрытия склада? |
|
|
|
11.10.2011, 17:50
|
#53 |
|
Moderator
|
Цитата:
Сообщение от Logger
Да вы чего, люди ?
Всерьез что-ли ? Нафига такое включать ? А если наезжать будут - могу по пунктам объяснить - в каком именно гробу и почему именно я видел их замечательные нововведения и как именно они повысят затраты на имплементацию и снизят качество решений... Кстати - да - licking the interface - неправильно. polishing the interface - более похоже на правду... |
|
|
|
11.10.2011, 18:08
|
#54 |
|
Участник
|
но Майкрософт вряд ли бы купил этот продукт, если бы он не соответствовал практике англо-саксонской бухгалтерии...
ее принцип - полная свобода действий, например, отсутствие единого плана счетов, замена объективных понятий (исторической стоимости) субъективными (рыночной оценке активов)... Цитата:
Сообщение от George Nordic
Надеюсь, Вы шутите? Как раз в Штатах DAX - не распространена, там есть Microsoft Dynamics SL (Solomon) и Microsoft Dynamics GP (Great Plains). Могу показать диск Damgaard Axapta 2.0, возможно, вспомните, что AX изначально являлся Европейской системой, и большинство инсталляций - именно в Европе.
С Уважением, Георгий |
|
|
|
11.10.2011, 18:11
|
#55 |
|
Участник
|
в итоге имеем не коробку такую как 1С, а среду разработки для автоматизации учета.... "героические усилия этих техноклоунов" лишь делают систему максимально адаптивной под нужды клиента...
|
|
|
|
11.10.2011, 18:15
|
#56 |
|
Участник
|
вопрос лишь в скилзах консультантов, которые адаптивность пустят в нужное русло и покажут value клиентам от него... например, создав что -то типа графика закрытия периода на базе workflow...
|
|
|
|
11.10.2011, 23:30
|
#57 |
|
Участник
|
Да, адекватные люди в MDCC еще остались.
По поводу впечатлений о DAX 2012 - было бы интересно услышать ваше мнение по пунктам. Что нравится, что не нравится. Пытался ли кто-то пройти через обновление данных на реальном клиенте ну и так далее. Еще один вопрос поднятый Александром - закрытие склада. Если у кого-то есть комментарии/пожелания - пишите. В настоящий момент мы пытаемся собрать данные по текущим проблемам с данным функционалом. Есть желание серьезно поработать над этой темой в рамках следующего релиза. |
|
|
|
12.10.2011, 10:02
|
#58 |
|
Moderator
|
Цитата:
Сообщение от SEKL
По поводу впечатлений о DAX 2012 - было бы интересно услышать ваше мнение по пунктам. Что нравится, что не нравится.
По поводу закрытия склада - так там только одна принципиальная проблема осталась, упомянутая Logger'ом. Надо (точнее говоря - можно) привязать себестоимость (и мгновенную себестоимость списания, и истинную себестоимость рассчитываемую при закрытии склада) не к лоту, а к сочетанию лот+аналитика финансового склада (чтобы себестоимость не ехала при переносах). Только в таком случае, вам еще придется ограничить возможности слияния/расщепления партий в обычном журнале переноса (чтобы не получалось что 3 партии списали и 2 других партии оприходовали) и сделать какой-то специальный журнал слияния/разделения аналитик, который позволял бы только операции вида 1:n или n:1 (Но никак не n:m). Из более мелкого (но полезного) - надо бессмысленную проверку остатков на текущую дату, заменить на проверку остатков по каждой номенклатуре в течении всего закрываемого периода. Если у меня номенклатуру продали чуть раньше чем купили (хотя сейчас остаток положительный или нулевой), система должна выводить в отчет сообщение о том что по такой-то номенаклатуре была нарушена хронология событий и точной себестоимости рассчитать невозможно. Наконец, говоря о проблеме корректировок складских проводок задним числом, затронутой опять таки logger'ом, надо: 1. Наконец-то написать вместо продвинутого отчета по остаткам (из Rollup7), который конечно все партнеры благополучно проигноирировали, а внятную методичку, которая объясняла бы как и почему считается финансовый остаток по номенклатуре на дату, объясняла бы что рассчитывать остаток тупым суммированием inventTrans - нельзя, а также то, что считать денежный остаток по номенклатуре можно только в разрезе подмножества финансовой складской аналитики. Я просто ни разу не видел чтобы кто-то всерьез использовал стандартные отчеты по складским запасам, все пишут свои (просто потому что нужен красивенький отчет с экспортом и в том виде, в котором его привык видеть клиент). И большая часть партнеров не обладает пониманием того как правильно себестоимость складскую считать. 2. Надо сделать специальную галочку (в складской модели наверное) "Запрет корректировки закрытых проводок" и специальный счет "корректировки прошлых периодов" (в разноске по номенклатуре). Если эта галочка установлена, то надо будет при любой попытке прогнать себестоимость через закрытую проводку, немедленно списывать данную корректировку себестоимости на счет корректировок прошлых периодов. При этом надо ОЧЕНЬ тщательно расписать в методичке, что вообще говоря, корректировка прошлых периодов является признаком проблемы с первичными данными. Либо нарушена хронология приходов и расходов, и начисление накладных расходов на открытый приход, из за нарушения хронологии, протягивается через приходы прошлых периодов, либо бухгалтерша по ошибке повесила текущие накладные расходы на накладную прошлого месяца. Причем надо понимать, что подход этот поможет только в сложных ситуациях (когда у нас циклы в графе себестоимости есть или что-то подобное). Если у меня незакрытый расход прошлого месяца сопоставился с приходом текущего (просто потому что бардак в первичке), то никакие переоценки и счета корректировок прошлых периодов - не помогут, потому что списание это сможет работать только при корректировке ПРИХОДА прошлых периодов - а у нас в этом примере у прихода все впорядке с датой, не в порядке дата у расхода... Наконец- надо сделать то что давно сделали в русской локализации -завести в настройках разносок специальный счет для списания ошибок и погрешностей округления при закрытии (обычных, а не связанных с корректировками прошлого периода) и опять таки написать в методичке как оно работает. Просто в английском стандарте для этого используется обычный счет прибылей и убытков по номенклатуре, и для среднего консультанта, понять по ваучеру закрытия, откуда у нас упало сколько-то там копеек на этот счет с какой-то аналитикой - выше понимания. Ну и наконец - можно в inventSettlement занести новое поле (или расширить там какие-то из перечислимых полей с типом сопоставления), чтобы позволить легко вычленять в inventSettlement все эти служебные корректировки со списанием ошибок и округлений... Вот - пожалуй все. Привет AEG'у
Последний раз редактировалось fed; 12.10.2011 в 11:25. Причина: Стилистику подправил. |
|
|
|
12.10.2011, 10:16
|
#59 |
|
Участник
|
согласен, кроме одного
Цитата:
Сообщение от fed
Если у меня номенклатуру продали чуть раньше чем купили (хотя сейчас остаток положительный или нулевой), система должна выводить в отчет сообщение о том что по такой-то номенаклатуре была нарушена хронология событий и точной себестоимости рассчитать невозможно.
не надо запрещать. если пользователь ввел, то надо рассчитывать "как получится", при этом кучу сил положить на то, чтобы рассчитывалось правильно. не надо запрещать пользователю - они ж все равно заставят внедренцев обойти проверку. сейчас по принципу "зупрещать неправильный ввод" работают русские авансовые отчеты. я понимаю, что они пытаются выставить зронологию и повторную печать... но пользователи не готовы платить ТАКУЮ цену, пользователи не готовы отказываться от "неправильного ввода", пользователи требуют чтобы система работала хоть как-то (желательно корректно) при любом раскладе. |
|
|
|
12.10.2011, 10:21
|
#60 |
|
Moderator
|
Цитата:
Сообщение от mazzy
согласен, кроме одного
не надо так делать. не надо запрещать. если пользователь ввел, то надо рассчитывать "как получится", при этом кучу сил положить на то, чтобы рассчитывалось правильно. не надо запрещать пользователю - они ж все равно заставят внедренцев обойти проверку. сейчас по принципу "зупрещать неправильный ввод" работают русские авансовые отчеты. я понимаю, что они пытаются выставить зронологию и повторную печать... но пользователи не готовы платить ТАКУЮ цену, пользователи не готовы отказываться от "неправильного ввода", пользователи требуют чтобы система работала хоть как-то (желательно корректно) при любом раскладе. Теоретически можно даже пофантазировать что было бы, если бы этот тул позволял бы сторнировать некорректные документы и проводить их корректной датой (но это очень тяжело реализовать)... Кстати - я когда-то в своей статье писал почему трудно в момент списания проверять остаток на дату. Во первых из за производительности, во вторых - из за резервирования (Если у тебя есть резерв сейчас, тебе трудно объяснить почему тебе не дают списать товар). Ну то есть - я очень сомневаюсь что микрософт смог бы сделать такую проверку в момент списания, даже если бы очень захотел... |
|
|
| Теги |
| ax2012, пожелания, себестоимость, хотелка, ax7 |
|
|
| Опции темы | Поиск в этой теме |
| Опции просмотра | |
|
Линейный вид
