fed: Net requirements update in MRP Module and Working Set of MRP

[Blog bot]

Источник: http://fedotenko.info/?p=247
==============

Most of Dynamics AX specialists (especially from support) heard about inventSumLogTTS table. Everyone knows that this table somehow is related to MRP; Everyone knows that if you do not run MRP, your inventSumLogTTS table grows bigger and bigger and eventually you need to clean it somehow.  But since detailed documentation on static/dynamic plan update algorithms is absent,  not many people understand how Axapta actually use this table for plan updates; what are advantages and caveats of dynamic vs static plan use;how order explosion differs from regeneration planning and so on…

I wrote this text mostly from my experience with Dynamics AX 2009. In the new version (DAX2012) approach remained the same from functional point of view, only technical details changed, so this information can be useful also for people using DAX2012.

A bit of history

As I wrote in my blog before, inventSumLogTTS table began its life (somewhere in late releases Axapta 2.5) only as a tool to track a list of changes which was applied to inventSum table in independent DB transaction. Should the main transaction be rolled back, the system was to iterate over related records in inventSumLogTTS and programmatically  rollback changes to inventSum. Starting from Axapta 3.0, inventSumLogTTS table started to be used to support dynamic update to MRP plan. In version Dynamics AX 4.0, the whole Inventory MultiTransaction System was dropped from Axapta and replaced with new approach. Nevertheless inventSumLogTTS table still exists in the system, but nowadays it is used only to support dynamic MRP plan update. Today, name of the table is misleading, because now it is not used to log InventSum updates. As of versions 4-2012 it is used only to keep track of inventTrans changes, which have not been applied to dynamic plan yet.



How data gets into inventSumLogTTS

The mechanism which now (in versions 4.0/2009/2012) is creating new records in inventSumLogTTS is the very same mechanism which is used to update inventSum. (I described this mechanism in details in the article I mentioned). When inventTrans is inserted/updated/deleted  the system calls  inventUpdateOnHand.addInventSumLogTTS() method  to register deletion or insertion of inventTrans. (and update goes as a delete and insert). InventSumLogTTS records are kept in cache till the end of transaction and are actually written to database at the same time when the system updates inventSum records, related to inventory updated in transaction.

To link two records of inventSumLogTTS related to the same update of an inventory transaction, the system uses the sequenceNumber field of the inventSumLogTTS table.  The system registers changes of inventTrans record, till it become physically/financially updated (Deducted/Sold or Received/Purchased statuses).  Only the very first change of the transaction to physical/financial status is registered to inventSumLogTTS. Later this change is to be applied to Net Requirement of On-Hand type by dynamic plan update mechanism. Subsequent changes to the same inventory transaction are not recorded, since they are not anymore relevant for MRP, since now the transaction is a part of OnHand Stock which is represented in Net Requirements as a one on-hand net requirement per item and coverage dimensions.

Working Set of MRP and a bit of terminology

To simplify further discussion I want to introduce a new term – Working Set.  I will use this term to describe a list of net requirements which are participating in current MRP session. In different stages of MRP session, content of that list is different. After update phase, it contains issue net requirements to be covered, during coverage phas it contain mixture of covered issue net requirements, covering receipt net requirements and uncovered issue net requirements to be covered. After coverage phase, working set contains only covered/covering net requirements.

But the point is: Working set of MRP session  is the most fundamental thing for understanding of MRP process and it always defined by adding to it uncovered issue net requirements. Everything else is implementation details.

Generally, there are two ways to start MRP: One is to start MRP from Master Planning->Periodic->Master planning; Another – to click Master Planning->Periodic->Master planning  in Requirement Profile form. The menu items point to different classes. From implementation point of view, both classes use different algorithms. First class is optimized for multi-threaded scheduling of large number of net requirements. Second is optimized for scheduling for only 1 item, but it has good caching mechanisms, so it might work much faster sometimes. I will use term  Full MRP for MRP from Periodic menu and term Item MRP for MRP from Requirement Profile form. From functional point of view, there is a serious difference between these two kinds of MRP. Item MRP runs on the level of specific net requirements; Full MRP works on the level of item-coverage dimension combination. When net requirement is added to Working Set of Full MRP,  it implicitly adds whole net requirements with a given item and coverage dimension combination into Working Set. Technically speaking, Item MRP  is implemented by combination of classes ReqCalcScheduleItem (Responsible for the planning process itself) and ReqTransCache_Daily(Responsible for Working Set support). ReqTransCache_daily class holds a set of itemIds in a Working Set, a set of coverage dimension combinations for every item in a Working Set and a map with Net Requirements of Working Set itself. Full MRP is implemented by combination of classes ReqCalcScheduleItemTable (responsible for planning process) and ReqTransCache_Periodic (Responsible for Working Set support).ReqTransCache_Periodic class holds only a set of items and set of coverage dimensions for items in a Working Set. (Technically these sets are stored as ReqProcessItemListLine and ReqProcessItemDim list tables).

As we will see later, working set is created on Update phase of MRP session (I will use term Initial Working Set for it), but can grow as a result of Coverage phase of MRP Session (I will use term Extended Working Set for working set after extension by coverage planning).

I will also occasionally use term Items in working set, to refer to the list of items which have net requirements in the given Working Set; Sometimes, I will also use term Session Item Set  to designate the set of items defined before MRP start. In case of Item MRP, this item is defined by current content of Requirements Profile form; In case of Full MRP, the items are defined by query parameters in dialog box which is popping up in beginning of MRP process

Simplest case: Regeneration of static plan

Before we proceed our discussion any further, I want to discuss a bit the simplest case of MRP: Regeneration of static plan. If we are running MRP in regeneration mode, here is what happens:

1. The system deletes all net requirements and all coverage information for Session Item Set of MRP session (actually, approved planned orders can be spared from deletion, but we are not going into such a deep discussion).
2. If some of the deleted net requirements were planned orders, the system also deletes dependent demand for them (say, demand for sub-components of planned production order). If some of deleted dependent net requirements was covered by another planned orders, these planned orders are deleted recursively and so on. The main point is: If we are running MRP for a limited working set , after an update stage, we won’t have net requirements for all items in Item Set;Also some of receipt net requirements items outside of the initial Item Set will become available. Say, we are running MRP for Item A, which consists from items B,C and D. We delete all item requirements for item A, including planned production order. It leads also to deletion of issue item requirements (not all of them, just this PO) for item B,C and D. We also delete coverage for these issue net requirements and some other receipt net requirements (say – from invent on-hand) become unused and available to cover something else.
3. The system creates new issue net requirements  for all items from Session Item Set. It imports info from all necessary sources – on-hand data, inventory transactions, forecast data, Min/Max data from Item Coverage setup and so on… Created uncovered issue net requirement are added to Working Set, thus forming Initial Working Set.
4. Coverage phase begins for the working set items, having lowest BOM Level. The system fetches  from working set all uncovered issue net requirements  for an item (all our newly created net requirements from previous step are uncovered) creates coverage info (if appropriate receipt net requirements were found) or creates a new planned order and create coverage info for it. Covering net requirement is added to working set. If new planned orders were planed production orders, then the system adds derived issue net requirements for sub-components for the planned production orders into initial working set. (Thus is making it to  be an  Extended Working Set) .
5. Then the system proceed to build coverage for working set items with next lowest BOM level; Again new planned orders are created; It again leads to creation of planned orders and to further extension of working set. So, with every new BOM level, the working set contains more and more net requirements.
6. Finally, after processing of working set items with highest BOM Level, the system finish coverage phase and proceed to subsequent phases.
7. Futures and action planning are executed over net requirements in working set. Since this stages are more receipt-oriented, behavior of Item MRP and Full MRP differs a lot. In case of Item MRP, the system calculates action/futures only for receipt net requirements which were actually used in current MRP session(at least one record in coverage was created for these receipt net requirements). In case Full MRP,  the system calculates action/futures for all net requirements which has the same itemid+coverage dimensions combination as any requirement used in the current planning session.

