Актуализиране на нестандартна конфигурация 1c инструкции стъпка по стъпка. Личен опит: как бързо и рентабилно да актуализирате променена конфигурация. Получаване на файл на доставчика

Актуализирането на нестандартна платформа е много трудно. Ще разгледаме как да актуализираме нестандартна конфигурация на 1C и ще опишем стъпка по стъпка решение на възникващите трудности.

Като в не типична конфигурация 1C за актуализиране.

Общи понятия

При актуализиране (update, английски) на нестандартна платформа, промените винаги засягат елементите на типичната конфигурация (configuration, английски) на доставчика.

Базата данни (DB) съдържа до три типа конфигурации:

самата база данни - с нея работят логически алгоритми;
работещ (т.нар. основен, ConfigOR) – който периодично променяме;
конфигурация на доставчика (ConfigP - на негова база се създава както работната, така и конфигурацията на базата данни от потребителя.

Ако програмата бъде премахната от поддръжката, тя вече няма да бъде от доставчика. Тогава обаче увеличението на разходите за труд за актуализиране е неизбежно. Помислете за актуализиране на нестандартна 1C конфигурация. Пример може да бъде платформата PPM (Manufacturing Enterprise Management).

Смесване

На първия етап трябва да премахнете разликите между работещите и предоставените конфигурации. Това ще намали оценката на подобренията, които сме въвели преди това. Несъответствията между тях възникват, когато по време на актуализацията са използвани външни файлове (не от предоставения комплект за разпространение) или методите за актуализация се различават от стандартните.

Сравнение на версиите

Проверяваме номерата на версиите (работещи и доставени). Първият се маркира в "Конфигурация" / "Отвори" / "Редактиране" / "Свойства". В секцията Разработка/Версия. Второ в "Конфигурация"/"Поддръжка"/"Настройки за поддръжка"/"Версия":

Ако числата съвпадат, можете да преминете към Получаване на файл чрез актуализация.

Следващите стъпки показват как да съпоставите операционната конфигурация и конфигурацията на доставчика. За да поставите на поддръжка онези обекти, които са премахнати или добавени от потребителя без поддръжка. За това:

Запазване на конфигурацията (работи)

Нека запазим ConfigOR във файл с име, например work.cf. За да направите това, изберете "Конфигурация" / "Запазване ...".

Получаване на файл на доставчика

За да съпоставите ConfigOR с ConfigP, имате нужда от cf файл от комплекта за разпространение на доставчика (от същата версия). По подразбиране ще бъде в C:/Program Files/1cv81/tmplts. Нека проверим наличието на необходимия cf-файл в таблицата с шаблони. Какво става, ако необходимият файл с конфигурационна версия на доставчика не съществува? След това трябва да създадете празна база данни от старата, да я актуализирате до необходимата версия и едва след това да я използвате.

Получаване на файл чрез актуализация

За да изпълните актуализацията на cf-файла ConfigP, в менюто се избира командата: “Конфигурация / Поддръжка / Актуализация ... / Избор на файл / Готово / Изпълнение” (Последователно на снимките):

За да го разрешите, трябва да премахнете отметката от обекта за изтриване в конфигурацията на доставчика. След това, след изтриване, извършваме сравнението отново - щракнете върху бутона „Актуализиране“ в прозореца за актуализиране.

Възстановяване на настройките

Някои от загубените настройки се възстановяват чрез сливане с предварително запазения файл work.cf. За да направите това, изберете „Конфигуриране / Сравняване, обединяване ... файл“.

Запазване и коригиране

За да запазите ConfigOR и да актуализирате базата данни, изберете „Update…DB“ в елемента от менюто „Configuration“. Тук срещаме нов проблем:

Най-вероятно причината за това е, че тези обекти са били копирани от ConfigP или са били изтрити от доставчика, а по-късно са добавени нови под същите имена. Въпреки това, с други идентификатори. В резултат се появиха обекти със същото име, но с различни идентификационни ключове.

Ролите могат просто да бъдат изтрити, тъй като не са променени. Реквизитът трябва да бъде преименуван, например, на OrderReserve1. И след актуализацията направете стойностите от преименуваната в създадената. Друг проблем с актуализацията. Ами формулярите?

От фигурата можете да видите, че ListForm е премахнат от доставчика и след това е добавен отново под същото име. Трябва да маркирате и двете за актуализиране и да щракнете върху „Изпълнение“.

Ако по време на актуализацията се издаде съобщение за наличието на връзки към обекти за изтриване, тогава, без да затваряте формуляра, трябва да изчистите връзките към него в свойствата на самите обекти. Ето го в регистъра имоти. След това във формуляра за актуализиране изберете опцията за актуализиране, маркирайте свойствата на регистъра за актуализиране сега и щракнете отново върху „Изпълни“.

Запазване на промените в работната и актуализиране на конфигурацията на базата данни: "Конфигурация / Актуализация ... DB". Прехвърлянето на стойността на атрибута OrderReserve1 към OrderReserve се извършва чрез външна обработка на режима 1C:Enterprise.

Подготовка на основата

Въз основа на резултатите от информацията изготвяме две идентични бази данни. Първият (основният) е желаният от нас резултат. Втората (спомагателна) е за извършване на подготвителни действия. В случай на файлова версия, ние просто ги копираме в директорията и ги свързваме към IB списъка, с опцията клиент-сървър ние правим качване/изтегляне.

Сравнение

След като отворим двете бази данни с конфигуратора, ще извършим тяхното тристранно сравнение. Използваме новия файл ConfigP за това - „Конфигурация / Поддръжка / Актуализация ... / Избор на файл ... / Готово":

Сравнението на работещите, старите и новите конфигурации на доставчика ни дава списък с променени обекти чрез филтъра „Показване на два пъти променени свойства“. С тях първо трябва да разрешите проблема:

В този момент работата със спомагателната база се преустановява до края на целия процес, бутонът „Изпълнение“ вече не се натиска. Продължаваме да работим в основната база данни с получения списък с два пъти променени обекти. Съгласието с актуализацията ще доведе до загуба на направените преди това подобрения. Затова за всеки един от обектите се изисква да се вземе решение - как ще бъде променен.

Ще направим предварителна оценка само за да намалим работата в бъдеще. Ако има повече промени в елемента в новия ConfigP, оставяме обекта доставчик. Поставяме отметка. Прехвърляне на промени от ConfigOR. Ако има още промени в елемента в работната конфигурация, оставяме екземпляр на обекта ConfigOR. Отстраняваме галата. Нека прехвърлим промените от ConfigP. Модулите трябва да се сравняват процедурно. За да направите това, натиснете бутона, както е на фигурата:

Поставете отметки в квадратчетата, за да посочите процедури и функции за замяна или изтриване:

Сега трябва да дублирате състоянието на квадратчетата за отметка в спомагателната база данни. В главния - щракнете върху "Изпълни". На този етап основно получаваме почти завършена конфигурация.

Последващите сравнения се извършват отново в спомагателната база данни. Намираме направените по-рано промени чрез допълнително сравнение на стария ConfigP с ConfigOR - "Конфигурация / Сравнение ...":

По подобен начин сравняваме стария ConfigP с новия. Ако няма нов файл, той вече може да бъде взет от основната база данни.

Така се получават два пъти променени обекти. В основната база данни е получена почти готова конфигурация. Трябва да се справи с два пъти променени елементи.

ВАЖНО. Когато анализира, потребителят трябва да се интересува не от причините за извършване на определени промени, а от техните последствия. Тоест основното е необходимостта от запазване на функционалността. Може би това ще изисква не прехвърляне на променени редове, а пълно преработване на кода за новия ConfigP.

За да вземете решение, е достатъчно да сравните формуляри, таблици и обектни модули. Понякога данните в отчетите са представени по такъв начин, че не ви позволява бързо да вземете решение. На тази стъпка се получава загуба на подобрения, ако промените засягат атрибутите на обекта от съставния тип.

В сравнителния отчет се дават различни данни под формата на списък, от който не става ясно какви типове данни са добавени/премахнати. Ако броят на редовете на отчета достигне двеста, тогава процесът на "ръчно" сравнение изглежда отнема доста време (около петдесет часа).

Намаляването на интензивността на труда се постига чрез използване например на конфигурацията "Сравнение на клетки" от компанията Inform Service. Той е достъпен за стартиране в режим 1C:Enterprise и представя сравнителни отчетни данни в удобна форма. Сравнението се извършва от възможностите на 1C:

Схемата на работа е проста. В конфигуратора се създава отчет за сравнителен обект. Записан във файл, например Comparison Report.mxl. В диалоговия прозорец на 1С:Предприятие се отваря и се посочват сравнените клетки (чрез двукратно щракване с десния бутон на мишката върху избраната клетка документ с електронна таблица). При натискане на "Сравнение" се дава резултатът от сравнението, като различните позиции се маркират с цвят.

Допълнителни инструкции за действие изглеждат така.

Следващият отчет се записва със същото име.
След приключване на актуализацията и прехвърляне на модификациите на стандартната конфигурация се извършва синтактичен контрол на модулите и тестване на работата на променените обекти.
След успешно тестване процесът може да се счита за завършен. Остава актуализиране на печатните форми, отчетите и обработката. В някои случаи проверете външни формуляри за докладване.

Работим с 1C 7.7

Надграждането на типична платформа до същата обикновено не създава затруднения. Просто следвайте указанията в инструкциите. Те се намират в UPDATE.TXT в директорията за разпространение.

Също така няма затруднения, ако към платформата се добавят допълнителни счетоводни елементи (директории, константи, селекции, отчети, регистри, дневници за изчисления и др.). Те ще паснат, когато платформите се комбинират. Добавените документи също няма да внесат дисхармония, ако не са настъпили промени в знаците за въвеждане „въз основа” на такива добавени документи.

Препоръчително е да стартирате актуализацията на бърз компютър с много RAM. С липсата си 1C може да откаже да изработи някои от функциите и да „замръзне“. Голямото количество виртуална памет не решава този проблем.

Създаване на архивно копие

За целта е необходимо да използвате опцията: „Администриране / Запазване на данни...“. Удобно е да посочите името на архива, като го съпоставите с датата на създаване (например YYMMDD.zip).

Изготвяне на каталог

За да работите, имате нужда от шест конфигурационни файла (1cv7.md):

"WorkingNew" за подготовка на актуализацията (резултатен md-файл);
"WorkingOld" за проследяване на промените при сравняване и за прехвърляне на настройки към TypeNew_2;
Типичен (стар) "TypeOld_1". На негова основа преди това е създаден работещ.
видове. (бивш) "TypeOld_2". Проследяване на промените в компанията 1C в новата стандартна версия;
Тип. (ново) "TypeNew_1". Подобрения на компанията 1C в новата версия;
"TypeNew_2" за сложни обекти.

И пет работещи конфигуратора (всички с изключение на „TypeNew_1“).

Първоначално директориите са идентични по двойки:

„Работно ново” и „Работещо старо”;
"TypeOld_1 и TypeOld_2";
„TypeNew_1“ и „TypeNew_2“.

Комбиниране на елементи

Първо сравняваме между 3 и 2, 4 и 5, 1 и 6. За да направите това, всеки от първите в двойката изберете елемента „Конфигурация / Асоциация ...“ и посочете файла с метаданни 1cv7.md на втори в двойката. На екрана ще се покаже форма с дърво с променени елементи. След това е необходимо да се анализират резултатите от сравнението по двойки на 3 с 2 и 4 с 5. Оставете за комбиниране на елементите в актуализираните платформи (1 и 6), в които има промени от 1C (4 от 5), но не са отразени в 3 и 2. 1 и 4 трябва да се комбинират в режим на отмяна.

други

Това включва сметкоплан и потребителски интерфейси. Ако има промени в сметкоплана, тогава той трябва да се актуализира в режим "Комбиниране на обекти" Работен нов заедно с Тип New_2. След обединяването на интерфейса той проверява за грешки: дублиране на елементи от менюто, дублиране на ленти с инструменти, задаване на знаци за ленти с инструменти „Местоположение от нов ред“.

Изтеглянето се извършва по мрежата или на сървър (за предпочитане). Първо, достъпът до базата данни се предоставя изключително. След това базата данни се зарежда през режима на конфигуратора. Преди и след изтеглянето данните се архивират (както е описано в самото начало на раздела). След това следвайте инструкциите във файла UPDATE.TXT. След като изтеглянето приключи, всички директории, с изключение на WorkingNew, могат да бъдат изтрити.

Надяваме се, че нашата публикация ви помогна да се справите с актуализирането на нестандартната конфигурация на 1C. Прегледахме това по отношение както на седмата, така и на осмата версия.

Оставете коментари, пишете за вашия опит в актуализирането на 1C.

Актуализирането на 1C се извършва чрез натискане на бутон "един", самата типична конфигурация може да изтегли актуализацията на 1C и да я инсталира. От потребителя ще се изисква само да въведе данни за регистрация.

Какво да направите, ако конфигурацията не е типична? Или типичен, но в него са направени подобрения - добавен е справочник, няколко подробности, отчет?

Отговорът на този въпрос ще разберем днес.

Какво е нетипична конфигурация 1C

Нетипична конфигурация 1C е, когато:

Конфигурацията е написана от нулата от програмиста
Конфигурацията беше типична, но бяха добавени промени към нея
Дори ако са добавили един реквизит.

За да направите промени в типичната конфигурация, трябва да .

При актуализиране на 1C нестандартна конфигурация, премахната от поддръжката, 1C ще предложи да „постави нестандартната конфигурация за поддръжка“ обратно. Тогава всички промени ще бъдат отменени (изтрити).

За да сте сигурни, че при актуализиране на 1C на нестандартна (променена) конфигурация на 1C промените остават и се прилага актуализацията на 1C, можете да използвате различен режим на актуализиране на 1C.

Нека да разгледаме пример за модифицирана конфигурация, която искаме да актуализираме. Това е типична конфигурация на 1C Accounting (вляво), която е изменена (вдясно):

4) В директорията "Лични лица", в модула за формуляри, във функцията ReadPlace of Birth() беше добавен ред на програмата

