Как правильно обновить сильно измененную конфигурацию

6. petrulnik 19 29.12.11 15:14 Сейчас в теме
Сильно измененная лучьше, чем неизмененная. внешними обработками поцепляй.
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
7. bitrostov 29.12.11 17:10 Сейчас в теме
Если такой вопрос задан, то в этом случае лучше всего вызвать хорошего программиста.
8. WarLex 29.12.11 17:22 Сейчас в теме
Я решал подобную задачку следующим образом, возможно данный метод и через пятое место, но спросить было на тот момент не у кого, но нужного эффекта в конце концов добился, ничего не сломав: в три захода:
1. Сравниваем измененную конфигурацию с типовой того-же самого релиза - составляем список изменённых объектов.
Оставшиеся можно смело обновлять.
2. Сравниваем типовую конфигурацию старой версии с типовой новой версии - составляем список именных объектов.
Сравниваем оба списка из п.1 и п.2- совпадения в первом и втором списках покажут объекты которые придется править руками.
3. Думаем как сочетаются изменения объектов сделанные руками с обновленной конфигурацией. Вносим правки в объединенную конфигурацию, по необходимости.
как-то так...
9. vbuots 20 29.12.11 18:05 Сейчас в теме
Я бы не стал обновлять конфигурацию. Тут только программиста вызывать!
10. OlegSantana 04.01.12 13:42 Сейчас в теме
Для обновления использую Конфигурацию АК 47 (Анализатор Коллизий).

Очень рекомендую.

процесс обновления наглядно отслежуемый.
11. endru 04.01.12 14:20 Сейчас в теме
(1) А так ли нужно все обновлять в вашем случае, может обновить только то, что необходимо для работы, а то что и так работает не трогать?
12. kievgorez 04.01.12 14:31 Сейчас в теме
Свою конфигурацию сравниваешь с таким же релизом, но типовым. Затем переносишь изменения в типовую последнего релиза (что ручками, что через объединение конфигураций). Затем этот конфиг накатываешь на свою базу. Естественно, не нужно забывать про копии.
ЗЫ Но лучше конечно специалиста вызвать.
13. Satv 04.01.12 14:51 Сейчас в теме
Нужно определиться какой из 2х вариантов потребует меньше работы и с помощью него обновить конфу:
1) Сравнить типовую конфу(не измененную) с релизом как у рабочей - с конфой рабочей(измененной). И внести различия в последний релиз конфы (до которого нужно обновить). Таким образом получим обновленную конфу.
2)Сравнить типовую конфу(не измененную) с релизом как у рабочей - с конфой псоледнего релиза( до которой нужно обновить). И внести различия в рабочую текущую конфу. Таким образом получим обновленную конфу.
14. alexk-is 6540 04.01.12 15:00 Сейчас в теме
15. dimachk 05.01.12 13:53 Сейчас в теме
Может быть нужно взвесить все за и против и обновить только нужные объекты с соответствующими исправлениями иначе рискуете нарваться на конкретный кусок работы.
Иваныч; +1 Ответить
16. petrulnik 19 17.01.12 07:44 Сейчас в теме
Никак ты бы еще спросил как после изменения в 8ке, в которой это называется "снятие с поддержки". Конфу когда правил надо было записывать что изменял, если записывал и помнишь что делал, переходи к сравнению конф, что нужно там и ставь галки. Можно попробовать внешними обработками. По опыту сам работаю на измененной, ну не нужны там 1сковские обновления, чего не так дописываю, прикрепляю. Да и не забывай бэкапит базу!!!
Узнать можно что там тебе такого понадобилось в обновлении, что ты без этого обойтись не можешь?
17. пользователь 30.01.12 12:40
Сообщение было скрыто модератором.
...
18. Quick_Loader 30.01.12 12:45 Сейчас в теме
19. slavok123 2 30.01.12 14:27 Сейчас в теме
обычно ведутся записи изменений вносимых и ставят коменты изменений в конфигурации
20. rippi 30.01.12 15:45 Сейчас в теме
ТиС не является конфигурацией сильно зависящей от изменений законодательства, от этих пертурбаций страдают печатные формы документов, которые правятся легко или же подгружаются внешние. Поэтому я бы не стал заморачиваться с обновлением данной конфигурации. А просто провел бы косметическую подстройку ручками
21. hild 27.02.12 14:11 Сейчас в теме
основное изменение в торговле, касается с/ф и новых книг покупок, продаж
обновляйте документы относящиеся к области формирования книг (счетафактуры, записи книг, формирование книг)
и полсе добавляйте в глобальный модуль или в модули документов, отчетов новые процедуры функции, имеющиеся уже старайтесь не менять, проще добавить такую функцию локально в модуль, где она используется
22. andy2011 01.03.12 16:33 Сейчас в теме
(1) nutmeg,
Однозначного рецепта нет.
но...
Есть рабочий алогоритм действий ( сталкивались несколько раз с подобной ситауцией) .
1. сделать бэкап.
2. при объединении ( ставишь галку - приоритет загружаемой) - вывести ПОДРОБНЫЙ ОТЧЕТ от изменениях.
3. особое внимание обратить на :
* изменение длин кодов в МЕНЬШУЮ сторону
* изменение уникальности кодов - по всему спр/в пределах подчинения
* изменение ТИПОВ кодов и номеров Документов
* изменение периодичности реквизитов
* изменение типов регистров - Остатки <-> Обороты (тут будет сложнее)
* нумераторы и последовательности
4. разобрать старую конфу утилитой GComp (через поиск гуглом/яндексом - найдешь сам)
5. критичные модули/формы , где вносили изменения - можно будет потом обратно также вставить - утилита двунаправленная

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