The main conclusion of this section is that the Session Item Set in Regeneration mode MRP have two purposes:

• It show the system, net requirements for which items must be regenerated and included into Initial Working Set.
• It implicitly define extended working set of planning session, by providing root items for implicit BOM explosion. Every item of this explosion is included into extended working set.

I also want to mention that ONLY full regeneration for all items (MRP Item Set have all items in the system). Even in regeneration mode (which brings much more up-to-the-rules planning results then Net Change/Net Change Minimized mode), the system can create a bit inconsistent planned orders. Say, if we created new sales line and ran regeneration mode MRP for the item used in this salesLine, it can create new planned production order to cover it and then new planned purchase order to cover a demand in one of it’s sub-components. If this sub-components has Requirement coverage model – it is Okey. If the sub-components has ‘period’ coverage model – it is a minor problem in the plan.


More complex case: Regeneration of dynamic plan
Regeneration of dynamic plan generally work the same way as regeneration of static plan only with few extra steps added:

• Before importing an item’s inventTrans/inventSum data into net requirements (step 4 of the previous case), the system cleans all records of inventSumLogTTS table for the item. (In DAX2012 this behavior changed slightly, but we will discuss it later).
• On coverage phase, before processing of an item (even if it was not in Session Item Set) the system runs special class (reqTransUpdate) which updates net requirements for the item with relevant information from inventSumLogTTS table and then drop this information from aforementioned table. I will call this process a Dynamic Update Stage.

So, here what’s the data propagation chain is: When user changes a logistics document, changed data are propagated to inventTrans; Then in the end of transaction changed data are propagated to inventSumLogTTS; Then, finally, recorded changes is propagated to Net Requirements data (reqTrans). After the records from inventSumLogTTS are applied to Net Requirements, they are dropped from inventSumLogTTS since they have fulfilled the purpose of their existence and are not needed anymore.
I want specially mention, that the the net requirements updated on Dynamic Update Stage,  are not automatically included into the Working Set.  Dynamic Update Stage is not very fine-grained; It runs on level of item;It might be that Dynamic Update has updated net requirements with configuration, sizes or colors that have nothing in common with the current Session Item Set.
Thus, inclusion of all updated net requirement for an item into a Working Set, would cause unnecessary increase in a Working Set size and increase complexity of planning.

Interesting side effect of inventSumLogTTS application is that MRP session can adapt to latest changes to inventTrans made by users during planning session. Say, if we have item with BOM Level 4 in our Session Item Set, it might happen that between initial net requirements creation and coverage planning for BOM Level 4, a user will make a set of changes to inventTrans for the item. Since coverage planning for item starts from propagation of recent inventTrans changes to net requirements, results of MRP will be consistent with inventTrans state in the beginning of coverage process for given item. In case of regeneration of static plan, reqTrans state is consistent with the state of inventTrans during initial net requirement update phase; All subsequent changes to inventTrans are not reflected in net requirements.

Net change update of dynamic plan


In Net Change/Net Change minimized mode,update phase of MRP is executed in entirely different way. It is simply a sequence of Dynamic Updates  for items in a Session Item Set.  The system iterates over the Session Item Set and for every item it calls usual net requirement update mechanism (reqTransUpdate class), so that relevant net requirements will be updated with recent information from inventSumLogTTS. As a result of this update, some of  net requirements are dropped, some are created, for some requirements quantity is changed.
Next, during coverage phase, coverage process uncovered issue net requirements in Working Set. Again, before running coverage process for an item, the system run usual net requirements update mechanism as usual, so even items not in Session Item Set  have their net requirements updated after coverage phase.
Regarding requirement update phase, there are two difference between Net Change and Net Change minimized modes:

1. In Net Change Minimized mode,  the system includes into Initial Working Set  only those net requirements, which are marked as uncovered. Since after regeneration planning, the plan can not have uncovered net requirements, technically, the Initial Working Set consists only from issue net requirements updated on net requirements update stage. Since no receipt net requirements are included into Initial Working Set by update stage, subsequent futures and action stages will work only for net requirements which were actually used in the planning session (in case of Item MRP) or net requirements which has the same itemId and coverage dimensions as any of net requirements used in coverage phase of planning session (in case of Full MRP).
2. In Net Change, the system includes into Initial Working Set  all net requirements  for all items in Session Item Set.  Also, the system drops action information (action quantity and action days in net requirements and coverage table) for all net requirements in Initial Working Set (even already covered). As a result, action phase works for all net requirement with items  in Session Item Set. (Coverage phase of MRP session cannot be influences by inclusion of all net requirements, since it simply ignores all issue net requirements which are already covered).

Shortly speaking, Net Change/Net Change Minimized plan update mode is the fastest way to update your plan with actual data. But as usual, this update speed comes at a price. Often, Net Change update mode results in non-optimal plan. (I mean – even more non-optimal comparing to results of partial MRP Regeneration).

Say, you have a 80 pieces of an item in stock and a sales order for exactly 50 pieces  item with delivery date in distant future. (Say – in 6 month). Regular nightly planning in regeneration mode, created coverage record between these two net requirements. SalesLine is fully covered with invent on-hand, while invent on-hand net requirement has 30 free pieces  left. This 30 pieces can be used to cover something else. Suppose that on next morning a customer came and placed an urgent order for 70 pieces of the item with delivery date of tomorrow. Common sense tells us that we can use our current on-hand to cover this new urgent sales order and for remaining uncovered 40 pieces of non-urgent sales order we can create appropriate planned order with execution date in distant future (in a few days before non-urgent order’s delivery date).
Instead of this, Net Change planning will use remaining 30 pieced of on-hand to cover urgent sales order and will create extra urgent planned order for remaining 40 pieces with execution date of today.

It happens, because net change/net change minimized  never touches net requirements which had not had related inventTrans changed. During update phase, the system creates new net requirement for 70 pieces for tomorrow. It cannot ‘release’   on-hand net requirement  for more urgent order, because it cannot touch it! During coverage phase it creates coverage record for 30 pieces between existing (not touched by Dynamic Update) on-hand net requirement and new sales net requirement. For remaining 40 pieces, the system creates new planned order.
The only way to solve this issue is to run regeneration mode scheduling for an item and all nested sub-components. If we run regen mode scheduling only for item in new urgent sales order, we won’t have the phenomena for the net requirements of item itself. But if this item is a BOM with sub-components, it means for sub-component items, the same problem can arise on next BOM Levels.
I am a bit surprised, that standard Dynamics AX does not have some special ‘Explosion regen MRP’ which would take item or item mask as an input and then build INITIAL working set from all sub-components of item entered. I made this functionality for a couple of projects. It works much faster then full regeneration scheduling and it works somewhat slower then explosion. (Which is working on different set of principles and is just a special case of Net Change Minimized planning). This MRP extension also happens to fix the issue of incorrect planned orders for items with Period coverage code, which I mentioned in the section before previous.


Explosion