Как ще работят всички тези промени по време на актуализиране на 1C на нестандартна конфигурация на 1C?

Актуализиране на 1C със запазване на промените в нестандартната конфигурация на 1C

Актуализацията на конфигурацията на 1C обикновено се разпространява като саморазархивиращ се архив. След разопаковането трябва да стартирате инсталационния файл, за да инсталирате актуализацията на 1C на вашия компютър (не в 1C!).

Когато инсталирате актуализацията, вие избирате къде да бъде инсталирана актуализацията на 1C. Обикновено това. Можете да инсталирате във всяка друга папка на диска и 1C да посочи къде е .

Файловете за актуализиране на 1C могат да бъдат в следната форма:

файл с разширение CF - съдържа целия новият видконфигурация
файл с разширение CFU - съдържа само промени от предишната версия.

И двата файла се съхраняват в директорията за актуализиране на 1C, в папка с името на версията.

Бъдете внимателни, когато използвате CFU файла - той ви позволява да надграждате само от !

Така че, за да актуализирате 1C, изберете една от опциите на менюто:

Конфигурация/Сравнете обединяване с конфигурация от файл - за CF файлове
Конфигурация / Поддръжка / Актуализиране на конфигурация / Избор на файл за актуализиране на 1C - за CF или CFU файлове.

