|  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 | 
| Участник | Цитата:  . Там наглядно видно какой из статусов на какое из полей влияет | 
|  | |
| За это сообщение автора поблагодарили: 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 юзайте стандартные классы | 
|  |