Explosion is a special kind of Net Change dynamic plan update. By definition, explosion only can be run for current dynamic plan. The most fundamental difference between explosion and regular MRP is that explosion includes into Initial Working Set  ONLY net requirements belonging to the specific order or line of the order. It  also means that it is the most fine-grained MRP kind. Since it is the most fine-grained kind of planning, it uses the same approach for working set update as Item MRP do. Working Set for explosion also stores working set as a set of particular net requirements, not as a set of item and coverage dimensions combinations. During requirement update stage, the system will simply run run Dynamic Update for the item of the net requirement being exploded and then create Initial Working Set from this net requirement and derived demand net requirements (sub-components for the planned production order or production order; derived net requirements on refill warehouse in case of planned transfer order and so on). The subsequent stages goes more or less in the same way as for Net Change Minimized dynamic plan update.

There are three kinds of explosion:

1. Sales line explosion. Implemented by the class ReqCalcExplodeSO. This class runs when you click ‘Update’ button on top of the Explosion form, called from sales orders form by clicking on Inquiries->Explosion. It also automatically run on salesLine creation or update if salesLine has reservation mode Explosion;Also – when a user has changed marking for inventory transaction. The last point looks a bit cryptic at a first sight, but purpose of it is very simple: Whenever a user is changing inventory marking (which is mirrored in coverage info), the system must drop existing coverage info and rebuild it from new marking information. (We will talk later about extra functions of explosion, which are not supported  by regular MRP)
2. Production order explosion. Implemented by the class ReqCalcExplodeProd. This class runs when you click ‘Update’ button on top of the Explosion form, called from production orders form by clicking on Inquiries->Explosion. It is also can be automatically run during Operation/Job Scheduling in of production order. Automatic explosion of production order happen in two cases: First of all, it happens when at least on of ProdBOM lines have a ‘On Schedule’ automatic reservation mode and the product order is being scheduled for the first time in its life. Second, it happens when production order does not have related Net Requirements in current dynamic plan (probably – because the order was entered manually and never was scheduled before) and user is running order scheduling with  ’Finite material’  checkbox in scheduling parameters. It might look surprising on a first sight, but ‘Finite material’ mode asumes compulsory integration of production order scheduling into MRP. There is no other way for Axapta to find availability of a material for a production order, but the usage of MRP. So, if you are hoping to use production orders without use of master planning, do not hope to have reasonable results of planning with ‘Finite materials’ checkbox.  If you have not specified current dynamic plan in Master Planning parameters, the system will use current static plan. If both static and dynamic plans have not been specified, the system will create new plan with reasonable defaults and set it in Master planning parameters as both current static and current dynamic.
3. Planned order explosion. Implemented by the class ReqCalcExplodePO. This class starts when you click ‘Update’ button on top of the Explosion form, called from planned orders form by clicking on Inquiries->Explosion. It is also called automatically when user creates/modify planned order or when planned production order is firmed.

In the most general case, there is three additional parameters which enable/disable certain functions, absent in regular MRP:

1. Current Explosion. This checkbox enables so to say, selective regeneration for explosion.All coverage information for the  net requirement being exploded. If covering net requirement was planned order and it does not cover another net requirements, it is also deleted, leading to recursive deletion of derived net requirements and so on. I want to warn you that this mode does not prevent  incorrect planing phenomena, which we discussed in previous section. Since this mode only deletes coverage information for derived demand of given net requirement, it won’t help if we have independent demand and our on-hand data is covering this non-urgent independent demand.
2. Marking and Reservation. This checkbox is available only for salesLine explosion and production order explosion. It instructs the system to delete marking information and drop reservations from underlying inventory transactions.  As you probably knew, marking and reservation have impact on coverage planning. If two inventory transactions are marked, their net requirements will be connected by coverage. If inventory transaction is Reserved Physically, it always covered from on-hand net requirement. So, if you checked Current Explosion, you would probably need to check this checkbox as well, otherwise most of dropped coverage information,would be restored from inventTrans data.
3. Autoreservation. This checkbox is available only for salesLine explosion and production order explosion. If you enabled this checkbox, after explosion, the system will duplicate coverage information into inventory transactions. Coverage info will be transferred into marking; If the requirement was covered by an on-hand net requirement, related inventory transaction will be reserved. This checkbox is especially useful if you want to handle the situation of manual production order entry. In ideal world, users never enter production orders manually. They run regeneration MRP for all items, firm resulting planned production orders and the firming process creates inventory markings from coverage info. But what if a user have created new production order? How can we set marking from coverage info in a quick way ? Just try to check this checkbox and run explosion.

I do not understand, why  autoreservation functionality in the system is limited only to sales orders and production orders. From time to time users manually create purchase orders, transfer order and inventory journals. All these orders/journals participate in coverage planning, but system do not have direct means to transfer created coverage information into inventory transaction. I once wrote a class, which can make something like ‘autoreservation’  for sales orders in a batch mode (I mean – for all sales orders). I am wondering, why Microsoft have not developed some functionality for flexible massive update of inventory transactions from current dynamic plan. Something which allows you to select type of net requirements, date range and so on, and then runs over suitable net requirements and transfer coverage info into inventory marking data…


Two plans scheme

 Standard MRP tutorials describes the idea of two plans schema in details. Shortly speaking, we have two plans – static and dynamic. Static plan is fully regenerated every night (or maybe every second night, every Saturday and so on…) and copied into dynamic plan. During daytime (between two static plan regenerations), production, purchase and logistics departments works with static plan. (Since it is stable and kept in  ’up-to-the-rules’ state), while sales managers works with dynamic plan, running explosions for newly created sales orders. In this case, sales managers have a tool to make reasonable estimation for a sales order delivery time, while all other departments work with stable plan without irregularities caused by last moment change. In this case, if Full MRP is run and Session Item Set contains all items,  update phase for static plan is also dropping all info from inventSumLogTTS table. The logic behind it is clear: Since we are running full regen and we are going to copy it results to dynamic plan anyway, there is no much point in keeping our old update log. In the beginning, we will drop inventSumLogTTS, create static plan from the scratch, then after MRP finish, we will copy static plan to dynamic. InventSumLogTTS at this moment will contain the list of updates to inventTrans made after initial plan regeneration. If user try to run explosion or dynamic plan update in Net Change/Net Change Minimized mode, the system will handle it in the same way as usual dynamic update of dynamic plan.



Change of current dynamic plan

If you try to change current dynamic plan settings in master planning parameters, you can encounter strange behavior. An attempt to change, the system will pop-up a dialog box with the message “Update and move transactions to new dynamic master plan?”. If you agree, on attempt to save changes, the system will hang for a while. After that you will be surprised a lot: Your new dynamic plan will contain exactly the same information as old dynamic plan. The system was hanging during parameters update just because it was copying old dynamic plan content into new dynamic plan…

On a first sight it looks totally weird and counter-intuitive.  We are deliberately changing dynamic plan and yet, as a results,  we have the same plan under a  different name. But if we think more about it, it is not so weird at all. Say, we just changed current dynamic plan without copying. What should the next explosion do ? We have a lot of recorded changes in inventSumLogTTS; Which of them should be applied to the new dynamic plan and which – should not ? There is no way to know. We have only one dynamic plan which is synchronized with inventTrans/InventSumLogTTS state. So, if we are changing current dynamic plan settings, there is only one relatively fast way to bring it to synchronous state – to copy old dynamic plan (which is kept in sync by definition) to new one.  An alternative approach would be to run  Full MRP in regeneration mode, but it would require much more time and DB/AOS server capacity. That’s why designers of MRP module in Dynamics AX decided to always copy dynamic plan on change of current dynamic plan setting.