Първо, 1C ще сравни двете конфигурации. Конфигурацията на вашата база данни се нарича „Основна конфигурация“, а конфигурацията от актуализацията се нарича „Конфигурация от файл“.

1C ще покаже всички разлики под формата на познато дърво, където промените се показват вдясно.

Вижте - в нашия пример директориите, които са били променени или добавени, са маркирани.

Тъй като актуализираме нестандартната конфигурация на 1C, която е променена - тоест някога е била типична, трябва да въведете някои настройки.

Щракнете върху бутона Настройки. Изберете „Заредената конфигурация е потомък на основната“ (т.е. това е модифициран тип).

Квадратчето за отметка „Разрешаване на изтриване на основните конфигурационни обекти“ ви позволява да изтриете, ако са изтрити в актуализацията на 1C. Тъй като добавихме подробности и директории към конфигурацията, но те не са в актуализацията на 1C, 1C ще приеме, че са премахнати в актуализацията на 1C. Следователно не е необходимо да поставяте отметка в това поле.

Нека разгледаме по-отблизо разликите, открити от платформата.

Да отворим клона на справочника Номенклатура. В клона Requisites виждаме, че няма подпори в типичната конфигурация и го добавяме. Минус означава, че ще бъде премахнат.

Тъй като не се нуждаем от премахване на подпорите, които сме добавили сами, трябва да направим следното (опции):

В бутона "Настройки" НЕ ПОСТАВЯЙТЕ отметка в квадратчето "Разрешаване на изтриване на основните конфигурационни обекти"
Ако квадратчето все още е поставено, премахнете отметката от квадратчето срещу този атрибут. Няма отметка пред реквизита на снимката, тъй като изтриването на обекти не е разрешено.

Променена е и формата на Номенклатурния справочник. 1C видя това и ни показва формата на директорията също в списъка с променени обекти.

За да видите какви промени са направени във формуляра, можете да направите следното (опции):

Щракнете с десния бутон първо върху формуляра в лявата колона и изберете елемента от менюто "Отвори формуляр", а след това вдясно. Визуално сравнете двете форми.
Щракнете с десния бутон върху формуляра и изберете елемента от менюто „Отчет за сравнение на обекти“ (подробен, документ с електронна таблица)

Докладът за сравнение на обекти, когато сравнява формуляри, показва много разлики. Това се дължи на факта, че когато добавим само едно поле към формуляра, автоматично се променят много съседни елементи - отстъпи, обвързвания и т.н.

В списъка с промени виждаме нашите промени - промени в надписа и подмяна на полето.

Можем да се съгласим или да откажем промяната на формуляра, като поставим отметка в квадратчето до него. Това води до следните последствия:

а) ако поставим отметка в квадратчето

формулярът ще бъде заменен с нов
нашите промени в конфигурацията по подразбиране ще бъдат изтрити
промените от актуализацията 1C ще бъдат приложени
тогава ръчно ще е необходимо да върнем нашите промени

б) ако не поставим отметка

формулярът ще остане такъв, какъвто е
нашите промени остават
новите промени от актуализацията 1C не се прилагат
тогава ръчно ще е необходимо да добавите промени от актуализацията на 1C.

Можете да използвате третия вариант. Разгънете клона Form до края и в колоната „Режим на обединяване“ изберете „Обединяване“.

в) ако изберем "Комбинирай"

формата ще бъде някаква нова, в която ще има както нови промени, така и стари
нашите промени остават
появяват се нови промени
ако едно поле е изтрито и на негово място е поставено друго, в резултат на сливането и двете полета ще бъдат на едно място едновременно - и старото, и новото
шансовете са, че формата ще изглежда добре
след това ръчно трябва да проверите дали няма "излишъци"

2) В директорията "Лични лица", в модула формуляр, във функцията ReadPlace of Birth() е добавен ред на програмата

За да видите промените в модула на формуляра, открит от 1C, разгънете клона на формуляра до края, щракнете с десния бутон върху него, изберете елемента от менюто „Показване на разликите в модулите“.

Промените се показват в контекста на всяка функция, но с този режим на преглед можете или да изберете да актуализирате 1C на целия модул, или да го откажете.

Друг начин е да използвате бутона за лупа на този ред.

Тогава не само ще видим промените в контекста на всяка функция, но можем също да използваме квадратчетата за отметка, за да изберем коя функция искаме да актуализираме и коя не.

3) В директория "Електронни представителства .." премахнати няколко подробности

1C установи, че сме изтрили детайлите на стандартната директория и ни предлага да ги възстановим.

Директорията, която добавихме, 1C предлага изтриване. В този случай важи същото правило, както в случая с добавения от нас атрибут (вижте по-рано).

Така че нашата задача е внимателно да проучим промените, открити от 1C, и с помощта на квадратчетата за отметка да се съгласим с тях или да откажем. След това щракнете върху бутона Изпълнение.

Моля, обърнете внимание, че ако сте изтрили атрибута в резултат на актуализиране на 1C, тогава сте изтрили и данните, въведени в него от потребителите, което означава, че добавянето на същия атрибут отново няма да възстанови тези данни.

Ако в конфигурацията има няколко свързани обекта - например атрибут и форма; в същото време разрешихте актуализиране на формуляра 1C, но не отметнахте подпорите, тогава възниква противоречие.

След като натиснете бутона Run, 1C намира такива ситуации и докладва за тях.

След като щракнете върху бутона Run, имате още една възможност да помислите.

