دارایی بعد پایه ثبت محاسبات است. محاسبات دوره ای پیچیده، محاسبه به زبان 1s را می پذیرد

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

در این بخش، دو روش برای به دست آوردن داده های اساسی موجود در سیستم را در نظر خواهیم گرفت - با استفاده از زبان پرس و جو و استفاده از نماد تابعی، به روش. GetBase(). در این صورت، ما رجیستر محاسباتی «اصلی» را رجیستری می نامیم که برای آن باید داده های اولیه را به دست آوریم، و رجیسترهای «پایه» (که ممکن است در حالت کلی چندین مورد از آنها وجود داشته باشد) آن ثبات هایی هستند که برای آنها جمع بندی منابع انجام می شود.

ما این روش ها را به تفصیل در نظر نخواهیم گرفت، فقط تفاوت ها و دامنه آنها را در نظر خواهیم گرفت.

متد GetBase().

روش GetBase()برای اشیا تعریف شده است RegisterCalculationManager.<Имя регистра расчета> و RegisterCalculationRecord.<Имя регистра расчета> . این روش به شما امکان می دهد منابع ثبت های پایه را تنظیم کنید که برای آنها باید گردش مالی را بدست آورید، فیلدهایی را که در چارچوب آنها باید گردش مالی را بدست آورید تنظیم کنید و قوانینی را برای مقایسه اندازه گیری های رجیسترهای محاسبه اصلی و پایه تنظیم کنید. .

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

نام ابعاد و منابع ثبات های پایه در قالب مشخص شده است<ИмяРегистраРасчета>.<ИмяПоля>.

نمونه ای از استفاده از روش:
Code 1C v 8.x Resources = New Array(1);
منابع = "اقلام تعهدی پایه. نتیجه، اقلام تعهدی اضافی. نتیجه";

ابعاد = ساختار جدید ("فرد، سازمان");
Dimensions.Individual = "اقلام تعهدی پایه.انفرادی،اقلام تعهدی اضافی.کارمند";
Dimensions.Organization = "BasicAccruals.Organization,Additional Accruals.Organization";

Slices = New Array(1);
بخش ها = "اقلام تعهدی پایه. روش، اقلام تعهدی اضافی. روش";
// محاسبه baseBaseDataTable = Calculation.Retention Register.GetBase(Selection,
// منابع، ابعاد، بخش ها)؛

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

جدول زبان پرس و جو برای دریافت داده های اولیه
برای به دست آوردن داده های اولیه در زبان پرس و جو، جداول مجازی تعریف می شوند «ثبت محاسبات.<Имя регистра расчета>.پایه<Имя базового регистра расчета>" . پارامترهای جدول مجازی ابعاد رجیستر اصلی، ابعاد ثبات پایه و فیلدهایی هستند که در زمینه آنها باید داده های اولیه را بدست آورید. ابعاد و برش ها به عنوان آرایه (یا لیستی از مقادیر) رشته ها با نام ابعاد مشخص می شوند.

نمونه ای از نوشتن یک پرس و جو با استفاده از جداول مجازی داده های پایه:
کد 1C v 8.x
Dimensions1 = Array(2);
Dimensions1 = "انفرادی";
Dimensions1 = "سازمان";

Dimensions2 = Array(2);
Dimensions2 = "کارمند";
Dimensions2 = "سازمان";

Slices = New Array(1);
Slices = "Mode";

Query Text = "SELECT Individual, Calculation Type, SUM(ResultBase)
| از
|انفرادی، نوع محاسبه، پایگاه نتایج را انتخاب کنید
| FROM Calculation Register.Deductions.BaseBasicAccruals(&Dimensions1,&Dimensions1,&Aspects)
|WHERE " + ConditionBasic + "
|به همه بپیوندید
| انتخاب کارمند، نوع محاسبه، پایگاه نتایج
| FROM Calculation register.Retention.BaseAdditional Accruals(&Dimensions1,&Dimensions2,&Sections)
|WHERE " + ConditionAdditional + "
|) پایگاه AS
|گروه توسط
| شخصی،
| نوع محاسبه
|";

