Всем привет! У нас в организации существует в одном магазине несколько складов. Каждый склад это отдел (Ваз-71 склад, Газ-72 склад, Камаз-73 склад). Начальство решило избавиться от разбивки на отделы и сделать все одним. Получается мне необходимо все 70-е склады изменить на... допустим 100 склад. Подскажите как это проще сделать или послать начальство со словами что это нереально? Нужно изменить все реализации, все перемещения, и ещё кучу всего включая регистры где есть 70-е склады на 100 склад. Да и самое главное какими средствами?

(0)Открыть конфигуратор и написать код или
http://infostart.ru/public/19345/
http://agkorepanov.ucoz.ru/load/poisk_i_zamena_znachenij_1s_7_7/1-1-0-4

Переместить товар перемещением.

Может достаточно перенести остатки?

если сделать перемещение, то тогда прошлые продажи будут видны на старом складе. Нужно просто везде все сменить на другой склад.

необходимо отслеживать динамику продаж

(4) обработка замена значения не то пальто?

(1) и (6)  не то. Документы потом перепроводить придется что ыб в регистрах прописались значения. Это нереально долго.

(7) http://infostart.ru/public/183962/

(4) Гм. А кто мешает отслеживать динамику без фильтра по складу?

(9) + 100 если склад один, то зачем тогда пользоваться фильтрами склада в данном отчете

(4) ну и да, а почему нельзя смотреть динамику в отборе ДВУХ складов не? Старый и новый нее???

Склад не один. Существую другие магазины со своими складами. Да и короче задание звучало как изменить везде. Нужно объединить склады в один без потери динамики.

мб они там что-то дальше ещё напридумывают. Так-то я динамику им покажу и по старым 3-м складам вместе

(8) она долго будет работать? Если за день справится, то хорошо. Но я сомневаюсь что с нашим оборотом за неделю бы осилить обработками

(12) Это решается либо универсальной обработкой по замене объектов но тут перепроведение, либо заменой ИД склада на новый со старых во всех таблицах.

(14) обрабатывать можно постепенно начиная с прошлых периодов.

Была идея залесть в скуль и там апдейтом поменять всё нужное.
Есть идеи в этом направлении?

есть еще один финт.

сделать группу складов поместив в группу все эти склады.
Отчет делать по группе.

Но вообще для отчетов запросы с выборками более 1 элемента тормозят сие действие

(17) кто-то делал. спец в этом @toypal

(18) Да не проблема сделать группу. Я не знаю что на уме у начальства. Вдруг они потом что-то хотят реализовать на основе единого склада.

да и куча всех отчетов и проверок похерется из-за группы

(20) ну так сделать единый новый. а старые в группе для аналитики

(0) Можно HEX редактором все строги с GUID найти и заменить на GUID другого склада.

не, существует куча обработок ночных и всяких о которых я даже и не в курсе. Они будут гнать. Нужно объединять

(23) у меня скуль

(0)Понимают ли они чего хотят и зачем?
Можно: выводить, хранить, учитывать.
Три разных варианта.
И следовательно если непонятна мотивация на изменения, то и не понятно что надо менять.

Так в моей практике был случай когда расчетчик в категорической форме потребовал разделить единую базу на три. Ей разделили. Поработав месяц, другой она поняла что это неудобно и сказала соберите все обратно в единую базу и была поражена тем что разделили за 15 минут, а собирали существенно дольше. Говорила, Вы же так быстро все разделили.

(25) ты сам ищешь себе неприятности просто. Надо все начинать с объяснения заказчику.

ты пишешь что у тебя скуль, ну так выгрузи в файловую, замени HEX редактором GUID и обратно в SQL

http://infostart.ru/public/66865/

Пойми сначала, что и зачем нужно сделать.

Тех, кто меняет справочники и получает везде в старых документах новые склады, МОЛ, ТМЦ - надо отстранять за профнепригодность.

(12) опосля перепровода, может измениться себестоимость, ежели везде сменишь склад на один..

Проще перемещением загнать на один склад и привет.

База 30 гигов, файл не охереет?

(30) цены одинаковые

Гы-гы-гы... Реклама infostart.ru?

(31) см (28)..

(28) ага, уже смотрю.

похоже на правду

Написать пачку запросов update не?

Когда уронишь базу, иди к Олегу Садовникову. Он, наверное, восстановит.

(38)Поможет восстановить из копии?)

"Поиск и замена значений" с ИТС. Заменить везде, в том числе и в регистрах.

Если себестоимость считалась и в разрезе складов то прибыть и т.п. может сильно уехать. некоторые доки могут вообще начать ругаться если есть проверка от дуроков. Тоже перемещение со склада на склад у меня при одинаковых складах непроводится и говорит, что сам дурак.
Про инвентаризации вообще молчу. есть 120 штук чегото числится 121.
На складе Газ-23 - 50 шт. вместо 51
на складе Камаз есть 70 шт.
после переноса всего на 1 склад окажется что всего есть 50 штук или 70 смотря какая инвентаризация раньше.
нельзя так тупо склад поменять и надеется что все будет пучком.

(38) Садовников нынче занимается другими делами...

941) товарищу пофиг - начальство сказало сделать, товарищ - делает. Такой товарищ - 1Сникам не товарищ!

(41) Инвентаризация не изменит остатки.

(42) Я в курсе. Но восстановить базу в Нске, насколько мне видно из-за Урала, сможет только он. Уговорить, возможно, будет тяжело :)

(44)Уверен как минимум в 5 Украинских типовых таки изменяет
(0) где то конфу указал. После 70 складов и что склад = отдел я бы не рискнул утверждать что и как делается и считается в его базе.