За да потвърдите актуализацията на 1C, трябва да изберете елемента от менюто Конфигурация / Актуализиране на конфигурацията на базата данни.

За да откажете да актуализирате 1C, трябва да изберете елемента от менюто Конфигурация / Връщане към конфигурацията на базата данни.

Третата опция (посочена е последователността от елементи от менюто):

Изберете File/Save
Конфигурация/Запазване на конфигурацията във файл
Конфигурация/Конфигурация на база данни/Връщане към конфигурация на база данни.

Така разтоварвате получената обединена конфигурация във файл и отказвате промените. Можете да анализирате получената конфигурация, да правите ръчни промени и по-късно просто да я заредите с помощта на менюто Конфигурация/Зареждане на конфигурация от файл.

Има много инструкции за актуализиране на променените типични конфигурации на платформата 1C. Ето защо, за да не увеличавам същността, няма да описвам напълно целия процес. В допълнение - предполага се, че този текст е за човек, който вече е обновил променените конфигурации и знае основните моменти и "подводни камъни". Този методсамо опростява този процес, като по същество предлага използването на автоматизирано сравнение на промените в конфигурацията и промените в модулите на ниво сравнение на текстови файлове. С този подход вероятността от грешки („пренаписване“ от актуализацията на важни промени поради невнимание), свързани с „човешкия фактор“, е значително намалена.

ВСЯКА актуализация на конфигурацията започва с разтоварване на IB. Това е "златното правило", това винаги трябва да се помни, това трябва да се направи с всеки метод (дори ако са забравили да го споменат там). След това можете да отидете по два начина: или актуализиране в тестовата база данни, или актуализиране в работната база данни. Тук важното е следното: обикновено променените конфигурации не се актуализират за всяка версия (както лесно може да се направи със стандартните), а за няколко наведнъж, тъй като този процес е трудоемък. При първия метод (актуализация на тестова база) окончателното прехвърляне на актуализацията към работната база се предполага чрез зареждане на cf файл. В този случай могат да възникнат грешки, свързани с изтрити детайли (може да се намерят много статии за това). Така че - има някои рискове, но по време на актуализацията (която може да отнеме цял ден или дори повече), потребителите могат безопасно да работят, променяйки базата данни. При втория начин (актуализация на работеща база данни) тези рискове са изключени, но ключови потребители няма да могат да работят в тази база данни през цялото времетраене на актуализацията. Във форумите има достатъчно дискусии за това кой метод е добър и дали си струва да прехвърлите актуализацията през конфигурационния файл. Мога само да кажа: въз основа на опита от работата по първия метод, подобни грешкине се случи при зареждане на cf файла. Във всеки случай можете да възстановите базата данни с помощта на резервно копие. Това е първият метод, който ще бъде разгледан тук, но това не засяга същността на метода и, ако желаете, можете да действате според втория метод, като използвате предложения метод.

И така - след като разположихме тестовата база на ново архивиране, ние правим последователни актуализации на версиите до най-новата. След всяка версия стартираме „Debug“, за да запазим промените в конфигурацията и да реорганизираме данните. Във всички диалогови прозорци щракнете върху OK / Следващ / Приемам / Да / Продължи ...

По този начин актуализирахме конфигурацията на тестовата база до най-новата версия, но трябва да проверим дали сме презаписали промени и ако сме ги презаписали, тогава трябва да ги прехвърлим в тази версия. Сега започва забавлението, така че ще го опиша стъпка по стъпка. Всяка стъпка ще бъде с някакво обяснение: тоест първо се описва същността и след това повече Подробно описание. Ако същността е ясна, тогава описанието може да бъде пропуснато.

1. Ние запазваме промените в конфигурацията ПРЕДИ и СЛЕД актуализацията в текстови файлове.Отворете работните и тестовите бази в режим Конфигуратор. Отворете техните конфигурации. И в двете бази данни започваме да обработваме сравнението на конфигурацията („Конфигурация – Сравнете конфигурации ...“). ВАЖНО: и в двете бази данни изберете конфигурации по същия начин:

Освен това го записваме по следния начин: в работната база данни (където конфигурацията е ПРЕДИ актуализацията) - във файл с окончание "стар", а в тестовата база данни (където конфигурацията е СЛЕД актуализацията) - във файл с окончание "ново".

2. Правене на загубени промени в актуализирана конфигурация. Преминаваме към ключовия етап на метода. Тъй като това е основната точка, тогава за малко обяснение на случващото се, малко от математическата част. На платформата 1C 7.7 файлът за актуализация беше пълна конфигурация. А актуализацията в 1C 7.7 се състоеше в зареждане на нова конфигурация и реорганизиране на базата данни за тази конфигурация. Така че и конфигурацията, и актуализацията бяха по същество един и същ md файл. За разлика от платформата 1C 7.7, на платформата 1C 8.x: конфигурацията се предава чрез cf файла, а актуализацията се предава чрез cfu файла. Разликата между тези файлове е, че cf файлът съдържа всички конфигурационни обекти, а cfu файлът съдържа само тези, които са променени от тази актуализация. И по този начин, когато се актуализира на платформата 1C 8.x, се засягат само онези конфигурационни обекти, които действително са променени в новата версия. В резултат на това, ако такъв обект е бил променен от нас, след актуализацията той ще бъде напълно заменен със стандартен и ще трябва да повторим в него промените, които е имал преди актуализацията, така че този обект да съдържа както нашите промените и промените на новата версия едновременно. Но ако конфигурационният обект, който сме променили, не е бил засегнат от актуализацията, нашите промени ще останат в него след актуализацията. За да бъде по-лесно да се разбере това, ще го изобразя под формата на диаграма:

Тази диаграма показва някои типични конфигурации в процеса на промяна и надграждане. Редовете са неговите обекти (документи, директории, обработки и т.н.). Първият (с номер I) е само типична конфигурация: всички обекти без никакви промени. След това под номер II вече виждаме типична променена конфигурация: някои обекти са променени и тези променени обекти са маркирани в червено. Номер III е друга актуализация за типична конфигурация: всъщност тя съдържа само обектите, засегнати от промените в новата версия, които са маркирани в зелено, но за по-голяма яснота приключих с чертането на всички останали обекти. И трябва да получим актуализирана типична конфигурация (изобразена на диаграма I), но с промени както в диаграма II, така и в диаграма III. На този пример- тази крайна конфигурация е изобразена като номер IV и съдържа един обект, който е променен както от нас, така и от актуализацията. Останалите обекти, които променихме, очевидно останаха незасегнати от тази актуализация. Сега въпросът е: как да направим ВСИЧКИ наши промени в обекта, който е бил засегнат от актуализацията? Очевидно е, че трябва да направим две стъпки: първо, да намерим този обект и второ, да намерим местата в него, където трябва да бъдат нашите промени, и да ги направим отново. Отбелязвам, че, разбира се, може да има няколко такива обекта и е необходимо всички да бъдат намерени и коригирани. И така, нека продължим към този последен етап от актуализацията. В момента трябва да имаме отворена тестова база данни в режим на конфигуратор. Ако резултатът от обработката на сравнението на конфигурацията или някакъв друг прозорец все още е отворен там, ние ще ги затворим всички, за да не се объркаме. След това отваряме работната база данни в режим на конфигуратор (възможно е да я затворим по време на актуализирането на тестовата база данни) и изпълняваме сравнение на конфигурацията там. И ще поставя описанието на последните две стъпки (намиране и коригиране) в отделни подпараграфи:

