برای ورود اطلاعات در Odoo 19 بدون رکورد تکراری، هویت هر ردیف را پیش از بارگذاری تعیین کنید: رکورد تازه است یا باید رکورد موجود را تغییر دهد؟ شناسهٔ خارجی ثابت، نگاشت روشن ستون‌ها و آزمون اجرای دوباره، سه کنترل اصلی این کارند. یکسان‌بودن نام مشتری یا سبزبودن نتیجهٔ Test به‌تنهایی کافی نیست. این راهنما برای ورود گروهی مخاطبان از فایل است؛ عملیات حسابداری، سفارش‌های چندسطری و اتصال دائمی سامانه‌ها به طراحی و آزمون جداگانه نیاز دارند.
پاسخ کوتاه: برای اصلاح اطلاعات موجود، از خروجی سازگار با ورود مجدد شروع کنید و External ID را نگه دارید. برای انتقال اولیه، شناسه‌ای پایدار از سامانهٔ مبدأ بسازید. سپس در محیط آزمون نشان دهید بار دوم، همان شناسهٔ داخلی تغییر می‌کند و تعداد رکوردها افزایش نمی‌یابد.
۱. تفاوت شناسهٔ خارجی با نام و شناسهٔ داخلی
External ID یا شناسهٔ خارجی، مرجعی برای یافتن رکورد در Odoo است. Database ID شناسهٔ داخلی همان رکورد در پایگاه داده است. نام، ایمیل و شمارهٔ تلفن، اطلاعات کسب‌وکارند؛ نباید بدون قرارداد مشخص، آن‌ها را معادل این دو شناسه فرض کنید. در مسیر بارگذاری ORM در شاخهٔ 19.0، شناسهٔ خارجی موجود به رکورد مربوط وصل می‌شود؛ شناسهٔ جدید می‌تواند مسیر ساخت رکورد را انتخاب کند.
پیشنهاد عملی این است که پیش از فایل، یک جدول تطبیق بسازید: سامانهٔ مبدأ، نوع موجودیت، کلید مبدأ و رکورد مقصد. مثلاً مشتری شمارهٔ ۴۲ و شخص تماس شمارهٔ ۴۲ دو موجودیت‌اند؛ پیشوندهای متفاوت مانند legacy_crm_company_042 و legacy_crm_person_042 از اشتباه انسانی جلوگیری می‌کنند. شمارهٔ ردیف فایل انتخاب خوبی نیست؛ با مرتب‌سازی یا حذف ردیف‌ها جابه‌جا می‌شود.
شناسهٔ ثابت، پاک‌سازی معنایی انجام نمی‌دهد. اگر یک شرکت در مبدأ دو شناسه داشته باشد، باید پیش از مهاجرت دربارهٔ ادغام آن تصمیم بگیرید. برعکس، دو شرکت هم‌نام را صرفاً به‌دلیل تشابه نام یکی نکنید. مالک داده باید تصمیم را تأیید کند و نگاشت قدیم به جدید باقی بماند. شناسهٔ خارجی هم رمز یا مجوز دسترسی نیست و نباید اطلاعات محرمانه را داخل آن نوشت.
۲. مسیر اصلاح موجود را از انتقال اولیه جدا کنید
برای اصلاح مخاطبان موجود، در نمای فهرست رکوردهای هدف را انتخاب و از Export استفاده کنید. گزینهٔ I want to update data (import-compatible export) را فعال کنید تا خروجی شناسهٔ خارجی را همراه داشته باشد. طبق راهنمای رسمی به‌روزرسانی داده، حذف یا تغییر این شناسه ممکن است به ساخت رکورد تکراری منجر شود.
نسخهٔ دست‌نخوردهٔ خروجی را نگه دارید و فایل کار را جدا بسازید. فقط ستون‌های مصوب را تغییر دهید؛ اگر هدف اصلاح تلفن است، اضافه‌کردن ستون‌های نامرتبط، دامنهٔ تغییر را بی‌دلیل بزرگ می‌کند. شناسه‌ها را در ابزار صفحه‌گسترده به‌صورت متن نگه دارید تا صفر ابتدایی یا رشتهٔ طولانی ناخواسته تبدیل نشود. پیش از ذخیرهٔ نهایی، چند مقدار واقعی را با نسخهٔ اولیه تطبیق دهید.
برای انتقال اولیه، ابتدا بررسی کنید آیا همان اشخاص یا شرکت‌ها قبلاً در مقصد وجود دارند. دادن یک شناسهٔ تازه به مشتری قدیمی به این معنا نیست که Odoo خودکار آن را بر اساس تلفن به مشتری قبلی وصل می‌کند. موارد مشکوک را از دستهٔ آماده جدا کنید و پس از تعیین تکلیف وارد کنید. هدف، عبور سریع همهٔ ردیف‌ها از ابزار نیست؛ هر ردیف باید مقصد معلوم داشته باشد.
۳. مثال آموزشی: شرکت و شخص تماس با هویت مستقل
مثال زیر کاملاً فرضی است و در محیط تولید اجرا نشده است. فرض کنید یک شرکت تازه و یک شخص تماس تازه باید ساخته شوند. فایل اول، شرکت را تعریف می‌کند. عنوان فنی ستون id در این نمونه به External ID نگاشت می‌شود؛ آن را با ستون Database ID اشتباه نگیرید. در رابط فارسی، نگاشت را صریحاً بازبینی کنید.
id,name,is_company
legacy_crm_company_042,شرکت نمونه سپهر,Trueپس از ورود و بررسی شرکت، فایل دوم شخص تماس را با ارجاع به شناسهٔ همان شرکت وارد می‌کند. parent_id/id در این مثال مسیر شناسهٔ خارجی «شرکت مرتبط» است. نام شرکت را در ستون رابطه کپی نکنید؛ رابطه باید به همان مقصد تأییدشده اشاره کند.
id,name,is_company,parent_id/id
legacy_crm_person_107,مخاطب نمونه,False,legacy_crm_company_042در نوبت بعد، برای اصلاح نام همین شخص، شناسهٔ او ثابت می‌ماند و فقط مقدار نام عوض می‌شود. انتظار آموزشی این است که شخص دوم ساخته نشود. این رفتار را با بازکردن رکورد و مقایسهٔ شناسهٔ داخلی قبل و بعد تأیید کنید. در مدل رسمی شناسه‌های خارجی، مرجع به مدل و رکورد متصل است؛ بنابراین استفادهٔ دوباره از یک مرجع برای دو موجودیت مستقل، طراحی درستی نیست.
۴. نگاشت ستون‌ها و رابطه‌ها را مستقل کنترل کنید
در کد رسمی ابزار ورود دادهٔ Odoo 19، پیشنهاد نگاشت بر پایهٔ نام ستون، برچسب فیلد و تشابه آن‌ها ساخته می‌شود. پیشنهاد خودکار را تصمیم نهایی تلقی نکنید. یک نفر ستون‌های فایل را بخواند و نفر بازبین، فیلد مقصد و نمونهٔ مقدار را تطبیق دهد. نام مشابه دو فیلد، کاربرد یکسان آن‌ها را ثابت نمی‌کند.
برای هر رابطه فقط یک روش روشن انتخاب کنید و هویت رکورد مرتبط را بررسی کنید. در مثال شخص تماس، پرسش صرفاً «این شرکت وجود دارد؟» نیست؛ باید دید «این شخص به شرکت درست وصل شده؟». در محیط چندشرکتی، شرکت‌های مجاز کاربر و اشتراکی‌بودن مخاطب را هم در سناریوی آزمون لحاظ کنید؛ برای رفع خطا، سطح دسترسی کاربر را بی‌برنامه افزایش ندهید.
ستون حذف‌شده و سلول خالی را یکسان ندانید. در به‌روزرسانی، ستونی که نگاشت نشده با ستونی که برای پاک‌کردن مقدار ارسال می‌شود فرق دارد؛ رفتار فیلد و گزینه‌های ورود را روی نمونه بیازمایید. برای اصلاح تلفن، ستون ایمیل خالی را صرفاً برای کامل‌بودن ظاهر جدول اضافه نکنید. قرارداد فایل باید روشن کند کدام مقدار تغییر می‌کند و کدام مقدار حفظ می‌شود.
| نشانه | کنترل پیشنهادی |
|---|---|
| رکوردی با همان نام پیدا شد | مالک داده و نگاشت مبدأ را بررسی کنید؛ نام به‌تنهایی تعیین‌کننده نیست. |
| شناسهٔ خارجی در فایل عوض شده | فایل اولیه را مقایسه کنید؛ پیش از Import علت تغییر را روشن کنید. |
| شخص به شرکت نادرست وصل شده | نگاشت ستون رابطه و شناسهٔ شرکت مقصد را بخوانید. |
| ستون موردنظر در پیشنهادها نیست | مدل، فیلدهای قابل ورود و تنظیمات پیشرفتهٔ همان نسخه را بررسی کنید. |
| فایل شامل ستون‌های اضافی است | دامنهٔ تغییر را کوچک و فقط ستون‌های تأییدشده را نگاشت کنید. |
۵. Test را با آزمون اجرای دوباره تکمیل کنید
دکمهٔ Test اعتبارسنجی ورود را انجام می‌دهد؛ مسیر dryrun در کد رسمی، نوشتارهای آزمون ورود را بازمی‌گرداند. بااین‌حال این نتیجه تضمین نمی‌کند شناسهٔ انتخابی شما به مشتری تجاری درست اشاره می‌کند. علاوه بر آن، ماژول سفارشی ممکن است هنگام اجرای منطق خود اثر خارجی ایجاد کند؛ محیط آزمون باید ارسال پیام، پرداخت و اتصال‌های واقعی را مطابق نیاز مهار کند.
یک بستهٔ کوچک اما متنوع بسازید: رکورد تازه، رکورد موجود با تغییر مجاز، دو نام مشابه، یک رابطه و یک مورد عمداً نامعتبر. سپس آزمون پذیرش را به این ترتیب انجام دهید:
- پیش از ورود، تعداد و هویت رکوردهای محدودهٔ آزمون را ثبت کنید.
- فایل را بارگذاری، نگاشت را تأیید و Test را اجرا کنید؛ خطاها را با شمارهٔ ردیف بررسی کنید.
- ورود واقعی را فقط در محیط آزمون انجام دهید و مقدار و رابطهٔ چند نمونه را بازخوانی کنید.
- همان فایل را دوباره وارد کنید؛ تعداد و شناسه‌های داخلی باید مطابق انتظار ثابت بمانند.
- یک مقدار مجاز را با همان شناسه تغییر دهید؛ تأیید کنید همان رکورد تغییر کرده و رابطه‌ها حفظ شده‌اند.
اگر تعداد ثابت بود ولی رکورد اشتباه تغییر کرد، آزمون شکست خورده است. اگر رکورد درست تغییر کرد ولی یک فیلد نامرتبط پاک شد، باز هم آمادهٔ تولید نیستید. نتیجه را با شواهد قابل بازبینی تحویل دهید، نه صرفاً تصویر پیام موفقیت.
۶. در خطا یا قطع ارتباط، از روی حدس تکرار نکنید
اگر پس از Import ارتباط قطع شد، وضعیت را «نامعلوم» ثبت کنید. ابتدا با شناسه‌های بسته، نتیجهٔ موجود را بخوانید و مشخص کنید کدام ردیف‌ها ساخته یا اصلاح شده‌اند. تغییر دسته‌جمعی شناسه‌ها برای فرار از خطا، امکان تطبیق را از بین می‌برد. دربارهٔ مرز تراکنش و تکرار درخواست در اتصال نرم‌افزاری، راهنمای JSON-2 در Odoo 19 مکمل این بحث است.
فایل بزرگ را به دسته‌های قابل رسیدگی تقسیم کنید و برای هر دسته، شناسه‌ها، نسخهٔ فایل، زمان اجرا و نتیجه را نگه دارید. اندازهٔ ثابت و تضمین‌شده‌ای برای همهٔ استقرارها وجود ندارد؛ پیچیدگی مدل، رابطه‌ها و ماژول‌های نصب‌شده مؤثرند. دسته‌های وابسته را طوری مرتب کنید که رکورد مرجع پیش از رکورد وابسته تعیین تکلیف شده باشد.
شناسهٔ جدید را هم از نام فنی ماژول‌های موجود نسازید. مسیر رسمی بارگذاری برای ساخت بعضی شناسه‌ها با پیشوند ماژول نصب‌شده محدودیت دارد. پیشنهاد تحریریه برای فایل مهاجرت، کلید متنی ساده با پیشوند مبدأ و نوع موجودیت است؛ شناسه‌های موجود در خروجی Odoo را همان‌طور که هستند حفظ کنید.
۷. اجرای تولید را با بستهٔ تغییر قابل بازگشت تحویل دهید
بستهٔ اجرا شامل فایل تأییدشده، فهرست شناسه‌ها، نگاشت ستون‌ها، خروجی پیش از اصلاح و نتیجهٔ آزمون دوباره باشد. مسئول اجرا و مسئول تأیید داده را مشخص کنید. برای مخاطبان، زمان مناسب اجرای اصلاح تلفن یا شرکت مرتبط را با تیم استفاده‌کننده هماهنگ کنید تا ویرایش هم‌زمان، نتیجه را مبهم نکند.
ورود داده دکمهٔ عمومی Undo ندارد. برای برگرداندن اصلاح چند فیلد، می‌توان فایل وضعیت قبلی را با همان شناسه‌ها و پس از بازبینی دوباره وارد کرد؛ اما این کار لزوماً آثار جانبی یا ویرایش‌های بعدی را برنمی‌گرداند. حذف رکورد تازه نیز ممکن است به رابطه‌های بعدی آسیب بزند. برای تغییر حساس، مسیر پشتیبان و آزمون بازیابی Odoo و filestore باید پیشاپیش معلوم باشد؛ بازیابی کامل دیتابیس تصمیمی جدا با اثر بر همهٔ نوشتارهای بعدی است.
معیار پایان: رکورد درست با مقدار درست تغییر کرده، رابطه درست مانده و اجرای دوباره رکورد اضافی نساخته است. فایل، نگاشت و شواهد را برای نوبت بعد نگه دارید. اگر در طراحی نگاشت مبدأ، کنترل موارد هم‌نام یا آزمون مهاجرت نیاز به همراهی دارید، از صفحهٔ مشاورهٔ آسیاپرداز دامنهٔ کار را مطرح کنید.
محدودهٔ اعتبار: مستندات و سورس رسمی Odoo شاخهٔ 19.0 در زمان تهیه بررسی شده‌اند. نام گزینه‌ها، فیلدهای قابل ورود و آثار جانبی می‌توانند به زبان رابط و ماژول‌های نصب‌شده وابسته باشند. مثال‌ها و روش آزمون پیشنهادی‌اند؛ نتیجهٔ استقرار واقعی یا تضمین حذف همهٔ تکرارهای تجاری ادعا نمی‌شود.