| 
			
			 | 
		#1 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
			
			
			Удаление разнесенного складского журнала.
			 
			
			Добрый День! Прошу помощи... необходимо написать жопик по удалению разнесенного складского журнала, который бы удалял журнал, строки и все что с этим связано. Помощь будет заключаться в подсказывании мне таблиц куда заноситься информация при разноске журнала. И я так думаю восстановлении того что было разнесено со склада.
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#2 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
			
			 Цитата: 
	
		
			Сообщение от opusss
			 
 
			Добрый День! Прошу помощи... необходимо написать жопик  по удалению разнесенного складского журнала, который бы удалял журнал, строки и все что с этим связано. Помощь будет заключаться в подсказывании мне таблиц куда заноситься информация при разноске журнала. И я так думаю восстановлении того что было разнесено со склада. 
		
	p.s. Кстати, а о каком типе журнала идет речь?  | 
| 
	
 | 
| 
			
			 | 
		#3 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Вообще-то, удаление журналов при разноске или периодическая операция по удалению разнесенных журналов это штатная функция Аксы (журнал это всего лиш черновик или, как мне больше нравится определение - центр управления). 
		
		
		
		
		
		
		
	Если имется ввиду, то нужно не только удалить журнал, но и полностью аннулировать все результаты его разноски, то это уже противоречит самой концепции Аксы (конечно можно аккуратно прочистить все данные), но основным способом коррекции в Аксе является сторно или реверс всех операций. Удалять то, что наворотили, не рекомендуется.  | 
| 
	
 | 
| 
			
			 | 
		#4 | 
| 
			
			 Axapta 
		
			
	 | 
	
	
	
		
		
		
		 
			
			В общем случае можно считать, что задача нерешаема и противоречит самой идее системы. Начать читать можно с очень-очень старой темы: Исследование возможности удаления проводок. В каком-то частном случае, может быть(!), и решаема, но вопрос у вас общий.
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#5 | 
| 
			
			 Аманд 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			В общем случае можно считать, что задача нерешаема и противоречит самой идеи системы
		
	 
![]() Цитата: 
	
		
			необходимо написать жопик по удалению разнесенного складского журнала, который бы удалял журнал, строки и все что с этим связано.
		
	 
 | 
| 
	
 | 
| 
			
			 | 
		#6 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Поправлюсь. 
		
		
		
		
		
		
		
	Складской журнал нужен только до разноски в международном функционале. Там он после разноски действительно уже не нужен. Но в российской локализаци на существование журнала завязаны печатные формы различных складских документов. Из-за этого, если используются российские печатные формы (те, что заданы в настройке наименований журналов на вкладке "Отчеты"), то удалять складские журналы нельзя! Они построены таким образом, что предполагают существование строк журнала. Это один из ярко выраженных антипаттернов того, как делать нельзя.  | 
| 
	
 | 
| 
			
			 | 
		#7 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Lemming нашел вот что  
		
		
		
		
		
		
		
	InventJournalTable ijtr; InventJournalTrans ijt; InventTrans itr; InventTransPosting itp; тип журнала: проводка Raven Melancholic? да я имел ввиду что нужно аннулировать все последствия разноски. Строки конечно есть, одна строка. Ситуация в том что пользователь ввел неправильную сумму, и как выяснилось можно, не только удалить но и изменить сумму(соответственно тоже с подчищением). я выезжаю к клиенту два раза в неделю, и админю его исправляю всякие данные в базе. В обычных журналах почти каждую неделю правим данные пока все ок. (чистим проводки и т.д)  | 
| 
	
 | 
| 
			
			 | 
		#8 | 
| 
			
			 Аманд 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			как выяснилось можно, не только удалить но и изменить сумму(соответственно тоже с подчищением). я выезжаю к клиенту два раза в неделю, и админю его исправляю всякие данные в базе. 
В обычных журналах почти каждую неделю правим данные пока все ок. (чистим проводки и т.д) ![]() Цитата: 
	
		
			В обычных журналах почти каждую неделю правим данные пока все ок. (чистим проводки и т.д)
		
	 
2. Почему вы уверены, что всё ОК? А если копнуть? Последний раз редактировалось Vals; 22.12.2009 в 18:05.  | 
| 
	
 | 
| 
			
			 | 
		#9 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Настоятельно прошу обратиться не к бухгалтерам (они естественно скажут, что без удаления всех операций не обойтись), а к аналитикам, экономистам или, если есть возможность, к ЛПР и объяснить, что такие вещи сделать можно, но только в случае, если заинтересованные лица готовы к тому, что их будут обманывать. 
		
		
		
		
		
		
		
	Повторюсь, если поставлен нормальный учет, то исправления делаются при помощи коррекций. Кстати, это требование идет еще с очень давних времен (достаточно посмотреть правила бухучета каких-нибудь 70 годов). Из-за 1С большинство бухгалтеров считает, что удаление одних документов и ввод вместо них других это и есть правила учета! Так вот, это не так В общем. прочистить данные можно (ты указал не все таблицы, ну это мелочи), но делать так НЕ НУЖНО! Еще раз - спроси мнение не бухов, а тех, кто несет ответственность за принятие решений.  | 