2.1. Търсене на обект с презаписани промени. Време е да си припомним за txt файловете със стари/нови окончания. Всъщност тези файлове отразяват всички промени в конфигурацията (спрямо типичните) ПРЕДИ и СЛЕД актуализацията, съответно. По този начин, ако презапишем някаква промяна с актуализация, тя ще бъде само във файла "ReportComparison_old.txt". Тоест търсенето на необходимите конфигурационни обекти се свежда до сравняване на тези два файла. Ще сравним тези файлове с помощта на файлов мениджър Total Commanderи неговите вградени инструменти. Мисля, че няма нужда да обяснявам тук какво е Total Commander, къде да го вземете и как да го използвате ... Въпреки това ще опиша накратко необходимите етапи от прилагането му тук. И така, стартираме Total Commander. Ако езикът на интерфейса е английски (главно меню и т.н.), тогава можете да го промените на руски: „Конфигурация - Опции ...“, в диалоговия прозорец изберете секцията „Език“ в лявата колона, потърсете / изберете „Руски (руски)“ в списъка и щракнете върху „OK“. След това чрез Total Commander търсим txt файлове с отчети, избираме ги („Вмъкване“ или „щракване с десния бутон“) и започваме сравнение на файлове: „Файлове - Сравнете по съдържание ...“ (в Английски интерфейс: „Файлове – Сравнете по съдържание...“). В прозореца, който се отваря, съдържанието на файловете се показва отляво / отдясно, съответно бутоните "Следваща разлика" / "Предишна разлика" ви позволяват да търсите разлики. Този инструмент ще ви позволи бързо да намерите обектите, които ни интересуват.

Коментирайте: може да се случи и обратната ситуация - да се появят разлики в конфигурацията СЛЕД актуализацията, които ги нямаше ПРЕДИ актуализацията. Това означава, че изданието на актуализацията премахна съответните обекти от конфигурацията. По принцип тези обекти могат просто да бъдат пропуснати в нашите корекции, тъй като няма промени в тези обекти.

2.2. Извършване на промени в актуализирани обекти.След като намерим обект с презаписани промени, трябва да определим къде точно са били тези промени: в модула (текст на програмата), диалогов прозорец (на формуляра) или други настройки. Тук ще отделя два случая: промяна в модул и всички други промени. Нека разгледаме тези два случая поотделно.

2.2.1. Промените, презаписани от актуализацията, бяха в модула.Всъщност това е основният случай (това се случва много по-често) и този случай е само в нашия пример: промяната е изтрита в модул "Отчитане на ДДС". Както вече споменахме по-горе, в конфигуратора на работната база имаме отворен прозорец за сравнение на конфигурацията. Там търсим обекта, който ни трябва. Всъщност неговата позиция в дървото на конфигурацията е описана в нашия текстов файл, а именно: "GeneralModule.VAT accounting.Module". Точно това търсим в прозореца за сравнение. Разширяваме дървото на подчинение, докато намерим необходимия модул - в левия край срещу него трябва да има зелен молив, което показва, че обектът е променен в сравнение с конфигурацията на доставчика. На намерения ред щракнете с десния бутон и изберете „Показване на разликите в модулите ...“:

След това ще се отвори прозорецът за сравнение на модулите:

Тук на върха са процедурии функции, в които има промени (в нашия случай това е една процедура „Показване на фактура към табличен документ“), а в долната част – текстовете на избраната процедура или функция с маркираните промени. Трябва да прехвърлим тези промени в нашата тестова база. Но не премахва промените от актуализацията. Можете да автоматизирате това по следния начин. Поставяме курсора в долната лява част (където е текстът на избраната процедура с нашите промени) и натискаме последователно Ctrl + A (избиране на всички) и Ctrl + C (копиране на селекцията в клипборда). След това създаваме файл с условното име "old_izm.txt", отваряме го текстов редактори натиснете Ctrl + V (поставете съдържанието на клипборда). Правим същото за долната дясна част (където текстът на избраната процедура е от типичната конфигурация на неактуализираната версия) - в резултат на това създаваме файл с условно име "old_type.txt". След това отидете на конфигуратора на тестовата база (трябва да е отворен наблизо, но без никакви прозорци вътре, за да не се объркате в тези два конфигуратора) - и в конфигурацията търсим нашия модул (в този пример той е „GeneralModule.VAT Accounting.Module“) и необходимата процедура в него (в този пример това е „OutputInvoiceIntoSpreadsheetDocument“): изберете всичко и го копирайте в нов текстов файлс условно име "new_type.txt". Така имаме три файла ("old_izm.txt", "old_type.txt", "new_type.txt"), на базата на които трябва да създадем четвъртия файл - "new_izm.txt". Този четвърти файл трябва да съдържа само нашите промени, но като вземе предвид актуализацията. Ще го формираме последователно като сравним наличните три файла. Като начало, нека определим дали има следи от промени в актуализацията в тази процедура? За да направим това, сравняваме чрез Total Commander (вижте по-горе) файла "old_type.txt" и "new_type.txt". Ако сравнението показа, че файловете са идентични или разликата в броя на интервалите или разделите - това означава, че имаме късмет с тази част от промените и можете да прехвърлите промените просто като копирате съдържанието на файла "old_izm.txt" и поставяйки го в отворения тестов базов модул, изтривайки съответната процедура преди това (с други думи - замествайки го). Тук е важно внимателно да наблюдавате пространствата преди и след процедурата, така че да няма излишни при по-нататъшното сравнение: това, разбира се, няма да повлияе на функционалността, но леко ще усложни проверката. Ако сравнението на "old_type.txt" и "new_type.txt" показа, че има реални разлики - това означава, че в тази процедура има както наши промени, така и актуализирани промени. За да опростите задачата за прехвърляне: първо, можете визуално да прецените кои промени са повече - от актуализацията или нашите. За да направим това, отново чрез Total Commander ние последователно сравняваме "old_type.txt" с "new_type.txt" и "old_izm.txt". И гледаме къде има повече промени: в сравнението на "old_type.txt" и "new_type.txt" или в сравнението на "old_type.txt" и "old_izm.txt". Ако има повече промени в първото сравнение (актуализацията промени функцията повече), тогава е по-лесно да коригираме актуализирания файл, като направим нашите промени, тоест променяме "new_type.txt". Условно ще наречем това първи случай на извършване на промени. Ако има повече промени във второто сравнение (имахме повече промени), тогава е по-лесно да поправим нашия файл, като направим актуализиращи промени, тоест променяме "old_izm.txt". Условно ще наречем този втори случай на извършване на промени. Сега как точно да прехвърлите промените бързо и точно. За целта създаваме четвърти файл и, както вече се договорихме, го наричаме "new_izm.txt". Като се има предвид оптимизирането на прехвърлянето на корекции, ние копираме съдържанието на "new_type.txt" или "old_izm.txt" в този файл (съответно за първия или втория случай на извършване на промени).
Сега отваряме два прозореца за сравнение на файлове наведнъж. За първия случай на извършване на промени, това са сравнения за файловете "new_izm.txt"/"old_izm.txt" и "old_type.txt"/"old_izm.txt". За втория случай това са сравнения на файловете "new_izm.txt"/"new_type.txt" и "old_type.txt"/"new_type.txt". В прозореца за сравнение има бутон "Редактиране": натиснете го при сравнението на първата двойка. Сега нека обясним какво виждаме. В първата двойка сравнение обектите са видими както от нашата промяна, така и от актуализацията. В съответствие с нашия случай трябва да прехвърлим само нашите промени или само актуализации. Във втория прозорец за сравнение се виждат само тези промени, които трябва да прехвърлим. Ако обърнете внимание - и в двата случая вторият файл и на първото, и на второто сравнение е един и същ. Следователно ние се ръководим от редовете в този файл и от редовете във второто сравнение, правим промени в прозореца на първото сравнение: натиснатият бутон "Редактиране" просто ще ни позволи да направим това.

