اصلاح تنظیمات استاندارد 1c. افزودن عناصر از پیش تعریف شده

آیا نیاز به گسترش عملکرد 1C دارید؟ آیا برای حل مشکلات نه تنها استاندارد، بلکه مشکلات خاص شرکت خود به این برنامه نیاز دارید؟ سرویس اصلاح 1C از Active-IT به شما کمک می کند تا به سرعت این مشکلات را حل کنید.

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

زمان چرخش- تا 5 روز در صورت تاخیر تا 10 روز، ما به صورت رایگان برای شما بازبینی می کنیم.

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

هزینه برنامه نویس 1C

هزینه تغییر پیکربندی: 1500 روبل. در هر ساعت کار برنامه نویس

در نتیجه دریافت می کنید:

همکاری با برنامه نویسان مجرب
ایجاد و اجرای اصلاحات کاملاً با هر سطح پیچیدگی.
اتمام کار در کوتاه ترین زمان ممکن - حداکثر تا 5 روز.
ضمانت بازگشت وجه در صورت تاخیر.
تضمین کیفیت.

تغییرات حسابداری 1C را از Active-IT سفارش دهید!
با ما کار 1C را مطابق با ویژگی های شرکت خود سفارشی کنید.

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

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

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

1. مفهوم به حداقل رساندن "تخریب" یک پیکربندی استاندارد

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

2. تغییر کد نظر دادن:

مطلقاً تمام تغییرات در کد برنامه ماژول ها باید نظر داده شود. یک بلوک از خطوط که دستخوش تغییر شده است باید با خطوط نظر با فرمت خاص احاطه شود. اصل تشکیل این خطوط در مثال نشان داده شده است:

//++ VION 07/20/2016 0001234 نهایی شدن در شروع //-- VION 07/20/2016

//++ - شروع بلوک
//— - پایان بلوک
VION - نام (یا نام مستعار) توسعه دهنده
0001234 - شماره کار مطابق با ردیاب، فقط در کامنت آغازین قرار داده شده است، به طوری که هر تغییر کد در نتایج جستجوی سراسری بر اساس شماره کار فقط یک بار ظاهر می شود.
بهبود در آغاز- یک نظر دلخواه، در صورت لزوم استفاده می شود، اما اگر شماره کار وجود ندارد، یک متن توضیحی کوتاه لازم است

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

نظرات حاشیه در لبه سمت چپ بلوک کد ویرایش شده تراز می شوند. مثال‌های زیر نحوه استفاده از نظرات تغییر را نشان می‌دهند:

2.1 درج کد

مثال:

رویه Opening() اگر این () New است، سپس فیلدها را به صورت پیش فرض پر کنید(); endIf; SetFormElements(); //++ VION 07/20/2016 0001234 ConfigureAdditionalElements(); //-- VION 07/20/2016 SetFieldVisibility ()؛ پایان رویه

2.2 حذف کد

مثال:

رویه OnOpen() //++ VION 07/20/2016 0001234 //اگر این جدید است() سپس // فیلدهای پیش فرض را پر کنید(); //EndIf; ConfigureAdditionalItems(); //-- VION 07/20/2016 SetFieldVisibility ()؛ پایان رویه

2.3 اصلاح کد موجود

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

مثال:

رویه OnOpen() اگر This New() است سپس //++ VION 07/20/2016 000123 //پر کردن فیلدها به صورت پیش فرض(); FieldFillSetting = GetFieldFillSetting(); FillFieldsDefaultExtended(SettingFillFields); //-- VION 07.20.2016 EndIf; SetFormElements(); SetFieldVisibility ()؛ پایان رویه

2.4 افزودن رویه ها و توابع به یک ماژول

برای رویه ها و توابع اضافه شده و همچنین برای اعلام متغیرهای ماژول اشیاء استاندارد، موارد زیر اعمال می شود: قوانین اضافیقالب بندی نظرات:

این بلوک رویه های اضافه شده به عنوان یک کل نیست که در مورد آن نظر داده می شود، بلکه هر یکرویه یا عملکرد اضافه شده در بصورت جداگانه.
کامنت آغازین روی خط قبل از رویه یا هدر تابع می رود و کامنت پایانی می رود در همان خط، جایی که می گوید "End of Procedure" یا "End of Procedure" که با یک فاصله از هم جدا شده است.
اظهار نظر در مورد تغییرات در رویه های موجود با استفاده از انجام می شود قوانین عمومی.

مثال:

//++ VION 07/20/2016 000123 متغیر mSettingField Filling; رویه ModifyFormProgrammatically () ... ... پایان رویه//-- VION 07/20/2016 //++ VION 07/20/2016 000123رویه DateShipmentProcessingSelection () ... ... پایان رویه//-- VION 07/20/2016

این قانون به شما اجازه می دهد تا به راحتی تغییرات را در یک ماژول در "مقایسه رویه ای" پیکربندی ها منتقل کنید.

اگر نظر پایانی را در خط بعدی قرار دهید:

سپس در طی "مقایسه رویه ای"، این نظر به عنوان شرح رویه بعدی در متن شناخته می شود که تغییر یافته در نظر گرفته می شود.

3. اضافه کردن اشیاء سطح بالا

نام ها اشیاء سطح بالا،ایجاد شده در پیکربندی، لزوماباید با پیشوند شرکت شما یا پیشوند پروژه خاص شروع شود. به عنوان یک قاعده، از دو یا سه تشکیل می شود حروف بزرگو برای مثال تاکید می کند AB_. بر این اساس، اشیاء ایجاد شده فراخوانی خواهند شد AB_دایرکتوری جدید, AB_NewInformationRegister, AB_NewDocumentو غیره.

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

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

مثال: یک دایرکتوری "پروژه ها" ایجاد کنید.

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

نام: AB_Projects
مترادف: (AB) پروژه ها

4. اضافه کردن اشیاء فرعی

روش افزودن جزئیات شیء پیکربندی بستگی به این دارد که ویژگی به کدام شیء پیکربندی اضافه شود: به یک شیء پیکربندی ایجاد شده توسط تامین کننده راه حل استاندارد(به عنوان مثال یک شی تحت پشتیبانی) یا یک شی که به عنوان بخشی از پروژه فعلی اضافه شده است (یعنی قبلاً یک پیشوند دارد).

4.1 افزودن اشیاء فرعی به اشیاء پیکربندی استاندارد

اشیاء فرعی اضافه شده به اشیاء پیکربندی موجود (استاندارد) باید پیشوند شود: AB_لوازم اضافی, AB_NewTabularPart, AB_FormUserSettings, AB_LayoutSpecialInvoice. اما در عین حال مترادف هایی از چنین اشیاء فرعی ایجاد می شود بدون پیشوند.

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

مثال: ویژگی «پروژه» سند «پیش پرداخت» را ایجاد کنید.

اقدامات توسعه دهنده: ویژگی زیر در پیکربندی ایجاد می شود:

نام: AB_Project
مترادف: پروژه
نظر: // VION 07/20/2016 000123

4.2 افزودن اشیاء فرعی به اشیاء اضافه شده در پروژه

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

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

مثال: ویژگی “Responsible” را در فهرست “(AB) Projects” ایجاد کنید.

اقدامات توسعه دهنده: اگر کار با کاری که در آن دایرکتوری "(AB) Projects" ایجاد شده است متفاوت باشد، جزئیات زیر در پیکربندی ایجاد می شود:

نام: مسئول
مترادف: مسئول
نظر: // VION 07/20/2016 000456

5. اضافه کردن عناصر از پیش تعریف شده

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

5.1 افزودن عناصر از پیش تعریف شده به اشیاء پیکربندی استاندارد

عناصر از پیش تعریف شده برای اشیاء پیکربندی معمولی لزوماً اضافه می شوند با پیشوند. نام داده شده است بدون پیشوند.

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

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

نام: AB_FormsStrictReporting
کد: 10.15
نام: فرم های گزارش دقیق

اگر نیاز به تغییر نام یک عنصر از پیش تعریف شده از یک شیء پیکربندی معمولی دارید (مثلاً یک فاکتور)، باید خود شیء را بدون تغییر رها کنید و تغییر نام را به صورت برنامه ای در یک خاص انجام دهید.

5.2 افزودن عناصر از پیش تعریف شده به اشیاء اضافه شده در پروژه

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

6. استفاده از ماژول های رایج و ساختار دقیق آنها

رویه ها و عملکردهایی که به طور مکرر در پیکربندی استفاده می شوند، پردازنده های اشتراک ها و کارهای معمول در ماژول های رایج قرار دارند. برای این اهداف باید اضافه کنید ماژول های خود، توسط اشیاء سطح بالا اضافه شده و ماژول های استاندارد باقی می مانند بدون تغییر. ماژول های کلی زیر ("AB_" پیشوند است) در طول توسعه مفید خواهند بود:

AB_هدف عمومی (مشتری، سرور، اتصال خارجی) - برای تطبیق رویه ها و عملکردهای رایج.
AB_سرور (فقط سرور) - برای رویه ها و توابعی که باید در محیط سرور اجرا شوند.
AB_Global - برای رویه ها و عملکردهایی که برای فراخوانی به روش استاندارد (از طریق نام ماژول و دوره) ناخوشایند هستند.
AB_ممتاز - برای رویه ها و عملکردهایی که همیشه باید با حقوق کامل اجرا شوند.
AB_استفاده مجدد - برای کش کردن مقادیر بازگشتی برخی از توابع.

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

7. استفاده از اشتراک و ساختار سختگیرانه آنها

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

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

رویه کنترل کننده اشتراک باید شامل فراخوانی به رویه های فرعی باشد که اقدامات لازم را انجام می دهند. آنها بسته به نوع منبع و همچنین در ترتیب مورد نیاز قابل دسترسی هستند. اظهار نظر در ماژول اشتراک هنگام اضافه کردن کد برای کارهای جدید انجام می شود.

مثال: هنگام ارسال سند "پیش پرداخت"، در ثبت انباشت "هزینه های پروژه (AB)" ثبت کنید.

اقدامات توسعه دهنده:

1. یک اشتراک "AB_DocumentsProcessingProcessing" ایجاد کنید (اگر چنین اشتراکی قبلا ایجاد نشده باشد)، همه اسناد را به عنوان منبع مشخص کنید، رویداد "ProcessingProcessing" است.

2. یک ماژول سرور مشترک "AB_DocumentsProcessing" ایجاد کنید.

3. در ماژول، یک رویه صادراتی "ProcessingProcessing" ایجاد کنید. این روش را به عنوان یک کنترل کننده برای اشتراکی که قبلا ایجاد شده است انتخاب کنید. در رویه، بسته به نوع سند، کنترل کننده های لازم فراخوانی می شوند.

4. ماژول سند "پیش پرداخت" باید بدون تغییر باقی بماند.

8. ویرایش فرم ها

8.1 ویرایش اشکال اشیاء استاندارد

اگر تغییر به یک فرم استاندارد (اعم از معمولی و مدیریت شده) کوچک باشد (مثلاً اضافه کردن چندین جزئیات جدید به فرم)، آنگاه چنین تغییری باید کاملاً برنامه‌ریزی شود. یعنی تغییرات فقط به ماژول فرم، و خود فرم در پیکربندی باقی می ماند بدون تغییر. برخی از توسعه دهندگان ممکن است این روش ویرایش فرم را در ابتدا بسیار دست و پا گیر بدانند. با این حال، داشتن تجربه کافی در تغییر فرم ها از نظر برنامه ریزی، اضافه کردن یک عنصر بیش از 3-5 دقیقه طول نمی کشد. زمان صرف شده با به روز رسانی های بعدی پیکربندی استاندارد چندین برابر می شود.

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

اقدامات توسعه دهنده: در کنترل کننده فرم "When CreatedOnServer" رویه "EditFormProgrammatically()" را اضافه کنید. در این روش عنصر مورد نظر را به عناصر فرم اضافه کنید.

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

در پیکربندی‌های معمولی مبتنی بر BSP 2، از قبل عملکرد ویژه‌ای برای این اهداف وجود دارد:

در رویه «When CreateOnServer» ماژول عمومی «تغییر پیکربندی لغو شد» می‌توانید با کنترلر خود تماس بگیرید.

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

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

8.2 ویرایش اشکال اشیاء اضافه شده در پروژه

اشکال اشیاء اضافه شده در پروژه (یعنی آنهایی که پیشوندی در نام خود دارند) به روش معمول ویرایش می شوند.

9. اصول کار با نقش ها

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

حقوق به اشیاء اضافه شده به پیکربندی باید اختصاص داده شود در جدیدنقش هایی که برای این منظور ایجاد شده اند.

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

10. گزارش های خارجی و پردازش

بیشتر پیشرفت‌ها در سیستم را می‌توان با استفاده از گزارش‌های اضافی و مکانیزم پردازش انجام داد.

در پیکربندی های مبتنی بر BSP 2 (ERP، UT 11، BP 3.0، ZUP 3.0، و غیره) این مکانیسم به طور قابل توجهی گسترش یافته است. با کمک آن، بدون تغییر پیکربندی، می توان گزارش ها و پردازش های خارجی ایجاد کرد (با قرار دادن دستور راه اندازی در رابط فرمان و امکان پیکربندی دسترسی برای کاربران مختلف)، پردازش پر کردن یک سند، پردازش ایجاد یک سند بر اساس، فرم های چاپی اضافی و غیره.

آیا این مقاله به شما کمک کرد؟

1C 8.2 و 8.3 بسیار قابل توجه است مزیت رقابتی- امکان تغییر تنظیمات استاندارد 1C و توسعه راه حل های خود بر اساس پلت فرم. این به لطف محیط توسعه داخلی به دست آمده است.

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

معمولاً چه کارهای جدیدی در 1C انجام می شود؟

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

نمونه هایی از تغییرات در 1C 8.3:

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

قیمت یک ساعت کار متخصص 1C

هزینه کار برای اصلاح تنظیمات استاندارد 1C معمولاً بر حسب ساعت کار برآورد می شود.

خب، بقیه، به گربه خوش آمدید.

قوانین و تکنیک هایی برای نهایی کردن پیکربندی های استاندارد 1C برای تسهیل پشتیبانی و به روز رسانی بیشتر آنها

بنابراین، هنگامی که ما پروژه ای را انجام می دهیم (منظورم از کلمه "ما" همه افرادی است که در خودکارسازی فرآیندهای کسب و کار درگیر هستند)، امیدواریم که به آرامی به سمت پشتیبانی جریان یابد. به عنوان یک قاعده، اگر همه چیز به خوبی انجام شود و مشتری راضی باشد، این اتفاق می افتد.

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

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

آیا کسی تا به حال مجبور شده است پیکربندی را که بدون هیچ علامت شناسایی بازنویسی شده است به روز کند؟ آیا درک می‌کنید که مقایسه پیکربندی فروشنده قدیمی با پیکربندی جدید، تجزیه دستی هر مورد «دو بار تغییر» هنگام مقایسه با پیکربندی فعلی و غیره چه دردسری دارد؟ این همه کاملاً مشکل ساز است.

9 قانون ساده برای طراحی تغییرات در تنظیمات استاندارد

1. مفهوم به حداقل رساندن "تخریب" یک پیکربندی استاندارد

اولین مورد حتی یک قانون نیست، بلکه نوعی مفهوم برای به حداقل رساندن "تخریب" یک پیکربندی استاندارد است.

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

2. تغییر کد نظر دادن

قانون دوم این است که l هر تغییر کد باید نظر داده شود.

در شرکت ما از طرح زیر استفاده می کنیم:

در ابتدای تغییر است نظر باز(با علائم شروع می شود //++ )
در پایان - نظر بستن(با علائم شروع می شود //-- )
آ تغییراتی که توسعه دهنده ایجاد کرده در وسط قرار دارد.

این یک قانون اجباری برای هر گونه تغییر است.

نظرات باز و بسته دارای علامت تغییر هستند. این شامل موارد زیر است اجزاء:

پیشوند پروژه- به طور پیش فرض ما از FTO استفاده می کنیم
نام دامنه توسعه دهنده. این بسیار راحت شکل گرفته است: شرکت بزرگ است، توزیع شده است، و اگر توسعه دهنده را نمی شناسید، اما باید از او چیزی در مورد او بپرسید، می توانید نام مستعار او را از این برچسب بگیرید، @fto.com.ru را در آن قرار دهید. حق و نامه ای برای او بفرستید تا با او تماس بگیرید.
بعدی می آید تاریخ اصلاح. هنگامی که تغییرات در چارچوب چندین کار رخ می دهد، این دسته از نظرات می توانند درون یکدیگر قرار بگیرند و همیشه مشخص نیست که این نظر بسته به کدام بلوک بازکننده تعلق دارد، بنابراین ما روی تاریخ تمرکز می کنیم. علاوه بر این، تاریخ بلافاصله نشان می دهد که چه زمانی اصلاح انجام شده است: سه سال پیش، شش ماه پیش یا دیروز.
سپس می آید شماره کار، که فقط در کامنت آغازین قرار داده شده است. چرا فقط اونجا؟ به طوری که در حین جستجوی سراسری بر اساس شماره کار، فقط ابتدای تغییرات کد در انتخاب گنجانده شده است که می توانید از آن به پایین نگاه کنید، در غیر این صورت دو برابر خواهد شد. به عنوان مثال، هنگام ارسال یک کار به بررسی کد، جستجوی خاص بر اساس برچسب بسیار راحت است.

مثال ها

این چیزی است که به نظر می رسد کد را وارد کنید:

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

این چیزی است که به نظر می رسد تغییر کد: ابتدا تمام کد فروشنده کامنت می شود و سپس کد خود شما اضافه می شود.

یک قانون جداگانه کار می کند برای افزودن رویه ها، توابع و متغیرهای ماژول جهانی. در این مورد نظر پایانی در همان خط قرار می گیرد کلمه کلیدیپایان رویه. چرا این کار انجام شد؟ به منظور آسان کردن انتقال تغییرات با استفاده از "مقایسه رویه ای".

در اینجا در تصویر می توانید آن را ببینید با استفاده از "مقایسه رویه ای" می توانید به سادگی این روش را هنگام ادغام برجسته کنید، و به طور کامل (همراه با علائم) منتقل می شود. یا برعکس، می توانید تیک کنار آن را بردارید تا انتقال داده نشود.

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

3. اضافه کردن اشیاء سطح بالا

قانون بعدی اضافه کردن اشیاء سطح بالا (دایرکتوری ها، اسناد، رجیسترها و غیره) به پیکربندی است.

این قانون این است نام اشیا باید با یک پیشوند شروع شود.برای چی؟

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

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

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

خوب، آخرین قانون: نظرات برای همه اشیاء اضافه شده باید دارای یک برچسب خاص با نام توسعه دهنده و شماره کار باشد. این برچسب شبیه نظر آغازین ماژول است، فقط بدون کاراکترهای خاص - با کمک آن همیشه می توانم بفهمم چه کسی، چه زمانی و برای چه کاری این شی را اضافه کرده است.

بنابراین، به طور خلاصه:

نام ها با پیشوند مشخص می شوند،
مترادف - با پیشوند در پرانتز
و نظر باید حاوی یک برچسب خاص باشد.

4. اضافه کردن اشیاء فرعی

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

در اینجا باید فوراً دو موقعیت را برجسته کنیم که در آن یک شیء فرعی اضافه می کنیم:

در یک شیء پیکربندی معمولی
یا به شیئی که قبلاً در پروژه اضافه شده است.

بیایید هر یک از این موقعیت ها را جداگانه در نظر بگیریم.

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

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

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

و در نهایت، نظر همچنین حاوی یک برچسب خاص است، تا مشخص شود کی، کی و چرا.

بنابراین، بیایید نحوه کار اضافه کردن اشیاء فرعی به اشیاء پیکربندی معمولی را خلاصه کنیم:

نام ها با پیشوند مشخص می شوند،
مترادف ها بر اساس قوانین کلی
و نظرات حاوی برچسب خاصی هستند.

آ اگر اشیاء فرعی را به آن اشیایی که قبلاً در پروژه اضافه شده اند اضافه کنیمو قبلاً دارای یک پیشوند در نام خود هستند، سپس:

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

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

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

حال بیایید نحوه اضافه شدن اشیاء فرعی به اشیاء اضافه شده در پروژه را خلاصه کنیم:

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

اگر این قانون را برای هر دو مورد ترکیب کنیم و "آن را به قطعات تقسیم کنیم"، جدول زیر را دریافت می کنیم:

اشیاء جدید:
- نام با یک پیشوند شروع می شود.
- مترادف - با پیشوند در پرانتز.
- نظر حاوی یک برچسب است.
اشیاء فرعی که به اشیاء عمومی اضافه می کنیم:
- نام ها با یک پیشوند شروع می شوند،
- مترادف بر اساس قوانین عمومی
- یک تگ در کامنت بگذارید.
و اگر اشیاء فرعی را به اشیاء اضافه شده در پروژه اضافه کنیم، پس
- هیچ قانون خاصی برای آنها وجود ندارد،
- اما اگر کار متفاوت است، به همین ترتیب یک تگ در کامنت قرار می دهیم.

5. اضافه کردن عناصر از پیش تعریف شده

قانون بعدی اضافه کردن عناصر از پیش تعریف شده است.

در اینجا، دو وضعیت را می توان دقیقاً به یک شکل تشخیص داد:

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

اگر یک عنصر از پیش تعریف شده را به یک شیء پیکربندی عمومی اضافه کنیم,

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

آ اگر عناصر از پیش تعریف شده را به اشیاء اضافه شده در پروژه اضافه کنیم، آن

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

بنابراین، اگر با جدول قبلی قیاس کنیم، آنگاه:

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

6. استفاده از ماژول های رایج و ساختار دقیق آنها

قانون بعدی مربوط به استفاده از ماژول های مشترک و سازماندهی یک ساختار دقیق برای آنها است.

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

ثانیاً لطفاً توجه داشته باشید ماژول های رایج طبق قوانین اضافه کردن اشیاء سطح بالا اضافه می شوند(نام و مترادف با پیشوند، برچسب در نظر و غیره)

سوم، نام ماژول ها باید مشابه ماژول های استاندارد مربوطه باشد.

نیازی به اختراع مجدد چرخ نیست: ما آن را به همان روشی که در تنظیمات استاندارد مرسوم است می نامیم - برای هر عملکرد ماژول خاص خود، مطابق با نامگذاری های پذیرفته شده عمومی در 1C. مثلا:

FTO_General Purpose Client,
FTO_General Purpose Server،
FTO_General Purpose Global,
FTO_RoutineTasksServer
و غیره.

و قدری وظایف فردی بزرگشما می توانید (و احتمالا باید) را در ماژول های مشترک جداگانه قرار دهید.

7. استفاده از اشتراک و ساختار سختگیرانه آنها

قانون بعدی استفاده از اشتراک و ساختار سختگیرانه آنهاست. جوهر آن چیست؟

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

قبل از ضبط
هنگام ضبط
و غیره.

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

اشتراک طبق قوانین توافق شده زیر اضافه می شود:

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

من می توانم با یک مثال به شما نشان دهم. فرض کنید چنین وظیفه ای وجود دارد: هنگام ارسال سند "گزارش پیشرفته"، ورودی هایی را در ثبت انباشته قبلی اضافه کنید.

ابتدا ماژول عمومی FTO_DocumentsProcessingProcessing را طبق تمامی قوانین اضافه می کنیم.

ما DocumentObject (همه اسناد) را به عنوان منبع مشخص می کنیم.
ماژول ما اضافه شده در بالا به عنوان یک کنترل کننده استفاده می شود.

و در حال حاضر در ماژول، در خود کنترل کننده، ما تعیین می کنیم که چه نوع سندی به ما رسیده است و بسته به نوع آن، یک یا روش دیگری را فراخوانی می کنیم.

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

در نتیجه، روند ایجاد اشتراک به شرح زیر است:

یک اشتراک،
یک ماژول مشترک
و هیچ چیز دیگری لازم نیست: ماژول سند بدون تغییر باقی می ماند - دیگر در موارد "دو بار تغییر یافته" ظاهر نمی شود.

8. ویرایش فرم ها

قانون بعدی ویرایش فرم ها است.

در اینجا دو نکته، دو موقعیت را برجسته می کنیم:

وقتی فرم های استاندارد را ویرایش می کنیم.
و زمانی که فرم های اضافه شده در پروژه را ویرایش می کنیم.

حالت اول ویرایش استفرم های استاندارد، اشکال اشیاء معمولی. این بحث برانگیزترین نکته قوانین است. زمانی، در زمان فرم‌های مرسوم، زمانی که پروژه‌ها عمدتاً روی UPP انجام می‌شد، بحث‌های زیادی در مورد اینکه با فرم‌ها چه کنیم، داشتیم. گزینه ها چه بود؟

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

بگذارید با یک مثال به شما نشان دهم. در کنترل کننده OnCreateOnServer، من یک فراخوانی را به رویه خود EditFormProgrammatically اضافه می کنم، جایی که به صورت برنامه ریزی عناصر را به فرم اضافه می کنم.

در پیکربندی های مبتنی بر BSP 2(مانند ERP، حسابداری و غیره) اضافه شد رویداد handlerForm.WhenCreatedOnServer()، که از جمله موارد دیگر جلو می آیدهمچنین به ماژول لغو شده.

و همینطور شما می توانید کد خود را در ماژول لغو اضافه کنید- به عنوان مثال، به رویه WhenCreatingOnServer() . در اینجا نام فرم را تعریف می کنم، و بسته به آن، یک یا روش دیگری را فراخوانی می کنم، جایی که عناصر را به صورت برنامه نویسی اضافه می کنم.

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

علاوه بر این، در پیکربندی‌های مبتنی بر BSP 2، سایر کنترل‌کننده‌های فرم دوباره تعریف می‌شوند - مانند When ReadingOnServer()، BeforeWritingOnServer() و غیره. و در این کنترل کننده ها می توانید به طور فعال از تعریف مجدد رویه های نامیده شده نیز استفاده کنید. علاوه بر این، ماژول بازتعریف شده توسط تامین کننده از نظر تئوری تغییر نمی کند و می توانید کد خود را بدون ترس از درگیری در آنجا بنویسید.

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

9. اصول کار با نقش ها

و آخرین قانون اصول کار با نقش هاست.

اصول کار با نقش ها به شرح زیر است:

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

به عنوان مثال، اگر من نیاز به تغییر RLS داشته باشم، یک کامنت افتتاحیه می‌گذارم، روی کد قدیمی نظر می‌دهم، سپس خودم را اضافه می‌کنم و یک نظر پایانی می‌گذارم. همیشه روشن است: چه کسی، چرا (در چه وظیفه ای) و چه زمانی تغییر کردم.

بنابراین من هر نه را فهرست کرده ام قوانین سادهثبت تغییرات

اشیاء و تکنیک های اضافی برای آسان تر کردن زندگی

در نهایت، برخی از اشیاء و تکنیک‌هایی را که می‌توانند زندگی یک توسعه‌دهنده را آسان‌تر کنند، پوشش می‌دهم.

1. خودشناسی پایگاه های آزمایشی

اولین تکنیک، خودشناسی پایگاه های داده آزمایشی است.

نکته این است:

مقداری ثابت وجود دارد که آدرس پایگاه داده تولیدی کار را ذخیره می کند.
هنگامی که سیستم راه اندازی می شود، این آدرس بررسی می شود: آیا با آدرس پایه کاری مطابقت دارد یا مطابقت ندارد.
و اگر مطابقت نداشت(پایه کار نمی کند)، پس هدر سیستم در حال تعویض است.

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

به این ترتیب، تغییر داده ها در پایگاه های اطلاعاتی را ایمن تر می کنیم.

بعلاوه، همچنین استفاده از بررسی مقدار این ثابت هنگام انجام برخی از کارهای معمول مفید است. برای مثال:

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

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

در پیکربندی های مبتنی بر BSP 2 مکانیسم مشابهی وجود دارد: اگر مکان پایگاه اطلاع رسانیتغییر می کند، سپس سوال پرسیده می شود - آیا این یک کپی از پایگاه داده است یا پایگاه داده منتقل شده است. در اصل، این مکانیسم ممکن است کافی باشد، اما باز هم، عامل انسانی ممکن است دخالت کند، کسی متوجه نمی شود که چه اتفاقی می افتد و دکمه اشتباه را فشار می دهد. از همین رو، به نظر من یک ثابت قابل اعتمادتر است.

2. پردازش اولیه

ترفند بعدی پردازش اولیه است.

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

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

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

در نمودار این رویه عملیاتیبه این صورت نشان داده شده است:

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

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

3. دایرکتوری مقادیر از پیش تعریف شده

ترفند بعدی مرجع مقادیر از پیش تعریف شده است.

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

چه گزینه های اجرایی وجود دارد؟

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

این دایرکتوری فقط دارای یک ویژگی با نوع DirectoryLink است(لینک به تمام کتاب های مرجع).

اگر لازم باشد به عنصری به عنوان بخشی از یک کار اشاره کنم، یک عنصر از پیش تعریف شده را به این کتاب مرجع اضافه می کنم (به عنوان مثال، Counterparty_Agroimpulse)

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

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

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

4. جداول موقت را در دیباگر مشاهده کنید

خوب، آخرین ترفند مشاهده جداول موقت در دیباگر است.

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

و نامبه نحوی کوتاه، به عنوان مثال VT()

در این مورد:

من من یک نقطه شکست تعیین کردمدر جایی که درخواستی دارم
در پنجره "محاسبه بیان" VT (پرس و جو) را می نویسم;
روی "محاسبه" کلیک می کنم و من ساختار جداول پرس و جو موقت را دریافت می کنمتا ببینیم چه داده هایی وجود دارد.

این یک ویژگی بسیار راحت است، ما همیشه از آن استفاده می کنیم. به خصوص هنگام محاسبه هزینه ها یا در تنظیماتی مانند ZUP. صادقانه بگویم، من نمی فهمم که دیگران چگونه بدون او زندگی می کنند.

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

نتیجه

با تشکر از همه. من یک وب سایت کوچک دارم، در این وب سایت همه این قوانین و موارد دیگر با جزئیات ارائه شده است - بیایید، بخوانید، از طریق ایمیل یا اسکایپ برای من بنویسید.

این موضوع برای من جالب است، من آماده بحث در مورد آن هستم. برای من واقعاً مهم است که همه چیز برای شما هم خوب باشد.

هر، حتی سازمان کوچکمجموعه ای از فرآیندهای تجاری خود را دارد. برای کار موثر و دریافت بالاترین سودفرآیندهای تجاری بزرگ باید خودکار شوند. برنامه های 1C با این عملکرد عالی کار می کنند. اما متأسفانه هیچ برنامه ایده آلی وجود ندارد، همانطور که هر فردی ایده های خاص خود را در مورد کمال دارد. یک برنامه نویس 1C می تواند به شما در بهبود برنامه کمک کند. با تغییر استاندارد 1C، برنامه ای دریافت خواهید کرد که به طور کامل ایده ها و نیازهای شما را برآورده می کند.

ویرایش 1C- مجموعه ای از اقدامات برای پیکربندی و مدرن سازی برنامه های 1C مطابق با نیازهای شرکت شما.

چگونه برنامه های 1C را بهبود می بخشیم

برای دستیابی به یک نتیجه ایده آل، زمانی که مشتری دقیقاً آنچه را که در هنگام نهایی کردن برنامه های 1C در نظر داشت دریافت می کند، ما طرح کاری زیر را ارائه می دهیم:

مشتری اطلاعات مربوط به نصب شده را گزارش می دهد.
مشتری متخصص ما را با اصول اولیه کار سازمان خود آشنا می کند، ماهیت مشکل را به اشتراک می گذارد، توصیف می کند که دقیقاً چه چیزی را می خواهد بهبود بخشد.
یک برنامه نویس 1C به مشتری اختصاص داده شده است که در تمام مدت کار با شرکت ما با مشتری همکاری می کند و از تمام ویژگی های حسابداری برای تجارت مشتری آگاه خواهد بود. برنامه نویس شخصی 1C به طور کامل مسئول عملکرد بهبودهایی است که پیاده سازی کرده است.
مشخصات فنی تهیه شده است. بر اساس اطلاعات دریافتی، برنامه نویسان 1C ما نتایج لازم را می گیرند و گزینه هایی را برای حل مشکل از طریق اصلاحات یا با انجام تنظیمات در 1C ارائه می دهند.
هزینه های زمانی و مالی برای نهایی کردن 1C توافق شده است.
کار توافق شده با مشتری اجرا می شود.
نتایج کار تست شده و به مشتری تحویل داده می شود.

رایج ترین تغییرات در 1C

در زیر ما بهبودهای محبوبی را در برنامه های 1C لیست می کنیم:

ایجاد دایرکتوری ها و جزئیات. ایجاد مکان های اضافیذخیره اطلاعاتی مانند شماره خودرو
اصلاح یا توسعه فرم های چاپی جدید. تغییر دادن ظاهرصورتحساب ها، فاکتورها و سایر اشکال چاپی اسناد با توجه به درخواست سازمان شما.
ایجاد گزارش های جدید یا اصلاح گزارش های موجود. ایجاد یا ویرایش گزارش های موجود برای حسابداران، مدیران یا مدیران شرکت.
تنظیم حقوق دسترسی. محدود کردن یا گسترش دسترسی کاربر به اطلاعات موجود در پایگاه داده.
توسعه درمان هاایجاد پردازش برای ساده سازی سیستم های ورودی اطلاعات، تجزیه و تحلیل فعالیت های سازمانی، عملکردهای انجام خودکار، به عنوان مثال، چاپ بسته ای از اسناد یا دانلود اطلاعات از یک فایل اکسل (*.xls).
راه اندازی صرافی 1C.واردات/صادرات داده ها از یک برنامه 1C به برنامه دیگر.
مشاوره با کاربران 1C.توضیح یا آموزش کاربران برای کار با بهبودهای اجرا شده.
به روز رسانی تنظیمات تغییر یافتهما تنظیماتی را که توسط برنامه نویسان 1C ما و شخص ثالث تغییر یافته است به روز می کنیم.

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

دلایل متعددی وجود دارد که چرا سفارش تغییرات از شرکت ما سودآور است:

کیفیت بالا.برنامه نویسان 1C ما متخصصان بسیار ماهر هستند که توسط گواهینامه های 1C مربوطه تأیید شده است.
کم هزینه.شرکت ما کوچک است، اما به سرعت در حال رشد است، ما واسطه های بین مشتری و برنامه نویس را حذف می کنیم، به همین دلیل ما موفق می شویم هزینه خدمات 1C را از 1000 روبل در سطح پایین نگه داریم. در هر ساعت کار تخصصی
اتمام سریع کار. تاخیر در تکمیل کار شما برای شرکت ما سودی ندارد. بنابراین تضمین می شود که نتیجه کار خود را حداکثر تا سه روز کاری دریافت کنید. اگر کار کوچک است، احتمالاً در روزی که با آن تماس می گیرید، بتوانید اصلاحات مورد نیاز خود را در 1C دریافت کنید.
تضمین 100٪ برای عملکرد اصلاح.شرکت ما عملکرد بهبودهایی را که کارمندان ما در برنامه شما ایجاد کرده اند تضمین می کند. در عرض یک سال پس از اجرای آن، می توانید در صورت مشاهده ایرادات پنهان به ما بگویید و ما در اسرع وقت آنها را به صورت کاملا رایگان برطرف خواهیم کرد.
علیرغم اینکه از نظر جغرافیایی در آن قرار داریم سنت پترزبورگ, ما می توانیم از راه دور هر کاری را برای شما انجام دهیم، مهم نیست در کجای جهان هستید.