12.09.2012, 19:32 | #1 |
Участник
|
Закрытие и коррекция
Прошу подсказать, ввиду не столь великих знаний пока о закрытии, какими последсвиями грозит изменение порядка методов в цикле сопоставлений класса InventCostItemDim.updateItem(), а именно отработать updateModel() перед "распространением" коррекций, сделанных по приходным проводкам на сопоставленные с ними расходные проводки (updateReceiptAdjustment()). Спасибо!
Версия DAX 2009. X++: // match issues and receipts per financial dimension combination se = setInventDim.getEnumerator(); while (se.moveNext()) { inventDim = se.current(); this.initMapInventTrans(); this.load(inventDim); this.updateReceiptAdjustment(); // перед this.updateModel(inventDim); // мой вариант после (вместо того, что перед) //this.updateReceiptAdjustment(); } Последний раз редактировалось Cardagant; 12.09.2012 в 19:42. |
|
13.09.2012, 10:48 | #2 |
Moderator
|
В общем - биться об заклад не буду, но мне кажется что у тебя после такой корректировки случаться грабли с проводками, скорректированными после даты закрытия/пересчета. То есть - функция updateReceiptAdjustment(), она не только прогоняет коррекцию с прихода на расход (которая в этой ветке вряд ли сработает), но и рассчитывает сумму более поздних коррекций. Скажем купил ты товар 25ого августа, продал 27ого, а 5 сентября начислил накладные расходы и теперь закрываешь август. Эта функция вызовет calcLaterAdjustment и положит его в mapSettleValue. А updateModel() в момент создания сопоставления, вытащит эту сумму (если она есть) и отнимет ее из inventTrans.costAmountPosted+inventTrans.CostAmountAdjustment. Я очень подозреваю, что если ты так сделаешь, то у тебя в такой ситуации августовские списания пойдут с учетом сентябрьских накладных расходов.
Просто попробуй сделать контрольный пример (с накладняком после продажи) и посмотри какая у тебя будет себестоимость расхода после закрытия августа. |
|
|
За это сообщение автора поблагодарили: Bega (5). |
13.09.2012, 13:24 | #3 |
Участник
|
А с какой целью? У вас теряются какие-то коррекции? Вообще по логике метод this.updateReceiptAdjustment() вызывается вот тут после обновления по модели,
X++: if (!(inventCostList.NumOfIteration == 0&&selfLoopCount == 0)&&inventClosing.AdjustmentType== InventAdjustmentType::Closing) { // if this is a closing and this item has been processed before, just propagate adjustments following settlements this.updateReceiptAdjustment(); } X++: do { selfUpdate = false; ttsbegin; this.updateItem(); ttscommit; selfLoopCount++; } while (selfUpdate&&selfLoopCount<=selfLoopMax); |
|
13.09.2012, 16:17 | #4 |
Участник
|
Не совсем в тему, но тоже вопрос про закрытие. После установки RU8 перестало работать закрытие и пересчет. Оказывается забыли положить табличку InventCostTmpNonFinancialTransfer, и класс InventCostNonFinancialTransferHandler не копилируется. Где ее можно взять? Может у кого есть
|
|
13.09.2012, 16:41 | #5 |
Ищущий знания...
|
Цитата:
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
13.09.2012, 16:50 | #6 |
Moderator
|
Цитата:
Странно что там какая-то таблица появилась. Может быть - микрософт выложил обновленный RU8 никому ничего не говоря ? Если не лень - киньтесь в меня этим классом на посмотреть - я когда-то там сильный mis-design репортил в микрософт (приводящий к блокировкам пользователей). |
|
13.09.2012, 16:57 | #7 |
Ищущий знания...
|
и метод fillInventCostTmpNonFinancialTransfer() не появился?
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
13.09.2012, 17:00 | #8 |
Участник
|
У меня в восточной версии RU8 метода fillInventCostTmpNonFinancialTransfer нет.Class_InventCostNonFinancialTransferHandler.xpo
|
|
13.09.2012, 17:07 | #9 |
Участник
|
Вот класс после RU8. Вообще, после RU8 и корр. счетов-фактур столько интересного ))) что у меня появился целый проект RU8_Error ))
|
|
|
За это сообщение автора поблагодарили: Cathome (1). |
13.09.2012, 17:09 | #10 |
Участник
|
|
|
13.09.2012, 17:22 | #11 |
Moderator
|
Ааа - в общем это они так подправили ошибку, которую я репортил. (Я в принципе про это в блоге писал). В старой версии у них там использовался неслабый такой update_recordset. А проблема оператора update состоит в том что он блокирует от записи другим процессом не только те записи, которые обновил, но и те записи которые прочитал . То есть - если план исполнения простенький, то он блокирует записи на страничке, читает, обновляет, разблокирует все кроме обновленных. А вот если план исполнения сложный, то он блокирует, читает,читает другую таблицу, джойнит, джойнит по хэшу,сортирует и тп и только потом в конце обновляет и разблокирует. В итоге update_recordset в версии из RU7 тупо блокировал всех пользователей (точнее почти всех - всех кто с inventTrans по записи может работать) одного турецкого клиента минимум минут на 5 (это если повезло и сиквел выбрал более или менее приличный план исполнения), а максимум минут на 40. В новой версии класса они сначала делают select recId в квазивременную таблицу, а потом запускают update_recordset только по тем записям которые в эту табличку попали...
Так что обновление в целом полезно, но забавно что они забыли саму табличку вложить в RU8. Возможно это на российской части partnersource выложили RU8 с включением пары позднейших хотфиксов.. Последний раз редактировалось fed; 13.09.2012 в 17:27. |
|
|
За это сообщение автора поблагодарили: AlGol (1), S.Kuskov (1). |
13.09.2012, 18:31 | #12 |
Участник
|
Цитата:
__________________
Ivanhoe as is.. |
|
13.09.2012, 18:47 | #13 |
Участник
|
Может выложите ее? Я не первый, у кого ее нет.
|
|
17.09.2012, 17:29 | #14 |
Участник
|
Вот.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: Ashir (1). |
18.09.2012, 09:47 | #15 |
Участник
|
Прошу прощения за офтоп, но вопрос к Ivanhoe Может у вас есть и табличка TaxRegime_MX, а то после накатываения Ру8 и нескольких обновлений на него какраз этих двух таблиц и не хватает?!
__________________
Самое полезное в жизни – это собственный опыт... Последний раз редактировалось Ashir; 18.09.2012 в 09:49. |
|
18.09.2012, 11:10 | #16 |
Moderator
|
В общем - выяснилось что так всех заинтересовавшие табличка и класс являются хотфиксом номер 2699890. Каким-то образом, индусы собиравшие один из билдов RU8 (вышедшего вообще-то в конце марта), ухитрились засунуть туда части более позднего, апрельского хотфикса.
Также имейте в виду, что если скачать сам хотфикс, то кроме одного измененного класса и одной новой таблицы, там, в качестве dependencies, болтается еще порядка 6 мегабайт кода, хоть как-то связанного с костингом. Устанавливайте аккуратно |
|
|
За это сообщение автора поблагодарили: Ashir (1). |
18.09.2012, 11:38 | #17 |
Участник
|
Уточнил - на приложении, с которого выгрузил таблицу выше установлены русские хот-фиксы по фактурам, наверное, туда попали и эти системные исправления по закрытию.
Зато сейчас под рукой другое приложение с RU8 без фиксов. Так в нем класс InventCostNonFinancialTransferHandler компилируется, в нем нет упоминаний этой таблицы.
__________________
Ivanhoe as is.. |
|