| 
	
 | 
| 
			
			 | 
		#10 | 
| 
			
			 Axapta 
		
			
	 | 
	
	
	
		
		
		
		 
			
			В тему, старая статья mazzy "Перепроведение: плюсы и минусы": http://offline.cio-world.ru/print/2003/16/27580/
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#11 | 
| 
			
			 Мрачный тип 
		
			
	 | 
	
	
	
		
		
		
		 
			
			А как же стандартно реализуемая архитектура "черновик => документ => модульные проводки => проводки ГК" ? Складской журнал - черновик ? А кто тогда является документом в таком случае, служащим основанием для оставшихся проводок ГК и номенклатуры ?
		 
		
		
		
		
		
		
			
				__________________ 
		
		
		
		
	Мы летаем, кружимся, нагоняем ужасы ...  | 
| 
	
 | 
| 
			
			 | 
		#12 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
  | 
| 
	
 | 
| 
			
			 | 
		#13 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			А теперь добавь к этому операции в ГК, Аудиторский след, российские заголовки документов, таблицу отслеживание операций российской функциональости, которая используется для сторно. Кстати, в одной из фирм, в которой я работал аудит проводил PricewaterhouseCoopers и их специалисты знают, что такое Аудиторский след в Аксе. У них может возникнуть вопрос по поводу того, почему в аудиторском следе операция есть, а в системе она не наблюдается?
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#14 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от oip
			 
 
			В тему, старая статья mazzy "Перепроведение: плюсы и минусы": http://offline.cio-world.ru/print/2003/16/27580/ 
		
	Цитата: 
	
  На самом деле затея с XML-ом там была бы к месту, если бы в момент разноски журнала XML-ка бы сериализовалась в InventJournalReportTable_RU, тогда отчеты можно было бы получить и после удаления строк. А так, просто "навернули" на ровном месте и снова в разрез с идеологией системы.
		 | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: Raven Melancholic (2). | |
| 
			
			 | 
		#15 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			И ещё не забудьте после удаления привести в соответствие остатки в наличии (тут ещё хорошо бы убедиться, что они не станут отрицательными на дату, если это важно) и пересчитать сальдо по периодам
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#16 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			А вас точно не устраивает сторнирование складских журналов (Функции/Копировать с отметкой "Сторно")? 
		
		
		
		
		
		
		
	Если разноска журналов с неправильными данными происходит на регулярной основе, то в первую очередь следует что-то изменить в бизнес-процессе работы с этими журналами, а не заниматься разработкой "жопиков", иначе именно в созвучном месте и окажется система в итоге ![]() Тем более, что задача по удалению разнесенных журналов в общем случае нерешаемая. На эту тему можно смело докторскую защищать.  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: Raven Melancholic (2), someOne (1). | |
| 
			
			 | 
		#17 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			А вас точно не устраивает сторнирование складских журналов
		
	 
 | 
| 
	
 | 
| 
			
			 | 
		#18 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от Raven Melancholic
			 
 
			Я так и не понял, почему журналы переноса отключны от функциональности сторнирования. понимаю, что в DAX4 переносы не пораждают финансовой разноски (в стандарте). Но помимо финансовой разноски можно было бы задавать, что перенос со склада 1 на склад 2 это коррекция ранее разнесенного перенос со склада 2 на склад 1 (и себестоимость нужно корректировать  учетом этого факта). почему перносы искючили из этого механизма непонятно (с заказами на перемещение-то хотя бы понятна причина - туда локализаторы не добрались). 
		
	 | 
| 
	
 | 
| 
			
			 | 
		#19 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Цитата: 
	
 )Цитата: 
	
		
			Сообщение от mazzy
			 
 
			Есть две позиции: 
		
	1. только реверс - это правильно, поскольку с точки зрения кладовщика есть только две операции приход и расход 2. только реверс - это неправильно, поскольку непонятно как вводить коррекции. Я соглашусь с точкой зрения разработчиков - с точки зрения кладовщика есть только приход и расход. С точки зрения кладовщика нет такой операции сторно прихода или сторно расхода. Коррекции же должны подтверждаться кладовщиками, поскольку иначе на складе будет бардак. Пока в складских проводках сторно нет, и это осознанная позиция разработчиков. Последний раз редактировалось gl00mie; 22.12.2009 в 20:45. Причина: раскопал еще одну ссылку  | 
| 
	
 | 
| 
			
			 | 
		#20 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Кстати, складская операция уже могла поучаствовать в закрытии (пересчете) склада. Нужно будет прочистить все эти следы. Причем, не только по конкретной операции, но и по операциям, на которые она повлияла (если используется средняя, то не исключено, что количество этих операций будет исчисляться тысячами), при этом нужно не только вернуть все зависимые операции в первоначальное состояние, но и подогнать все другие операции таким образом, как будто нашей операции не было!
		 
		
		
		
		
		
		
		
	 | 
| 
	
 |