قوانین انتقال داده 1c. مثالی از یک قانون برای تبدیل اشیا. گزینه های خرید انتقال داده

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

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

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

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

بیایید برخی از آنها را در نظر بگیریم:

• تبادل از طریق فایل های متنی؛
• استفاده از طرح های مبادله
• و غیره.

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

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

تبدیل داده ها یک راه حل معمولی، خود پیکربندی است. هر کاربر با اشتراک ITS: Prof می تواند این بسته را کاملاً رایگان از سایت پشتیبانی کاربر یا از دیسک ITS دانلود کند. نصب به روش استاندارد انجام می شود - مانند سایر راه حل های معمولی از 1C.

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

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

مزیت سومی که به آن اشاره می کنم عدم وجود محدودیت در توزیع داده است. خود توسعه دهنده روش تحویل داده ها به پیکربندی گیرنده را انتخاب می کند. دو گزینه خارج از جعبه موجود است: آپلود در فایل xml و اتصال مستقیم به پایگاه اطلاعاتی (COM / OLE).

ما معماری می خوانیم

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

پیکربندی "KD" نوعی سازنده بصری است که با کمک آن توسعه دهنده قوانین تبادل را ایجاد می کند. نمی داند چگونه داده ها را تخلیه کند. پردازش خدمات خارجی اضافی موجود در کیت توزیع CD مسئول این است. چندین مورد از آنها وجود دارد (XX در نام فایل شماره نسخه پلت فرم است):

• MDXXExp.epf- پردازش به شما امکان می دهد توضیحات ساختار پایگاه اطلاعاتی را در یک فایل xml بارگیری کنید. توضیحات ساختار برای تجزیه و تحلیل بیشتر و ایجاد قوانین تبادل در CD بارگذاری می شود.
• V8ExchanXX.epf- داده ها را از پایگاه اطلاعاتی مطابق با قوانین تبادل تخلیه / بارگیری می کند. در اکثر پیکربندی‌های معمولی، پردازش خارج از جعبه وجود دارد (به آیتم منوی «سرویس» مراجعه کنید). پردازش جهانی است و به هیچ پیکربندی/قوانین خاصی وابسته نیست.

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

1. تعریف تکلیف. لازم است به وضوح درک کنید که چه داده هایی باید منتقل شوند (از کدام اشیاء پیکربندی) و مهمتر از همه، کجا باید منتقل شوند.
2. تهیه شرحی از ساختارهای پیکربندی (منبع / گیرنده) برای بارگذاری بعدی در CD. این کار با پردازش سرویس MDXXExp.epf حل می شود.
3. بارگذاری توضیحات آماده سازه ها در IB.
4. ایجاد قوانین تبادل با استفاده از ابزارهای CD تصویری.
5. انجام آپلود/دانلود طبق قوانین تبدیل داده ایجاد شده با استفاده از پردازش V8ExchanXX.epf.
6. اشکال زدایی قوانین تبادل (در صورت لزوم).

ساده ترین تبدیل

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

اول از همه، بیایید نگاهی به طرح تبدیل داده بیندازیم و لیست اقداماتی را که باید انجام شوند دوباره مطالعه کنیم. سپس پیکربندی "Source" را راه اندازی می کنیم و پردازش سرویس MD82Exp.epf را در آن باز می کنیم.

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

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

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

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

سی دی را باز کرده و در منوی اصلی انتخاب کنید "Directories" -> "Configurations"... مرجع حاوی توضیحاتی در مورد ساختارهای همه تنظیمات است که به استفاده از آنها برای ایجاد تبدیل کمک می کند. ما توضیحات پیکربندی را یک بار بارگذاری می کنیم و سپس می توانیم به طور مکرر از آن برای ایجاد تبدیل های مختلف استفاده کنیم.

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

اکنون همه چیز برای ایجاد قوانین مبادله آماده است. در منوی اصلی CD، "References" -> "Conversions" را انتخاب کنید. ما یک عنصر جدید اضافه می کنیم. در پنجره ایجاد یک تبدیل جدید، باید مشخص کنید: پیکربندی منبع (انتخاب UT) و پیکربندی گیرنده («گیرنده» را انتخاب کنید). سپس تب "Advanced" را باز کرده و فیلدهای زیر را پر کنید:

• نام فایل قوانین تبادل - قوانین تبادل ایجاد شده با این نام ذخیره می شود. نام فایل را می توان در هر زمان تغییر داد، اما اکنون تنظیم آن سود بیشتری دارد. این باعث صرفه جویی در زمان در آینده می شود. نام قوانین نسخه ی نمایشی را گذاشتم: "rules-ut-to-priemnik.xml".
• نام - نام تبدیل. نام می تواند کاملاً هر چیزی باشد، من خودم را به "دمو" محدود کردم. UT به گیرنده ".

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

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

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