За "яснота" нека изобразим графично действията по време на прехвърлянето в първия случай (ние променяме актуализирания файл, като правим нашите промени):

Действията във втория случай са абсолютно подобни и принципът на действие е абсолютно същият.

Най-трудният и неприятен случай е, когато нашите промени и ъпдейт промени са на ЕДНО място. Тоест всъщност имаше две промени в един сегмент от кода. В този случай е необходима намесата на програмиста. Също така, намесата на програмиста, но в по-малка степен, е необходима, ако например актуализацията промени имената на променливите, които се използват в нашите промени. Също така си струва да се отбележи, че във файла "old_type.txt" или "old_izm.txt" може да има празни редове - това са "следите" на нашите промени. Необходимо е да ги прехвърлите, за да не са във финалния файл. Това не засяга функционалността, но при по-нататъшни сравнения (с последващи актуализации) ще направи малко по-трудно анализирането на действията. И така, след като сме генерирали четвъртия файл, след като сме прехвърлили всички промени, трябва да копираме съдържанието му в конфигурацията. В конфигуратора на тестовата база данни необходимият модул трябва да се отвори на ново място: изтрийте съществуващата процедура и поставете съдържанието на нашия окончателен файл, като вземете предвид всички интервали между предишните / следващите функции. Така прехвърлихме промените в ЕДНА процедура на намерения обект. Имаме (фиг. 6) тази процедура е наистина една. Ако има няколко такива процедури, описаните действия трябва да се извършат за всяка. Ако процедурата е нова (само в лявата половина), просто я добавете към съответния модул в тестовата база (за коректността на по-нататъшното сравнение трябва да запазите реда на процедурите, както в съответния модул на работна база, където все още има стара версия).

2.2.2. Промените, презаписани от актуализацията, НЕ бяха в модула.За да прехвърлите такива промени, такова сравнение няма да опрости работата по никакъв начин, следователно промените се прехвърлят просто чрез визуално сравнение на обекти в работните и тестовите бази данни.

По този начин прехвърляме промените за всеки обект, където нашите промени са били презаписани от актуализацията. За да проверим колко правилно сме прехвърлили всички промени, запазваме конфигурацията в тестовата база данни, качваме сравнението на конфигурацията във файла "Comparison Report_new2.txt" и го сравняваме с файла "Comparison Report_old.txt". Ако всичко е идеално, тогава ще се покаже съобщението "Файловете са идентични". Ако някои обекти са били изтрити от актуализацията, само тези обекти в разликата ще бъдат видими, ако промените са прехвърлени правилно. Ще бъде правилно, ако в сравнението се виждат само интервали / празни редове / раздели, но в този случай е по-добре да го изчистите и да постигнете съобщението „Файловете са идентични“. Така, след като запазим промените в тестовата база, качваме сравнението във файл и го сравняваме с промените в старата версия - повтаряме това, докато сравнението покаже, че сме прехвърлили всички необходими промени.

3. Прехвърляне на актуализираната конфигурация от тестовата база данни към производствената база данни. На предишните етапи актуализирахме тестовата база данни до най-новата версия, проверихме и мигрирахме необходимите промени и запазихме получената конфигурация. Сега го разтоварваме в cf файл и го зареждаме в работещата база данни. Преди изтегляне - трябва да направите копие на работещата база данни и да премахнете конфигурацията от поддръжката. ВСИЧКО. Потребителите "бездействат" само в началото, когато разтоварихме базата и в края, когато отново разтоварихме базата и заредихме конфигурацията.

Това завършва актуализацията.

Оригиналната статия е на уебсайта

Нестандартна конфигурация 1C е, когато: 1) конфигурацията 1C е написана от нулата от самия програмист, 2) конфигурацията 1C е типична, но към нея са добавени промени, дори ако е добавен един атрибут.

В тази статия ще разгледаме как правилно да актуализираме конфигурациите на 1C, както и няколко трика за мека промяна на типичните конфигурации, т.е. правилна промяна, която няма да повлияе на възможността за надграждане по-късно.

За да направите промени в типичната конфигурация на 1C, е необходимо да отключите промяната в типичната конфигурация на 1C и в някои случаи да я „премахнете от поддръжката“.

В най-оптималната опция за актуализиране конфигурацията на 1C може да се актуализира изцяло автоматичен режим, това е възможно, когато промените в конфигурацията са деактивирани. Доста често се налага да се включи промяна на конфигурацията, тъй като е необходимо да се адаптират приложните решения към бизнес изискванията на клиента и ние ще се спрем на тази опция.

Преди актуализиране силно препоръчително да се направи архивиране база данни, това може да стане през меню Администриране / Качване на информационна база.

Има 2 опции за актуализиране: а) Актуализация на 1C чрез поддръжка (обадете се през диалоговия прозорец Конфигурация / Поддръжка / Актуализиране на конфигурацията) и б) чрез Сравнение и обединяване с конфигурацията от файл. Трябва да се плати Специално вниманиече разликата между тези две точки е, че в първия случай се актуализират и основната конфигурация, и конфигурацията на доставчика, а при сравняване на сливането на конфигурации се актуализира само основната конфигурация, конфигурацията на доставчика остава старата. Следователно най-препоръчителната опция е да актуализирате чрез Update Configuration. За актуализиране чрез поддръжка на конфигурация се използват CF или CFU файлове за разпространение на доставчика, които могат да бъдат намерени чрез търсене в директорията с шаблони, като посочите пътя в Интернет или директно посочите пътя до желания файлна твърдия диск.