Мы в таких случаях цепляем 1с++ и все что нужно выносим в классы.
Через объект Перехватчик - можно динамически менять код в зависимости от обстоятельств.
Это - самый безболезненный и эффективный вариант, т.к. позволяет :
* совместить типовой код и дописанный
* обеспечить минимальное вмешательство в типовой код на уровне конфигурации
Все вышеописанное - при необходимости сохранить дописанный функционал.
Удачи.
23. petrulnik 19 19.03.12 20:23 Сейчас в теме
Типа никак, да и смысла нету, всё что появляется можно внешними прикрепить, что нельзя то можно и самим исправить, конфу ведь правили, тобишь знаете зачем и откуда ручки растут, сможете и в этот раз поправить.
covach2011; +1 Ответить
24. covach2011 20.03.12 05:17 Сейчас в теме
В торговле и складе, как бы сильно ничего не меняется, это тебе не УСН которые каждый день чот новое. Внешними цепляй.
25. Kowka0011 23.03.12 11:29 Сейчас в теме
26. arc581 24.03.12 09:28 Сейчас в теме
только сравнивать конфы
27. lyashuk2012 01.04.12 04:36 Сейчас в теме
Когда правил конфу надо было внешними цеплять, не пришлось бы теперь голову ломать.
28. kelebro63 04.04.12 09:14 Сейчас в теме
Соглашусь с вышесказанным, только штудируя конфигурацию. У меня была сильно переписанная ТиС, которая не обновлялась более трех лет. Когда пришло время, пришлось повозиться, обновлял только нужные блоки. Но в торговле проще, например в бухгалтерии все с этим обстоит намного сложнее.
29. dump 04.04.12 09:35 Сейчас в теме
(1) Обновление сильно измененной конфы, которую до тебя несколько лет курежили разные люди - это искусство. Судя по вопросу - вы это не потянете. При таком обновлении зачастую можно проигнорировать до 90% изменений, т.к. сейчас они уже не используются. Бывает, проще внести несколько нужных объектов (новая с/ф), чем обновлять всю конфу. Чисто индивидуальный подход, короче.
"потом стал ставить приоритет её выше, чем у той которой обновляю" -однозначно НЕТ.
30. alexdm 06.04.12 22:22 Сейчас в теме
(29) dump, Согласен на 100%, это, действительно, искусство... Обычно действую примерно так, как описано в (8), только с некоторыми нюансами, просто изменения (либо свои, либо типовые) частенько копирую напрямую из окна сравнения конфигураций, мыша там не работает, а Ctrl+Ins и Shift+Ins работают. Частичное обновление очень не рекомендую, т.к в дальнейшем теряется возможность отследить изменения типового релиза от того, что обновляем.
Уж на что офигенный опыт обновления сильно перепаханных конфигураций что в 7.7, что в 8, но и то сам последние четыре дня (!) убил на обновление базы Рарус:Общепит от 2006 года, базовый релиз бухии, на котором он сделан - 474 (кто в теме - тот поймет), его обновляли именно выборочно. Сам Рарус тех лет не особо утруждал себя комментариями сделанных изменений, сейчас, кстати, намного лучше, практически все изменения типовых объектов прокомментированы. Да еще и "внедренцы", которые "внедряли" постарались так, что иногда уже и не знал, то ли плакать, то ли смеяться. Чего только стоит определение места хранения по вхождению в наименование слова "стол" - значит, это столовая, номенклатуры - "минерал" - значит, минеральная вода и прочее... Так хрен бы с ним, но от этих наименований очень сильно зависят варианты проведения документов... Очень классно внести в табличную часть документа поступления товаров реквизит "СуммаР", который означает розничную сумму, да еще и перекрутить, соответственно, все процедуры управления видимостью реквизитов, пересчета по строке, подсчета общей суммы, и это при наличии стандартных реквизитов розничной цены и количества... Видимо, цена, умноженная на количество не всегда дает сумму... Или вообще шедевр - в документе "План-Меню" в процедуре "ПриОткрытии" идентифицируем одну уникальную столовую - опять же, по наименованию, но этого нам мало - для еще большей уверенности в том, что это именно она, мы предварительно добавили отдельный реквизит шапки в документ, вывели его на форму в виде чекбокса, проверяем - а она ли, а то хрен его знает, вдруг не она, и его взводим, если она. Потом это юзаем в обработке проведения. И все это после проверки на запрет редактирования, в результате получаем модифицированность формы при закрытии и вопрос юзеру, а не стоит ли записать документ, датированный хрен знает каким годом, который сносит ему крышу, а потом и мне... Про количественный учет на 01 счете (что вообще - бред сивой кобылы) без намека на изменения в документах по ОС вообще молчу... И такого море... Убил бы...

