| 
			
			 | 
		#1 | 
| 
			
			 NavAx 
		
			
	 | 
	
	
	
		
		
			
			
			Проблема изменения номера партии в складской аналитике
			 
			
			Есть задача изменить номер партии в во всех складских аналитиках где он 
		
		
		
		
		
		
		
	присутствует. При попытке использовать код : inventBatch = InventBatch::find('000000120','50.07.00002',true); if (inventBatch) { inventBatch.inventBatchId = '000001241'; inventBatch.renamePrimaryKey(); } выдается сообщение - что обновлены такие то таблицы : ..... Но при этом никакой замены не происходит. В чем могут быть проблемы. Если кто-нибудь решал такую задачу - поделитесь опытом.  | 
| 
	
 | 
| 
			
			 | 
		#2 | 
| 
			
			 Аманд 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Номенклатура/Функции/Редактирование кодов аналитики
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#3 | 
| 
			
			 NavAx 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от Vals
			
			 
Номенклатура/Функции/Редактирование кодов аналитики 
		
	 | 
| 
	
 | 
| 
			
			 | 
		#4 | 
| 
			
			 NavAx 
		
			
	 | 
	
	
	
		
		
		
		 
			
			А так не подходит? 
		
		
		
		
		
		
		
	update_recordset InventDim setting InventBatchId = "Новая" where InventDim.InventBatchId = "Старая"  | 
| 
	
 | 
| 
			
			 | 
		#5 | 
| 
			
			 Аманд 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Хм, а чем отличается Номер партии от Кода аналитики?
		 
		
		
		
		
		
		
		
		
			Последний раз редактировалось Vals; 28.07.2006 в 15:20.  | 
| 
	
 | 
| 
			
			 | 
		#6 | 
| 
			
			 Участник 
		
			
	 | 
	
	|
| 
	
 | 
| 
			
			 | 
		#7 | 
| 
			
			 Member 
		
			
	 | 
	
	
	
		
		
		
		 
			
			raz, у вас плохая идея. 
		
		
		
		
		
		
			wit, проблема в том, что в классе InventDimRenameDimValue Микрософт зарыл очередную дурацкую багу. Перерисуйте в нем один метод примерно вот так. InventDim parmInventDimOrig(InventDim _inventDimOrig = inventDimOrig) { ; // GLIBS: Bug fix --> inventDimOrig = _inventDimOrig.data(); // inventDimOrig = _inventDimOrig; // GLIBS: Bug fix <-- return inventDimOrig; } Потом откройте форму InventBatch и перетащите туда (output) пункт меню InventDimRenameDimValue, заполнив свойство с DataSource. И можно клацать. 
				__________________ 
		
		
		
		
	С уважением, glibs®  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: mazzy (5). | |
| 
			
			 | 
		#8 | 
| 
			
			 Member 
		
			
	 | 
	
	
	
		
		
		
		 
			
			А если хотите, чтобы заработал тот код, который написали вы, то подправьте на таблице InventBatch метод примерно так. 
		
		
		
		
		
		
			void renamePrimaryKey() { InventDimRenameDimValue inventDimRenameDimValue = InventDimRenameDimValue::newInventBatch(this); ; ttsbegin; inventDimRenameDimValue.run(); if (this.isFormDataSource()) inventDimRenameDimValue.updateCallerForm(this.dataSource()); ttscommit; // GLIBS: Bug fix --> this.update(); // GLIBS: Bug fix <-- } И убедитесь, что тот код, который вы написали, находится в транзакции. Дело в том, что он обновляет все, кроме самой партии. Т.е. в проводках, например, у вас уже другой номер партии после запуска джоба. А в справочнике партий — старый. 
				__________________ 
		
		
		
		
	С уважением, glibs®  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: 36AC (1). | |
| 
			
			 | 
		#9 | 
| 
			
			 Модератор 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от glibs
			
			 
wit, проблема в том, что в классе InventDimRenameDimValue Микрософт зарыл очередную дурацкую багу 
		
	![]() вводная: СУБД - MSSQL, регистронезависимая кодовая страница (это важно) переименовываем конфигурацию с "КоНфИгУрАцИя" на "конфигурация" - все, нет больше остатков по этой аналитике \Classes\InventDimRenameDimValue\handleTable_InventSum PHP код: 
	
			
	
				__________________ 
		
		
		
		
	-ТСЯ или -ТЬСЯ ?  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: mazzy (5), glibs (3). | |
| 
			
			 | 
		#10 | 
| 
			
			 NavAx 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Glibs спасибо. Все заработало.  
		
		
		
		
		
		
		
	Но есть проблема. Возникла ситуация. При использовании стандартных функций копирования закупки - копируются строки, где в аналитике остается номер партии от прежней строки закупки. Как указать(восстановить) новый номер партии для закупок которые уже обработаны.  | 
| 
	
 | 
| 
			
			 | 
		#11 | 
| 
			
			 Member 
		
			
	 | 
	
	
	
		
		
		
		 
			
			wit, только сейчас заметил ваше сообщение, прошу прощения. 
		
		
		
		
		
		
			Я никогда не указываю партию или ГТД, например, в строках закупки. Для указания партии, ГТД, серийного номера я рекомендую использовать регистрацию (а если закуплено Управление складом 2, то журнал прибытия товаров) при закупке (в заказах можно использовать резервирование/авторезервирование или комплектацию (а если закуплено Управление складом 2, то отгрузки)). В таком случае проблем с партиями не будет. Да и работать так удобнее. Что вы будете делать, если у вас по одной номенклатуре несколько партий поступит? Строку закупки разбивать? А кто это будет делать? Кладовщик? Или у вас Аксапта внедрена в режиме 1С (сам себе хозяин — как нравится, так и пишу). 
				__________________ 
		
		
		
		
	С уважением, glibs®  | 
| 
	
 | 
| 
			
			 | 
		#12 | 
| 
			
			 Сенбернар 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Недавно решал аналогичную задачку, только вместо Номера партии был номер ГТД. Решилось примерно так : 1. Поиск по всем таблицам Ax - где есть поля типа ItemId и InventGTDId_RU (так, по-моему), запоминание списка таблиц и полей (опционально, чтобы каждый раз не ждать долго  ).2. Поиск по найденным таблицам - полям пары значений (ItemId, для которого изменяем ГТД + старое значение ГТД). При нахождении - замена старого ГТД на новый. Вроде работает, клиент претензий не заявлял ![]() 2 glibs : Цитата: 
	
		
			Я никогда не указываю партию или ГТД, например, в строках закупки.
		
	 
![]() Только, насколько я понял, там УЖЕ указали? Последний раз редактировалось RVS; 26.12.2006 в 12:59.  | 
| 
	
 |