Каким образом можно сернуть УПП 1.2.36.1 , что бы затем перенести в УПП 1.3.22.1
сабж, ситуация следующая, есть УПП 1.2.36.1 с многочисленными доработками, в том чиле множество дублирующих документов, добавленных к типовым по которым было движение, учет ведется с начала 10 года, если делать обновления, то мало того, что нужно вносить все доработки которые были сделаны, но еще и анализировать добавленные дублированные документы и в них производить теже самые доработки, что видимо совсем неподъемно.
Самое оптимальное на мой взгляд, сворачивать базу на конец 2011 и переносить в 2012 уже в УПП 1.3.22.1 остатками на 31.12.11 , что вы можете предложить в такой ситуации? есть ли какие то обработки для формирования и или переноса остатков и потом писать правила для переноса или что можно более разумное сделать в такой ситуации?
Самое оптимальное на мой взгляд, сворачивать базу на конец 2011 и переносить в 2012 уже в УПП 1.3.22.1 остатками на 31.12.11 , что вы можете предложить в такой ситуации? есть ли какие то обработки для формирования и или переноса остатков и потом писать правила для переноса или что можно более разумное сделать в такой ситуации?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) вертер,
Сейчас делаю примерно то же самое, переходим с сильно дописанной 1.2.29 на 1.3.20
(в эти выходные планирую окончательный переход).
Делать через обновления до актуального релиза посчитал излишне сложным + база уже очень большая.
Обрезать будет слишком долго (учет с 2009 года, в день порядка 250 заказов + реализаций).
Поэтому взял новый релиз 1.3.20 (точнее на момент начала работ он был новым, сейчас уже 1.3.22 актуален), перенес в него все изменения и дополнения.
Завтра перенесу все остатки на 31.12.2011 и все документы с 01.01 по текущую дату.
Документы переношу через правила обмена, которые создал через Конвертацию данных.
Остатки на 01.01 в старой базе сформирую с помощью обработки "Свертка базы", она умеет их выгружать в документы "Бух.операция" и "Корректировка регистров", затем эти документы перенесу в новую базу и проведу.
Многие доработки в базе делались до меня разными программистами. Часть этих доработок уже не нужна, но все равно перенес все, заодно ознакомился со всеми доработками: часть из них потом уберу, часть оптимизирую, чтобы впоследствии было легче базу обновлять.
Сейчас делаю примерно то же самое, переходим с сильно дописанной 1.2.29 на 1.3.20
(в эти выходные планирую окончательный переход).
Делать через обновления до актуального релиза посчитал излишне сложным + база уже очень большая.
Обрезать будет слишком долго (учет с 2009 года, в день порядка 250 заказов + реализаций).
Поэтому взял новый релиз 1.3.20 (точнее на момент начала работ он был новым, сейчас уже 1.3.22 актуален), перенес в него все изменения и дополнения.
Завтра перенесу все остатки на 31.12.2011 и все документы с 01.01 по текущую дату.
Документы переношу через правила обмена, которые создал через Конвертацию данных.
Остатки на 01.01 в старой базе сформирую с помощью обработки "Свертка базы", она умеет их выгружать в документы "Бух.операция" и "Корректировка регистров", затем эти документы перенесу в новую базу и проведу.
Многие доработки в базе делались до меня разными программистами. Часть этих доработок уже не нужна, но все равно перенес все, заодно ознакомился со всеми доработками: часть из них потом уберу, часть оптимизирую, чтобы впоследствии было легче базу обновлять.
Скажите, что до 1 апреля с/ф терпят, и спокойно обновляйте.
Что вас пугает?
Вы детально проанализировали реальный объем изменений?
Сам только что перенес все изменения доработанной упп 1.2 на 1.3.
На вид изменений было очень много и страшно.
Получилось за три дня все что касается изменений перенести.
Что вас пугает?
Вы детально проанализировали реальный объем изменений?
Сам только что перенес все изменения доработанной упп 1.2 на 1.3.
На вид изменений было очень много и страшно.
Получилось за три дня все что касается изменений перенести.
(3) amiralnar, дело в том, что анализ изменений показал, что кто то внедряя программу не смог технологический процесс производства разместить в рамках типовой конфигурации, поэтому насоздавали параллельные учетные справочники и документы, внедряли в течении 10 года и начала 11, где то до февраля так как 1.2.36.1 была выпущена примерно в это время, в результате доработок в течении года закрыть год так и не смогли, 11 год организация худо бедно вела приход и расход, сейчас им захотелось что бы программа работала, НО
вот и по всей видимости мне кажется, что нужно переходить остатками на 2012 год и сразу в новую конфигурации, вот только какими остатками вводить вручную, или как то писать правила обмена и потом корректировать, вот над этим я еще думаю, и жду позсказки с форума, я и так уже от вас много чему научился, думаю что и тут подскажете...
вот и по всей видимости мне кажется, что нужно переходить остатками на 2012 год и сразу в новую конфигурации, вот только какими остатками вводить вручную, или как то писать правила обмена и потом корректировать, вот над этим я еще думаю, и жду позсказки с форума, я и так уже от вас много чему научился, думаю что и тут подскажете...
(5) вертер, Скажите, а вы сможете внедрить технологический процесс производства в рамках типовой конфигурации? Вы писали правила обмена в КД для переноса данных остатками и документами между разными конфигурациями?
Если объемы предприятия позволяют говорить о варианте "вводить вручную" - так и поступайте.
Если объемы предприятия позволяют говорить о варианте "вводить вручную" - так и поступайте.
(6) amiralnar, если бы я все это умел, то конечно бы не спрашивал тут, а брал бы и делал, но УПП я не внедрял, только присутствовал при внедрении на вторых ролях,правила обмена не писал, только настраивал в КД в автоматическом режиме, но если бы получил на форуме такую информацию, что так сделать можно, то попытался бы сделать, литературы достаточно,к сожалению нет времени на то что бы самостоятельно во всем разобраться самому, поэтому обращаюсь на форум, но собственно для этого он и существует, что бы кто то более опытный сократил работу по освоению менее опытным. Что касается вводить в ручную, то в бухгалтерии есть такой документ "ввод остатков", и обработка по переносу остатков и документов из бухгалтерии 1.6 в 2.0, почему бы и тут не сделать нечто подобное, не могли бы вы немного яснее выразить свою мысль по внедрению технологического процесса в том числе?
(3) amiralnar, пугает то что организация не делала закрытия месяца, на протяжении 2х лет работы, у вас было так же или иначе, а доработок я не боюсь, жалко только напрасно потраченного времени своего и чужого, если после всех обновлений окажется что месяца так и не закроется. Еще вопрос вы обновляли через cfu последовательно или как то иначе?
Мы перешли с сильно дописанной 1.2.39 на 1.3.18.1 через последовательность
обновлений до актуального релиза и перенос в последний релиз всех изменений и дополнений, актуальность с доработками которого поддерживается регулярно при выходе также нового обновления! В результате переход занял порядка 8 часов!
обновлений до актуального релиза и перенос в последний релиз всех изменений и дополнений, актуальность с доработками которого поддерживается регулярно при выходе также нового обновления! В результате переход занял порядка 8 часов!
(10) ekean, непонятно:(
Т.е. вы последовательно обновляли все 10 релизов, в каждый перенося изменения нетиповой УПП?
И все это за 8 часов? Признаться, я вами восхищаюсь. У меня только один шаг обновления нашей в хлам не типовой УПП занимает часов 10 :(
С другой стороны... А нафига? Ибо все тоже самое можно сделать одним прыжком, немного подправив обработчики обновления ИБ.
Или я просто неправильно вас понимаю?
Т.е. вы последовательно обновляли все 10 релизов, в каждый перенося изменения нетиповой УПП?
И все это за 8 часов? Признаться, я вами восхищаюсь. У меня только один шаг обновления нашей в хлам не типовой УПП занимает часов 10 :(
С другой стороны... А нафига? Ибо все тоже самое можно сделать одним прыжком, немного подправив обработчики обновления ИБ.
Или я просто неправильно вас понимаю?
(12) CnupT,
1. Вы неправильно понимаете. Процесс выглядит так:
Например, сейчас обновление с 1.3.22 до 1.3.23 я сделаю за час.
При этом подготовку обновления с 1.2.28 на 1.3.22 я делал ... три дня.
Изменений не много.
1. Вы неправильно понимаете. Процесс выглядит так:
- Создание cf файлов всех обновляемых релизов, с сохранением изменений типов данных.
- Подготовка последнего релиза с изменениями форм и алгоритмов
- Обновление накатыванием cf файлов
Например, сейчас обновление с 1.3.22 до 1.3.23 я сделаю за час.
При этом подготовку обновления с 1.2.28 на 1.3.22 я делал ... три дня.
Изменений не много.
(13) amiralnar,
Ни в коем случае не сочтите за критику, я еще только учусь... Зачем необходимы cf всех промежуточных релизов?
Почему бы не перепрыгнуть сразу? 1.2.39 -> 1.3.xx
Я вижу только две проблемы: возможную потерю данных из-за удаленных реквизитов, в этом случае это можно решить добавлением промежуточного прыжка, и отсутствие в последних релизах обработок, которые запускаются при первом запуске после обновления.
Конкретно при переходе с 1.2.39.х на 1.3.22.х удаленных объектов вроде не было, а подправить обработчики обновления ИБ вроде не сильно трудно.
Ни в коем случае не сочтите за критику, я еще только учусь... Зачем необходимы cf всех промежуточных релизов?
Почему бы не перепрыгнуть сразу? 1.2.39 -> 1.3.xx
Я вижу только две проблемы: возможную потерю данных из-за удаленных реквизитов, в этом случае это можно решить добавлением промежуточного прыжка, и отсутствие в последних релизах обработок, которые запускаются при первом запуске после обновления.
Конкретно при переходе с 1.2.39.х на 1.3.22.х удаленных объектов вроде не было, а подправить обработчики обновления ИБ вроде не сильно трудно.
(14) CnupT, Зачем мне выяснять, какой релиз является ключевым, и рисковать не столько потерей данных, сколько их непротиворечивостью.
Например, по вашему сценарию произойдет первоначальное заполнение БД, в которой вы ведете учет. Включится РАУЗ, изменятся настройки заполнения счетов.
В моем же сценарии эксцессов не будет. А подготовка промежуточных релизов - это только время, потраченное на выгрузку cf. То есть - дешево.
(15) CnupT, Упрощение обновлений зависит от качества изменений. Большинство из них возможно сделать по методике динамического изменения форм и обработчиков, подписок на события. Таким образом, сложность сокращается на порядок.
Например, по вашему сценарию произойдет первоначальное заполнение БД, в которой вы ведете учет. Включится РАУЗ, изменятся настройки заполнения счетов.
В моем же сценарии эксцессов не будет. А подготовка промежуточных релизов - это только время, потраченное на выгрузку cf. То есть - дешево.
(15) CnupT, Упрощение обновлений зависит от качества изменений. Большинство из них возможно сделать по методике динамического изменения форм и обработчиков, подписок на события. Таким образом, сложность сокращается на порядок.
(16) amiralnar, все равно немного не понимаю.
Пусть у нас есть 1.2.39 релиз дописанной УПП. А хотелось бы 1.3.много
Мы делаем с десяток cf-ников типовых релизов, в каждом из них исправляя типы данных (если нужно)
Накатываем эти cf-ники, благополучно затирая изменения, следя только за типами данных
Подготавливаем последний, самый важный cf - в него перетаскиваем все изменения из исходного релиза.
И накатываем его поверх непойми чего, получившегося в результате наложения типового релиза на нетиповую конфу
Если это так, то как вы решаете проблему времени? На не самой большой базе реструктуризация данных выполняется 3+ часа, делать удавалось только по ночам. На пару дней останавливать производство - меня с потрохами съедят:)
P.S. первоначальное заполнение не произойдет, если подправить версию, чтобы сам по себе включился рауз - первый раз слышу, вроде не было такого. Да и со счетами... Просто аккуратно просмотреть обработчики
Пусть у нас есть 1.2.39 релиз дописанной УПП. А хотелось бы 1.3.много
Мы делаем с десяток cf-ников типовых релизов, в каждом из них исправляя типы данных (если нужно)
Накатываем эти cf-ники, благополучно затирая изменения, следя только за типами данных
Подготавливаем последний, самый важный cf - в него перетаскиваем все изменения из исходного релиза.
И накатываем его поверх непойми чего, получившегося в результате наложения типового релиза на нетиповую конфу
Если это так, то как вы решаете проблему времени? На не самой большой базе реструктуризация данных выполняется 3+ часа, делать удавалось только по ночам. На пару дней останавливать производство - меня с потрохами съедят:)
P.S. первоначальное заполнение не произойдет, если подправить версию, чтобы сам по себе включился рауз - первый раз слышу, вроде не было такого. Да и со счетами... Просто аккуратно просмотреть обработчики
(17) CnupT, Если у вас 3 часа реструктуризация выполняется, это еще не конец. При обновлении с 1.2 на 1.3 выполняется самая долгая реструктуризация. Следующие будут гораздо быстрее.
Я делаю cf ники с изменениями в структуре данных. Это не типовые.
По поводу сброса настроек - читайте партнерский форум.
Мы делаем с десяток cf-ников типовых релизов
Я делаю cf ники с изменениями в структуре данных. Это не типовые.
По поводу сброса настроек - читайте партнерский форум.
(13) По поводу изменений... десяток измененных справочников, пяток новых; два десятка измененных документов, опять же пяток новых... Ну и еще по мелочи
Вопрос для меня сильно актуальный, и если как-то можно упростить сей процесс, было бы просто замечательно :)
Вопрос для меня сильно актуальный, и если как-то можно упростить сей процесс, было бы просто замечательно :)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот