22.02.2011, 10:47 | #1 |
Участник
|
Остатки по inventsum... По каким полям правильнее собрать?
Доброго времени!
Передо мной стоит задача - дописать процедуру импорта в Аксу v3.0 с 1С v7.7. Проблема в следующем - склады с которых списывается продукция в 1с не должны уходить в минус по партии... Чтобы каждый раз не высчитывать по inventtrans`у - решил брать остатки с inventsum (жду критики ). Но как мне проверить количество, учитывая ранее закаченный заказ, но не разнесенный? Т.е. я закачиваю сначала заказы, допустим со склад1 на склад2 (насколько я понимаю данное количество получается в заказе), потом - заказы со склада2 на клиентов... дык вот, если проверять при закачке заказов на клиента по полю физ. доступно - ясно дело количества по партии не хватит. По каким полям высчитать "доступное количество" по партии? Может где нибудь есть тема по расшифровке полей inventsum (но что то не нашел)? |
|
22.02.2011, 10:57 | #2 |
Участник
|
Цитата:
Цитата:
Сообщение от Che
Но как мне проверить количество, учитывая ранее закаченный заказ, но не разнесенный? Т.е. я закачиваю сначала заказы, допустим со склад1 на склад2 (насколько я понимаю данное количество получается в заказе), потом - заказы со склада2 на клиентов... дык вот, если проверять при закачке заказов на клиента по полю физ. доступно - ясно дело количества по партии не хватит.
По каким полям высчитать "доступное количество" по партии? Может где нибудь есть тема по расшифровке полей inventsum (но что то не нашел)? 1 - физическое наличие - товар лежит на полках 2 - зарезервировано из физ.наличия - зарезервировано из того, что лежит на полках 3 - доступно на полках после резервирования 4 - ожидается приход (заказы на покупку/журналы в статусе Заказано) 5 - ожидается расход (заказы на продажу/журналы в статусе Заказано) 6 - зарезервировано из ожидаемого прихода (если включена эта функциональность) 7 - доступно с учетом ожидаемого прихода и расхода вам нужна колока 7 на вкладке "В наличии" есть более детальные суммы. |
|
|
За это сообщение автора поблагодарили: Che (1). |
22.02.2011, 11:01 | #3 |
Участник
|
Коль уж тема создана в разделе программирование, то тогда в качестве "расшировки полей" можно использовать код метода InventSum.addInventTransOnSum . Там наглядно видно какой из статусов на какое из полей влияет
|
|
|
За это сообщение автора поблагодарили: Che (1). |
22.02.2011, 11:02 | #4 |
Участник
|
Спасибо за исчерпывающие ответы!
Честно говоря, думал что будет критика)))) Все-таки, как думаете, оптимально ли по инвентсуму проверять (сам уже не раз сталкивался с корявыми остатками)... Но по инвенттрансу - долго Последний раз редактировалось Che; 22.02.2011 в 11:04. |
|
22.02.2011, 11:09 | #5 |
Участник
|
рекомендую сначала сделать пробное суммирование по inventtrans по 200 - 1000 номенклатур и сравнить полученное значение с inventsum по этим же номенклатурам. если различий будет очень очень мало, то можно и по inventsum остатки считать.
но у нас было много кастомизаций. в итоге беглое сравнение показало что для первых 1000 номенклатур в 30% случаях суммы отличаются. видимо где не успевало обновится inventsum если у вас различия меньше 5% то можно наверно и по inventsum. |
|
22.02.2011, 11:12 | #6 |
Участник
|
А остатки вам нужны "мгновенные" или все-таки на какую-то дату?
Если inventsum расходится с inventtrans - это повод сильно задуматься над работоспособностью вашего "решения".
__________________
Ivanhoe as is.. |
|
22.02.2011, 11:12 | #7 |
Участник
|
Цитата:
А то что она у вас корявая, это значит что вы ручками/программно корректируете InventTrans в обход стандарта. Также помните что всегда можно запустить процедуру пересчёта/актуализации InventSum. Это повод задуматься над работоспособностью всей системы! |
|
22.02.2011, 11:15 | #8 |
Участник
|
Цитата:
Сообщение от Evgeniy2020
рекомендую сначала сделать пробное суммирование по inventtrans по 200 - 1000 номенклатур и сравнить полученное значение с inventsum по этим же номенклатурам. если различий будет очень очень мало, то можно и по inventsum остатки считать.
но у нас было много кастомизаций. в итоге беглое сравнение показало что для первых 1000 номенклатур в 30% случаях суммы отличаются. видимо где не успевало обновится inventsum если у вас различия меньше 5% то можно наверно и по inventsum. X++: static void Job70(Args _args) { InventTrans inventTransStatus; RecordSortedList cacheInventSum; InventSum inventSum; InventSum inventSumCurrent; InventDimId lastDimId; ItemId itemId; boolean mustInventBeControlled; boolean ok; Dialog dialog = new Dialog("Пересчет"); DialogField dfItemId; InventTable iTb; void testSum(InventSum _inventSum) { inventSumCurrent.itemId = _inventSum.itemId; inventSumCurrent.inventDimId = _inventSum.inventDimId; cacheInventSum.find(inventSumCurrent); cacheInventSum.del(inventSumCurrent); } dfItemId = dialog.addFieldValue(typeid(ItemId),itemId,"Номенклатура"); if(!dialog.run()) return; itemId = dfItemId.value(); cacheInventSum = new RecordSortedList(TableNum(InventSum)); cacheInventSum.sortOrder(FieldNum(InventSum,itemId),FieldNum(InventSum,inventDimId)); //Che while select iTb where iTb.ItemId like itemId { //Che // mustInventBeControlled = InventTable::find(itemId).inventItemType().mustInventBeControlled(); mustInventBeControlled = InventTable::find(iTb.ItemId).inventItemType().mustInventBeControlled(); ttsbegin; // while select forupdate inventSum where inventSum.itemId == itemId while select forupdate inventSum where inventSum.itemId == iTb.ItemId { cacheInventSum.ins(inventSum); inventSum.delete(); } if(mustInventBeControlled) { while select sum(qty),sum(costAmountPosted),sum(costAmountAdjustment),sum(CostAmountSecCurPosted_RU),sum(CostAmountSecCurAdjustment_RU),sum(CostAmountSecCurPhysical_RU),sum(costAmountPhysical) from inventTransStatus group by itemId,inventDimId,statusReceipt,statusIssue,datePhysical,dateInvent,dateExpected // where inventTransStatus.itemId == itemId where inventTransStatus.itemId == iTb.ItemId { if (ok) { if (inventTransStatus.inventDimId != lastDimId) { // inventSum.itemId = itemId; inventSum.itemId = iTb.ItemId; inventSum.inventDimId = lastDimId; inventSum.insert(); testSum(inventSum); inventSum.clear(); }//if (inventTransStatus.inventDimId != lastDimId) } //if (ok) else ok = true; lastDimId = inventTransStatus.inventDimId; inventSum.addInventTransOnSum(inventTransStatus); } //while }//if(mustInventBeControlled) if (ok) { // inventSum.itemId = itemId; inventSum.itemId = iTb.ItemId; inventSum.inventDimId = lastDimId; inventSum.insert(); testSum(inventSum); }//if (ok) ttscommit; }//while select iTb where iTb.ItemId like itemId } Последний раз редактировалось Che; 22.02.2011 в 11:22. |
|
22.02.2011, 11:22 | #9 |
Участник
|
На всякий случай ещё кину ссылочку на тему Пересчет inventSum
|
|
|
За это сообщение автора поблагодарили: mazzy (5). |
22.02.2011, 11:44 | #10 |
Участник
|
Цитата:
Сообщение от S.Kuskov
На всякий случай ещё кину ссылочку на тему Пересчет inventSum
Спасибо ВСЕМ! |
|
22.02.2011, 12:43 | #11 |
Участник
|
это неправильный джобик.
на правильный указал S.Kuskov там же сказано как сделать принудительный пересчет без джобиков, из главного меню |
|
22.02.2011, 12:50 | #12 |
Участник
|
|
|
22.02.2011, 13:06 | #13 |
Участник
|
1. Закат солнца вручную
2. в вашей проверке нет таблицы inventSettlement, поэтому финансовые остатки вы проверить не сможете. только количество. 3. поле costAmountAdjustment само по себе является агрегатом (= sum of inventSettlement). это поле может содержать неверные значения (обычно из-за вмешательства программистов). Его нельзя использовать для ПРОВЕРКИ! и сравните со стандартным кодом: Пересчет inventSum юзайте стандартные классы |
|