Когато актуализирате конфигурацията на 1C без възможност за извършване на промени, актуализацията след избиране на файла за актуализация се извършва автоматично, ако конфигурацията е активирана за извършване на промени, след като изберете файла за актуализация, ще се покаже прозорец за сравнение на конфигурацията. В този диалогов прозорец можем да видим как системата ни подканва да актуализираме нашата нестандартна 1C конфигурация. В долната част на диалоговия прозорец има съответна легенда за статусите на обекти: „Статуси по съответствия на обекти“ означава сравнение на „Основна конфигурация“ и „Нова конфигурация“, „Статуси по история на обекти“ означава сравнение на обекти на конфигурация с обекти " стара конфигурациядоставчик“.

Като поставите отметки в квадратчетата до обектите, можете да изберете дали текущият конфигурационен обект да се промени или да остане старият, както и метода за промяна на обекта. В менюто за действие е възможно да поставите отметка в квадратчетата за подсистеми (това е полезно, ако конфигурацията се поддържа от няколко доставчици). Също така в това меню е възможно да се посочи приоритетът на сливане за всички обекти наведнъж; по подразбиране системата счита конфигурацията на доставчика за по-висок приоритет. Настройките на филтъра ви позволяват да посочите кои конфигурационни обекти да покажем, за да можем да посочим подробно режима на сливане. Има няколко стандартни шаблона за филтриране и можете да посочите филтри за всяка двойка конфигурации, които сравнявате. Възможно е да поставите отметка в квадратчето „Показване само на два пъти променени свойства“ в настройките на „Филтър“, това ще ви позволи да филтрирате обекти, при чието актуализиране не е имало конфликти между промените на доставчика и модификациите на тези обекти:

Така че резултатът ще бъде списък с обекти, които са били променени два пъти при прецизиране на типичната конфигурация и в новата конфигурация на доставчика. Ако сте съгласни с актуализацията, подобренията, направени по-рано в тези обекти, ще бъдат загубени. Затова за всеки обект трябва да се вземе решение как ще се актуализира. На този етап трябва да се извърши предварително сравнение единствено с цел по-късно да се намали количеството работа. Оценката не е точна бързо - "на око". Ако има повече промени в обекта в новата конфигурация на доставчика, тогава оставяме екземпляра на обекта на доставчика. Оставяме отметка. След това ще трябва да прехвърлите промените от работната конфигурация. Ако има повече промени в обекта в работната конфигурация, тогава оставяме екземпляр на работния конфигурационен обект. Премахваме отметката от квадратчето. След това ще трябва да мигрирате промените от конфигурацията на доставчика. С модулите можете да направите малко по-различно, защото. възможно е модулите да се сравняват процедурно.

Тези. в случай, че различни модулни процедури са променени в нашата конфигурация на 1C и в конфигурацията на доставчика, тогава, като поставим правилно квадратчетата за отметка, ще се спасим от ръчно прехвърляне на промени в кода. За да стигнете до това, трябва да щракнете върху бутона под формата на лупа до името на режима на комбиниране на модули:

При показване на меню с действия върху обект (например чрез натискане десен бутонмишка), можем да извикаме отчета за сравнение на обекти.

Няколко правила, които опростяват бъдещата актуализация на конфигурациите на 1C:

Основното правило за актуализиране на 1C: трябва да добавите нови обекти, защото. при актуализиране новите обекти не се влияят от системата

При промяна на текстовете на модулите също е желателно да добавите свои нови процедури и функции и да извикате новите си от съществуващите.

Използвайки абонаменти за събития, благодарение на това можете да прецизирате типичните механизми, без да променяте типичния код

Използване на типичната функционалност за конфигурация

Програмно създаване на елементи на формуляр (в събитието OnFormCreateOnServer)

Благодаря ти!

Личен опит: как бързо и рентабилно да актуализирате променена конфигурация

Актуализирането на конфигурацията за няколко версии наведнъж е много опасно. Въпросът е, че след всяка актуализация на конфигурацията, актуализацията на информационната база се стартира в режим 1C:Enterprise. Следователно, ако актуализирате само последната версия, информационните бази може да не съвпадат последна конфигурация. В статията Дмитрий Рудаков, специалист от ЗАО Сибирска аграрна група, споделя своя личен опит в еднократна актуализация на конфигурацията за 12 версии.

Проверка на режима за промяна на конфигурацията

Нека си представим такава ситуация. Разработчиците на „Управление на производствено предприятие“ (наричано по-нататък PPM) във версия 1 (номерата на версиите са присвоени по-долу условно) на измерването (индикатор) на регистъра за изчисление, те присвоиха типа „DirectoryReference.Individual“ с името „ Индивидуален". Във версия 2 добавиха още едно измерение - "Служител" с тип "ReferenceReference.Employees". При стартиране на 1C:Enterprise е активирана обработка, която попълва измерението "Служител" по същия начин като измерението "Индивидуално лице". И тогава във версия 3 разработчиците на "1C" премахнаха измерението "Индивидуално" и оставиха само "Служител". Ако актуализирате конфигурацията от версия 1 незабавно до версия 3, можете да изчистите целия регистър на изчисленията.

И ако конфигурацията се поддържа с възможност за промяна и регулираното отчитане се генерира в същата база данни, тогава е необходимо да се актуализира конфигурацията за всяко издание, което може да бъде много скъпо по отношение на човекочасове. Например, актуализирането на силно модифициран "SCP" за 1 версия може да отнеме 30 часа работно време на опитен специалист.

Следователно, преди да продължите с актуализацията, трябва да определите: работите ли в типична конфигурация с възможност за промяна или в конфигурация без възможност за промяна? За да направите това, отидете в конфигуратора, където в менюто следвайте стъпките "Конфигурация - Поддръжка - Настройки за поддръжка".

Фиг. 1. Извикване на прозореца за настройка на поддръжката на конфигурацията

Ако е настроено на "При поддръжка", тогава тази конфигурация е типична, а ако "Променлива е активирана" - конфигурацията най-вероятно е променена (поне такава възможност е включена). Третото състояние е „Конфигурацията е отхвърлена“. Различните състояния на конфигурация са показани на фигури 2, 3, 4.

Ориз. 2. Типова конфигурация без възможност за промени

Ориз. 3. Типична конфигурация с активирана промяна

Ориз. 4. Конфигурацията е премахната от поддръжката

Алгоритъм за актуализиране на променени конфигурации

Наскоро се сблъсках със задачата да актуализирам променената конфигурация "Trade Management", версия 10.3.13.2. Конфигурацията е променена в резултат на сливането с индустриалното решение "BIT: Car Service Management 8" и е непрекъснато усъвършенствана в продължение на две години. Сега конфигурацията трябваше да бъде актуализирана до версия 10.3.25.1, тоест 12 версии. Разделих цялата процедура за актуализиране на няколко стъпки.

Етап 1. Оценка на разходите и графика на процедурата за подновяване