Dynamic Update process

Dynamic update algorithm is pretty straightforward. The system runs over the inventSumLogTTS records for the specified item sorted by sequence id and apply every change to underlying net requirement record (reqTrans). There are few points to be made though:

1. InventSumLogTTS table uses pessimistic locking. If two users are trying to run planning or explosion for the same item, one of them will be suspended. If we have a lot of changes for the given item, this user can spend 20-30 seconds waiting. In version 2012, developers has changed this approach and now use optimistic locking for the table.
2. Dynamic Update process starts not only during MRP or Explosion, but also when a user opens Requirement Profile or Explosion forms. If your inventSumLogTTS has a lot of records for the given item, do not be surprised that on attempt to open any of these forms for the item, Axapta client can hand for a while (up to several minutes, if you have not run regeneration planning for a long time and your database server is weak). Also, even if you just created new order line (say – Sales Order line) and have not run MRP/Explosion afterwards, in the Requirements Profile form, you will see requirement for this line – exactly the result of this mechanism execution.
3. When the system is running Dynamic Update process, it keeps list of changed dimensions and changed quantities. After the update, it tries to find paired Net requirements with changed dimensions and ‘re-wire’ coverage information for them. Say, if you changed warehouse in purchase line and the system automatically changed warehouse in marked inventory transaction for sales order, next dynamic update will first drop and then recover coverage information even without real MRP coverage stage is run. (You can check it if you open Requirements Profile form after changing warehouse, but before running MRP/Explosion).
4. I never saw the following situation, but I still believe that it can happen sometimes: Since Axapta does not use serializable transaction isolation level, it might happen that after the system red inventTrans data (used to regenerate net requirements) but before the deletion of  inventSumLogTTS data, another user might update inventTrans. As a result: Information about change is deleted from inventSumLogTTS (since we deleted all info for the item) and is not present in Net Requirements (because query which reads inventTrans to build net requirements was started before the change). Probability of it is very low, but it still can cause minor inconsistency in planning results. I believe that the only way to fix it is to implement a support for snapshot transaction isolation level in Axapta.

Источник: http://fedotenko.info/?p=247

[lev]

Жалко что не на русском так не охото тратить время на перевод

[oip]

Цитата:

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

Жалко что не на русском так не охото тратить время на перевод

Вообще странно, что у разработчиков есть проблемы с чтением технических текстов на английском (как вообще работать, почти вся полезная информация же на нем?), но поскольку статья полезная, можно для будущих поколений попробовать совместно перевети ее на русский. Все я сейчас не осилю, но могу начать. Вот первые 10%. Переводилось бегло, местами коряво, но всяко лучше автоматического перевода. Кто-нибудь продолжит? Еще девять добровольцев, каждый по одной вордовской страничке, и все будет переведено.

Цитата:

fed: Обновление чистых потребностей в модуле MRP и Working Set* в MRP

*термин "Working Set" я не перевожу, данный термин ввел fed непосредственно в статья, и в ней же объясняется его значение.

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

Я написал данный текст в основном по своей работе с Dynamics AX 2009, но в новой версии (DAX2012) подход остался с функциональной точки зрения таким же, изменились только технические детали, поэтому текст может быть полезен и для специалистов, использующих DAX2012.

Исторический экскурс

Как я уже писал в своем блоге, таблица inventSumLogTTS появилась где-то в последних релизах Axapta 2.5 исключительно для отслеживания изменений в таблице inventSum в отдельной транзакции на уровне БД. И в случае если основная транзакция откатывалась, система должна была пробежаться по соответствующим записям в таблице inventSumLogTTS и программно откатить изменения в inventSum. Начиная с версии Axapta 3.0 таблица inventSumLogTTS стала использоваться и для обновления динамических MRP планов. Однако в версии Dynamics AX 4.0 система множественных складских транзакций из Аксапты была удалена и вместо нее стал и спользоваться иной подход. Несмотря на это, таблица inventSumLogTTS в системе все еще существует, но в настоящее время используется только при обновлении динамических планов. И поэтому ее название может вводить в заблуждение, ведь она больше не используется для журналирования записей InventSum.

Каким образом в таблицу inventSumLogTTS попадают данные

Механизм создания новых записей в inventSumLogTTS в последних версиях Аксапты (4.0/2009/2012) похож на механизм обновления InventSum, который я уже подробно описывал в статье, упомянутой в предыдущем разделе. При вставке/обновлении/удалении записей в таблице inventSum система вызывает метод inventUpdateOnHand.addInventSumLogTTS(), который и регистрирует вставку или удаление записи в InventSum (обновление отражается как удаление и затем вставка). Записи в таблице InventSumLogTTS сохраняются в кэше до конца транзакции и вставляются в базу данных только тогда, когда система непосредственно обновляет записи в таблице InventSum, связанных со складским обновлением в транзакции.

Для связи двух относящихся к одному и тому же обновлению в складской транзакции записей таблицы inventSumLogTTS система использует поле sequenceNumber. Система фиксирует изменений в записях InventTrans только до тех пор, пока они не будут обновлены физически или финансово (статусы Отпущено/Продано или Получено/Закуплено). При этом в таблице inventSumLogTTS фиксируется только самое первое изменение в транзакции, приводящее к физическому или финансовому статусу. Последующие изменения в той же складской транзакции уже не записываются, поскольку они больше для MRP не нужны, так как теперь эта транзакция является частью запасов в наличии, которые представлены в чистых потребностях как одна чистая потребность на каждые товар и аналитику покрытия.
...

[lev]

Цитата:

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

Вообще странно, что у разработчиков есть проблемы с чтением технических текстов на английском (как вообще работать, почти вся полезная информация же на нем?), но поскольку статья полезная, можно для будущих поколений попробовать совместно перевети ее на русский. Все я сейчас не осилю, но могу начать. Вот первые 10%. Переводилось бегло, местами коряво, но всяко лучше автоматического перевода. Кто-нибудь продолжит? Еще девять добровольцев, каждый по одной вордовской страничке, и все будет переведено.

проблем с переводом нет просто на чтение документации на иностранном языке уходит больше времени чем на родном (у вас наоборот? )

З.Ы. у кого есть желание, можете забросать меня грязными тряпками просто мне комфортней читать литературу на русском языке, вот я и высказал свое мнение (зная что fed может и на русском). В дальнейшую полемику вступать не буду, извините

[oip]

Цитата:

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

у вас наоборот?

Мне все-равно на каком языке (русском или английском) читать технические тексты. Не сонеты Шекспира же.

[lvan]

Цитата:

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

Жалко что не на русском так не охото тратить время на перевод

Ищущий знания... говорите?
Сами себя не обманывайте

[S.Kuskov]

Недавно был ещё пост про inventSumLogTTS и Динамический план dynamicscare: Running a Dynamic Plan in Dynamics AX, но из него я мало что понял.

В этом же труде fed'а все разжёвано для самых ленивых. Огромное спасибо тебе, Денис!

[mnt_dx]

Автоперевод http://translate.google.ru/translate...26prmd%3Dimvns

[fed]

Пожалуй что ключевой кусок сам переведу:

Цитата:

Рабочий набор MRP и немного терминологии

