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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.10.2011, 23:19   #41  
Мирослав Лянцевич is offline
Мирослав Лянцевич
Участник
 
77 / 11 (1) +
Регистрация: 30.08.2006
в этом случае саповская идеология контроллинга с заведением БЕ-независимой controlling area попадает в яблочко...
Старый 11.10.2011, 01:19   #42  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
396 / 478 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
Спасибо всем высказавшимся. Вот черновик. Поскольку человек я не обученный профессиональному переводу и не имевший дела с русским функционалом, прошу меня проверить на случай если я чего-то недопонял, переврал или тупо неграмотно написал.

==============================================================

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  
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
Хотя к качеству перевода претензий нету, но я пожалуй свою часть чуть-чуть подправлю (просто они явно наш форум не читают и контекст не понимают).

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  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Спасибо всем высказавшимся. Вот черновик.
Мое сообщение можно не вписывать. Я, ошибочно, решил, что речь идет о модуле COSCosting.
Старый 11.10.2011, 10:17   #45  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от Мирослав Лянцевич Посмотреть сообщение
позиционирование объясняется происхождением...
САП воплощение немецкой школы учета, для которой учет - точная наука... Акса - американская система, в которой учет это проявление психологии... Отсюда отсутствие конкретных объектов и шаблонов...
Надеюсь, Вы шутите? Как раз в Штатах DAX - не распространена, там есть Microsoft Dynamics SL (Solomon) и Microsoft Dynamics GP (Great Plains). Могу показать диск Damgaard Axapta 2.0, возможно, вспомните, что AX изначально являлся Европейской системой, и большинство инсталляций - именно в Европе.

С Уважением,
Георгий
Старый 11.10.2011, 10:54   #46  
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
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Мое сообщение можно не вписывать. Я, ошибочно, решил, что речь идет о модуле COSCosting.
На самом деле - не ошибочно. Costing - понятие широкое. Но то что в понимании пользователей и консультантов COSCosting и закрытие склада отделены друг от друга непроходимым барьером, очень хорошо и наглядно демонстрирует проблему.

Пожалуй это тоже можно перевести и включить в описание ситуации

Последний раз редактировалось fed; 11.10.2011 в 11:02.
Старый 11.10.2011, 11:41   #47  
blokva is offline
blokva
Пенсионер
Аватар для blokva
SAP
NavAx Club
 
743 / 167 (7) ++++++
Регистрация: 04.06.2003
Адрес: Беларусь
А мне нравится 2-я идея fed по учету косвенных затрат, а если строить не одно дерево из МВЗ, а несколько и использовать принцип весовых коэффицентов для тех МВЗ в которых затруднена фиксация затрат, то ИМХО получится интересная система.
__________________
Законы природы еще никто не отменял!
А еще у меня растет 2 внучки!!! Кому интересно подробности тут:
http://www.baby-shine.com/
Старый 11.10.2011, 12:24   #48  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
396 / 478 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от fed Посмотреть сообщение
Пожалуй это тоже можно перевести и включить в описание ситуации
Сделаем.

Насчет поправок в черновик - тоже сделаем.

Я буду ждать новых предложений до завтра, а завтра разошлю окончательный перевод нашей команде.
Старый 11.10.2011, 16:23   #49  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
На счет поправок в черновик - по-моему, грубовато получилось про 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).
По-русски это все как-то проще воспринимается - как прикол. Плюс, если уж оставлять это, то "вылизывать интерфейс", наверно, лучше перевести более нейтрально - как-нить to tweak/to polish...
Старый 11.10.2011, 16:30   #50  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
О, я даже не обратил внимания... deep shit, stupid moron... ценный перевод, надо прямо так и в спецификацию включить.
Старый 11.10.2011, 16:40   #51  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от EVGL Посмотреть сообщение
О, я даже не обратил внимания... deep shit, stupid moron... ценный перевод, надо прямо так и в спецификацию включить.
Да вы чего, люди ?
Всерьез что-ли ?
Нафига такое включать ?
Старый 11.10.2011, 17:43   #52  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
396 / 478 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от 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  
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
Цитата:
Сообщение от Logger Посмотреть сообщение
Да вы чего, люди ?
Всерьез что-ли ?
Нафига такое включать ?
Просто говорят что некоторые участники разработки DAX2012 считают что они сделали кайфовый продукт, с замечательной удобнейшей средой разработки, которой так не хватало любой современной ERP. Буквально таки ждут что им всем выдадут футболки с надписью "Я разработал DAX2012" и они будут гордо в них ходить еще лет 10 не снимая.Будет полезно если на них ушат холодной воды выльют. Уверен, что вменяемые люди в MDCC (которые там еще остались кстати) примерно также оценивают усилия по переводу на .net, поддержку workflow, интеграцию с OCS и все другие героические усилия этих техноклоунов. Только им корпоративная вежливость не позволяет это от своего имени всем этим дотнетчикам написать... А мне в общем пофигу, мои пути с микрософтовскими мало пересекаются, так что если на меня эти любители дотнета обидятся - то мне в общем разницы никакой...
А если наезжать будут - могу по пунктам объяснить - в каком именно гробу и почему именно я видел их замечательные нововведения и как именно они повысят затраты на имплементацию и снизят качество решений...