Преди да започна самостоятелна работа, реших да получа независима оценка от експерти в тази област. Единствената компания, която има възможност да актуализира променените конфигурации чрез автоматизирани методи, е 1C-IzhTiSi LLC. Свързах се със специалистите на тази компания с молба за оценка на разходите за актуализиране на моята конфигурация. За да преценя времето и цената на работата, предоставих текуща конфигурациянуждаещи се от актуализиране. Ден по-късно получих имейл с доклад.

Доклад за резултатите от оценката на разходите и времето на актуализацията на конфигурацията:

Конфигурация: Управление на търговията Ревизия 10.3
Сегашна версияконфигурация: 10.3.13.2
Актуализация до версия: 10.3.25.1
Брой надграждащи се модули: 1847
Брой контролни освобождавания: 8

Резултатите от оценката ме изненадаха, тъй като цената на акция беше посочена на уебсайта на компанията - 1000 рубли. за една актуализация на изданието. Коментар "1C-IzhTiSi":

„Цената на актуализиране за всяко пропуснато издание не е по-висока от 2000 рубли. Сега има промоция, така че цената не надвишава 1000 рубли. Но крайната цена на услугите се определя от резултатите от оценката на разходите за труд за актуализиране и може да бъде под 1000 рубли / издание."

Също така изясних как са избрани версиите, необходими за актуализацията. В отговор на въпроса ми получих скрийншот, на който това беше ясно демонстрирано (фиг. 5). Колоната Номер на версията показва версията на конфигурацията, до която искате да надстроите. Колоната „Версия за надстройка“ показва от коя версия можете да надстроите. В резултат на оценката броят на необходимите актуализации беше намален на 9.

Ориз. 5. Избор на версии, които трябва да се използват за правилно актуализиране на конфигурацията

След като проучих отчета 1C-IzhTiSi, изчислих личното време, изразходвано за същото количество работа. Всяка процедура за актуализиране ми отнема приблизително 6 часа. Следователно общото изразходвано време е 56 (9x6) работни часа, тоест приблизително седем работни дни. Освен това има вероятност след актуализацията да се разкрият някои недостатъци: например потребителят ще се оплаче, че промените в конфигурацията, от които се нуждае, са загубени и тогава разходите за време ще се увеличат сериозно. Междувременно специалистите на компанията "1C-IzhTiSi" предлагат да извършат целия обем работа за три до четири работни дни. Затова реших да използвам техните услуги.

Сега ще обясня накратко какво точно е променено в конфигурацията.

Силно модифицирани обекти.Това са обекти, в които са променени много типични свойства. Корекциите са сложни. Добавени са подробности за обекта таблична част, показани във формуляра за обекти и във формуляра за списък. Добавени манипулатори за добавени подробности във формуляри. Типичният механизъм за осчетоводяване на документ или записване на набор от движения за регистъра е променен.

Силно модифицирани документи:
„Поръчка към доставчика“;
„Движение на стоки”;
"Изискване-фактура";
„Получаване на стоки и услуги“.

Силно модифицирани регистри:
„Пратки стоки в складове”;
"Стоки в складове".

Значително модифицирани обекти.Обекти, в които са добавени детайли, променени са или формите на обектите, или модулите на обекта (по правило документът не се въвежда).
Документ „Входящ касов ордер”;
Регистър на информация "Номенклатура на компонентите";
Регистър на информация "Отписани стоки";
Общи модули.

Леко променени обекти.В обектите са променени само формите и добавени детайли.

Справочници:
„Видове номенклатура”;
„Договори на контрагенти“;
„Изпълнители”;
"Номенклатура";
„Номенклатурни видове цени”;
„Редица информационни регистри”.

Променени абонаменти за събития, оформления, роли, общи модули в раздела „Общи“. Почти всичко е променено с решение на индустрията.

Етап 2. Премахване на поверителна информация

Преди да предоставите на служителите на 1C-IzhTiSi информационна база за тестване, е необходимо да изтриете поверителна информация в нея. За такива случаи 1C препоръчва използването на обработката „Промяна на поверителна информация“, която не е много широко известна.

Обработка "Промяна на поверителна информация" е предназначена за селективна промяна или почистване на информация в информационната база.Обработката може да се използва за приготвяне информационна базапреди преминаване за тестване, където е необходимо да се скрие (изчисти, промени) някаква информация.

Обработването на ChangePrivateInformation.epf е на ITS диска в директорията 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Също тази обработкаможете да изтеглите от връзката: http://its.1c.ru/db/metod81#content:1644:1.

Естествено, поверителната информация във всяка компания е различна, но обръщам внимание на данните, които най-вероятно трябва да бъдат променени:

Справочници: Физически лица, Лица за контакт, Лица за контакт на контрагенти, Контрагенти, Видове цени.
Информационни регистри: Паспортни данни индивидуален, пълно име

Вашият списък вероятно ще бъде по-дълъг, но това са най-често срещаните данни. Промяната им е малко вероятно да повлияе на способността да тествате вашата информационна база. Можете също така да изтриете всички тези обекти, с които обслужващата компания не трябва да работи чрез групова обработка.

Етап 3. Вземете резултатите от актуализацията

Три дни по-късно ми бяха предоставени cf файлове и изчерпателни инструкции за инсталирането им. За контролни издания се предоставят cf файлове, които не могат да се използват за работа на потребителите, тъй като в тях са актуализирани само метаданни. Те са предназначени само за правилно надграждане до най-новата версия.

Според резултата от извършената работа мога да кажа, че всички промени в конфигурацията бяха запазени; по време на визуален преглед всички обекти, които бяха променени, запазиха своите характеристики и разлики от типичната конфигурация. По време на работа никой от потребителите не съобщи за загуба на промени.

В резултат на актуализацията идентифицирах две малки задачи за независимо решение.

Първо. Поради факта, че актуализацията се извършва с помощта на механизма „Сравняване, обединяване“, конфигурацията на базата данни е наистина актуализирана и актуализирана правилно, без технически рискове поради контролните версии. Конфигурацията на доставчика обаче не се актуализира. Разбира се, технически компетентен специалист лесно ще добави тази работа, обаче помолих "1С-ИжТиСи" да изпрати още пълни инструкциичрез актуализация. В съответствие с него дори неопитен специалист може да актуализира.

Второ. В резултат на актуализацията всички обекти остават поддържани с възможност за промяна, което също може да бъде косвен недостатък. Ако трябва да използвате тези услуги наведнъж, тогава трябва да поставите всички обекти на поддръжка отново. Засега мога да направя това само чрез изброяване на всички обекти с метаданни. За съжаление, докато този процес се извършва ръчно, но в бъдеще ще бъде автоматизиран.

В допълнение към двете споменати задачи беше открит един малък недостатък, който по принцип не влияе на качеството на актуализацията и рядко се проявява. В резултат на актуализацията кодовите редове на оригиналната конфигурация и актуализираната визуално съвпадат, но по някаква причина в края на редовете се добавят интервали. Това е недостатък, тъй като леко увеличава обема на модифицирания код. И в случай на по-нататък ръчна актуализацияби било по-добре да няма такива части от кода. На фиг. 6 показва пример преди актуализацията, а на фиг. 7 е пример след актуализацията.