Для упрощения дальнейшей дискуссии, я хочу ввести новый термин – Рабочее множество. Я буду использовать этот термин для того чтобы сослаться на набор чистых потребностей участвующих тем или иным образом в текущей сесии сводного планирования. На различных стадиях сводного планирование, содержимое этого набора изменяется. После стадии обновления, он состоит из чистых потребностей, подлежащих покрытию; Во время выполнения стадии покрытия он содержит смесь покрытых чистых потребностей, использованых покрывающих чистых потребностей и непокрытых чистых потребностей подлежащих покрытию в дальнейшем.После завершения стадии покрытия, этот набор состоит из полностью покрытых отрицательных чистых потребностей и использованых покрывающих положительных чистых потребностей.

Основной посыл введения данного термина следующий: Рабочий набор сводного планирования является наиболее фундаментальным понятием необходимым для понимания работы сводного. Он всегда создается путем добавления непокрытых отрицательных чистых потребностей. Все остальное - подробности реализации.

В целом - существует два способа запуска сводного планирования: Один - через Master Planning->Periodic->Master planning;Второй - через Master Planning->Periodic->Master planning в форме Чистых Потребностей. Данные пункты меню ссылаются на разные классы. С точки зрения реализации, это классы используют различные алгоритмы. Первый класс спроектирова для многопоточной обработки большого количества чистых потребностей. Второй - соптимизирован для сводного планирования всего одной номенклатуры, но этот класс имеет хорошие механизмы кэширования данных и может временами работать заметно быстрее.
Я буду использовать термин Полное MRP для того планирования которое запускается из меню Periodic и термин Номенклатурное MRP для того планирования, которое запускается из формы Чистых потребностей. С функциональной точки зрения, данные два типа сводного планирования достаточно сильно отличаются друг от друга: Номенклатурное MRP работает на уровне определенного набора чистых потребностей. Полное MRP работает на уровне комбинации номенклатуры и аналитики покрытия. В тот момент когда чистая потребность добавляется в Рабочий Набор Полного MRP , это неявным образом добавляет не только данную чистую потребность, но и вообще все чистые потребности с данной комбинацией номенклатуры и аналитики покрытия. С технической точки зрения, Номенклатурное MRP реализовано как комбинация классов ReqCalcScheduleItem (ответственного за собственно процесс планирования) и класса ReqTransCache_Daily(ответственного за поддержку Рабочего Набора)
Класс ReqTransCache_Daily хранит список номенклатур в Рабочем Наборе, список комбинаций аналитик покрытия для каждой номенклатуры в Рабочем Наборе и собственно map с чистыми потребностями. Полное MRP реализовано как комбинация классов ReqCalcCacheScheduleItemTable (ответственного за собственно планирование) и ReqTransCache_Periodic(ответственного за поддержку Рабочего Набора). Класс ReqTransCache_Periodic хранит только набор номенклатур и комбинаций аналитик покрытия для каждой номенклатуры в Рабочем Наборе
(Это списки хранятся в таблицах ReqProcessItemListLine и ReqProcessItemDim).

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

Время от времени, я буду использовать термин Номенклатуры Рабочего Набора для того чтобы сослаться на все номенклатуры имеющие чистые потребности в данном Рабочем Наборе ; Иногда я также буду использовать термин Номенклатуры Сессии чтобы сослаться на набор номенклатур, заданных пользователем при запуске сессии сводного планирования. В случае Номенклаурного MRP этот список состоит из единственной номенклатуры взятой из текщей строки формы чистых потребностей;В случае Полного MRP эти номенклатуры определяются параметрами запроса по InventTable, которые пользователь задал в диалоговом окне при запуске сессии сводного.

To Lev: Я конечно мог бы и сам перевести наверное, но после недели редактирования текста и подбора терминологии,меня от него слегка мутит. Целиком все переводить было бы очень противно.

[lev]

Цитата:

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

Пожалуй что ключевой кусок сам переведу:

To Lev: Я конечно мог бы и сам перевести наверное, но после недели редактирования текста и подбора терминологии,меня от него слегка мутит. Целиком все переводить было бы очень противно.

Fed, огромное спасибо! Если честно я на это и рассчитывал, хотел увидеть русский вариант от автора

[fed]

Цитата:

Простейший случай: Регенерация статического плана

Прежде чем мы продолжим обсуждение, я хочу рассмотреть простеший случай сводного планирования: Регенерацию статического плана. Вот как происходит процесс планирования в данном случае.

1. Система удаляет все чистые потребности и информацию покрытия для Номенклатуры сессии (На самом деле, утвержденные спланированные заказы могут избежать удаление, но мы не собираемся заходить в обсуждении в такие глубины).
2. Если часть из удаленных чистых потребностей оказались спланированными заказами, система также удаляет их зависимые чистые потребности. (Например - потребности в материалах для спланированного производственного заказа).Если какие-то из удаленных чистых потребностей были покрыты другими спланированным заказами, эти спланированные заказы также рекурсивно удаляются и так далее. Основная идея: Если мы запустили сводное для ограниченного набора номенклатур, в начале стадии обновления мы не будем иметь чистых потребностей для всех номенклатур из Номенклатур сессии;Кроме того, освободятся (станут доступными для покрытия) часть положительных чистых потребностей, для номенклатур не входящих в в Номенклатуры сессии.Допустим, мы запустили MRP для номенклатуры A, состоящей из компонентов B,C и D;Система удалит все чистые потрености для номенклатуры A, в том числе - спланированный производственный заказ.Это приведет к удалению зависимых чистых потребностей для номенклатур B,C и D. Кроме того, система удалит данные о покрытии этих отрицательных чистых потребностей и часть положительных чистых потребностей по этим номенклатурым (например - запасы в наличии) станут доступны для того чтобы покрыть что-то другое.
   
3. Система создает новые отрицательные чистые потребности для всей номенклатуры из Номенклатуры сессии.При этом импортируется информация изо всех необходимых источников: данные о запасах в наличии, данные складских проводок, данные прогнозов и данные журналов номозапаса. Свежесозданные непокрытые отрицательные чистые потребности добавляются в Рабочий набор, фирмируя тем самым Исходный Рабочий Набор
4. Фаза покрытия начинается с обработки тех номенклатур в Рабочем наборе, которые имеют наименьший уровень вложености (BOMLevel).Система пробегает по всем непокрытым отрицательным чистым потребнстям данной номенклатуры в Рабочем наборе(Все наши свежесозданные чистые потребности с прошлого шага как раз непокрыты) создает информацию о покрытии (если удалось найти подходящую положительную чистую потребность) или создает новый спланированный заказ и использует его для покрытия. Покрывающая чистая потребность добавляется в Рабочий набор. Если вновь созданные планированные заказы были спланированными производственными заказами, система добавляет зависимые чистые потребности в материалах в Исходный Рабочий Набор. (Тем самым превращая его в  Расширенный Рабочий Набор) .
5. Далее сситема продолжает строить покрытие для номенклатуры рабочего набора со следующим минимальным уровнем вложености (BOMLevel).Система снова создает спланированные заказы; Это в свою очередь приводит к созданию зависимых потребностей и дальнейшему расширению рабочего набора. Таким образом, по мере обработки все новых и новых уровней вложености, Рабочий Набор содержит все больше и больше чистых потребностей.
6. В конце концов, после обработки номенклатуры рабочего наборас максимальным уровнем вложености, система завершает стадию покрытия и переходит к исполнению последющих стадий.
7. Планирование фьючерсов и действий выполняется для чистых потребностей в текущем Рабочем наборе Поскольку данные стадии пляшут скорее от положительных чистых потребностей, поведение Номенклатурного MRP и Полного MRP сильно различается. В случае Номенклатурного MRP, система рассчитывает фючерсы/действия только для чистых потребностей которые реально были использованы в данной сессии планирования(чистые потребности для которых в данной сесии была создана хотя бы одна запись покрытия). В случае Полного MRP,  система рассчитывает фьючерсы/действия для всех чистых потребностей у которых сочетание номенклатура+аналитика покрытия совпадает с номенклатурой и аналитикой покрытия у любой из использованых чистых потребностей.
   