در این مرحله به دو تب "قوانین تبدیل شی" و "قوانین آپلود داده" علاقه مندیم. در ابتدا، ما باید قوانین تطبیق را تنظیم کنیم، یعنی. مقایسه اشیاء با دو پیکربندی در مرحله دوم، برای تعیین اشیاء احتمالی که برای تخلیه در دسترس کاربر خواهد بود.

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

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

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

در مورد من، سه دایرکتوری از این دست وجود دارد: نام‌گذاری، سازمان‌ها و انبارها. همچنین یک کتاب مرجع Clients وجود دارد که بار معنایی مشابهی را انجام می دهد. پیمانکاران"از پیکربندی" NS". درست است، استاد به دلیل نام عالی آنها نتوانست آنها را مطابقت دهد.

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

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

اساس قوانین مبادله آماده است. ما اشیاء را برای همگام سازی انتخاب کردیم و قوانین تبدیل خواص و قوانین تخلیه به صورت خودکار ایجاد شد. بیایید قوانین تبادل را در یک فایل ذخیره کنیم، سپس "منبع" IB را باز کنیم (در مورد من UT است) و پردازش سرویس را در آن شروع کنیم. V8Exchan82.epf.

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

پس از اتمام فرآیند آپلود داده ها در یک فایل، به IB بروید. گیرنده". پردازش را نیز در آن باز می کنیم. V8Exchan82.epf، فقط این بار به برگه "دانلود داده ها" بروید. فایل داده را انتخاب کنید و دکمه "بارگیری" را فشار دهید. تمام، داده ها با موفقیت منتقل شدند.

وظایف دنیای واقعی

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

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

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

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

مشکل چندین راه حل دارد. ما گزینه پر کردن مورد نیاز را در نظر خواهیم گرفت " سازمان"درست در پایگاه داده" گیرنده"، یعنی در زمان بارگذاری داده ها سازمان فعلی در یک ثابت ذخیره می شود، بنابراین، هیچ مانعی برای دریافت این مقدار وجود ندارد. بیایید قانون تبدیل شی (از این پس PCO) را باز کنیم. مشتریان"(روی شی دوبار کلیک کنید) و در جادوگر قوانین به بخش "Event handlers" بروید. در فهرست کنترل‌کننده‌ها، « پس از بارگذاری”.

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

اگر NOT Object.EtoGroup سپس Object.Organization = Constants.CurrentOrganization.Get (); EndIf

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

مشکل شماره 2. جزئیات در ثبت اطلاعات

در مرجع « پیمانکاران"پیکربندی UT، جزئیات وجود دارد" مشتری"و" تامین کننده". هر دو ویژگی از نوع « بولیو برای تعیین نوع طرف مقابل استفاده می شود. در IB " گیرنده"، در کتاب مرجع" مشتریان"هیچ جزئیات مشابهی وجود ندارد، اما یک ثبت اطلاعات وجود دارد" انواع مشتریان". عملکرد مشابهی را انجام می دهد و می تواند چندین ویژگی را برای یک مشتری ذخیره کند. وظیفه ما انتقال مقادیر مشخصه به رکوردهای جداگانه ثبت اطلاعات است.

متأسفانه ابزارهای بصری به تنهایی نمی توانند با این موضوع کنار بیایند. بیایید از کوچک شروع کنیم، یک PKO جدید برای ثبت اطلاعات ایجاد کنیم. انواع مشتریان". چیزی را به عنوان منبع مشخص نکنید. از جانب ایجاد خودکارقوانین تخلیه را رد کنید.

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

• روش نمونه گیری. تغییر به "الگوریتم رایگان"؛
• قانون تبدیل ما ثبت اطلاعات "انواع مشتریان" را انتخاب می کنیم.
• کد (نام) قانون. ما آن را به عنوان "Unloading Client Views" یادداشت می کنیم.

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

در زیر کد مربوط به مدیریت رویداد آمده است. قبل از پردازش". این پارامتر را مقدار دهی اولیه می کند واکشی داده ها"به دنبال پر کردن اطلاعات از کتاب مرجع" پیمانکاران". در اینجا باید به پر کردن ستون توجه کنید. نوع مشتری". در "UT" ما نشانه هایی از نوع "Boolean" داریم و در گیرنده - enumeration.

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

DataFetch = NewValuesTable (); FetchData.Columns.Add ("مشتری")؛ FetchData.Columns.Add ("ClientType"); FetchDataFromDirectory = Directories.Contractors.Select (); در حالی که FetchingDataFromDirectory.Next () حلقه IfFetchingDataFromDirectory.ThisGroup سپس ادامه دهید. EndIf اگر DataFetchFromDirectory.Buyer سپس NewRow = DataFetch.Add (); NewString.Client = DataFetchFromDirectory.Link; NewString.ClientType = "خریدار"; EndIf اگر DataFetchFromDirectory.Provider سپس NewRow = DataFetch.Add (); NewString.Client = DataFetchFromDirectory.Link; NewString.ClientType = "تامین کننده"; EndIf پایان چرخه؛

بیایید قانون تخلیه داده را ذخیره کنیم و به " قوانین تبدیل شی". برای ثبت اطلاعات اضافه کنید انواع مشتریانقوانین تبدیل ملک: نوع مشتری و مشتری. منبع را خالی بگذارید و در کنترل کننده رویداد «قبل از بارگیری» بنویسید:

// برای ویژگی "Client" Value = Source.Client; // برای ویژگی "ClientType" If Source.Client = "Customer" Then Expression = "Enumerations.ClientTypes.Customer" OtherwiseIf Source.Client = "Supplier" then Expression = "Enumerations.ClientTypes.Supplier"; EndIf

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

تمام است، قوانین مبادله آماده است. مثال در نظر گرفته شده کاملاً جهانی است. یک رویکرد مشابه اغلب هنگام انتقال داده ها از پیکربندی های ایجاد شده در پلت فرم 7.7 استفاده می شود. نمونه بارز این امر انتقال الزامات دوره ای است.

مشکل شماره 3. ترفندهای بخش جدولی

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

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

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

DataFetch = NewValuesTable (); // یک بخش جدولی دیگر وجود خواهد داشت DataFetch.Columns.Add ("محصولات"); // همچنین یک بخش جدولی DataFetch.Columns.Add ("سرویس ها") وجود خواهد داشت. FetchData.Columns.Add ("پیوند")؛

مشکل شماره 4. انتقال داده به یک عملیات

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

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

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

مشکل شماره 5. همگام سازی داده ها برای چندین مورد

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

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

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

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

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

ما حق انتخاب رشته ها را خودمان داریم. با توجه به INN، KPP، نام، بلافاصله چندین معیار جستجو را نشان خواهیم داد. راحت؟ کاملاً، اما باز هم این کافی نیست. اگر بخواهیم معیارهای جستجو را تغییر دهیم چه؟ برای مثال ابتدا به دنبال لینک INN + KPP می گردیم و اگر چیزی پیدا نکردیم، شروع به امتحان شانس خود با نام می کنیم.

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

اگر SearchVariantNumber = 1، SearchPropertyNameString = "INN, KPP"; در غیر این صورت اگر SearchVariantNumber = 2 سپس SearchPropertyNameString = "Name"; EndIf

همیشه چندین راه حل وجود دارد

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

به نظر من، 1C به طور غیرمستقیم موضوع استفاده از تبدیل داده را دور می زند. برای کل وجود این فناوری، تنها یک کتاب در مورد آن منتشر شده است: "1C: Enterprise 8. Data Conversion: Exchange between Application Solutions". کتاب بسیار قدیمی است (2008)، اما هنوز هم مطلوب است که با آن آشنا شوید.

دانش پلتفرم ها همچنان ضروری است

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

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

شما همچنین می توانید داده ها را با استفاده از. بسیاری از پیکربندی‌های 1C 8.3 دارای عملکرد استاندارد برای تنظیم همگام‌سازی داده‌ها بین پیکربندی‌های مختلف و ادغام یکپارچه با مدیریت اسناد 1C هستند.

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

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

همه کاره است و برای هر پیکربندی مناسب است.

بیایید مثالی از بارگیری فهرست نامگذاری از یک پایگاه اطلاعاتی 1C 8.3 Accounting 3.0 به دیگری را در نظر بگیریم. یک پیش نیاز انتخاب توسط والدین (گروه) "نجاری".

بارگیری داده ها از 1C به XML

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

پردازش آپلود و دانلود را باز کنید داده های XML(Ctrl + O).

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

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

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

ستون "Unload در صورت لزوم" به این معنی است که اگر این شیء با ویژگی دایرکتوری که در حال بارگذاری مجدد آن هستیم ارجاع داده شود، لازم است دوباره بارگیری شود. به عنوان مثال، موقعیت موردی که مجدداً بارگیری می کنید دارای یک واحد اندازه گیری است که در پایه گیرنده نیست. اگر چک باکس ستون "در صورت لزوم تخلیه بارگیری" در مقابل کتاب مرجع با واحدهای اندازه گیری تنظیم شود، موقعیت جدیدی ایجاد می شود. در غیر این صورت، مقدار مشخصه حاوی کتیبه "<Объект не найден>"و شناسه منحصر به فرد آن.

در یک حالت ساده، بدون نمونه برداری، تنظیمات بارگیری مجدد آیتم به این صورت خواهد بود.

V این مثالشما باید فقط نامی را انتخاب کنید که در پوشه "Woodworking" قرار دارد.

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

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

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

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

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

بارگیری یک مرجع از XML

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

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

نتیجه دانلود در پیام ها نمایش داده می شود. در مورد ما همه چیز خوب پیش رفت.

دایرکتوری "نامگذاری" در پایه - گیرنده پر نشده است. اکنون دارای پنج عنصر است: سه مورد نامگذاری و دو گروه.

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

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

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

مراحل انتقال

انتقال اطلاعات شامل 5 مرحله است. ما سعی کردیم آنها را به جزئی ترین و قابل فهم ترین شکل توصیف کنیم.

چرا انتقال اطلاعات ما بهتر است؟

هزینه انتقال داده های معمولی

نگهداری از یک برنامه جدید

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

انتقال به 1C 8.2

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

چرا ما بهتریم؟

انتقال سفارش

تیم ما

چرا انتقال 1C ما بهتر است؟

شفافیت

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

رویکرد فردی

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

کیفیت

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

برای نتیجه کار کنید

کار تنها پس از اینکه مطمئن شوید که انتقال دایرکتوری های 1C 8 و سایر داده ها به درستی انجام شده است، انجام شده و از نتیجه راضی هستید. ما مشتریان خود را رها نمی کنیم!

مرحله 1. تجزیه و تحلیل کلی از پایگاه منبع

چه کاری انجام می شود:

به دست آوردن یک پیکربندی نسخه معمولی مشابه با پایه منبع؛

تجزیه و تحلیل کلی تغییرات در ساختار داده (مقایسه با یک پیکربندی معمولی)؛

تجزیه و تحلیل کلی تغییرات در فرم ها و ماژول های پیکربندی (مقایسه با یک پیکربندی معمولی)؛

کنترل در دسترس بودن حساب های حسابداری غیر معمول برای پیکربندی های حسابداری؛

کنترل کلی صحت حسابداری در پایه منبع (وجود مانده های "قرمز"، دوره های باز، توالی های بازیابی نشده و غیره)؛

به روز رسانی پایگاه داده منبع به نسخه مورد نیاز توسط قوانین مهاجرت استاندارد؛

انتقال داده آزمایشی؛

تهیه توصیه های احتمالی برای تهیه پایگاه داده منبع برای انتقال کتاب های مرجع 1C 8 و سایر داده ها.

چرا:

تعیین امکان استفاده از یک انتقال معمولی؛

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

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

اگر انتقال معمولی صحیح امکان پذیر نباشد، پیشنهادی با هزینه کار بر روی نهایی کردن تنظیمات، قوانین مبادله و انتقال غیر معمول تهیه می شود.

قیمت: 2000 روبل

مرحله 2. تهیه اسناد فنی برای انتقال غیر معمول

چه کاری انجام می شود:

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

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

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

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

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

چرا:

تضمین کیفیت و شفافیت کار در انتقال غیر معمول پایگاه های داده 1C؛

برآورد دقیق هزینه و مدت کار؛

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

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

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

مرحله 3. اصلاح پیکربندی گیرنده

چه کاری انجام می شود:

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

آزمایش اولیه تغییرات انجام می شود.

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

نمایش پیشرفت ها برای کاربر انجام می شود (تحویل - پذیرش کار)؛

یک کتابچه راهنمای کاربر برای بهبود در حال توسعه است (در صورت لزوم).

چرا:

شما در حال گرفتن هستید آخرین نسخهتنظیمات با تغییراتی که نیاز دارید؛

شما اسنادی را برای بهبودهایی که برای بیشتر نیاز دارید دریافت می کنید
به روز رسانی توسط یک مهندس خدمات

مرحله 4. اصلاح قوانین انتقال

چه کاری انجام می شود:

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

آزمایش اولیه انتقال با در نظر گرفتن تغییرات انجام می شود.

چرا:

انتقال صحیح داده ها ارائه شده است که توسط قوانین تبادل استاندارد منتقل نمی شود.

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

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

مرحله 5. انتقال داده ها

چه کاری انجام می شود:

حمل و نقل اطلاعات مرجع(همه، یا از طریق پیوندها)، انتقال مانده ها به تاریخ معین؛

کنترل صحت انتقال - مقایسه داده های پایگاه داده منبع و پایگاه داده مقصد.

تهیه توصیه های احتمالی برای تنظیم مانده ها در پایه دریافت با در نظر گرفتن ویژگی های حسابداری در پیکربندی های مختلف (در صورت لزوم).

چرا:

برای رفتن آماده میشی پایه جدیدداده ها با موجودی فعلی شما

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