Кстати - да - licking the interface - неправильно. polishing the interface - более похоже на правду...
Старый 11.10.2011, 18:08   #54  
Мирослав Лянцевич is offline
Мирослав Лянцевич
Участник
 
77 / 11 (1) +
Регистрация: 30.08.2006
но Майкрософт вряд ли бы купил этот продукт, если бы он не соответствовал практике англо-саксонской бухгалтерии...

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



Цитата:
Сообщение от George Nordic Посмотреть сообщение
Надеюсь, Вы шутите? Как раз в Штатах DAX - не распространена, там есть Microsoft Dynamics SL (Solomon) и Microsoft Dynamics GP (Great Plains). Могу показать диск Damgaard Axapta 2.0, возможно, вспомните, что AX изначально являлся Европейской системой, и большинство инсталляций - именно в Европе.

С Уважением,
Георгий
Старый 11.10.2011, 18:11   #55  
Мирослав Лянцевич is offline
Мирослав Лянцевич
Участник
 
77 / 11 (1) +
Регистрация: 30.08.2006
в итоге имеем не коробку такую как 1С, а среду разработки для автоматизации учета.... "героические усилия этих техноклоунов" лишь делают систему максимально адаптивной под нужды клиента...
Старый 11.10.2011, 18:15   #56  
Мирослав Лянцевич is offline
Мирослав Лянцевич
Участник
 
77 / 11 (1) +
Регистрация: 30.08.2006
вопрос лишь в скилзах консультантов, которые адаптивность пустят в нужное русло и покажут value клиентам от него... например, создав что -то типа графика закрытия периода на базе workflow...
Старый 11.10.2011, 23:30   #57  
SEKL is offline
SEKL
Участник
Сотрудники Microsoft Dynamics
 
48 / 27 (1) +++
Регистрация: 15.08.2007
Адрес: Denmark
Да, адекватные люди в MDCC еще остались.

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

Еще один вопрос поднятый Александром - закрытие склада. Если у кого-то есть комментарии/пожелания - пишите. В настоящий момент мы пытаемся собрать данные по текущим проблемам с данным функционалом. Есть желание серьезно поработать над этой темой в рамках следующего релиза.
Старый 12.10.2011, 10:02   #58  
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
Цитата:
Сообщение от 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  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
согласен, кроме одного
Цитата:
Сообщение от fed Посмотреть сообщение
Если у меня номенклатуру продали чуть раньше чем купили (хотя сейчас остаток положительный или нулевой), система должна выводить в отчет сообщение о том что по такой-то номенаклатуре была нарушена хронология событий и точной себестоимости рассчитать невозможно.
не надо так делать.
не надо запрещать. если пользователь ввел, то надо рассчитывать "как получится", при этом кучу сил положить на то, чтобы рассчитывалось правильно.
не надо запрещать пользователю - они ж все равно заставят внедренцев обойти проверку.


сейчас по принципу "зупрещать неправильный ввод" работают русские авансовые отчеты.
я понимаю, что они пытаются выставить зронологию и повторную печать...
но пользователи не готовы платить ТАКУЮ цену, пользователи не готовы отказываться от "неправильного ввода", пользователи требуют чтобы система работала хоть как-то (желательно корректно) при любом раскладе.
__________________
полезное на axForum, github, vk, coub.
Старый 12.10.2011, 10:21   #60  
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
Цитата:
Сообщение от mazzy Посмотреть сообщение
согласен, кроме одного


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


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

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

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
axforum blogs: Квест: Подружим Dynamics Ax 2009 Sp1 RU7 c SharePoint Foundation 2010 Blog bot DAX Blogs 4 16.10.2017 17:50
Проблема: Массовое развертывание клиентов Dynamics Ax 2009 Poleax DAX: Администрирование 8 23.08.2012 17:28
dynamics-ax: Official Details about Dynamics AX '6' released, including comments from Microsofts Kees Hertogh Blog bot DAX Blogs 0 11.01.2011 05:22
dynamics-ax: Interview with Apparel and Fashion Veteran, Joe Fink Blog bot DAX Blogs 1 07.01.2011 13:43
gatesasbait: Dynamics AX 2009 SSRS and SSAS Integration Tips Blog bot DAX Blogs 3 09.07.2009 13:07
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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