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

Начини за намаляване на усилието да се актуализират нестандартни конфигурации, които са базирани на стандарта

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

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

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

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

Особености променящата се роля (роли 1C имат приоритетен достъп през забраната и достъп до съоръженията и детайлите, генерирани чрез добавяне на набор от дадените роли):

  • Ако е възможно, не е нужно да се промени стандартните роли, а по-скоро да се добави: или въз основа на типа и да се отрази това в името на ролята, или като допълнение към вече съществуващите стандартни роли, но "Hrazdan" право на писмени конфигурационни контакт обекти;
  • Когато настройвате новосъздадената роля е най-добре да се следват правилата за създаване на роли за типични конфигурации - втвърдители от квадратчетата за ролята на "установява правото на детайли и таблични части от по подразбиране" и "независими права върху подчинените обекти", ако, разбира се, има някои много значима аргументът е проста инсталация от тези кърлежи. Ако се случи да се създаде роля с пълни права, че е подходящо да се установи от кърлеж "се уреждат правилата за нови обекти", но трябва да се помни, че интерактивната ролята на "Interactive отстраняване" също е инсталиран по подразбиране за нови обекти (!) И трябва да бъдат отстранени ръчно ,
  • Това се случва, че необходимостта да се вземе правата върху определени обекти в типична роля, например, "Потребител" - такива действия трябва да имат сериозно изследване и трябва да се разбира, че това значително ще увеличи времето на ролите актуализация - ще трябва всеки път да се сравни ролята и ръчно да конфигурирате обекти за достъп , Като алтернатива на предложеното решение може да бъде да се помисли за създаването, например, регистъра на информация от регистрите, които ще определят достъпа до обекти конфигурация на даден потребител, но изисква значително количество от писане на код.

Характеристики интерфейсни възможности:

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

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

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

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

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

Променете модул код:

// @@@ код преди промяната: |

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

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