Ревизираните правила типични конфигурации 1С за улесняване на по-нататъшни актуализации (част 1)

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

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

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

0. Съдържание разработва списък с правила:

1. Понятието минимизиране на "разрушаване" на типична конфигурация

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

2.1 Въвежда се кодът

2.2 Изтриване на код

2.3 Промяна на съществуващ код

2.4 Добавяне на процедури и функции на модула

Това правило е лесно да се прехвърли промени в модула в "сравнение poprotsedurnom" конфигурации.

3. добавяне на обекти най-високо ниво

Имената на обектите на най-високо ниво, които са създадени в конфигурацията трябва да започват с префикса на вашата фирма или физическо лице префикс проект. Тя обикновено се състои от две или три главни букви и подчертаване, например AB_. Съответно, генерирани обекти ще бъдат посочени AB_NovyySpravochnik. AB_NovyyRegistrSvedeny. AB_NovyyDokument и т. D.

Синонимите (видими за потребителското име), добавени към обектите на най-високо ниво трябва да започва с представката, оградена в скоби: (AB). В резултат на това тези обекти визуално ще се открояват в списъците и група пребивават в ранното им (което улеснява и тестване и употреба).

Пример. Създайте директория "Проекти".

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

4. Добавяне на подчинените обекти

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

4.1 Добавяне на подчинените обекти в обичайна конфигурация обекти

Подчинените обекти се добавят към трябва да бъдат снабдени с префикси съществуващите (типичен) конфигурация обекти. AB_DopolnitelnyyRekvizit. AB_NovayaTablichnayaChast. AB_FormaNastroekPolzovatelya. AB_MaketSpetsialnayaNakladnaya. Но в същото синоними на подчинените обекти са създадени без префикс.

Пример. Създаване подпори "Проект" документ "авансово плащане."

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

4.2 Добавяне на подчинените обекти в обекти добавени към проекта

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

Пример. Създаване подпори "отговорност" в Handbook "(AB) проекти."

действие за разработчици. Ако проблемът не се различава от тази, в която позоваването е създаден "(AB) проекти", следващата подпората се създава в конфигурация:

5. Добавете предварително определен елементи

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

5.1 Добавяне на предварително определени елементи в конфигурация проба обекти

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

Пример: В сметкоплана "самоносещи" Добавяне на предварително определени от 10.15 - Форми на стриктното отчитане.

действие за разработчици. Добавете следните предварително дефинирани по:

• Име: AB_BlankiSrogoyOtchetnosti
• Код: 10.15
• Име: Форми на стриктното отчитане

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

5.2 Добавяне на предварително определени елементи в обекти добавени към проекта

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

6. използването на общи модули и тяхното стриктно структурата

Многократно се използва в процедурите за конфигурация и функции, и абонамент за манипулатори рутинните работни места са поставени в общите модули. трябва да се добавят по поръчка модули за тази цел. Добавена от правилата на добавянето на обектите на най-високо ниво, оставяйки без промяна типичните модули. В строителството ще бъде от полза за следните общи модули ( "AB_" - код):

• AB_ObschegoNaznacheniya (клиент, сървър, външна връзка) - за да се настанят на нормалните процедури и функции.
• AB_Serverny (сървър само) - за процедури и функции, които трябва да бъдат изпълнени в сървърна среда.
• AB_Globalny - за процедури и функции, е предизвикателство, което по стандартния начин (чрез името на модула, и точката) е неудобно.
• AB_Privilegirovanny - за процедури и функции, които винаги трябва да се извърши с пълни права.
• AB_PovtornoeIspolzovanie - да кешира върнатите стойности на определени функции.

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

7. Използване на абонаменти и тяхното стриктно структура

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

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

Пример. При извършване на документ "авансовото плащане" на, да пише в регистъра за съхранение "(AB) разходи за проекта."

2. Създаване на общ сървър модул "AB_DokumentyObrabotkaProvedeniya".

3. В модула за създаване на процедура за износ "ObrabotkaProvedeniya". Изберете тази процедура като манипулатор създадена по-рано абонамент. В рамките на процедурата, в зависимост от вида на документа, призовава необходимите манипулатори.

4. "Първа вноска" модул на документа трябва да остане непроменена.

8. Формулярите за редактиране

8.1 Редактиране образува типични обекти

Ако промяната в стандартния формуляр (конвенционално и контролира), малък (например, за да се направи под формата на няколко нови подробности), а след това да извърши такава промяна трябва да бъде напълно софтуер. Д. се изменя само в модула за форма. и формата на конфигуратора остава непроменена. Някои предприемачи като метод за редактиране на форма първоначално може да изглежда по-скоро труден. Въпреки това, има достатъчно опит в областта на софтуера форма промени, не повече от 3-5 минути, за да отида, за да добавите един елемент. Прекарано време се отплаща многократно в последващи актуализации типична конфигурация.

Пример. Основната форма на документ "авансово плащане", добави подпори за "проект (AB)."

действие за разработчици. манипулатор форма "PriSozdaniiNaServere" добави процес "DorabotatFormuProgrammno ()". При тази процедура, се добавя желания елемент елементи форма.

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

В типичните конфигурации на базата на БСП 2, вече има специална функционалност за тази цел:

В "PriSozdaniiNaServere" процедура "ModifikatsiyaKonfiguratsiiPereopredelyaemy" общ модул може да се обадите манипулатор.

Когато формата за име, можете да се обадите на необходимите процедури със софтуер преработи форма.

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

8.2 Редактиране на формуляри обекти са били добавени към проекта

Формите са добавени към проекта (т.е.. Д. като префикс в името си) са редактирани по обичайния начин.

9. Принципи на роли

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

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

10. Външно отчитане и обработка

По-голямата част от подобренията в системата може да бъде направено чрез механизъм на допълнителни отчети и лечения.

В конфигурации базирани BSS 2 (ERP, UT 11 BP 3.0 SPP 3.0 и т.) Този механизъм значително се разширява. С него, без да променя конфигурацията е възможно да се създаде външни доклади и обработка (с поставянето на план команда в интерфейса на командния и приспособима достъпа до различните потребители), попълване на документи за обработка на обработка документ е създаден въз основа на допълнителните табели и др.

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