|  25.09.2009, 08:28 | #1 | 
| Сам.AX | Класс wrkCtrMasterData_prod в AX40sp2 
			
			Доброго здоровья. Кто знает зачем нужен класс wrkCtrMasterData_prod при обновлении произв. заказа (приемка), если мы не используем в производстве маршруты и задания? Больше всего интересует что выполняет метод Load() в котором есть загадочный, для меня, кусок кода: X++: if (this.last()) do { this.updateExplosion(cacheProdTable); } while (this.prev()); | 
|  | 
|  25.09.2009, 12:12 | #2 | 
| Moderator | 
			
			В общем - wrkCtrMasterData инкапуслирует несколько зависимых производственных заказов, получившихся из спецификации с типами строк "Производство". Метод load() просто загружает данные о заказах в память. Загадочный кусок кода - просто пробегает по списку заказов и по каждому запускает сводное планирование (фактически - ищет покрытие списаний под ПЗ). В версии 2009 эта штука запускается только при разноске маршрутных журналов (но никак не журнала приемки), если в параметрах производства включена галка Update Capacity Plan (поле JournalUpdateCapacity). Возможно - в вашем случае он отрабатывает потому, что какие-то загадочные галочки в журнале приемки (я их названия плохо помню) подспудно запускают разноску маршрутных операций со стандартными значениями (из BOMCalcTrans).  Идея за эти стоит следующая: Хочется чтобы по фактическим временным данным, внесенным в журнал маршрутных проводок пересчитывалась загрузка производственных мощностей. Хочу заметить, что я этот механизм до конца не раскапывал, никогда им не пользовался и как он работает полностью не понимаю. Я например так до конца и не разобрался, как временные данные введенные в журнале, обновляют время текущей операции в prodRoute/prodRoteJob. Однако - очень подозреваю что общая идея, которую я тут описал - правильная... | 
|  | |
| За это сообщение автора поблагодарили: Murlin (1), Alexx7 (1). | |
|  25.09.2009, 12:17 | #3 | 
| Banned | Цитата: Я бы поинтересовался, что именно беспокоит автора. Или это опять та же тема, что и несколько недель назад, с изменением даты отгрузки подчиненных заказов? | 
|  | 
|  25.09.2009, 14:33 | #4 | 
| Сам.AX | 
			
			Вся идея в том, что строчка  X++: this.updateExplosion(cacheProdTable); X++: void updateItemLock(ItemId _itemId) { ; select pessimisticlock inventTableLock where inventTableLock.ItemId == _itemId; } | 
|  | 
|  25.09.2009, 14:56 | #5 | 
| Banned | 
			
			Понятно. Если можете гарантировать, что сводное планирование не будет запускаться в конкурентном режиме, закомментируйте эти строчки в ReqCalc.
		 | 
|  | 
|  25.09.2009, 15:09 | #6 | 
| Сам.AX | 
			
			Вот комментировать код то совсем не желательно. У меня всётаки есть надежда, что: Пытаюсь по коду проанализаровать, где есть проверка галочки. Но если кто уже знает о вышеупомянутой "загадочной галке". Буду признателен. | 
|  | 
|  25.09.2009, 15:14 | #7 | 
| Banned | 
			
			ProdParameters.JournalUpdateCapacity - в случае авторазноски журнала произв. маршрутов. Больше параметров нет. Стек вызова до ReqCalc приведите, пожалуйста. | 
|  | 
|  25.09.2009, 15:42 | #8 | 
| Сам.AX | |
|  | 
|  25.09.2009, 15:49 | #9 | 
| Сам.AX | 
			
			[s]\Classes\ReqCalc\updateItemLock (4) [s]\Classes\ReqCalcExplodeProd\insertData (23) [s]\Classes\ReqCalc\updateData (10) [s]\Classes\ReqCalc\run (11) [s]\Classes\ReqCalcExplode\run (10) [s]\Classes\WrkCtrMasterData_Prod\updateExplosion (9) [s]\Classes\WrkCtrMasterData_Prod\load (55) [s]\Classes\WrkCtrScheduleJobs\run (13) [s]\Classes\ProdUpdScheduling\run (13) [s]\Classes\ProdUpdScheduling_Operation\run (10) [s]\Classes\ProdTableType\runOperationScheduling (9) [s]\Classes\ProdStatusType_CostEstimate\runOperationScheduling (12) [s]\Classes\ProdUpdRelease\runPreviousJob (12) [s]\Classes\ProdStatusType_CostEstimate\runRelease (13) [s]\Classes\ProdUpdStartUp\runPreviousJob (10) [s]\Classes\ProdStatusType_CostEstimate\runStartUp (13) [s]\Classes\ProdUpdReportFinished\runPreviousJob (9) [s]\Classes\ProdStatusType_CostEstimate\runReportFinished (12) [s]\Classes\ProdMultiReportFinished\run (15) [c]\Classes\ProdMultiReportFinished\main (16) | 
|  | 
|  25.09.2009, 16:00 | #10 | 
| Banned | 
			
			Все понятно. Вы запускаете приемку для заказа в статусе Estimated, как я и предполагал. Система последовательно обновляет статусы, проходя через статус "Запланировано". Вы не найдете параметра, чтобы отключить такое поведение.
		 | 
|  | |
| За это сообщение автора поблагодарили: Alexx7 (1). | |
|  25.09.2009, 16:37 | #11 | 
| Сам.AX | Цитата: Вопрос: Чем черевато обнуление галочки? . | 
|  | 
|  25.09.2009, 17:29 | #12 | 
| Banned | 
			
			Тем, что при планировании (втч. вычислении ближайшей даты поставки) не будет учитываться наличие материалов.
		 | 
|  | 
|  08.10.2009, 11:00 | #13 | 
| Сам.AX | 
			
			Вопрос № 2. При обновлении производственного заказа до статуса "Запланировано", обновляется таблица "Чистые потребности" (ReqTrans). Туда попадают строки спецификации изделия по условиям настроеным ранее. Считаю, что всё логично. Вопрос: Почему при обновлении блокируется само изделие, а не сырьё из спецификации? Вот в этот кусок кода ([s]\Classes\ReqCalc\updateItemLock (4) ) попадает выходное изделие. X++: void updateItemLock(ItemId _itemId) { ; select pessimisticlock inventTableLock where inventTableLock.ItemId == _itemId; // Блокирует изделие. Зачем? } | 
|  |