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

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

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

Общи правила за извършване на промени в конфигурационни обекти:

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

Характеристики на промяна на ролите (ролите в 1C имат приоритет на достъпа пред забраната и достъпът до обекти и детайли се формира чрез добавяне на набор от предоставени роли):

Ако е възможно, не е необходимо да променяте типичните роли, но е по-добре да добавите нови: или на базата на типична и да отразите това в името на ролята, или като допълнение към съществуваща типична.роли, но "разпределяне" на правата върху конфигурационните обекти, които добавихме;
Когато настройвате новосъздадени роли, по-добре е да следвате правилата за създаване на роли за типични конфигурации - това е поставянето на квадратчетата за отметка за ролята „Задаване на разрешения за атрибути и таблични секции по подразбиране“ и „Независими права на подчинени обекти“, освен ако, разбира се, нямате някои МНОГО сериозни аргументи за премахване на отметките в тези квадратчета. Ако внезапно създадете ролята си с пълни права, тогава е удобно да поставите отметка в квадратчето „Задаване на права за нови обекти“, НО не забравяйте, че интерактивната роля „Интерактивно изтриване“ също ще бъде инсталирана за нови обекти по подразбиране (!) И ще трябва да бъде премахната ръчно.
Случва се да трябва да отнемете правата върху някои обекти от типична роля, например „Потребител“ - такива действия трябва да имат сериозна обосновка и трябва да се разбере, че това значително ще увеличи времето за актуализиране на ролите - ще трябва да сравнявате тази роля всеки път и ръчно да конфигурирате достъпа по обекти. Като алтернатива на предложеното решение можем да разгледаме създаването например на информационен регистър, чрез чиито записи ще определим достъпа до конфигурационните обекти на конкретен потребител, но това изисква писане на значително количество код.

Характеристики на променящите се интерфейси:

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

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

Промяна на фигурите:

Промяна на оформленията:

Не трябва да променяте оформленията, трябва да използвате механизма за свързване на външни форми за печат, в краен случай просто добавете модифицираното си оформление като ново, като му дадете например префикса "gu".

Промяна на подсистемите:

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

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

Промяна на кода на модула:

//@@@ Код преди промяна:

Не винаги е възможно да се променят манипулатори на събития, но е възможно да се прихванат манипулатори на събития на формуляри с помощта на оператора Execute (приблизително както е описано тук: http://kb.mista.ru/article.php? >

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

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