Таким образом, при работе сводного планирования,указание Номенклатура сесии служит двум целям:

• Указывает системе, чистые потребности для каких номенклатур необходимо пересоздать и включить в Начальный Рабочий Набор
• Неявно задает Расширенный Рабочий Набор сессии сводного планирования, позволяя казать корневые номенклатеры неявного развертывания спецификаций, порождающих Расширенный рабочий набор
  

Надо заметить, что ТОЛЬКО полная регенерация плана для всей номенклатуры в системе (Набор сессии содержит все номенклатуры из InventTable) позволяет создать план идеального качества. Даже в режиме регенерации потребностей (результаты которого лучше соответствуют правилам чем результаты планирования в режиме Net Change/Net Change Minimized), система может создавать немного некорректные спланированные заказы. Допустим, мы создали новую строку заказа и запустили полную регенерацию плана по номенклатуре из данной строки. Это может привести с созданию спланированого производственного заказа на производство самой номенклатуры, а также спланированного заказа на покупку для покрытия потребности в одном из материалов этого производственного заказа. Если для этого материала задан режим покрытия Потребность - все в порядке. Однако же, если для данного материала указан режим покрытия Период - это может считаться некоторой ошибкой при планировании. (Поскольку, возможно, мы получили два заказа на закупку для одной номенклатуры в одном периоде. Лучше было бы увеличить количество в соседнем спланированом заказе на закупку, чем плодить второй заказ в периоде...)

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

[fed]

Цитата:

Более сложный пример: Регенерация динамического плана
Регенерация динамического плана работает примерно также как и регенерация статического, однако несколько шагов все-таки добавлено:

• Прежде чем проимпортировать данные inventSum/inventTrans (шаг 4 из предыдущего раздела) для данной номенклатуры, система вычищает все записи таблицы inventSumLogTTS, относящиеся к данной номенклатуре.
• Во время стадии покрытия, перед тем как обработать номенклатуру (даже если она не включена в Номенклатуры сессии) система запускает специальный класс (reqTransUpdate), который которая переносит запротоколированные обновления по данной номенклатуре из inventSumLogTTS в чистые потребности (reqTrans), а затем вычищает перенесенную информацию из первой из этих таблиц. Я буду называть этот процесс Динамическим Обновлением

Таким образом, используется следующая последовательность продвижения информации: Когда пользователь изменяет логистический документ, измененные данные переносятся в складские проводки (inventTrans); Далее в конце транзации БД, данные копируются в inventSumLogTTS; Затем, в конце концов, запротоколированные изменения переносятся в данные чистых потребностей (reqTrans). После того как запротоколированные в таблице inventSumLogTTS изменения были применены к данным чистых потребностей, эти изменения удаляются из протокола, поскольку смысла их хранить уже нету.
Я хочу специально заметить, что те чистые потребгости, которые оказались обновлены на стадии Динамического обновления не включаются автоматически в Рабочее множество. Динамическое обновление не особо изберательно; Оно выполняется на уровне конкретной номенклатуры. Может так случится, что Динамическое обновление обновило чистые потребности с конфигурациями, размерами или цветами, которые ничего не имеют общего с текущей Номенклатурой сессии. Таким образом, включение всех случайно обновленных чистых потребностей по номенклатуре в Рабочий Набор вызвало бы ненужное увеличение размера Рабочего набора и увеличило бы сложность планирования.

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

Продолжаем...

[fed]

Цитата:

Обновление динамического плана в режиме Накопленные изменения(Net Change)

В режиме Накопленные изменения/Минимальные изменения (кстати отмечу неудачность русского перевода терминов Net Change/Net Change Minimized), фаза Обновления плана выполняется совершенно другим образом. Попросту говоря, это последовательность Динамических обновлений для всей номенклатуры из Набора сессии. Система пробегается по всем номенклатурам из Набора сессии и для каждой номенклатуры вызывается обычный класс обновления чистых потребностей (reqTransUpdate), который собственно и переносит в чистые потребности накопленную информацию об изменениях, хранящуюся в таблице inventSumLogTTS. В результате этого обновления, часть чистых потребностей удаляется, часть - создается, для у части чистых потребностей изменяется количество или другие релевантные поля. Затем, во время фазы рассчета покрытия, система пробегается по всем непокрытым отрицательным чистым потребностям в Рабочем множестве. Как и в режиме регенерации динамического плана, система, перед рассчетом покрытия по каждой номенклатуре, запускает стандартную процедуру Динамического обновления. Таким образом, даже для номенклатур не входящих в Набор сессии данные чистых потребностей актуализуются в соответствии с текущим состоянием складских проводок.
С точки зрения фазы обновления чистых потребностей, хочу отметить два отличия между режимами Накопленных изменений и Минимальных изменений:

1. В Режиме минимальных изменений,система включает в Начальный Рабочий Набор только те отрицательные чистые потребности, которые были помечены как непокрытые. Поскольку после пересчета плана в режиме регенерации, ни одна чистая потребность не может остаться не покрытой, технически Начальный Рабочий Набор состоит только из чистых потребностей обновленных на стадии Обновления. Поскольку во время фазы обновления, положительные чистые потребности не включаются в Начальный рабочий набор последующие стадии рассчета фьючерсов и действий работают только с чистыми потребностями, которые действительно были задействованы на стадии покрытия (в случае Номенклатурного MRP) или со всеми чистыми потребностями, имеющими ту же номенклатуру и аналитику что и одна из чистых потребностей задействованных на стадии покрытия (в случае Полного MRP.
2. В режиме Накопленных изменений, система включает в в Начальный Рабочий Набор все чистые потребности для всех номенклатур из Набора сессии.Кроме того, система удаляет из плана всю информацию  о действиях (количество и дату действия в таблицах чистых потребностей и покрытия) для всех чистых потребностей в Начальном Рабочем Наборе.Как результат, на фазе рассчета действий, система обрабатывает все чистые потребности из номенклатуры в Наборе сессии.(Включение в Начальный рабочий набор всех чистых потребностей никак не влияет на работу стадии покрытия, поскольку рассчет покрытия попросту игнорирует все уже покрытые чистые потребности).

Коротко говоря, режим Накопленных изменений/Минимальных изменений это самый быстрый способ привести сводный план в соответствие с текущим состоянием дел. Но как это обычно и бывает, за высокую скорость обновления плана приходится расплачиватьcя. Зачастую, в режиме Накопленых изменений, система генерирует неоптимальный план. (Я имею в виде - даже более неоптимальный чем результаты планирования в режиме регенерации для части номенклатуры.)

Допустим у нас на складе есть 80 штук некой номенклатуры, а также имеется заказ на продажу 50 штук этой же номенклатуры с датой доставки из далекого будущего (Допустим - через 6 месяцев). Регулярное ночное сводное планирование, создало запись о покрытии между двумя соответствующими чистыми потребностями. Потребность заказа на продажу полностью покрыта запасами в наличии, в то же время у чистой потребности запасов в наличии осталось неиспользованных 30 штук. Эти 30 штук могут быть использованы для того чтобы в будущем покрыть что-то еще.Предположим что на следующее утро пришел клиент и попросил срочно отгрузить ему 70 штук нашей номенклатуры. Здравый смысл подсказывает нам, что мы должны покрыть этот заказ номенклатурой в наличии, а для оставшихся непокрытыми 40 штук несрочного заказа создать плановый заказ эдак за пару дней до планирующейся даты отгрузки этого несрочного заказа.
Вместо этого, планирование в режиме Накопленных изменений использует для покрытия срочного заказа только те 30 штук из запаса в наличии, которые остались свободными после ночного перепланирования 30 штук из номенклатуры в наличии, а для недостающих 40 штук оно создаст срочный плановый заказ с сегодняшней датой исполнения.
Это происходит, поскольку планирование в режиме Накопленых обновлений/Минимальных обновлений никогда не трогает те чистые потребности, у которых не было изменены соответствующие складские проводки. На фазе обновления, система создает новую чистую потребность на 70 штук с завтрашней датой. Система не может 'Освободить' чистую потребность 'В наличии', для срочного заказа, поскольку она не может модифицировать эту чистую потребность ! Во время фазы покрытия, система создает запись покрытия на 30 штук между новым заказом и запасами в наличии (чистая потребность которых не была модифицирована Динамическим обновлением), а затем, для покрытия оставшихся 40 штук, система порождает новый спланированный заказ.
Единственный способ исправить эту ситуации - это запуск сводного в режиме регенерации для данной номенклатуры и для всех субкомпонентов данной номенклатуры (или вообще для всех номенклатур в системе).Если мы запустим регенерацию только для данной номенклатуры, то с чистыми потребностями по самой номенклатуре все будет хорошо. Однако же если данная номенклатура - это спецификация с субкомпонентами, это означает что для субкомпонентов чистые потребности не будут удалены и перегенерированы с ноля и точно такая же проблема может возникнуть на следующих уровнях вложености.
Я слегка удивлен что стандартная версия Dynamics AX не поддерживает некого специального режима "Регенерации развертывания", который бы получал на входе номенклатуру или маску номенклатуры, а затем бы строил НАЧАЛЬНЫЙ рабочий набор из указанных номенклатур и всех их субкомпонентов.Я реализовал подобную функциональность для пары проектов; Она работает заметно быстрее чем полная регенерация плана (для всех номенклатур) и заметно медленнее чем стандартное развертывание.(Которое работает на другом наборе принципов и является частным случаем режима Минимальных обновлений).К слову сказать, это расширение стандарта MRP также исправляет проблему некорректного планирования для режима покрытия Период, о котором я писал в позапрошлом разделе.

Продолжаем...

[fed]

Цитата:

Развертывание (Explosion)


Развертывание - это просто такой специальный вариант режима обновления Минимальные изменения.По определению, развертывание может запускаться только для текущего динамического плана.Наиболее фундаментальное отличие между развертыванием и обычным сводным планирование состоит в том, что развертывание включает в Начальный Рабочий Набор ТОЛЬКО чистые потребности относящиеся к специфическому документу или даже строке документа.
Поскольку развертывание является наиболее 'точечным' вариантом сводного планирования, оно использует тот же подход к обновлению Рабочего набора что и Номенклатурное MRP. Рабочий набор развертывания также хранится как набор конкретных чистых потребностей, а не как набор комбинаций номенклатуры и аналитик покрытия.На стадии обновления чистых потребностей, система просто запускает Динамическое обновление для номенклатуры той чистой потребности, для которой выполняется развертывание, а затем создает Начальный рабочий набор для из данной чистой потребности и связанных с ней зависимых чистых потребностей (компонентов в случае спланированного производственного заказа или производственного заказа, зависимые потребности в номенклатуре на складе пополнения в случае спланированого заказа на перенос и т.д.). Последующие стадии выполняются более или менее тем же способом, что и в режиме Минимальных Изменений.

Существует три разных варианта Развертывания:

1. Развертывание строки заказа. Реализовано в классе ReqCalcExplodeSO. Этот вариант развертывания запускается в том случае, если вы кликаете на кнопке 'Обновить' в форме Развертывания, запущенной из формы заказов на продажу по кнопку Запросы->Развертывание. Эта же разновидность развертывания запускается автоматически при создании или обновлении строки заказа на продажу в том случае, если для этой строки указан режим резервирования Развертывание. Кроме того, это же случается если пользователь изменил маркировку складской проводки. Последний случай выглядит слегка непонятным, но на самом деле его цель совершенно понятна: Как только пользователь меняет маркирование (которое служит отражением покрытия), система должна удалить текущие данные покрытия и построить их заново из маркирования.Чуть позже мы поговорим о некоторых дополнительных функциях развертывания, связаных с маркированием, которые не отсутствуют в стандартном MRP.
2. Развертывание производственных заказов. Реализовано классоа RecCalcExplodeProd. Этот вид развертывания запускается в том случае если вы кликаете по кнопке 'Обновить' в форме развертывания, запущеной из формы производственных заказов.Этот же вариант развертывания может запускатся автоматически при запуске планирования операций или планирования заданий. Автоматическое развертывание производственного заказа производится в двух случаях: Во первых, оно происходит в том случае, если хотя бы у одной строки производственной спецификации установлен режим резервирования "При планировании" и если данный производственный заказ планируется первый раз за время его жизненного цикла.Во вторых, это случается если для данного производственного заказа не существует ни одной чистой потребности в текущем динамическом плане (вероятно - потому что производственный заказ был создан в ручную и после этого не планировался) и пользователь в форме планирования поставил галочку в поле "Ограничение по материалам".Возможно, с первого взгляда такое поведение кажется неожиданным, но режим "Ограничение по материалам" подразумевает принудительную интеграцию планирования производственного заказа со сводным планированием.В Аксапте нету другого способа узнать - доступны материалы или нет, кроме использования сводного планирования. Так что если вы собираетесь использовать планирование производственых заказов без нормально настроенного сводного планирования, не рассчитывайте получить разумные результаты планирования с галкой "Ограничение по материалам". Если вы не указали текущий динамический план в параметрах модуля, система будет использовать для развертывания текущий статический план. Если оба плана не заданы, система создаст новый план с разумными умолчаниями и будет использовать этот план как текущий статический и динамический план.
3. Развертывание спланированых заказов.Реализовано в классе ReqCalcExplodePO. Этот вид развертывания запускается если вы кликните на кнопке 'Обновление' в форме Разветывания, запущенной из формы спланированных заказов.Эта же функциональность автоматически запускается если пользователь создал или модифицировал спланированный заказ в ручную или при утверждении спланированых заказов.

В наиболее общем случае, функционал развертывания имеет три дополнительных параметра, включающих/выключающих дополнительные функции, отсутствующие в обычном сводном планировании:

1. Текущее развертывание. Этот флажек разрешает, так сказать, выборучню регенерацию развертывания. Вся информация о покрытии для данной чистой потребности удаляется. Если покрывающая чистая потребность является спланированым заказом, и этот заказ ничего больше не покрывает, он также удаляется, что приводит к рекурсивному удалению зависимых чистых потребностей и тд. Хочу предупредить вас что данный режим не предотвращает проблему некорректного планирования, которую мы обсуждали в предыдущем разделе. Поскольку в этом режиме информация покрытия удаляется только для данной чистой потребности и непосредственно зависящих от нее чистых потребностей, это не сможет помочь если мы имеем ситуацию независимой чистой потребности и запасы в наличии покрывают эту несрочную независимую чистую потребность.
2. Маркировка и резервирование. Этот флажек доступен только при развертывании строки заказа и при развертывании производственного заказа. Он заставляет систему удалить маркировку и снять резервирование с соотвествующих складских проводок. Как вы, вероятно, уже знаете, маркирование и резервирование влияют на покрытие. Если две складских проводки были примаркированы друг к другу, их чистые потребности будут покрывать друг друга. Если складская проводка была физически зарезервирована, она будет покрыта чистой потребностью запасов в наличии. Так что если вы поставили галочку в параметре Текущее покрытие, то вам, вероятно, надо поставить галочку и для данного параметра; В противном случае, большая часть удаленной информации о покрытии будет восстановлена из данных складских проводок.
3. Авторезервирование. Данный флажек доступен только для развертывания строи заказа и производственного заказа.Если вы включили этот флажек, то после развертывания, система продублирует информацию покрытия в складские проводки. Данные о покрытии переносятся в маркировку складских проводок. Если данная чистая потребность была покрыта запасами в наличии, соответствующая складская проводка будет физически зарезервирована. Этот режим особенно полезен, если вы хотите исправить ситуацию после ручного ввода производственного заказа.В идеальном мире, пользователи никогда не создают производственных заказов в ручную. Они всегда сначала запускают регенерацию плана для всей номенклатуры, потом утверждают спланированные заказы, а функция утверждения создает маркировки из данных покрытия спланированного заказа. Однако - что же можно сделать если пользователь создал производственный заказ в ручную? Как нам перенести данные о покрытии в маркирование складских проводок ?Просто включите этот флажек и запустите развертывание.

Я не понимаю, почему функционал авторезервирования ограничен только заказами на продажу и производственными заказами. Время от времени, пользователи в ручную создают заказы на закупку, перенос, складские журналы. Все эти документы участвуют в рассчете покрытия, но система не поддерживает никаких инструментов, которые позволили бы перенести информацию покрытия в складские проводки по данным документам. Я однажды разработал класс, который в пакетном режиме запускал подобное авторезервирование по всем заказам на продажу. Любопытно, почему Микрософт до сих пор не разработал какую-то функциональность для гибкого массового обновления складских проводок на основании данных из текущего динамического плана? Что-нибудь, что позволило бы вам выбрать тип чистых потребностей, период времени и т.п., а затем пробегало бы по подходящим чистым потребностям и переносило бы данные о покрытии в маркировку складских проводок...

Продолжаем...

[fed]

Цитата:

Схема с двумя планами

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



Смена текущего динамического плана
Если вы попытаетесь сменить текущий динамический план, вы столкнетесь со странным поведением системы. При попытке замены, система выкинет диалоговое окно с загадочным сообщением: "Обновить и переместить проводки в новый динамический генеральный план?" (Кстати хочу отметить традиционно низкое качество перевода. Не очень понятное английское сообщение было заменено на абсолютно непонятное русское.) Если вы согласитесь, в момент записи изменений, система надолго зависнет. А затем, вас ждет большой сюрприз: Ваш новый текущий динамический план будет содержать в точности те же самые данные что и ваш бывший динамический план.Система висела как раз потому что она копировала содержимое из старого динамического планеа в новый.

На первый взгляд, это выглядит ненормальным и неожиданным. Мы осознано решили сменить динамический план, но, тем не менее, в качестве результата мы получили тот же самый старый план, просто под другим именем.Но если мы разберемся в проблеме глубже, всё это не так уж и ненормально. Допустим мы поменяли текущий диинамический план без копирования. Что делать следующему развертыванию ? У нас в InventSumLogTTS хранится информация о куче изменений; Какие из них должны быть применены к новому динамическому плану, а какие -нет ? В системе для этого нету необходимой информации. Есть только один динамический план, который засинхронизирован с состоянием данных в таблицах inventTrans/inventSumLogTTS. И когда мы меняем текущий динамический план, существует только один относительно быстрый способ засинхронизировать новый план с этими данными - это скопировать старый план в новый. Альтерантивой был бы запуск Полного MRP в режиме регенерации, но это потребовало бы значительно больше времени и ресурсов от серверов БД и AOS. Именно по этому, разработчики модуля сводного планирования в Аксапте предпочли копировать старый план в новый при любой попытке изменения текущего динамического плана.

Процесс динамического обновления

Процесс динамического обновления достаточно прямолинеен.Система пробегает по записям таблицы inventSumLogTTS, для данной номенклатуры, отсортированным по номеру обновления (sequence number) и применяет каждое запротоколированное изменение к соответствующей записи чистых потребностей. Тем не менее, я хочу отметить несколько фактов:

1. Работа с таблице inventSumLogTTS происходит в режиме пессимистических блокировок. Если два пользователя пытаются запустить планирование или развертывание одной и той же номенклатуры, один из них будет заблокирован.Если у нас для данной номенклатуры накопилось много обновлений, заблокированный пользователь может прождать порядка 20-30 секунд.В версии 2012, разработчики слегка изменили принципы работы с этой таблицей, и теперь блокировка выполняется в оптимистическом режиме.
2. Динамическое обновление запускается не только из сводного планирования или развертывания, но также и в тех случаях, когда пользователь открывает форму Чистые Потребности или Развертывание. Если у вас в таблице inventSumLogTTS накопилось много записей для данной номенклатуры, не удивляйтесь если при открытии одной из этих форм, ваш аксаптовский клиент зависнет ненадолго. (До нескольких минут, если вы давно не запускали перегенерацию плана или если у вас слабенький сервер БД). Кроме того, даже если вы только что создали новую строку заказа (допустим - заказа на продажу) и после этого пока не запускали Сводное/Развертывание, в форме Чистых потребностей вы все равно увидите чистую потребность в свежесозданной строке заказа - как раз таки результат работы данного механизма.
3. Когда система выполняет процедуру Динамического обновления, она запоминает список обновленных складских аналитик и измененных количеств. В конце обновления, система пытается найти парные изменения Чистых Потребностей с одинаковыми складскими аналитиками и так сказать 'перепрошить' данные о покрытии между ними. Допустим, мы поменяли склад в строке закупки и система автоматически поменяла склад в примаркированной складской проводке по продажам. Следующее Динамическое обновление удалит, а потом пересоздаст информацию о покрытии, даже без необходимости запуска настоящего сводного планирования со стадией рассчета покрытия. (Вы можете попробовать открыть формы Чистых потребностей после смены заказа но до запуска развертывания или сводного планирования).
4. Я никогда не сталкивался со следующей ситуацией, но я все равно считаю что она может иногда случаться:Поскольку Аксапта не поддерживает сериализуемый уровень изоляции транзакций, может случится что во время планирования, на фазе обновления, после переноса информации из складских проводок в чистые потребности, но до очистки данных inventSumLogTTS, какой-то пользователь изменит какие-то складские проводоки. В результате - информация об обновлении будет удалена изinventSumLogTTS (поскольку мы там вообще все записи удаляем), и не скопирована в чистые потребности (поскольку в момент копирования, складские проводки еще не были изменены). Вероятность такой ситуации невысока, а последствия - не особо тяжелы.Я думаю, что единственным способом, который смог бы исправить ситуацию, была бы реализация поддержки Snapshot Transaction Isolation Level и использование этого уровня изоляции при обновлении данных чистых потребностей из складских проводок...

Все - последняя часть