P.S. Может, немного увлекся, но это все к тому, что при обновлении сильно перепаханной конфы надо много думать, а стоит ли вообще переносить изменения наших предшественников... Так что процесс творческий, это точно...
34. AlexJohn1980 24.04.12 16:35 Сейчас в теме
(30) alexdm,
Да еще и "внедренцы", которые "внедряли" постарались так, что иногда уже и не знал, то ли плакать, то ли смеяться.

Я работал с "Ресторан+Бар+Кафе". Тоже проникся "оригинальными" идеями разработчиков :)
31. ceramica 13 11.04.12 20:49 Сейчас в теме
1. сделать бэкап.
2. при объединении ( ставишь галку - приоритет загружаемой) - вывести ПОДРОБНЫЙ ОТЧЕТ от изменениях.
3. особое внимание обратить на :
* изменение длин кодов в МЕНЬШУЮ сторону
* изменение уникальности кодов - по всему спр/в пределах подчинения
* изменение ТИПОВ кодов и номеров Документов
* изменение периодичности реквизитов
* изменение типов регистров - Остатки <-> Обороты (тут будет сложнее)
* нумераторы и последовательности
4. разобрать старую конфу утилитой GComp (через поиск гуглом/яндексом - найдешь сам)
5. критичные модули/формы , где вносили изменения - можно будет потом обратно также вставить - утилита двунаправленная

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

Мы в таких случаях цепляем 1с++ и все что нужно выносим в классы.
Через объект Перехватчик - можно динамически менять код в зависимости от обстоятельств.
Это - самый безболезненный и эффективный вариант, т.к. позволяет :
* совместить типовой код и дописанный
* обеспечить минимальное вмешательство в типовой код на уровне конфигурации
Все вышеописанное - при необходимости сохранить дописанный функционал.
Удачи.
32. Svetlana_E 5 14.04.12 19:38 Сейчас в теме
Могу поделиться своим опытом. Когда-то делала так:
!!!Если обновления вносились не вами и не выделены в тексте комментариями, то находим типовую того релиза, который стоит у вас.
1) "Объединение конфигураций" и смотрим какие именно изменения вносились. Я их складываю в отдельный файл и сохраняю - это потом будет нужно при каждом обновлении. НАзовем список этих объектов - СПИСОК_ИЗМ
2) делаем копию нашей базы не через конфигуратор, а просто копирую дирректорий, подключаю его и дальше работаю с ним.
3) "Объединение конфигураций" ( обновляем уже нужным вам новым релизом). Смотрим объекты, которые попали в СПИСОК_ИЗМ - встаем на них -"Сравнить" - смотрим каких изменений больше - тех, что сделали мы(или до нас :-))) или тех, которые появились в обновлении. В зависимости от этого делю для себя эти объекты на 3 группы: 1гр- старых изменений намного больше, чем новых; 2гр- наоборот; 3гр - это объекты, которых вообще нет в типовой.
Далее
а) оставляю галочки у тех объектов, которые не подвергались изменениям ранее и их можно безболезненно обновить. И у тех, в которые старые изменения легко внести заново. Приоритет у "загружаемой", Метод "Замещать объекты". ОК. Внести изменения, если это надо. Сохранить конфу.
б) снова "Объединение конфигураций" - галочки у тех, которые вошли в 1 группу - ставлю приоритет у "текущей", Метод "Объединять объекты". ОК. Захожу в каждый объект, анализирую( все внесенные изменения при объединении выделяются "скобками" {MRG}) и вношу нужные исправления.
в) снова "Объединение конфигураций" - галочки у тех, которые вошли в 2 группу - ставлю приоритет у "загружаемой", Метод "Объединять объекты". ОК. Захожу в каждый объект, анализирую( все внесенные изменения при объединении выделяются "скобками" {MRG}) и вношу нужные исправления. Сохранить.
С 3 группой: Они просто остаются и все.
4) Полученным файлом конфигурации обновляю рабочую базу. ОБЯЗАТЕЛЬНО перед этим выполнить сохранение!!!!!!!


