11 KiB
پیشنهاد مدل اشخاص در مرحله استعلام
وضعیت: پیادهسازیشده در ۱۴۰۵/۰۶/۲۲
دامنه: تمام جریانهای استعلام کاربر، کارشناس، پروندهساز و مرکز تماس
نسخه انگلیسی: inquiry-participants-proposal.md
interface پیادهسازیشده
فیلدهای نقشها و آبجکت الزامی vehicle که در ادامه آمدهاند، مستقیماً در body تمام درخواستهای استعلام فعلی پذیرفته میشوند. این تغییر شامل فرم اولیه کاربر و mirror کارشناس/ثبتکننده در V2، جریان کارشناس V3، جریانهای پروندهساز V4/V5، مرکز تماس V6 و مسیرهای تکدرخواستی حضوری است. routeهای پلاک و VIN از قوانین مشترک اشخاص استفاده میکنند. فیلدهای تخت راننده/بیمهگذار و شماره تلفن، ورودی استعلام نیستند.
پاسخها و جزئیات پرونده برای نقشهای عملیاتی، در صورت وجود داده، فیلدهای نرمالشده participants، participantRoles، vehicle.registrationState، vehicle.previousPlateId و vehicle.previousPolicyholderNationalCode را نمایش میدهند.
مسئله
قرارداد فعلی استعلام عمدتاً فقط راننده و شخصی با عنوان insurer را نگه میدارد. این مدل کامل نیست و نامگذاری نیز دقیق نیست: شخص، بیمهگذار است و بیمهگر شرکت بیمه است.
برای هر وسیله نقلیه در یک Party نقشهای هویتی زیر وجود دارد:
| نوع پرونده | نقشهای الزامی |
|---|---|
THIRD_PARTY |
راننده، مالک وسیله نقلیه، بیمهگذار شخص ثالث |
CAR_BODY |
راننده، مالک وسیله نقلیه، بیمهگذار شخص ثالث، بیمهگذار بدنه |
ممکن است یک شخص چند نقش را داشته باشد، اما سیستم نباید یکسان بودن آنها را فرض کند.
پیشنهاد
پیش از اجرای استعلام، یک مرحله کوتاه تعیین اشخاص اضافه شود. ابتدا نسبت اشخاص پرسیده شود و اطلاعات فقط برای افراد متفاوت دریافت شود. دریافت بدون شرط اطلاعات کامل همه اشخاص مناسب نیست. همچنین افزودن فلگهای دوتایی متعدد مانند driverIsOwner و ownerIsPolicyholder باعث ابهام، تناقض و رشد سریع حالتها میشود.
بهجای آن، هر نقش یا اطلاعات یک شخص جدید را داشته باشد یا به نقش قبلی ارجاع دهد:
{
"driver": {
"nationalCode": "0012345678",
"birthday": "1370/01/01",
"hasDrivingLicense": true,
"licenseNumber": "123456789",
"licenseType": "1"
},
"vehicleOwner": { "sameAs": "DRIVER" },
"thirdPartyPolicyholder": { "sameAs": "VEHICLE_OWNER" },
"carBodyPolicyholder": {
"nationalCode": "0098765432",
"birthday": "1365/02/03"
}
}
فیلد carBodyPolicyholder برای THIRD_PARTY مجاز نیست و برای CAR_BODY الزامی است. هر نقش باید فقط یکی از دو حالت «اطلاعات شخص» یا sameAs را داشته باشد. بکاند این ورودی را به فهرست اشخاص یکتا و اتصال نقشها به آنها تبدیل میکند.
هر بیمهگذار باید با اطلاعات هویتی یا sameAs به یک شخص مشخص متصل شود. گزینه حذفشده unknown برای هیچ نقشی پذیرفته نمیشود؛ بنابراین استعلام بیمه بهدلیل نامشخص بودن هویت بیمهگذار رد یا عمداً اجرانشده ثبت نمیشود.
برای راننده، hasDrivingLicense الزامی است. اگر مقدار آن true باشد، هر دو فیلد licenseNumber و licenseType نیز الزامی هستند؛ اگر مقدار آن false باشد، استعلام گواهینامه عمداً اجرا نمیشود.
انتقال مالکیت اخیر و پلاک قبلی
نقش اشخاص و شناسههای خودرو دو موضوع جدا هستند. اگر خودرو بهتازگی فروخته یا خریداری شده باشد، ممکن است اطلاعات رسمی یا بیمهنامه هنوز به پلاک قبلی متصل باشد. این وضعیت باید صریح ثبت شود و پلاک قبلی نباید جایگزین پلاک فعلی شود:
{
"vehicle": {
"registrationState": "RECENTLY_TRANSFERRED",
"currentPlate": {
"leftDigits": "44",
"centerAlphabet": "ب",
"centerDigits": "111",
"ir": "22"
},
"previousPlate": {
"leftDigits": "55",
"centerAlphabet": "ج",
"centerDigits": "222",
"ir": "33"
},
"previousPolicyholderNationalCode": "0098765432",
"vin": "NAAM01E15HK123456"
}
}
مقدار پیشفرض registrationState برابر CURRENT است و برای این مسیر استثنایی مقدار RECENTLY_TRANSFERRED استفاده میشود. در انتقال اخیر، previousPlate، previousPolicyholderNationalCode و vin الزامیاند؛ فیلدهای مربوط به پلاک قبلی در حالت عادی CURRENT نباید ارسال شوند. این اطلاعات انتقال فقط بهعنوان متادیتای پرونده نگهداری میشوند و پلاک فعلی همچنان شناسه اصلی خودرو است.
در route پلاک، هماهنگکننده دقیقاً یک استعلام بیمه انجام میدهد: currentPlate همراه با بیمهگذار نهایی همان نوع بیمه. در route شماره شاسی نیز vehicle.vin با همان بیمهگذار نهایی ارسال میشود. previousPlate هیچگاه استعلام نمیشود، previousPolicyholderNationalCode به ارائهدهنده استعلام ارسال نمیشود و VIN برای انتخاب نتیجه پلاک قبلی به کار نمیرود.
ترتیب پیشنهادی فرم
- پلاک فعلی دریافت و درباره انتقال مالکیت اخیر پرسیده شود. در صورت انتقال اخیر، پلاک قبلی، کد ملی بیمهگذار مربوط به پلاک قبلی و VIN/شماره شاسی نیز دریافت شوند.
- اطلاعات هویتی و گواهینامه راننده دریافت شود.
- پرسیده شود آیا مالک خودرو همان راننده است؛ فقط در صورت تفاوت، اطلاعات مالک دریافت شود.
- برای بیمهگذار شخص ثالث یکی از «راننده»، «مالک» یا «شخص دیگر» انتخاب شود؛ فقط برای شخص دیگر فرم جدید نمایش داده شود.
- در
CAR_BODYهمین انتخاب برای بیمهگذار بدنه انجام شود و امکان انتخاب هر شخص ثبتشده یا شخص دیگر وجود داشته باشد. - خلاصه اشخاص نمایش داده شود و سپس استعلامها اجرا شوند.
به این ترتیب مسیر رایج کوتاه میماند و همه ترکیبهای معتبر نیز پشتیبانی میشوند.
محل منطق در بکاند
یک resolver مشترک برای اشخاص ساخته شود و تمام routeهای استعلام از آن استفاده کنند. interface این ماژول باید:
- نقشهای لازم را بر اساس نوع پرونده اعتبارسنجی و ارجاعهای نامعتبر یا حلقوی
sameAsرا رد کند؛ - شخص نهایی هر نقش را برگرداند؛
- هویت درست را به استعلام مرتبط بدهد: گواهینامه ← راننده، مالکیت و تطبیق شبا ← مالک خودرو، بیمه شخص ثالث با پلاک/VIN ← بیمهگذار شخص ثالث، بیمه بدنه با پلاک/VIN ← بیمهگذار بدنه؛
- شبا را در استعلام شخص مطالبهکننده خسارت (
SECONDزیاندیده درTHIRD_PARTYو طرف اول درCAR_BODY) الزامی کند و با کد ملی مالک خودرو اعتبارسنجی کند؛ در استعلامFIRSTمقصر پرونده ثالث شبا دریافت نمیشود؛ - فقط پلاک فعلی یا VIN ارسالشده را با بیمهگذار نهایی همان نوع بیمه استعلام کند؛ متادیتای انتقال قبلی نباید مسیریابی استعلام را تغییر دهد؛
- استعلام هویت را برای هر شخص یکتا فقط یک بار اجرا کند؛
- اشخاص نرمالشده و نقشهای آنها را در
Partyمربوط ذخیره کند. participantsوparticipantRolesذخیرهشده را بدون حذف اطلاعات در جزئیات پرونده پنلهای کارشناسی و پرونده خسارت متصل نمایش دهد تا اطلاعات راننده و سایر نقشها برای بررسی در دسترس بماند.
جریانهای V2 کاربر/کارشناس، V3، V4، V5 و V6 باید adapter همین قوانین مشترک باشند و منطق نسبت اشخاص را جداگانه پیادهسازی نکنند.
مرز قرارداد
ورودی استعلام فقط شامل آبجکتهای ساختاریافته اشخاص و خودرو است. بکاند فیلدهای تختی مانند nationalCodeOfDriver، nationalCodeOfInsurer، driverIsInsurer، plate/vin سطح بالا و phoneNumber را با خطای اعتبارسنجی رد میکند. احراز هویت تلفنی و جریانهای تماس با طرفین از جمعآوری هویت برای استعلام جدا هستند.
تصمیم پیشنهادی
راهحل مناسب، دریافت شرطی اطلاعات همراه با اتصال صریح نقشها است. این روش بدون طولانی کردن مسیر اکثر کاربران، اطلاعات کامل فراهم میکند، از تناقض فلگها جلوگیری میکند و یک مدل یکسان برای همه جریانهای استعلام میسازد.