исполнение такого распоряжения без постановки в известность руководства о неминуемых последствиях и возможных "подводных камнях" - смелый шаг.

Если кому интересно, то начал переносить документы вот таким вот способом
update popov.dbo.RA2351 set popov.dbo.RA2351.sp10196='00000T001' where popov.dbo.RA2351.Iddoc in
(select jj.iddoc as iddoc from dbo._1SJOURN as jj where jj.IDDOCDEF = '3114')
and popov.dbo.RA2351.sp10196 like '%11001%';

update popov.dbo.DH3114 set popov.dbo.DH3114.SP3093='00000T001' where popov.dbo.DH3114.IDDOC in
(select jj.iddoc as iddoc from dbo._1SJOURN as jj where jj.IDDOCDEF = '3114')
and popov.dbo.DH3114.SP3093 like '%11001%';
----  set popov.dbo.DH3114.SP3093='000011001' where popov.dbo.DH3114.IDDOC like '%18IBW001%'

update popov.dbo._1SJOURN set popov.dbo._1SJOURN.SP10051='70' where popov.dbo._1SJOURN.IDDOCDEF = '3114'
---- set popov.dbo._1SJOURN.SP10051='72' where popov.dbo._1SJOURN.DOCNO like '%0100220168%'

update  popov.dbo.RA405 set popov.dbo.RA405.SP418='00000T001' where popov.dbo.RA405.IDDOC in
(select jj.iddoc as iddoc from dbo._1SJOURN as jj where jj.IDDOCDEF = '3114')
and popov.dbo.RA405.SP418 like '%11001%';
----  set popov.dbo.RA405.SP418='000011001' where popov.dbo.RA405.IDDOC like '%18IBW001%'

update dbo._1SCRDOC set dbo._1SCRDOC.Parentval='B1  1J     T001        '  where dbo._1SCRDOC.CHILDID in
(select jj.iddoc as iddoc from dbo._1SJOURN as jj where jj.IDDOCDEF = '3114')
and dbo._1SCRDOC.Parentval like '%11001%';


Какие меня подводные камни могут ждать?
Скажу сразу что остатки перенесем обычным перемещением.

(47) на сколько валидными будут после сей операции типа перемещения?

получишь кучу документов с двумя одинаковыми складави, при попытки перепроведения (или востановления последовательности) будет ругатся...

ну и так далее...

универсальная замена разве не везде меняет? в документах и в движениях сразу не?

(48) да нихрена с перемещениями по идее не будет проведутся спокойно...

Универсальная замена это лажа с перепроведением документов и кучей затраченного времени! здесь тебе грозит только совпадение номеров доков!

(49) да мне нужно что бы в регистрах поменялось ещё. А это каждый документ перепроводить, очень долго.
(48) А за перемещения я не беспокоюсь, остатки со складов перекинем.

т.е. по идее я поменял в документах склад и в регистрах (своими апдейтами)
пока полёт нормальный. Но хотелось бы знать, что через некоторое время что-нить да не полетит.
(51) номера доков...да и хрен с ними

Чую подвох... Себестоимость таки может измениться...

(52) какой наивный..
поменял движуху двух регистров, а итоги оставил "как" есть

уже санитары за вами выехали

Пересчет итогов сделай.

Итоги попорчу, действительно нужно пересчитать

+ склад еще и в графе отбора светится поди.. там, видно что не поменял.

ЗЫ: есть же поделка готовая, чего не воспользовался ?

(58) у меня бонусов нет, а деньги тратить не хочу

http://zalil.ru/34699004

+Но после такой операции задним числом ничего не трогай.

проще было отчет одновременно по нужным складам сделать

(61) спс, погляжу
(62) Отчет написать не проблема. Но ведь начальство не зря решило объединить склады

(63) "начальство не зря решило". Зря ты веришь в нерушимость слов начальства.

(62)ладно 1 отчет а если из 150 и каждый переписывать!

(66) смотря какие отчеты ... иногда проще написать 150 отчетов чем данные корежить ...

(66) ну мне бы было проще подменить ссылки через скуль и пересчитать итоги чем свои отчеты препахивать!

Вечная память котёнку. Хорошая была база, да?

(68)Да он поди в копии делает с начало!))

с интересом понаблюдаю за развитием событий. автору просьба сообщать как идут дела.

у меня тут похожая ситуация - решил чуток добавить реквизитов и отчеты допилить , чем заниматься перепахиванием данных , ибо хз как и где они привязаны ... перепашешь а потом вылезет в других отчетах , которые никоим образом вроде не пересекаются ...

новый проект: "За компом"
Ок, буду писать что выходит

(71) получи все таблицы где встречается твой документ посмотри что за таблицы в каждой апдейтом поменяй что тебе нужно и потом пересчет итогов сделай!

(71) Могу дать процедурку на скуле как отыскать упоминание о нужном тебе объекте во всех таблицах

А может просто сделать справочник склады двухуровневыми?
Ну и отчеты получать по группе...

(75) Обсуждалось уже! не вариант! Много лопатить тогда!

ИМХО сначало надо было сварганить перемещения загнать все на 1 склад сделать по нему инвентаризацию чтобы зафиксировать остатки и себестоимость, а уж потом такое запускать. Наверника когда нибутьктото таки решит залесть в прошлый период. и чет там поправить. всебы решалось перепроведением 2 доков . испровляемого и инвентаризации.

(74) (73) в отчетах(да и не в отчетах) тоже предлагаешь рыться ? :))) где это используется , а если в коде есть перлы типа Если ляля код = "семьпитсот" то логика работы такая
---
то чоу ?