Очаква се да дефинира функционална процедура преди. Разширяване на модула

Оказа се доста актуално :)

Добре, нека направим и този уикенд полезен.

И така, днес е друга тема за „приложна работа на 1C“:

Механизъм за разширение в платформа 8.3.6

За какво говорим?

В платформа 8.3.6 е внедрен нов механизъм - механизъм за разширение, който улеснява адаптирането на приложно решение към конкретен клиент.

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

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

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

За да можете да разберете това по-подробно, публикуваме още няколко видеоклипа + PDF за разширения.

И така, започваме:

Предназначение на разширенията на конфигурацията

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

Обекти, които могат да бъдат модифицирани в разширението

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

Работа с разширения в конфигуратора

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

Заемане на обекти

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

Създаване на ваши собствени обекти в разширение за конфигурация

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

Работа с разширения в потребителски режим

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

Работа с управлявани формуляри в разширения за конфигурация

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

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

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

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

Внедрено във версия 8.3.9.1818.

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

И по-подробно, можете да промените всички модули, с изключение на модули от обикновени форми:

Общи модули;
Обектни модули (обектен модул, мениджърски модул и др.) за всички видове обекти;
Сесиен модул;
Модул за управлявано приложение;
Модул за външна връзка;
Командни модули;
Модули за формуляри;
и т.н.

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

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

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

Собствени модули
Можете да създадете свои собствени общи модули в разширението.

Обадете се
И накрая, можете да извикате всеки стандартен конфигурационен метод във вашето разширение.

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

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

Прихващане на извиквания на метод

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

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

Анотацията &Before("Procedure1") означава, че се прихваща обща процедура с име Procedure1. Името на анотацията Преди означава, че вашата процедура за прихващане Ext_Proc1() ще бъде изпълнена първо, а след това генеричната Procedure1().

Резюме &Преди

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

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

Резюме и след

Тази анотация означава, че вашият интерцептор ще бъде изпълнен след изпълнението на общия метод.

Резюме &Вместо това

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

За същата стандартна процедура можете да инсталирате една от следните комбинации от прехващачи във вашето разширение:

&Преди;
&След;
&Вместо;
&Преди и след.

Последната комбинация от прехващачи (&Преди и &След) ще бъде изпълнена, както следва:

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

Извикване на метод, заменен от &Вместо

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

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

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

Така че вашата функция за прихващане е разделена на две части. Частта, която се изпълнява преди изпълнението на стандартната функция, и частта, която се изпълнява след стандартната функция.

Можете да използвате метода ContinueCall() не само при припокриване на функции, но и при припокриване на процедури. В този случай резултатът от използването му ще бъде същият по смисъл, както при използването на двойка прехващачи &Преди и &След. Единствената разлика ще бъде, че в този случай вашата част „преди“ и вашата част „след“ ще съществуват в един и същи контекст. Това може да е удобно в някои ситуации. На вграден език подобна процедура за прихващане може да изглежда така:

Кое е по-добро, &Преди, &След или &Вместо?

Когато прихващате общи методи за конфигуриране, винаги е полезно да имате предвид две неща:

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

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

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

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

Последователност на извиквания при прихващане на методи

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

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

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

Както в конфигуратора, така и в режим 1C:Enterprise последното свързано разширение е последно в списъка.

Така че в този пример генеричният е в долната част, Extension2 е в горната част, а Extension1 е между тях. Всяко следващо разширение прихваща (разширява) това, което е под него.

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

Пример 1

Например, ако един и същ общ метод е прихванат (рамкиран) в две разширения, тогава последователността на извикване на манипулаторите ще бъде както следва:

Прехващачът от Extension2 ще бъде извикан първи, защото е отгоре. Това ще бъде интерцепторът &Before, защото има тази анотация;
След това ще бъде извикан прехващачът от Extension1, защото е следващият в пая. Отново ще бъде &Before, защото има тази анотация;
Генеричният метод ще бъде извикан, защото няма повече прехващачи, които да попречат на изпълнението му;
След това, в обратния ред на пая, ще бъдат извикани интерцепторът &After от Extension1 и интерцепторът &After от Extension2.

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

Пример 2

Ако прехващачите използват метода ContinueCall(), тогава се прилага същият принцип на пай.

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

Пример 3

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

Този пример ще изпълни само прихващача &вместо Extension2. Тъй като покрива стандартния метод, тоест целия „пай“, който е под него.

Пример 4

Това всъщност е вариация на темата от втория пример, но когато под горното разширение има разширение, което също „натиска“ надолу повикването към стандартната процедура.

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

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

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

Първо, името на прихванатия метод е името на събитието. Например, BeforeRecord:

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

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

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

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

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

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

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

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

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

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

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

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

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

Общи модули

В разширението можете да създадете всеки свой собствен общ модул. Има само две ограничения:

Не е необходимо те да са глобални сървъри;
Те не трябва да бъдат привилегировани.

Когато разширите общ модул с типична конфигурация, има и подобни ограничения:

Не можете да заемате глобални сървърни модули;
Кодът от вашето разширение ще бъде изпълнен само в непривилегирован режим (освен ако не е разрешено друго в профила за защита).

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

Сървърните методи не винаги се разширяват

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

Ако приложното решение работи във файлова версия или във версия клиент-сървър без профили за сигурност, тогава при свързване на вашето разширение:

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

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

Най-простият от тях е квадратче за отметка за разширяване на всички модули в групата Разрешен пълен достъп. Той „с един замах“ позволява разширяване на контекста на сървъра.

Има и по-прецизна настройка с помощта на полетата Модули, налични за разширение и Модули, които не са налични за разширение. Предполагаме, че ще ги използвате, както следва:

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

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

Какво представляват външните доклади и обработка

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

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

В Button са разработени няколко десетки решения за обработка, които позволяват на нашите счетоводители да използват „практическа магия“. Например, за да се анализира коректността на счетоводството в Бутона, се използва външният отчет „Автоматичен одит на база данни“. Лесните за четене таблици предоставят анализ по 120 критерия за салда и обороти по сметки, съответствие на данните от данъчните декларации и счетоводната информация, анализ на дълготрайните активи и др.

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

Отваря се формуляр за попълване на необходимите данни:

И се показва печатната форма на договора:

Ние използваме планирана обработка (рутинни задачи), например, за да коригираме отчети. Бутоните са създали интеграции с големи банки и специални роботи зареждат отчети директно в 1C. Благодарение на технологията за машинно обучение, процентът на грешките по време на разреждане е намален до 3%. Но, както винаги, има изключения, например клиенти, които използват агентска схема за продажба на стоки, в този случай правилата за извършване на банково извлечение са индивидуални. За да не се препрограмира робота за конкретен случай, преди появата на разширенията за конфигурация, се използваше рутинна задача за коригиране на изявлението на робота на всеки 10 минути.

Какво представляват разширенията за конфигурация

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

Механизмът предполага три вида използване, които всъщност са посочени в полето „Цел“ при създаване на разширение:

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

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

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

Допълнителен отчет или обработка се създава в конфигуратора на 1C: Enterprise 8 като стандартни външни отчети и обработка и се записва във файл с разширение - .epf (за допълнителна обработка) или .erf (за допълнителни отчети).

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

Моля, обърнете внимание, че важният параметър е „Версия“. Ако сте направили промени в обработка, която преди това е била качена в директорията на диспечера на услугата, не забравяйте да промените номера на версията, в противен случай диспечерът на услугата ще откаже да зареди файла. Когато разработвате отчет или обработка, трябва да вземете предвид, че потребителите работят в модел на услуга чрез уеб клиент (добра статия в блога на 1C). Ако обработката съдържа формуляри, тогава те трябва да работят в уеб клиента под всички уеб браузъри, които се поддържат от технологичната платформа 1C: Enterprise 8.

Съгласно стандартите на услугата 1cfresh.com, допълнителен отчет или обработка трябва да бъдат напълно функционални, когато се изпълняват в безопасен режим, тоест да работят без достъп до обекти, външни за конфигурацията.

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

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

Подготовката се извършва в локално разположена информационна база на конфигурацията, за която е предназначен допълнителният отчет или обработка. Използваме специален помощник за създаване на комплект за доставка, външна обработка Подготовка на допълнителни отчети и обработка на публикации в Service Model.epf. Можете да прочетете повече в документацията за Технологията за публикуване на решения 1C Fresh.

Инсталиране на допълнителни справки и обработка в сервизния модел

Отличителна черта на технологията 1C Fresh е, че външен отчет или обработка не могат да бъдат заредени директно в областта за данни. Добавянето може да се извърши само от администратора на услугата чрез мениджъра на услугата. След като се подготви zip архивът с файла за обработка, той трябва да бъде качен в директорията на диспечера на услугите и инсталиран за конкретен абонат на услугата.

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

Приложенията могат да имат различни 1C конфигурации (Счетоводство на предприятието, Управление на заплати и персонал, Управление на нашата компания и др.), За които е възможно да се използва в модела на услугата. Допълнително отчитане или обработка може да се инсталира само в приложенията на абоната, които са посочени при изтеглянето на файла.

Ето как изглежда формата за свойства за допълнителен отчет с версии. Използвайки хипервръзката „Инсталиране/Премахване“, стигаме до списъка с приложения и избираме необходимите бази данни.

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

Започваме обработка по график

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

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

При изготвяне на комплекта за доставка ние определяме график. Сега нашата обработка ще се извършва на всеки час.

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

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

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

Доста лесно е да подготвите ново разширение. Нека да разгледаме процеса на създаване на разширения, използвайки конкретни примери.
Въз основа на трудовия опит лидерът в исканията за корекции е печатният формуляр TORG-12. Например, трябва да направим разширение, за да можем да отпечатаме бележка за доставка в чуждестранна валута (по подразбиране тя може да се генерира само в рубли).
Отворете Меню → Конфигурация → Разширения за конфигурация
Създаваме ново разширение с цел „Адаптиране“.

Разширението изглежда като познато конфигурационно дърво, но все още без обекти. Първо, нека добавим ново оформление TORG-12, в което вмъкнахме колони със суми във валута.

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

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

За да променим стандартните процедури, ние използваме анотацията &After;, ние също се нуждаем от няколко наши собствени функции и процедура.

Нека разгледаме по-отблизо анотациите. В разширенията можете да използвате: &Before, &After, &Instead (много внимателно). Принципът на работа е прост: искаме нашите алгоритми от разширението да се изпълнят първи, поставяме анотацията &Before и в скоби посочваме името на процедурата от стандартната конфигурация. Ако първо се обработва стандартен модул, а след това нашият, използваме &After.

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

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

Заключение

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

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

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

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

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

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

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

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

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

Може да е полезно да прочетете: