[anykey]1c

да

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

Скажи, а вы все тут такие борзые, что не зная предмета лезите "работать"? Я-то дурак считал что если ты идешь на работу, то должен знать как это делать.

+1.
В общем, топикстартер, если ты патчи когда-нибудь на сорцы линуха някатывал, и сталкивался с reject'ами и конфликтами, должен понимать что это и как разруливается.
"Типовые" конфигурации, которые ни разу не дорабатывались или дорабатывались грамотными программистами (не индусокод, с представлениями о рефакторинге) обновлять легко. Новый код висит сбоку и не отсвечивает, изменения в "новом коде" не ломают типовые и наоборот.
Если запущенный случай индусокода с вложенными IF'ами -- то обновлять её надо осторожно, объединить свои изменения, чужие и апстрим в "типовой". Если ты разруливал конфликты при мёрджах в SVN/CVS/hg/git/.. вручную, сливал изменения вручную, то должен понимать, как это делается.

Универсальный алгоритм:
1. Берётся базовая для той версии, что стоит у клиента (типовая такая-то).
2. Строится дельта базовая-рабочая(у клиента)
3. Строится дельта апстрим базовой и новой версии базовой
4. Накатывается дельта 3 на дельту 2, затёртые изменения (конфликты) разруливаются руками.

В общем-то, банальный cherry picking.
Средства для "объединения изменений" в стандартной 1Cv7 убогие, в v8 получше (где-то на уровне SVN/SourceSafe). Но, для v7 существует gcomp -- компилятор/декомпилятор 1Cv7.md в тесктовые файлы, которые уже можно хранить например в git/hg/darcs, накатывать патчи автоматически через hg MQ/ git rebase, "теорию патчей" darcs, и т.п.

+2, "одинэснег" -- это диагноз, понты и пальцы шире дверей.

google 1C.mp3

там все инструкции

http://sysadminday.com.ru/media/download.php?file=1C.mp3

Плюс, иногда релизы типовых unstable, пофиксили одну фичу, сломали пару баг старых. Соотвественно, ты должен рубить в предметной области (бухучёте, калькуляции ФОТ и начислении ЗП, для торговли и упр. учёта полегче, не так сильно меняется) на предмет "почитали ченджлог, забекапили рабочую базу, потестили что 1) новые фичи работают 2) старые не отвалились, 3)пофиксили если что отвалилось 4)запустили автоматические юнит-тесты (см. например functest) на предмет "не сломалось ли чего своего", и пофиксили конфликты или юнит-тесты.
Технически это не сложно, напрягает что нужно мониторить изменения в законодательстве не реже раза в квартал и т.п. и смотреть, надо свой релиз подтянуть под новые требования или изменения их не касаются.

Ммм, ясно, спасибо.
Буду думать.

<7.7> если конфиг стандартный - делать там ваще нефиг

обновлять саму прогу, как правило, так часто не требуется, в основном отчетности

обновления отчетностей - зараренные селфекстракт рары(у наших так было), нужно их скормить(exe-шники) 1с-ке

главное - делай бэкапы старой конфигурации(хотя маловероятно что они пригодятся)

p.s. если деньги не так сильно нужны, забей, такая дрянь

>забей, такая дрянь

Пожалуй так и сделаю.

Смотря что обновляешь. Если скажем Камин - там последовательность обновления есть - сначала мерж конфигурации с новой, потом копирование ExtForms, причем желателен бакап так как при это отвалиться может.
В Упрощенке там куча экзешников, а именно нечто зажатое досовской arj демо версией, и список экзешников. И это надо куда-то скормить там, причем уже в самой программе. Короче зависит от того, кто ту или иную шнягу для 1с делал, но сделано там везде все через задницу(

Всё дело, как обычно, в нюансах. Вы, судя по всему, полный профан. Можно сразу об этом сказать тёткам. Если согласятся на таких условиях - их проблемы.

Мой совет — лучше разгружай уголь. Если с 1С не хочешь работать, то лучше и не трогать. А то ж придеться потом конфы править... и превратишься в "программиста 1С".