Request = New Request(RequestText);
Query.SetParameter("Dimensions1", Dimensions1);
Query.SetParameter("Dimensions2", Dimensions2);
Query.SetParameter("بخش ها"، بخش ها);

// ...تنظیم پارامترهای پرس و جو اضافی مورد استفاده در شرایط WHERE//،..
// انتخابی از پرس و جو را دریافت کنید resultSelection = Query.Execute().Select();

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

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

توجه داشته باشید که عملکرد به دست آوردن داده ها با استفاده از روش تابعی و استفاده از پرس و جو علی رغم پیچیدگی ظاهری کد اجرایی در مورد کوئری ها یکسان است.

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

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

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

ثبت اطلاعات

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

• SliceFirst
• SliceRecent

ثبت های تجمع

برای رجیسترهای تجمع، مجموعه جداول مجازی ارائه شده نیز به نوع ثبات بستگی دارد. همانطور که می دانید دو نوع ثبت انباشت وجود دارد: باقیو گردش مالی

ثبت انباشت مانده

جداول مجازی زیر موجود است

• باقی
• گردش مالی
• باقی می ماند و گردش می کند

ثبت گردش مالی

فقط یک میز مجازی موجود است

• گردش مالی

ثبت محاسبات

در اینجا بسته به تنظیمات، جداول مجازی زیر نیز موجود است

ثبت های حسابداری

رجیسترهای حسابداری دارای بزرگترین مجموعه جداول مجازی هستند

• باقی
• گردش مالی
• RPMDtKt
• باقی می ماند و گردش می کند
• زیرمجموعه
• MovementsSubconto

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

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

ساختار

اطلاعات موجود در رجیستر محاسباتی به عنوان رکوردهایی ذخیره می شود که هر کدام حاوی مقادیر ابعاد و مقادیر منابع مربوط به آنها است.

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

رکوردهای ذخیره شده در پایگاه داده به شکل زیر خواهد بود:

ارتباط با طرح انواع محاسبات

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

دوره ای

ثبت محاسبات داده ها را نه تنها در زمینه اندازه گیری های ایجاد شده، بلکه در زمینه زمان نیز ذخیره می کند. این دلیل وجود یک فیلد اجباری دیگر برای هر رکورد ثبت محاسبات است - اعتبار. هنگام ایجاد یک ثبات محاسباتی، توسعه‌دهنده می‌تواند حداقل تعداد دفعات ورود ورودی‌ها به رجیستر را مشخص کند:

ارائه به اداره ثبت

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

رابطه با جدول زمانی

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

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

محاسبات مجدد

ثبت محاسبات می تواند شامل اشیاء خاص باشد - محاسبات مجدد:

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

منحصر به فرد بودن رکوردها

این سیستم کنترل منحصر به فرد بودن رکوردهای ذخیره شده در ثبت محاسبات را فراهم می کند. بنابراین، ثبت محاسبات نمی تواند شامل دو ورودی مربوط به یک خط از یک سند باشد.

سازوکارهای اجرا شده توسط ثبت شهرک

مکانیسم حذف بر اساس دوره اعتبار به شما امکان می دهد دوره اعتبار واقعی یک ثبت تسویه حساب را بر اساس تجزیه و تحلیل سایر ورودی های موجود در ثبت محاسبه کنید.

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

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

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

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

ثبات محاسباتی از دو نوع وابستگی به دوره پایه پشتیبانی می کند:

• وابستگی به مدت اعتبار؛
• وابستگی به دوره ثبت نام

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

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

پیچیده ترین نسخه وابستگی به دوره پایه زمانی است که ویژگی "Validity period is the base period" برای نوع محاسبه این رکورد تنظیم شده باشد. این ویژگی به این معنی است که نه دوره پایه مشخص شده در فیلدهای مربوط به رکورد به عنوان دوره پایه این رکورد استفاده می شود، بلکه از دوره اعتبار واقعی رکورد استفاده می شود که در نتیجه مکانیسم حذف توسط دوره اعتبار به دست می آید. و در حالت کلی مجموعه ای از چند دوره است.

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

نتیجه مکانیسم تولید سوابق محاسبه مجدد، مجموعه ای از سوابق محاسبه مجدد است که حاوی اطلاعاتی در مورد اینکه کدام ورودی های ثبت باید مجدداً محاسبه شوند (مجدد محاسبه شوند) است.

محاسبه فرم های ثبت نام

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

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

قابلیت ثبت محاسبه

عملکرد اصلی که ثبت محاسبات در اختیار توسعه دهنده قرار می دهد عبارتند از:

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

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

تشکیل سوابق در رجیسترها

یکی از اولین سوالات مربوط به ثبت نام این است: چرا؟

چرا نیاز به ایجاد جداول جداگانه دارید که اغلب رکوردهای موجود را کپی می کنند؟

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

بنابراین، متوجه شدیم که یکی از راه‌های ایجاد یک ورودی ثبت، نوشتن با استفاده از یک ثبت‌کننده (سند) است. این گزینه در انواع رجیسترها وجود دارد.

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

گزینه دوم برای ایجاد رکورد به طور مستقیم و بدون ایجاد سند ثبت است. شما می توانید رکوردها را از این طریق فقط در رجیسترهای اطلاعات ایجاد کنید، در حالی که در ویژگی های ثبات، ویژگی "Record mode" باید مقدار مناسب را داشته باشد (شکل 1).

مشترک برای همه رجیسترها

ساختار داخلی هر رجیستر را می توان در شکل 2 نشان داد

شکل 2

بیایید آن را با جزئیات بیشتر در نظر بگیریم:

• ابعاد - ویژگی هایی را ضبط می کند که تعیین می کند داده ها در کدام بخش ها ذخیره می شوند اطلاعات مهم;
• منابع - آنها حاوی اطلاعاتی هستند که باید سیستماتیک شوند.
• الزامات - فیلدهایی را ضبط کنید که حاوی اطلاعات اضافی هستند.
• Forms یک ویژگی است که حاوی اطلاعات گرافیکی در مورد ظاهر یک لیست، عنصر و غیره است. و ماژول های داخلی آنها؛
• طرح‌بندی - فرم‌های چاپی ثبت‌ها.

ثبت اطلاعات

از آنجایی که ما در مورد ثبت اطلاعات در بالا صحبت می کنیم، اجازه دهید در مورد آنها صحبت کنیم.

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

لیست ویژگی های مهم ثبت اطلاعات کوچک است (شکل 3)، بیایید در مورد موارد اصلی صحبت کنیم:

شکل 3

1. تناوب، میزان کنترل منحصر به فرد بودن رکورد را نشان می دهد (در عرض یک دقیقه، ساعت، روز، سال، مطابق با مقدار انتخاب شده، نمی توان دو رکورد با اندازه گیری های یکسان وجود داشته باشد)، همچنین می تواند مقدار را بگیرد. "توسط ثبت کننده"، اما برای این کار باید حالت ضبط مناسب را انتخاب کنید.
2. حالت ضبط در واقع انتخابی از دو مقدار است: "مستقل" و "فرع به ثبت".
   1. درک این نکته مهم است که انتخاب یک حالت مستقل به این معنی نیست که یک رکورد توسط یک سند نمی تواند تشکیل شود، فقط انتخاب توسط ثبت کننده و کنترل منحصر به فرد بودن رکورد توسط آن غیرممکن خواهد بود.
3. Allow totals slice of the first and Allow totals slice of the last: (دو مورد را در یک مورد ترکیب کنید) - وقتی چک باکس های مربوطه انتخاب شدند، می توان یک درخواست به ثبت اطلاعات در جداول اضافی انجام داد (Slice of the first و Slice of the آخرین)، که شامل مجموعه داده های مربوطه است، به عنوان یکی از پارامترهای این جداول، تاریخی است که در آن لازم است داده هایی انتخاب شود.

ثبت های تجمع

ساختار یکی از آنها را در شکل 2 دیدیم. ویژگی اصلی که به شدت بر ظاهر رجیستر و همچنین ساختار داخلی آن تأثیر می گذارد «نوع رجیستر» است (شکل 4).

بسته به الزامات برای اطلاعات ذخیره شده، می تواند مقادیر زیر را داشته باشد:

• باقی؛
• گردش مالی.

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

یکی از مشکلات اصلی که توسعه دهندگان مبتدی هنگام استفاده از جداول Balances و BalancesAnd Turnovers در پرس و جوها با آن مواجه می شوند این است که وقتی یک پرس و جو موجودی را برای یک تاریخ خاص دریافت می کند، داده های این جداول ممکن است متفاوت باشد. و در اینجا یک نکته ظریف وجود دارد: هنگام تعیین یک مقدار خاص به عنوان تاریخ پایان دوره، پلتفرم داده ها را از جدول موجودی ها بدون درج این مقدار در دوره انتخاب می گیرد.

اگر به داده‌هایی نیاز دارید که شامل پایان دوره باشد، می‌توانید:

• از جدول موجودی ها و گردش مالی استفاده کنید.
• تاریخ را 1 ثانیه بزرگتر از تاریخ داده شده انتخاب کنید (یعنی نه در 12/31/16 23:59:59، بلکه در 01/01/17 00:00:00).
• از متد Boundary استفاده کنید، که به پیکربندی گزینه ای کمک می کند تا یک نقطه زمانی در دوره مورد بررسی را شامل شود (مورد استفاده: Boundary(EndDate,Including).

ثبت های حسابداری

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

شکل 5

نمودار حساب ها یک شیء فراداده جداگانه است که نیاز به بحث جداگانه دارد. بسته به نمودار حساب‌ها، پیکربندی‌های معمولی 1C شامل 4 ثبت اصلی حسابداری است:

1. بودجه بندی؛
2. بین المللی؛
3. مالیات؛
4. خود حمایت کننده.

پارامتر دوم، معمولی برای ثبت حسابداری، "مطابقت" است.

علامت زدن این کادر به شما امکان می دهد ورودی های دوگانه حاوی حساب اعتباری AccountKt و حساب بدهی AccountDt و تجزیه و تحلیل (subconto) مربوط به این حساب ها را ایجاد کنید. اگر چک باکس علامت زده نشود، فقط یک حساب در ورودی های ثبت وارد می شود.

ثبت محاسبات

اینها احتمالاً سخت ترین ثبت ها برای درک هستند. در همین حال، در ذات خود، آنها بسیار شبیه به ثبت های انباشت از نوع "Turnover" هستند.

تفاوت تعیین کننده رجیستر محاسبه با سایر رجیسترها وجود پارامتر "طرح نوع محاسبه" در ویژگی های آن است. علاوه بر این، ثبت محاسبات و همچنین ثبت اطلاعات، دوره ای است.

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

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

کاربرد اصلی آنها در تنظیمات معمولی 1C - ثبت و تسهیل کار با اقلام تعهدی به کارکنان سازمان.

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

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

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

• سازمان،
• شخصی،
• زير مجموعه.

تصور کنید که باید وظایف زیر را حل کنید:

• اخذ برای سوابق معینی از ثبت گردش مالی ثبت برای همه سوابق با تقسیم بندی مشابه رکورد اصلی. این ممکن است مثلاً محاسبه کمک هزینه باشد که به اقلام تعهدی کل واحد بستگی دارد.
• به دست آوردن گردش مالی در سوابق با همان فرد و بخش. آن ها دریافت مبلغ اقلام تعهدی کارمند که در همان بخش به وی تعلق گرفته است (اقلام تعهدی همان کارمند که در سایر بخش ها دریافت کرده است مستثنی است).
• دریافت گردش مالی در سوابق با همان فرد و همان سازمان (همه اقلام تعهدی به یک فرد در همان سازمان).

تمام وظایف فوق با استفاده از پرس و جوهای جدول مجازی داده های پایه حل می شوند. در این حالت، پارامترهای "Measurements of main register" و "Measurements of the base register" برای هر سه کار متفاوت خواهند بود. در مورد اول، فقط یک بعد وجود دارد - "Subdivision"; در دوم - "فردی" و "فرعی"؛ در سوم - "سازمان" و "فرد".

بهینه سازی پایه جمع آوری داده ها

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

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

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

این وظیفه است که به شما امکان می دهد بعد ویژگی Base ثبت محاسبه را حل کنید. با تنظیم این ویژگی روی چند بعد، توسعه‌دهنده پیکربندی یک نمایه در تمام ابعادی که به عنوان "پایه" مشخص شده‌اند ایجاد می‌کند (برای جزئیات بیشتر، به بخش "شاخص‌های جداول پایگاه داده" مراجعه کنید).

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

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

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

اما در عین حال مهم است که ترتیب اندازه گیری های ثبت محاسبات را به خاطر بسپارید ...

در مورد ترتیب اندازه گیری ها در ثبت محاسبات

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

در مثال ما، اگر ابعاد "انفرادی" و "دپارتمان" به عنوان ابعاد اصلی انتخاب شوند، با تنظیم مجدد آنها، سرعت به دست آوردن داده های اولیه در مورد یک فرد و بخش را تغییر نمی دهیم، بلکه با به دست آوردن وضعیت را به شدت بدتر خواهیم کرد. داده های یک فرد و سازمان هنگام مقایسه مقادیر در فیلدهای "Organization" و "Individual"، سیستم نمی تواند از شاخص Subdivision + Individual استفاده کند، زیرا فیلد "Individual" اولین مورد در آن نیست و شرط اعمال نمی شود. در زیربخش و در مورد یک شاخص، یک گروه + فرد هم از به دست آوردن داده های پایه برای یک بخش و یک فرد و هم از دستیابی به داده های پایه برای یک سازمان و یک فرد سود می برد، زیرا فیلد "انفرادی" در فهرست اولین خواهد بود. ، سیستم می تواند از آن به صورت "جزئی" استفاده کند (هر کدام یک فیلد). ضمناً رشته «انفرادی» نسبت به رشته «سازمان» «انتخابی» بسیار بیشتری دارد و تعیین شرایط برای سازمان زمان زیادی نمی برد.

اگر بعد پایه یک باشد

بیایید وظیفه مثال خود را فراموش نکنیم، که شامل به دست آوردن اطلاعات اولیه فقط برای بخش است. به نظر می رسد ایجاد یک نمایه Individual + Division برای حل دو کار دیگر را مستثنی می کند. کار کارآمدجدول مجازی داده های پایه در یک بعد "بخش". اما در اینجا لازم است در مورد امکان نمایه سازی ابعاد رجیستر (ویژگی Indexing) به یاد داشته باشید. توانایی نمایه سازی یک بعد به شما امکان می دهد تا به طور موثر مشکل بدست آوردن پایه از یک بعد پایه را حل کنید.

بنابراین، در مثال ما، باید ویژگی Base را برای ابعاد "Individual" و "Department"، ویژگی Indexing را برای بعد "Department" تنظیم کنید و همچنین مطمئن شوید که بعد "Individual" "بالاتر" از بعد "بخش" (ترتیب بعد "سازمان" "مهم نیست).