Другой вариант-последнее время все чаще применяю именно его:

1) делаем копию нашей базы(назовем ее СТАРАЯ)
2) разворачиваю пустую базу с новым релизом
3) в одном окне открываю в Конфигураторе старую базу(пусть ОКНО1), во втором окне в конфигураторе новую типовую(ОКНО2).
4)В ОКНО1 запускаю "Объединение конфигураций", сравниваю с типовой того же релиза, что и старая база. Смотрю каждый измененный объект- какие именно изменения вносились.
Анализирую эти изменения- нужны нам в дальнейшем? иногда внесенные когда-то изменения давно уже не используются и нет смысла их поддерживать. Бывает и такое(правда довольно редко), что этот механизм уже реализовали в типовой. Выбираем, какие изменения все-таки надо сохранить.
Если это объекты, которых вообще нет в типовой(документы, справочники, перечисления ) - просто выписываю их себе. В дальнейшем при обновлении они просто останутся нетронутыми.
для остальных объектов -
5)"сравнить" и из ОКНА1 переношу изменения в соответствующий объект в ОКНЕ2. Сохранить
6) Полученным файлом конфигурации обновляю рабочую базу. ОБЯЗАТЕЛЬНО перед этим выполнить сохранение!!!!!!!

А вообще-то,не зная размер и характер ваших изменений, сложно рекомендовать что-то конкретнее. Сколько баз - столько и вариантов.
33. ibazh 24.04.12 16:22 Сейчас в теме
нужно, брать новую конфу переносить все изменения и объединять, либо если изменения небольшие то повторить их в рабочей бд
35. belgos 28.04.12 06:08 Сейчас в теме
Для сильно изменных конфигураций я обычноделаю так:Читаю файл release.txt, смотрю что изменилось.Сравнивая мою конфигурацию и обновление, аккуратно внощу изменения в рабочую. Конечно долго, зато все измения останутся на месте и ты курсе что изменилось, где были ошибки. Стоит раз проделать эти изменения, следующий раз делать обновления будет на много проще. Я все релизы ставлю по очереди, через много релизов не перепрыгиваю.
36. shkr_rimma 11 28.04.12 12:55 Сейчас в теме
Торговлю обычно не обновляют до последних релизов, все зависит от того, какие изменения Вам нужны. Если берем счет-фактуры (изменения 2012года), так мы установили внешние формы. Так дешевле и проще.
А если все же решили обновлять:
1. Сравнение базы с типовым релизом(номер релиза совпадает с релизом базы)
2. Сравнение типовых релизов (старый и новый)
3. Анализ приоритета изменений. Берем переносим изменения Нашей базы в новый релиз, или наоборот изменения между релизами в нашу базу.
4. Объединяем Нашу базу с измененным md файлом нового релиза(если в него внесли сами изменения).
Выверка получается долгая, но ...
37. kykysk 02.05.12 15:36 Сейчас в теме
На самом деле сравнение объединения не всегда правильное решение.
Иногда приходиться код написанный в старой программе переноситься частично и отлаживать.
А чему писать в торговли чтобы помом обновлять ?
38. nutmeg 28.09.07 10:34 Сейчас в теме
Подскажите как правильно обновить сильно измененную конфигурацию, её дописывали миллион лет разный народ, я её сначала вообще не трогал, потом стал ставить приоритет её выше, чем у той которой обновляю. Правильно ли я делаю?
39. sashulyT 201 28.09.07 11:50 Сейчас в теме
для сильно изменных конфигураций я обычно:
1. Читаю файл release.txt, смотрю что изменилось
2. Сравнивая мою конфу и обновление, аакуратно внощу измеения в рабочую.

Конечно долго, зато не затреш измения и в курсе что изменилось, где были ошибки.
falex423; +1 Ответить
40. nutmeg 28.09.07 15:19 Сейчас в теме
Спасибо. Но дело в том, что база несколько лет не обновлялась, и что теперь поднимать все релизы по очереди?
41. O-Planet 6437 28.09.07 17:49 Сейчас в теме
Сравниваешь с неизмененной той же версии и перетаскиваешь изменения по частям в чистую новую.
43. Иваныч 23 29.11.21 10:21 Сейчас в теме
Обновлял с 7.70.927 на 7.70.988 сразу, т.к все до определенного момента устраивало. Но с переходом на маркированный товар пришлось. Как итог процесс не особо долгий, но чтобы свое не порушить пришлось повозиться. Единственное долго проходили внутренние пересчеты базы, когда после обновления открыл само Предприятие.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот