در این مقاله، من پیشنهاد می کنم در نظر بگیریم که "پسوند پیکربندی" چیست، چگونه یک برنامه افزودنی اضافه یا غیرفعال کنیم. شروع از نسخه 1C در 8.3.6.1977 مکانیزم جدیدی در پلتفرم معرفی شد - پسوندهای پیکربندی. اول، کمی تئوری.

برنامه های افزودنی در 1C چیزی شبیه پیکربندی های موازی هستند که به طور خودکار با پیکربندی فروشنده اصلی ادغام می شوند. علاوه بر این، در برنامه های افزودنی، می توانید هم اشیاء خود را اضافه کنید و هم اشیاء را از پیکربندی اصلی قرض بگیرید.

افزونه ها برای چه هستند؟

اول از همه، برنامه های افزودنی ایجاد می شوند تا تغییرات در برنامه را آسان تر کنند. یعنی اگر کاربران بخواهند برخی از قابلیت ها را اضافه کنند، قبل از ظهور برنامه های افزودنی، برنامه نویسان مجبور بودند پیکربندی را از پشتیبانی کامل حذف کنند و پیکربندی معمولی را تغییر دهند.

حذف از پشتیبانی کامل چندین مشکل را به همراه دارد:

• امکان به روز رسانی خودکار ناپدید می شود، که حداقل منجر به افزایش زمان برای .
• ضروری صلاحیت بالامتخصص در خدمت برنامه؛
• اگر تغییراتی در اشیاء استاندارد یک پیکربندی معمولی ایجاد شده باشد، در طول به روز رسانی ممکن است آنها ناپدید شوند، یعنی می توان آنها را دوباره با موارد استاندارد از تامین کننده جایگزین کرد.

هنگام استفاده از برنامه های افزودنی، هنگام ایجاد تغییرات، برنامه نویس پیکربندی استاندارد را لمس نمی کند. همه تغییرات با استفاده از پسوندها انجام خواهند شد که (همانطور که در بالا نوشتم) تنظیمات نیز هستند. بنابراین، پیکربندی اصلی در پشتیبانی کامل باقی خواهد ماند.

پس از به‌روزرسانی پیکربندی اصلی، اگر تغییراتی در نسخه جدید با شی‌ای که قبلاً توسط افزونه اصلاح شده است، ایجاد شود، باز هم تغییرات از برنامه افزودنی گرفته می‌شود. یعنی افزونه ها بر پیکربندی اصلی اولویت دارند.

ویدئو - پسوندها در 1C در 45 دقیقه

267 درس ویدیویی 1C را به صورت رایگان دریافت کنید:

نمونه ای از افزودن پسوند به 1C

برای نشان دادن چیستی افزونه، بهتر است نمونه ای از ایجاد آن در پیکربندی 1C ارائه شود.

در پیکربندی، به منوی "پیکربندی" بروید و مورد "پسوندهای پیکربندی" را انتخاب کنید. پنجره ای با لیستی از پسوندها (در صورت وجود) باز می شود. روی دکمه "افزودن" کلیک کنید و یک پسوند جدید اضافه کنید. اکنون می توانید پیکربندی برنامه افزودنی را باز کنید:

همانطور که می بینید، پیکربندی افزونه دقیقاً همان ساختار اصلی را دارد. فقط در ابتدا کاملاً خالص و بدون اشیا است.

من اخیراً مقاله ای در مورد نحوه ساخت خود نوشتم. با استفاده از مثال او، می‌خواهم آن را با استفاده از یک افزونه درون خطی کنم.

در پردازش، من یک فیلد با پیوند به فهرست "سازمان ها" دارم. به همین دلیل به این راهنما نیاز دارم. اما ما یک فهرست سازمانی جدید ایجاد نخواهیم کرد، به خصوص که پلتفرم اجازه نمی دهد. شما نمی توانید در پیکربندی برنامه افزودنی اشیایی داشته باشید که با اشیاء موجود در پیکربندی اصلی نام یکسانی داشته باشند.

بنابراین، ما دایرکتوری را از پیکربندی اصلی قرض می گیریم:

اکنون روی "Processing" کلیک راست کرده و "Insert external processing, report..." را انتخاب می کنیم بنابراین، یک پردازش جدید به پیکربندی برنامه افزودنی اضافه می کنیم. اگر از پردازش من استفاده می کنید، بلافاصله نام آن را تغییر دهید، زیرا پیکربندی اصلی قبلاً پردازشی با آن نام دارد.

خوب، لمس نهایی. من می خواهم پردازش من در منوی "Administration" منعکس شود. برای انجام این کار، زیرسیستم پیکربندی اصلی به همین نام را قرض می گیریم. فراموش نکنید که در پردازش نشان دهید که متعلق به این زیرسیستم است.

این ساختاری است که من گرفتم:

ببینیم چی گرفتیم ما پیکربندی پایگاه داده را به روز می کنیم و برنامه را در حالت 1C: Enterprise اجرا می کنیم و به منوی "Administration" می رویم. بله، تقریباً فراموش کردم، پیکربندی برنامه افزودنی باید بسته شود، در غیر این صورت برنامه شروع نمی شود:

هزینه کار و گزینه های ترجمه از نسخه های مختلف

	ترجمه 8.1 → 8.2.13	ترجمه 8.2.13 → 8.2.16	ترجمه 8.2.16 → 8.3.10
قیمت، مالش. *	54000 ₽	12000 ₽	76 800 ₽

لیست تمامی تغییرات در نسخه های مختلف پلتفرم در لینک های زیر موجود است:
برای پلتفرم 8.2:
http://downloads.v8.1c.ru/content/Platform/8_2_19_106/1cv8upd.htm

قبل از شروع کار بر روی ترجمه به 8.3، باید:

حالت مسدودسازی مدیریت شده را بررسی کنید. اگر از "Automatic" استفاده شود، انتقال به 8.3 ممکن است نیاز به هزینه های اضافی برای تغییر حالت قفل کنترل شده داشته باشد.
اگر از حالت سازگاری با 8.2.16 و بالاتر استفاده می شود، باید بررسی کنید که آیا جداول بازسازی شده اند یا خیر.
تعیین نوع کلاینت هایی که استفاده می شود (نازک، ضخیم، وب کلاینت)
تعیین کنید که آیا ماشین هایی وجود دارند که لینوکس را اجرا می کنند

ترجمه پیکربندی 8.1 → 8.2.13

هزینه کار: 54000 روبل.

ترجمه پیکربندی 8.2.13 → 8.2.16 (شامل بازسازی)

تغییرات کلیدی:
حالت ذخیره سازی ثابت ها و تنظیمات رجیسترهای تجمع تغییر کرده است. هر شیء جدول پایگاه داده خود را دارد
اجرای مکانیزم قفل مدیریت شده دوباره طراحی شده است.
برای رویداد گزارش فناوری "TLOCK"، ویژگی "Txt" فقط در حالت سازگاری با نسخه 8.2.13 نوشته شده است.
تأثیر حالت اشکال زدایی بر سرعت کار در حالت 1C: Enterprise برای تین کلاینت، کلاینت ضخیم، سرور و اتصال خارجی کاهش یافته است.
اجرای بهینه شده یک پرس و جو مانند "ValueType(Field1) = ValueType(Field2)" اگر "Field1" و "Field2" حاوی مقادیر نوع مرجع باشند.
برای فیلدهای فرم مدیریت شده که یک ویژگی از نوع ترکیبی را نمایش می دهند، در مواردی که نوع ترکیبی شامل انواع مرجع با تنظیمات مختلفانتخاب سریع
برای استقلالی جدید و نه ثبت دوره ایاطلاعات، شاخص بر اساس ابعاد خوشه بندی شده است

تغییراتی که نیاز به تغییرات پیکربندی دارند:

هنگامی که حالت سازگاری غیرفعال است، پارامتر "Period" از روش "Get()" مدیر ثبت اطلاعات دوره ای مورد نیاز است. در حالت سازگاری با نسخه 8.2.13 و نسخه 8.1، رفتار تغییر نکرده است (روش را می توان بدون تعیین پارامتر استفاده کرد، اما نتیجه تعریف نشده است).
هنگامی که از متدهای "SetValue()" و "UseFromDataSource()" شی "DataLockItemItem" به طور همزمان استفاده می کنید، یک استثنا ایجاد می شود. در حالت سازگاری با نسخه 8.2.13، رفتار تغییر نکرده است (اولویت به مقدار تنظیم شده توسط روش "UseFromDataSource()" داده می شود).
ذخیره مقادیر داده ای که از سریال سازی پشتیبانی نمی کنند پشتیبانی نمی شود. در حالت سازگاری، رفتار تغییر نکرده است.
اگر پایگاه داده یک فایل است، پس پایگاه اطلاعاتی باید تبدیل شود. پس از شروع تبدیل، کار با این پایگاه اطلاعاتی با نسخه های قبلی پلت فرم 1C:Enterprise 8 غیرممکن خواهد بود. اگر توسعه با استفاده از مخزن پیکربندی انجام می شود، باید قبل از تبدیل پایگاه اطلاعاتی، یک کپی از مخزن تهیه کنید.

مهم. برای به دست آوردن تأثیر تغییر حالت سازگاری، باید از طریق پیکربندی کننده یک بازسازی انجام دهید: "اداره → تست و تعمیر → بازسازی جداول پایگاه اطلاعات".

ابتدا باید بازسازی را روی یک پایه آزمایشی انجام دهید و زمان اجرای این عملیات را اندازه گیری کنید.
اگر از نسخه سرور 1C قدیمی‌تر از 8.2.19 استفاده شود، به عنوان مثال، نسخه 8.3، ممکن است خطاهای زیر در هنگام بازسازی رخ دهد:

در این صورت باید موارد زیر را انجام دهید:
سرور 1C نسخه 8.2.19 را جداگانه نصب کنید و پایگاه داده مورد مطالعه را روی آن مستقر کنید
پایگاه داده را در پیکربندی سرور 1C نسخه 8.2.19 باز کنید، حالت سازگاری را به "استفاده نکنید" تغییر دهید.
بازسازی جداول پایگاه اطلاعاتی را انجام دهید
پس از تکمیل بازسازی، پایگاه اطلاعاتی را به سرور اصلی 1C نسخه 8.3 منتقل کنید

هزینه انتقال پیکربندی از حالت سازگاری 8.2.13 به حالت 8.2.16 (حالت عدم سازگاری هنگام استفاده از پلتفرم 8.2.16، 8.2.19 و حالت سازگاری 8.2.16 هنگام استفاده از پلت فرم 8.3) است. 12000 روبل.

قالب قرارداد کار قابل دانلود است.

ترجمه پیکربندی 8.2.16 → 8.3.10

کار ترجمه پیکربندی شامل بهبودهای پیکربندی زیر است:

1. از بین بردن تضاد نام دارایی. تغییر نام متغیرها برای مطابقت با ویژگی های جدیدی که در 1C: Enterprise 8.3 ظاهر شده است.

2. از بین بردن تضاد نام تصاویر. تغییر نام تصاویر با نام هایی که با نام های موجود در کتابخانه عکس مطابقت دارند.

3. اصلاح کد هنگام تغییر خصوصیات یک ساختار ثابت. جایگزینی نشان‌دهنده ویژگی‌های یک سازه ثابت با بازآفرینی یک سازه ثابت یا جایگزینی استفاده از آن با نوع مشابهی از "Structure".

4. جایگزینی مقادیر غیرقابل سریال سازی در حافظه موقت با کد پشتیبانی شده در 1C: Enterprise 8.3.

5. جایگزینی استفاده از فراخوانی متد "نمایش" برای ویژگی های یک فرم مدیریت شده، با استفاده از ویژگی های "CurrentElement"، "CurrentPage"، روش "فعال کردن"

6. جایگزینی نام اشیاء فراداده با طول بیش از 80 کاراکتر، با نام هایی با طول نام 80 کاراکتر یا کمتر برای اشیاء فراداده

7. تغییر نام روش ها و ویژگی ها، با توجه به روش تغییر به نسخه 8.3.

8. اصلاح مکانیسم های کار با انتخاب ها، طراحی مشروط، گروه بندی و ترتیب در لیست های پویا.

9. اصلاح کد برای درخواست‌ها با کلمه کلیدی "Results ON GENERAL" در حالت تخلیه شده "دور زدن نتیجه پرس و جو. با گروه بندی"، به منظور حفظ منطق قدیمی کار.

10. تغییر در نام کلاس اشیاء COM. جایگزینی نام "V82.COMConnector" با "V83.COMConnector" و "V82.Application" با "V83.Application".

11. امتناع در کد برنامه از رویداد "Start of SelectionFromList" برای فیلدهای ورودی در حالت انتخاب از لیست

12. امتناع در کد برنامه از ویژگی "SelectionListButton" برای فیلدهای ورودی با تنظیم ویژگی "DropdownListButton".

13. تغییر کد با در نظر گرفتن تغییر در نوع مقدار بازگردانده شده توسط روش زمینه جهانی "SafeMode ()"

14. تغییر کد با در نظر گرفتن تغییر نتیجه یک پرس و جو به ثابت (هنگام دسترسی به فیلد "Value" جدول ثابت، اگر ثابت مقدار "ValueStorage"، "UniqueIdentifier" یا "ExternalDataSourceTableReference" را ذخیره کند. نوع).

15. جایگزینی ویژگی پیکربندی "MainRole" با "MainRoles"

16. رد کردن خصوصیات "User" و "Password" برای شی "InternetProxy" و جایگزینی با متدهای "Set()"، "User()"، "Password()".

17. اصلاح کد برای پشتیبانی از دستور "نمایش در لیست"، با توجه به روش تغییر به نسخه 8.3.

18. اصلاح کد برای حفظ منطق قبلی عملیات سیستم با مقدار بازگشتی تغییر یافته ویژگی SystemInformation.OSVersion،

19. اصلاح کد برای حفظ منطق قدیمی سیستم در هنگام عدم استفاده از سیستم شمارش WindowOpeningVariant که دیگر در نسخه 8.3 موجود نیست.

20. اصلاح کد با در نظر گرفتن امتناع از استفاده از پنجره های مدال.

21. اصلاح کد پشتیبانی کلاینت وب، یعنی رد تماس های سرور و باز شدن پنجره ها در "قبل از بسته شدن"، رد تماس های سرور در "در بسته شدن".

22. اصلاح کد برای امکان استفاده صحیح از تابع ()RoleAvailable، هنگام انتقال تابع به عنوان پارامتر به نقش گم شده.

23. برای یک برنامه مدیریت شده: شروع از نسخه 8.3.8 در مدیریت رویدادهای برنامه مدیریت شده BeforeSystem Shutdown، OnSystem Shutdown، و همچنین در مدیریت رویدادهای مدیریت شده که در حالت بسته هستند، BeforeClose، OnClose، باز کردن ویندوز و برقراری هرگونه تماس با سرور ممنوع است. لازم است پیکربندی را اصلاح کنید تا بسته شدن فرم ها به درستی انجام شود - بدون تماس سرور.

24. تضاد نام متغیر: نمی توانید از نام متغیر FormParameters در ماژول فرم استفاده کنید. بنابراین لازم است تمام ماژول های فرم مدیریت شده که از متغیرهایی با نام FormParameters استفاده می کنند با تغییر نام این متغیرها نهایی شوند.

قیمت این کارها مقدماتی است و برای اکثر پیکربندی ها مرتبط است. قبل از شروع کار در انعقاد قرارداد، پیکربندی و پس از تأیید، ما قیمت و شرایط کار را تأیید می کنیم. تأیید ضروری است زیرا پیکربندی‌ها می‌توانند بسیار متفاوت باشند، از جمله پیکربندی‌هایی که به شدت بازنویسی شده‌اند.

هزینه کار: 76800 روبل

قالب قرارداد کار قابل دانلود است.

هزینه تبدیل پیکربندی به حالت سازگاری با 8.3.10 می تواند باشد افزایش یافت، اگر:
پیکربندی از فرم های مدیریت شده استفاده می کند
لازم است استفاده از مدالیته متوقف شود
حفظ عملکرد پیکربندی در سیستم عامل لینوکس ضروری است

نسخه جدیدی از پلتفرم 8.3.11 منتشر شده است که به شما امکان می دهد اشیاء متادیتا را از طریق یک افزونه اضافه و اصلاح کنید. آیا واقعاً می‌توانیم اکنون بدون حذف پیکربندی از پشتیبانی، هر گونه پیشرفتی را اعمال کنیم؟ آیا ارزش دارد که بدون هیچ عواقبی به مشتری قول کوه های طلا بدهیم؟

اول از همه، باید از محدودیت هایی که افزونه ها دارند آگاه باشید.

محدودیت در اشیاء ایجاد شده

در این لحظهمی توانید ایجاد کنید:

• کتاب های مرجع
• مدارک
• ثبت اطلاعات
• طرح های مبادله

می توانید جزئیات را به موارد زیر اضافه کنید:

• کتاب های مرجع
• مدارک

در نهایت به چه میرسیم؟ همه انواع اشیاء ابرداده را نمی توان اضافه کرد. رایج ترین و محبوب ترین، اما هنوز همه نیست. علاوه بر این، ابعاد و منابع جدیدی را نمی توان به ثبت اطلاعات اضافه کرد. شما فقط می توانید یک دفتر کل جدید ایجاد کنید.

عملکرد برنامه های افزودنی به حالت سازگاری پیکربندی که برنامه افزودنی به آن اعمال می شود بستگی دارد.

حالت سازگاری 8.3.8- شما فقط می توانید اشکال اشیاء و ماژول های آنها را تغییر دهید، گزارش ها و پردازش های خود را اضافه کنید.

حالت سازگاری 8.3.10- می توانید ماژول های رایج، ماژول های شی و مدیر، نقش ها را تغییر دهید، از دستورالعمل های "قبل"، "بعد"، "به جای" برای هر ماژول استفاده کنید.

حالت سازگاری "استفاده نکنید"- می توانید از تمام قابلیت های افزونه ها از جمله افزودن اشیاء جدید استفاده کنید.

در حال حاضر، UT 11.3 معمولی دارای حالت سازگاری 8.3.8 است. در UT 11.4، حالت سازگاری 8.3.10 است، به عنوان مثال، برای UT، بیشترعملکرد برنامه افزودنی از جمله ایجاد اشیاء فراداده در دسترس نیست.

به نظر می‌رسد که این سؤال پیش می‌آید: چرا فقط از ریشه پشتیبانی نمی‌کنید، حالت سازگاری را روی «استفاده نکنید» تنظیم نکنید و با خیال راحت از برنامه‌های افزودنی استفاده کنید؟ هنگامی که حالت سازگاری را تغییر می دهید، رفتار فرم ها، نتایج پرس و جو، به عنوان مثال. رفتار سیستم در کل ما قویاً توصیه می کنیم که حالت سازگاری را بدون آزمایش قبلی تغییر ندهید. اما بدیهی است که امکان تست کامل (یا حداقل در بخشی از اسناد مورد استفاده) یک راه حل کاربردی کامل وجود دارد. بنابراین نباید از این گزینه استفاده کرد.

هنگام اتصال یک برنامه افزودنی به یک پیکربندی معمولی، وام گرفتن اشیاء معمولی، برنامه افزودنی حالت سازگاری پیکربندی اصلی و انواع اشیاء قرضی و جزئیات آنها را کنترل می کند. اگر ویژگی های کنترل شده مطابقت نداشته باشند، برنامه افزودنی غیرفعال می شود و تا زمانی که علت از بین نرود، کار نمی کند. یعنی با یک آپدیت بزرگ، احتمال زیادی وجود دارد که حداقل یکی از ویژگی های کنترل شده تغییر کند و افزونه عملکرد خود را از دست بدهد.

علاوه بر این، اگر پیشرفت‌ها قابل توجه باشند، بسیاری از رویه‌ها و عملکردهای پیکربندی استاندارد جایگزین شده‌اند، لازم است آنها را به دقت کنترل کنید و در صورت لزوم با حفظ تغییرات قبلی، آنها را با پیکربندی استاندارد مطابقت دهید.

در موارد بالا، همچنان به کمک یک برنامه نویس و احتمالاً زمان قابل توجهی برای بازبینی نیاز دارید (اما هنوز کمتر از زمان به روز رسانی پیکربندی که از پشتیبانی حذف شده است).

نتیجه گیری

• انتشار جدید پلتفرم فرصت های جدیدی را برای استفاده از برنامه های افزودنی ایجاد کرد، امکان افزودن اشیاء ابرداده وجود داشت، اما با وجود این، عملکرد دارای محدودیت های خاصی است.
• حالت سازگاری پیکربندی که برنامه افزودنی برای آن اعمال می شود، دامنه برنامه افزودنی را به شدت محدود می کند و تغییر حالت سازگاری توصیه نمی شود.
• به‌روزرسانی‌های بزرگ همچنان نیازمند توجه توسعه‌دهنده هستند، زیرا احتمال تغییرات در ویژگی‌های کنترل‌شده زیاد است.

در نسخه 8.3.6.1977 پیاده سازی شده است.

ما یک مکانیسم اساساً جدید را برای انطباق راه حل های کاربردی با یک مصرف کننده خاص - مکانیسم توسعه اجرا کرده ایم.

چرا افزونه ها خوب هستند؟

برنامه های افزودنی استراتژی متفاوتی نسبت به استراتژی موجود برای تغییر پیکربندی های معمولی ارائه می دهند. استفاده از این استراتژی جدید، نگهداری راه حل های استانداردی را که می خواهید با نیازهای یک پیاده سازی خاص، یک مشتری خاص سازگار کنید، بسیار تسهیل می کند.

اکنون این فرآیند چگونه است؟ یک پیکربندی معمولی وجود دارد. تحت پشتیبانی کامل فروشنده است. این بدان معنی است که نمی توان آن را تغییر داد. به صورت دوره ای، فروشنده نسخه های جدید (بهبود) این پیکربندی را منتشر می کند. در چنین شرایطی آپدیت کنید نسخه قدیمیپیکربندی نسخه جدید کاملاً خودکار انجام می شود. راحت است و نیازی به مهارت یا دانش خاصی از مشتری ندارد.

اما اغلب مشتری می خواهد چیزی اضافه کند یا چیزی را در یک پیکربندی معمولی "برای خودش" تغییر دهد. برای انجام این کار، حالت پشتیبانی تغییر می کند، پیکربندی از پشتیبانی کامل حذف می شود. شریک پیاده سازی یا متخصصان IT خود مشتری تغییرات لازم را در آن ایجاد می کنند. از این مرحله به بعد، به‌روزرسانی کاملاً خودکار پیکربندی معمولی به نسخه جدید منتشر شده توسط تأمین‌کننده غیرممکن می‌شود.

اکنون، به روز رسانی پیکربندی نیاز به مشارکت یک متخصص دارد. علاوه بر این، اگر تغییرات ایجاد شده به خواست مشتری قابل توجه باشد، متخصصی که به روز رسانی پیکربندی را انجام می دهد نیز ممکن است به زمان قابل توجهی نیاز داشته باشد. و اغلب ممکن است دانش بسیار خوبی از خود پیکربندی معمولی و تغییرات انجام شده مورد نیاز باشد.

استراتژی ارائه شده توسط افزونه ها به شرح زیر است. اگر می‌خواهید پیکربندی معمولی را تغییر دهید، خود پیکربندی را لمس نمی‌کنید. تمام تغییراتی که در افزونه ایجاد می‌کنید، که در واقع یک پیکربندی است.

در حالت 1C: Enterprise، شما به سادگی برنامه افزودنی خود را به پیکربندی استاندارد متصل می کنید. پلت فرم به طور خودکار، در حالت 1C: Enterprise، برنامه افزودنی شما را با یک پیکربندی معمولی ترکیب می کند. در نتیجه، مشتری با یک راه حل استاندارد اصلاح شده، مطابق با خواسته خود کار می کند.

هنگامی که یک فروشنده نسخه جدیدی از پیکربندی عمومی را منتشر می‌کند، به‌روزرسانی خودکار انجام می‌شود زیرا حالت پشتیبانی از پیکربندی عمومی تغییر نکرده است. او در حمایت کامل تامین کننده باقی ماند. و هنگامی که یک راه حل برنامه به روز شده را راه اندازی می کنید، پلت فرم دوباره به طور خودکار پیکربندی معمولی تغییر یافته را با برنامه افزودنی شما ادغام می کند. و مشتری با یک راه حل استاندارد اصلاح شده مطابق با خواسته خود به کار خود ادامه خواهد داد.

چه زمانی باید از افزونه ها استفاده کنید؟

مکانیسم گسترش به دلیل تطبیق پذیری وسوسه انگیز است. بنابراین، مهم است که تصور درستی از چه وظایفی داشته باشید.

اولا، زمانی که راه حل اعمال شده در حالت اشتراک داده کار می کند، برنامه های افزودنی ضروری هستند. مثلا در مدل سرویس. یکی از مشترکین می خواهد چند گزارش اضافی داشته باشد. در حالی که سایر مشترکین می خواهند با پیکربندی استاندارد بدون تغییر کار کنند.

سپس برای این مشترک است که می توانید یک برنامه افزودنی ایجاد کنید که در آن تمام خواسته های او را محقق کند. مشترک این افزونه را به خود متصل می کند و با پیکربندی تغییر یافته کار می کند. در حالی که برای سایر مشترکین هیچ تغییری رخ نخواهد داد. زیرا همه پسوندها در چارچوب مقادیر جداکننده فعلی متصل و راه اندازی می شوند.

وضعیت دیگر تکمیل یک پیکربندی معمولی برای یک مشتری خاص در اجرای او است. یا بهبودهایی در پیکربندی استاندارد که توسط متخصصان فناوری اطلاعات مشتری به تنهایی انجام می شود. اگر همه این بهبودها در برنامه افزودنی انجام شود، پیکربندی معمولی به طور کامل پشتیبانی می‌شود، که نگهداری بیشتر آن را بسیار ساده‌تر می‌کند.

وسوسه استفاده از برنامه های افزودنی برای ایجاد راه حل های کاربردی تکراری وجود دارد، اما شما نباید این کار را انجام دهید. اولاً، زیرا برنامه های افزودنی برای چنین کارهایی طراحی نشده اند. و ثانیاً، زیرا سایر مکانیسم‌های پلتفرم، مانند مکانیسم‌های تحویل و پشتیبانی، چیزی در مورد افزونه‌ها نمی‌دانند.

اگر کمی به تاریخچه ظهور افزونه ها نگاه کنید، مطمئناً قبلاً دیده بودیم و اکنون می بینیم که پیکربندی ها پیچیده تر می شوند. ما می بینیم که حمایت بیشتری مورد نیاز است سطوح مختلفپیشرفت ها: کتابخانه، مدولار و صنعت و غیره ما تمام این وظایف را تجزیه و تحلیل کردیم و به این نتیجه رسیدیم که بالاترین اولویت در حال حاضر، انطباق تنظیمات با خواسته‌های کاربران در حین پیاده‌سازی است.

برای این کار است که ما مکانیسم توسعه را ایجاد کردیم. البته، در آن شما می توانید ویژگی های مختلف سایر زمینه های توسعه ذکر شده را مشاهده کنید. اما آنها هدف اصلی آن نیستند و نباید شما را گیج کنند.

اکنون چه چیزی را می توان با کمک برنامه های افزودنی تغییر داد؟

تاکنون در مورد آنچه که قرار است انجام شود، کار زیادی انجام نشده است. مکانیسم، البته، تکامل خواهد یافت. اما آنچه قبلا انجام شده است می تواند در بسیاری از موارد در پیاده سازی ها مفید باشد. اکنون:

• میتونه تغییر داده بشه فرم های مدیریت شده، موجود در یک پیکربندی معمولی؛
• می توانید جدید اضافه کنید زیر سیستم ها. می توانید ترکیب زیرسیستم های موجود را در یک پیکربندی معمولی تغییر دهید.
• میتونه تغییر داده بشه نقش هایک پیکربندی معمولی با اضافه کردن اشیاء ایجاد شده در پسوند به آنها.
• میتونه تغییر داده بشه رابط فرمانپیکربندی معمولی (پارتیشن اصلی، زیرسیستم ها)؛
• می توانید جدید اضافه کنید گزارش هاو در حال پردازش.

در آینده، ما قصد داریم به تدریج عملکرد برنامه های افزودنی را افزایش دهیم و خوشحال خواهیم شد که نظر شما را در مورد اینکه کدام عملکرد برای پیاده سازی ها با تغییرات جزئی بیشترین تقاضا را دارد، دریافت کنیم.

پسوند چگونه ساختار یافته است؟

پسوند بسیار شبیه به پیکربندی معمولی است. همچنین به عنوان درختی از اشیاء نشان داده می شود. برای کار با افزونه، از همان روش های کار مانند پیکربندی معمول استفاده می شود.

یکی از ویژگی های مهم افزونه حضور است اشیاء قرض گرفته شده. شما می توانید هر شی از یک پیکربندی معمولی را با استفاده از دستور منوی زمینه قرض بگیرید:

اشیاء قرضی همیشه مورد نیاز نیستند. بهترین راه برای توضیح این موضوع با مثال «خانگی» است، اگر با ناهار در رستوران تشبیه کنیم.

اولین وضعیت زمانی است که اشیاء قرض گرفته شده مورد نیاز است.

شما به خوردن ناهار در همان رستوران عادت کرده اید. شما همیشه استیک و چای سفارش می دهید. مثلاً چون در این رستوران خیلی خوب هستند. یا به دلایل دیگری. مهم نیست. تنها چیزی که مهم است این است که شما آنها را بخورید، نه چیز دیگری.

سپس رستوران یک پایگاه اطلاعاتی معمولی است. شما یک فرمت هستید. منوی رستوران یک پیکربندی استاندارد قابل توسعه است. استیک بیفت و چای اشیایی قرضی هستند. شما آنها را قرض گرفته اید (به یاد داشته باشید که آنها در منو هستند).

چگونه افزونه به پیکربندی متصل می شود و چگونه کار می کند؟ شما به یک رستوران می روید و منو می خواهید. در منو می بینید که یک استیک و چای وجود دارد. به این معنی که شما یک تناظر بین اشیاء قرضی و اشیاء با یک پیکربندی معمولی برقرار می کنید. طبیعتاً شما با نام مطابقت دارید :). برایت استیک و چای می آورند، تو می خوری. یعنی افزونه متصل است و کار می کند.

یک هفته بعد شما می آیید، اما منوی رستوران تغییر کرده است (پیکربندی استاندارد به روز شده است). با این حال، منو همچنان شامل استیک و چای است. آنها دقیقا همان چیزی هستند که شما نیاز دارید. آنها را برای شما می آورند، شما آنها را می خورید. یعنی برنامه افزودنی با پیکربندی معمولی به روز شده به کار خود ادامه می دهد.

یک هفته بعد، به یک رستوران می آیید و می بینید که استیک و چای از منو محو شده اند. شما بلند می شوید و می روید (پیام خطای اتصال برنامه افزودنی). چون تو آنها را می خواستی و هیچ ایده ای در مورد سایر ظروف (اشیاء) ندارید. توسعه دهنده به شما یاد نداده است که چگونه حلزون ها یا خرچنگ ها را به درستی بخورید.

موقعیت دیگری که در آن می توانید بدون اشیاء قرضی انجام دهید.

شما به یک رستوران می روید، اما علاقه ای به در دسترس بودن غذاهای خاص ندارید. چون به هر حال قرار نیست آنها را بخورید. شما فقط می خواهید از آنها عکس بگیرید. و شما می دانید که چگونه از هر ظرفی عکس بگیرید. سپس فقط به پیکربندی متصل می‌شوید و می‌گویید هر خوراکی را در منو دارید بیاورید (مجموعه اسناد را از ابرداده دریافت کنید). من براشون میفرستم (عکس بگیر).

اگر این را به زبان خشک توسعه دهندگان توصیف کنید، معلوم می شود که باید اشیاء را قرض بگیرید:

• زمانی که برای طراحی بصری مورد نیاز هستند. به عنوان مثال، شما یک فرم را گسترش می دهید و مواردی مانند فرم را اضافه می کنید ReferenceCurrency.Link. سپس مطمئناً باید یک کتاب راهنما قرض بگیرید ارزها، به طوری که هنگام اتصال به یک پیکربندی معمولی، می توانید مطمئن شوید که چنین دایرکتوری همچنان در آن وجود دارد.
• زمانی که برای کارکرد کد مورد نیاز هستند. به عنوان مثال، در کد پسوند، به ویژگی مرجع اشاره می کنید نامگذاری - وارد کننده. سپس این ویژگی نیز باید قرض گرفته شود تا هنگام اتصال مطمئن شویم که در پیکربندی معمولی چنین ویژگی همچنان در فهرست وجود دارد. نامگذاری.

اتصال یک افزونه

شما یک پسوند در پیکربندی ایجاد می کنید. پس از رفع اشکال و آزمایش، می توانید با ذخیره پسوند در یک فایل *.cfe آن را رد کنید.

شما می توانید این فایل را برای مشتری ارسال کنید. مشتری به طور مستقل آن را در پایگاه اطلاعاتی خود در حالت 1C: Enterprise با استفاده از عملکرد استاندارد آپلود می کند. مدیریت برنامه های افزودنی پیکربندی.

کار با برنامه های افزودنی از زبان داخلی در دسترس است، بنابراین در راه حل کاربردی می توانید پردازش خود را ایجاد کنید که افزونه ها را بارگیری می کند. برای جلوگیری از "بازی کردن" همه با برنامه های افزودنی، یک حق جدید اضافه کردیم - مدیریت پسوندهای پیکربندی.

هنگام بارگیری پسوند از یک فایل، در آن ذخیره می شود پایگاه اطلاع رسانی. علاوه بر این، در زمینه مقادیر فعلی جداکننده های استفاده شده در این جلسه ذخیره می شود.

برای اینکه برنامه افزودنی کار کند، جلسه باید دوباره راه اندازی شود. در شروع جلسه، درست قبل از فراخوانی رویداد SettingSessionParameters، تمام پسوندهای ذخیره شده در پایگاه اطلاعاتی و مربوط به مقادیر جداکننده جلسه فعلی گنجانده خواهد شد.

در نتیجه، هنگام کار در حالت اشتراک داده، برنامه افزودنی فقط برای کاربران این مشترک خاص اعمال می شود. و اگر از جداسازی داده ها استفاده نشود، پسوند برای همه کاربران پایگاه اطلاعاتی کار خواهد کرد.

همانطور که قبلاً گفتیم هنگام اتصال یک افزونه، کنترل می شود که اشیاء قرضی در یک پیکربندی معمولی وجود داشته باشد. اشیاء با نام مطابقت دارند.

علاوه بر این، کنترل دقیق تر نیز امکان پذیر است. شما می توانید نه تنها وجود اشیاء، بلکه وضعیت خصوصیات فردی آنها را نیز کنترل کنید. یعنی اگر به یک رستوران و یک استیک فکر می کنید، ممکن است برای شما نه فقط وجود یک استیک پخته شده مهم باشد، بلکه دقیقاً این واقعیت است که در اینجا نپخته، "با خون" پخته می شود.

با بازگشت به برنامه افزودنی، به طور پیش فرض ویژگی های اشیاء قرض شده را کنترل نمی کند. اما در صورت نیاز، می توانید برخی از ویژگی ها را قابل کنترل کنید. به عنوان مثال، برای الگوریتم شما مهم است که نه تنها یک فهرست وجود داشته باشد نامگذاری، بلکه کد آن از نوع است خط.

سپس اگر در یک پیکربندی معمولی، تامین کننده نوع کد این دایرکتوری را به آن تغییر دهد عدد، برنامه افزودنی شما این را در زمان اتصال تشخیص می دهد و یک خطا را گزارش می کند.

یک نکته جالب مربوط به تغییر نام اشیاء پیکربندی معمولی است. به عنوان مثال، شما به یک رستوران آمدید، و به جای منو استیکنوشته شده است استیک. یعنی هنگام اتصال به پیکربندی، افزونه دایرکتوری را در آن پیدا نمی کند. نامگذاری، زیرا فروشنده نام آن را به محصولات.

حالا این وضعیت برای شما مشکلی ندارد. و شما مجبور نیستید همه کد برنامه افزودنی را "بیل کنید" تا به جای آن نامگذارینوشتن محصولات. آثار و. بنابراین شما فقط باید نام شیء قرض گرفته شده را به تغییر دهید محصولات، و پلتفرم بقیه تغییرات را در خود افزونه انجام می دهد. یا با حداقل کمک شما.

کار توسعه

شما می توانید برای مدت طولانی در مورد ویژگی های پسوند اشیاء مختلف، در مورد ویژگی های کار خود پسوندها صحبت کنید. اما دامنه مقاله مروری ما محدود است، بنابراین فقط به نکات کلیدی و آشکار کننده می پردازیم.

"جذابیت" اصلی افزونه ها البته این نیست که بتوانید چیزی را به پیکربندی معمولی اضافه کنید که در آن نیست. و این واقعیت که در برنامه افزودنی می توانید آنچه را که قبلاً در پیکربندی معمولی است تغییر دهید. یعنی می توانید ویژگی های اشیاء قرض گرفته شده را تغییر دهید.

مفهوم اصلی مورد استفاده در هنگام کار با پیکربندی و افزونه را می توان به شرح زیر توصیف کرد. در مکان هایی که "تقاطع نمی کنند"، پسوند پیکربندی را تکمیل می کند. در مکان هایی که آنها "تقاطع" دارند - پسوند اعمال می شود.

می توانید این را با جزئیات بیشتری در مثال فرم های مدیریت شده مشاهده کنید. می توانید فرمی را از پیکربندی اصلی قرض بگیرید و بدون محدودیت آن را در پسوند ویرایش کنید. برای بخش بصری فرم و برای ماژول آن، از دو استراتژی ادغام متفاوت استفاده می شود.

قسمت بصری فرم در لحظه قرض گرفتن در پسوند ثابت می شود. و در حالت 1C: Enterprise، برای هر عنصر فرم، تغییرات نسبت به این حالت در پیکربندی استاندارد و در پسوند تجزیه و تحلیل می شود.

اگر هیچ تغییری وجود نداشت، یا فقط در پیکربندی معمولی بود، مقدار از پیکربندی معمولی اعمال می‌شود. در غیر این صورت از مقدار پسوند استفاده می شود.

بنابراین، اگر یک دستور جدید به فرم در پسوند اضافه کنید، آن را به همراه بقیه دستورات فرم خواهید دید. و اگر عنوان یک گروه موجود را تغییر دهید، حتی اگر فروشنده عنوان این گروه را در یک پیکربندی معمولی تغییر دهد، عنوان خود را خواهید دید.

ماژول های فرم رویکرد متفاوتی دارند. برای یک فرم قرض گرفته شده، برنامه افزودنی ماژول خود را با کنترل کننده های خود برای همه رویدادها ایجاد می کند. در حالت 1C: Enterprise، هر دو ماژول فرم (از پیکربندی استاندارد و از پسوند) در یک زمینه ترکیب می شوند. به همین دلیل، هر افزونه پیشوند مخصوص به خود را دارد که به کنترل کننده های همه رویدادها در ماژول فرم اضافه می شود. به طوری که هیچ منطبقی با کنترل کننده از پیکربندی معمولی وجود ندارد. پس از آن، کنترل کننده های رویداد و فرمان به صورت متوالی و همزمان فراخوانی می شوند. اول، کنترل کننده از پسوند. سپس از پیکربندی معمولی. شما می توانید این دنباله را تغییر دهید، یا به طور کامل اجرای کنترل کننده را از پیکربندی معمولی ممنوع کنید.

به طور کلی، با توجه به کار مشترک پیکربندی و پسوند در حالت 1C: Enterprise، آنها در یک فضای نام مشترک وجود دارند. این نه تنها برای تک تک ماژول ها، بلکه در مورد درخت های ابرداده نیز صدق می کند. بنابراین، هیچ راهی در حالت 1C: Enterprise برای تعیین اینکه آیا این شیء برای یک پیکربندی معمولی "بومی" است یا اینکه از یک برنامه افزودنی آمده است وجود ندارد.

در مورد بقیه اشیایی که می توانید در افزونه استفاده کنید، همه چیز برای آنها بسیار ساده تر به نظر می رسد.

در افزونه، می توانید زیرسیستم های خود را ایجاد کنید. با استفاده از اشیاء قرض‌گرفته‌شده، می‌توانید زیرسیستم‌های موجود را گسترش دهید: اشیا و زیرسیستم‌هایی را که قبلاً در پیکربندی استاندارد هستند یا آن‌هایی را که در برنامه افزودنی ایجاد کرده‌اید به آنها اضافه کنید. شما نمی توانید چیزی را از یک زیرسیستم موجود حذف کنید.

شما فقط می توانید نقش ها را با افزودن اشیاء ایجاد شده در پسوند به آنها گسترش دهید. شما نمی توانید چیزی را از یک نقش موجود حذف کنید. همین امر در مورد رابط فرمان نیز صدق می کند.

یک برنامه افزودنی تقریباً یک پیکربندی است

در ابتدا گفتیم که یک افزونه شبیه به یک پیکربندی معمولی است. بنابراین، در پایان، می خواهم چند کلمه در مورد نحوه ادغام افزونه ها با مکانیسم های پلت فرم دیگر بگویم.

یک برنامه افزودنی (مانند یک پیکربندی معمولی) دارای یک پیکربندی اصلی و یک پیکربندی پایگاه داده است. مکانیسم مقایسه و ادغام پیکربندی ها با افزونه ها به همان روشی که با پیکربندی های معمولی کار می کند.

می‌توانید پسوند را در یک فایل بارگیری کنید (اما، با پسوند *.cfe متفاوت)، و از یک فایل بارگیری کنید. برنامه های افزودنی را می توان در XML بارگیری / بارگیری کرد.

مکانیسم های جستجوی جهانی، جایگزینی، ویرایش متون رابط نیز با پسوندها کار می کنند.

گزینه های خط فرمان جدیدی برای کار با برنامه های افزودنی و همچنین رویدادهای جدید در گزارش وجود دارد.

در زبان داخلی، هدف اصلی برای کار با پسوندها است پیکربندی مدیر برنامه افزودنی.

ما نسخه جدیدی از پنل تلفن را برای 1C منتشر کرده ایم.

• نسخه 1.2.24.10 برای معمولیبرنامه های کاربردی
• نسخه 1.4.26.17 برای اداره می شودبرنامه های کاربردی

در نسخه منتشر شده برای یک برنامه مدیریت شده، امکان تعبیه پنل تلفن با آن فراهم شد حداقل تغییراتپیکربندی اولیه با مکانیزم انبساطپیکربندی

مزایای استفاده از افزونه

پسوند بسیار شبیه به پیکربندی معمولی است. برای کار با آن، از همان روش های کار مانند پیکربندی معمول استفاده می شود. برنامه‌های افزودنی عمدتاً برای سهولت در ایجاد تغییرات در برنامه ایجاد می‌شوند. حالا دیگر لازم نیست «تکه‌هایی از کد» را در ماژول‌های خاصی وارد کنید و اشیاء ابرداده جدیدی را اضافه کنید، فقط یک پسوند به پیکربندی اضافه کنید.

مزیت بزرگ استفاده از افزونه ها این است به روز رسانی خودکارپیکربندی اصلی اکنون نیازی به تغییر تنظیمات پشتیبانی برای یک پیکربندی معمولی نیست.

ویژگی های تعبیه پنل تلفن برای 1C

چنین ویژگی‌هایی برای برنامه‌های افزودنی برای پلتفرم در دسترس قرار گرفتند که از نسخه شروع شد 8.3.9.1818 . بنابراین، برای استفاده از این، حالت سازگاری افزونه را از زمان نسخه غیرفعال کردیم 8.3.9 هنوز پشتیبانی نشده است بر این اساس، غیرفعال کردن حالت سازگاری برای پیکربندی اصلی ضروری است، در غیر این صورت خطایی رخ می دهد: " حالت سازگاری پسوند پیکربندی بیشتر از حالت سازگاری پیکربندی اصلی است".

2) در پیکربندی اصلی، نقش را اضافه می کنیم MIKO_Softphone، که همه حقوق مربوط به آن را حذف می کنیم.

هنگام اضافه کردن یک شی ابرداده جدید، در این مورد یک نقش، لازم است دایرکتوری را به روز کنید شناسه های شیء فراداده. وقتی این نقش را به افزونه اضافه کردیم، پیکربندی‌های معمولی آن را نادیده گرفتند، یعنی هنگام به‌روزرسانی پوشه MetadataObjectIdentifiers، نقش در آن ظاهر نشد. به همین دلیل، مکانیسم پروفایل تنظیمات پنل تلفن به درستی کار نکرد، یک خطا رخ داد: " شناسه شی فوق داده برای نقش MIKO_Softphone یافت نشد".

علاوه بر این، این وضعیت در همه پیکربندی ها رخ نداده است "مدیریت تجارت، 11.2.3.218"و "اتوماسیون یکپارچه، 2.0.3.222"وقتی نقش به خود افزونه اضافه شد مشکلی با آن وجود نداشت. برای ارائه مقداری تطبیق پذیری در راه حل خود و اطمینان از عملکرد روان در اکثر پیکربندی هایی که پشتیبانی می کنیم، تصمیم گرفتیم این نقش را اضافه کنیم. MIKO_نرم افزاروارد پیکربندی اصلی شده و آن را در برنامه افزودنی قرض بگیرید و سپس تنظیمات این نقش را در برنامه افزودنی اجرا کنید.

یک ویژگی بسیار مهم این واقعیت است که اگر پس از جاسازی افزونه ما، می خواهید پنل را طبق دستورالعمل های قدیمی ما جاسازی کنید، باید افزونه را غیرفعال کنید و نقش MIKO_softphone را حذف کنید. اگر می خواهید دوباره از افزونه استفاده کنید، ابتدا باید نقش را اضافه کنید و سپس افزونه را اضافه کنید.

خلاصه کردن

حتی با در نظر گرفتن امکان تغییر پیکربندی اصلی و ایجاد حداقل تغییرات در پیکربندی، ما فرآیند تعبیه پنل تلفن را بسیار آسان کرده ایم. اکنون نیازی به ایجاد تغییرات در ماژول های برنامه مدیریت شده، اضافه کردن پردازش و زیرسیستم ها به پیکربندی، یا تنظیم نقش ها ندارید. افزونه همه این کارها را برای شما انجام خواهد داد! ما به بهبود روند تعبیه پنل تلفن برای 1C ادامه خواهیم داد!

دستورالعمل تعبیه یک پنل تلفن برای 1C با استفاده از مکانیزم گسترش قرار دارد.

سوالات خود را از طریق فرم بازخورد بپرسید.

© 2019. MIKO LLC کلیه حقوق محفوظ است.