در طول یک دهه گذشته ، "بدون پول" یکی از برجسته ترین عناوین در اقتصاد هند بوده است. در حالی که قدرت دیجیتالی شدن فراگیر بوده است ، معامله از طریق پول نقد فیزیکی سنتی است که کاملاً متزلزل نشده است. و اثبات آن تعداد معامله هایی است که ما در فضای تجارت الکترونیکی بیش از حد شاهد هستیم. در یک بازار 3 طرفه ، مانند Swiggy ، که در آن سفارشات در زمان واقعی است و کوانتومی معاملات نمایی است ، پول نقد در تحویل [COD] به یک چالش یک چالش تبدیل می شود. بنابراین چگونه می توانیم اطمینان حاصل کنیم که مدیریت و ردیابی معاملات نقدی به صورت ضد آب انجام می شود؟چگونه فناوری می تواند موارد نشت و کلاهبرداری ها را در این روش پرداخت غیر دیجیتالی به طرز چشمگیری کاهش دهد؟برای دیدن آنچه که ما در مورد ...

در یک تجارت در بازار ، COD (پول نقد در تحویل) راهی عالی برای جذب علاقه مشتریان جدید است. بسیار محبوب در بین شهرهای Tier-2 & Tier-3 ، و همچنین در بین مشتریان زرنگ و دانا ، COD گزینه ای برای کسانی است که نسبت به قرار دادن کارت اعتباری خود بر روی سوابق یا استفاده از بانکداری اینترنتی نگران هستند. در حالی که UPI با توجه به جمعیت بزرگ و متنوع ما و مقیاس عملیات Swiggy ، دارای نفوذ در مورد پرداخت های آنلاین است ، COD همچنان موقعیت قطب را به عنوان یکی از بزرگترین روش های پرداخت (20 ٪ حجم سفارش) که مشتریان ما به آن جا می گیرند ، ادامه می دهد.

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

• چگونه می توانیم اطمینان حاصل کنیم که DES (مدیران تحویل) انگیزه دارند که بدون تأخیر ، پول نقد را به حساب Swiggy واریز کنند؟
• در صورت عدم پرداخت پول نقد توسط شریک تحویل ، چگونه می توانیم ضرر را به حداقل برسانیم؟
• چگونه می توانیم به طور مداوم حجم و سن پول نقد را پیگیری کنیم؟
• چگونه می توانیم یک مسیر فعال از DES را که Swiggy را بدون سپرده گذاری مجموعه های COD ترک کرده است ، نگه داریم و چگونه می توانیم در صورت پیوستن به Swiggy در یک بازه زمانی بعدی ، تعطیلی را مدیریت کنیم؟

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

برای پرداختن به ضرر نقدی ، ما شروع به ساختن یک سیستم مدیریت نقدی شناور (FCMS) کردیم. FCMS به منظور انجام این کار است:

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

Floating Cash (FC) نقدی است که DES به نمایندگی از Swiggy از مشتریان جمع آوری کرده است ، اما واریز نشده است. این سیستم کلیه داده های سفارش را برای سفارشات COD و کلیه سپرده های نقدی انجام شده توسط DE مصرف و ذخیره می کند. هنگامی که یک سفارش COD جدید تحویل داده می شود ، این سیستم یک رویداد را دریافت می کند و پول نقد شناور را برای DES به روز می کند. این سیستم یک API را در معرض دید قرار می دهد که می تواند دیدگاه زمان واقعی را با DE و انتظار جمع آوری داشته باشد. این سیستم شناسه سفارش ، مبلغ سفارش و شناسه را برچسب می زند.

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

دلایل مختلفی وجود دارد که واریانس COD رخ می دهد. به عنوان مثال ، اگر مشتری سفارشات COD را برای نان پیتزا (400 روپیه) و سیر (150 روپیه) قرار داده است و به دلایلی اگر رستوران شامل نان سیر به همراه پیتزا نباشد ، مشتری 400 روپیه پرداخت می کند (پرداخت نمی کند. 150 برای نان سیر) هنگام تحویل سفارش. یا مشتری به دلیل مشکل لغزش یا بسته بندی ناراضی است و هیچ مبلغی را پرداخت نمی کند. در این مورد چه می کند؟او کالای تحویل شده را علامت گذاری می کند و این نظر را در مورد آنچه اتفاق افتاده است یا ممکن است با خدمات مشتری ما نیز تماس بگیرد. همچنین می تواند مواردی وجود داشته باشد که DE 650 نفر را از مشتریان جمع کرده باشد ، اما او به امید اینکه 150 را در جیب خود نگه دارد (پرونده کلاهبرداری) در برنامه خود وارد 500 نفر شد. ما این را به عنوان واریانس COD علامت گذاری می کنیم که بخشی از پول نقد شناور می شود. در موارد واقعی ، DE به تیم OPS ما می رسد و ما اصلاح لازم را انجام می دهیم. با توجه به مقیاس و قله های ما (به عنوان مثال شام آخر هفته ، IPL Match) تیم OPS به یک تنگنا برای رسیدگی به تمام سؤالات تبدیل می شود.

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

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

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

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

ما چندین مصرف کننده کافکا داریم که از خوشه های کافکا در رویدادهایی مشترک هستند. این رویدادها توسط Checkout و DE System منتشر می شوند. DE Systems مسئول برنامه های شریک زندگی ، مدیریت چرخه زندگی راننده ، قابلیت خدمات و سایر ویژگی های مربوط به تحقق سفارش است. شما می توانید به سیستم های مجدداً-swiggys-logistics-systems و معماری و طراحی-اصول-در-پشت-سوگیجی-ارسال کننده-برنامه ها مراجعه کنید که در مورد برخی از مشکلات جالب که DE System حل می کند صحبت می کند. هنگامی که غذا تحویل داده می شود ، DE System رویدادهای تحویل شده ای را که توسط FCMS مصرف می شود ، ارسال می کند. FCMS منطق کسب و کار را اجرا می کند ، دفترچه نقدی شناور را به روز می کند و بر اساس مبلغ قابل پرداخت خالص در این رویداد ، ارزش نقدی جدید شناور ایجاد می کند.

از دیدگاه عملکرد ، مهم است که FCMS دقیق است و زمان واقعی و نمای مداوم از داده های نقدی شناور را ارائه می دهد. FCMS رویدادهای زمان واقعی را از سیستم های پرداخت (سفارش قرار داده شده) و DE Systems (رویداد تحویل سفارش) مصرف می کند. FCMS در هنگام قله های ناهار و شام ما ترافیک زیادی می کند. این سیستم باید اطمینان حاصل کند که قادر به مصرف رویدادها و پردازش رویداد با همان نرخ است. این باید دفترچه نقدی شناور را در زمان واقعی به روز نگه دارد ، زیرا همچنین تماس تلفنی از هزاران نفر از DE را دریافت می کند که می خواهند پس از انجام سفارشات COD ، پول نقد شناور خود را بررسی کنند. در زیر نمودار رویدادهای مصرفی را نشان می دهد و تماس های API دریافت شده توسط FCMS را برای یک هفته هفته دریافت می کند. قله هایی که در نمودار زیر مشاهده می کنید ، قله های ناهار و شام هستند. معمولاً قله های ناهار از شام کوچکتر هستند.

همانطور که از نمودار فوق مشاهده می شود ، فروشگاه داده های پس زمینه ما باید برای وارد کردن داده های سفارش جدید کارآمد باشد و برای تهیه پول نقد شناور دقیق در طول تماس های GET در ساعات اوج ، کارآمد باشد. برای این مورد استفاده خاص ، ما از MySQL به عنوان یک فروشگاه داده برای ذخیره معامله COD و دفترچه برای شناور پول نقد استفاده می کنیم. ما از تکنیک تکثیر MySQL Master Slave استفاده می کنیم تا اطمینان حاصل کنیم که همه نوشتن ها به گره استاد می روند و تمام درخواست های خوانده شده از Slave ارائه می شود. ما همچنین دو پایگاه داده برده برای توزیع بیشتر نمایش داده ها بر اساس الگوهای خوانده شده داریم. تمام نمایش داده شدگان API توسط یک برده ارائه می شوند و کلیه نمایش داده های خوانده شده مربوط به مشاغل دسته ای توسط یک برده دیگر ارائه می شود. این تفکیک برای اطمینان از برنامه های دسته ای بر عملکرد API در زمان واقعی تأثیر نمی گذارد.

از طرف برنامه ، ما از گروه مقیاس گذاری AWS AUTO برای موارد مجلل و پایین EC2 در صورت لزوم استفاده می کنیم.

عدم پردازش رویدادها منجر به از بین رفتن پول و پردازش بیش از یک بار منجر به مقادیر نادرست نقدی شناور می شود که منجر به تشدید توسط DE و حجم تماس زیاد به تیم OPS ما می شود. FCMS همچنین باید اطمینان حاصل کند که مصرف می کند و ضمانت دقیقاً یک بار پردازش را ارائه می دهد. اگر ما به دلیل هرگونه خطایی (به عنوان مثال DB Timeout) قادر به پردازش یک رویداد نباشیم ، پس از 3 بار دوباره امتحان کردن پیام را در صف آزمایش مجدد قرار می دهیم تا اطمینان حاصل کنیم که پس از حل مسئله خاص قادر به پردازش این رویداد هستیم. این سیستم همچنین API را که توسط خدمات مختلف مربوط به Genies Swiggy و Swiggy Stores Business استفاده می شود ، در معرض دید قرار می دهد (بیشتر در مورد این بعداً ..).

ما از یک شناسه منحصر به فرد (به عنوان مثال OrderID) برای بررسی های IdemPotency استفاده می کنیم که دقیقاً یک بار پردازش را تضمین می کند.

توانایی حفظ محدودیت نقدی پایین و بالا توسط منطقه

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

ما از پول نقد شناور محاسبه شده در نقطه 1 بالا و حد پایین و حد بالایی برای ارسال سیگنال های مختلف به سیستم DE استفاده می کنیم. DE Systems مسئول تکالیف سفارش به DE ، مدیریت چرخه زندگی راننده (DLM) ، برنامه DE از جمله موارد دیگر است. یک سیگنال می تواند در صورتی باشد که پول نقد شناور از حد پایین تر و کمتر از 120 ٪ از حد بالایی باشد ، سپس اختصاص سفارشات جدید COD را متوقف کنید ، اما ما می توانیم به اختصاص سفارشات پیش پرداخت ادامه دهیم. یا اعلان را به DE APP ارسال کنید که وی از محدودیت نقدی شناور عبور کرده است و برای واریز پول نقد برای ادامه دریافت سفارشات COD واریز می کند. به طور مشابه با عبور از 120 ٪ از حد بالایی ، ما سیگنالهایی را برای متوقف کردن اختصاص کلیه سفارشات به DE یا به زور وارد کردن ورود به سیستم می فرستیم تا اینکه شریک زندگی پول نقد را سپری می کند. همچنین مواردی وجود دارد که یک DE سفارش بزرگی از گفتن 6000 روپیه را به عنوان پول نقد انجام می دهد ، و یک ساعت اوج است. بنابراین غیر منطقی است که از DE بخواهید پول نقد را در همان لحظه واریز کنید. تنظیماتی وجود دارد که می توانند بر اساس عرضه تقاضا تنظیم شوند تا اطمینان حاصل شود که DE در ساعت اوج خود از سیستم خارج نشده است ، اما این موضوع بحث دیگری است.

کانال های سپرده نقدی را افزایش دهید

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

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

بنابراین DE اکنون می تواند به CDM برود یا از UPI برای انتقال پول به حساب Swiggy استفاده کند. شرکای بانکی ما هر زمان که DE پول نقد را واریز می کند ، با API ما تماس می گیرند. اینها API های مهمی هستند که نیاز به در دسترس بودن بالایی دارند ، زیرا ما نمی توانیم 100 ٪ به بانک ها اعتماد کنیم تا در صورت بروز خرابی ها ، اقدامات خود را انجام دهند و تحمل گسل را انجام دهیم. ما از تکنیک های مشابه همانطور که در بالا توضیح داده شد استفاده می کنیم تا اطمینان حاصل کنیم که دقیقاً یک بار پردازش برای سپرده نیز انجام می دهیم.

ما غالباً به موضوعاتی رسیده ایم که DE شکایت می کند که او حتی پس از واریز پول نقد قادر به ورود به سیستم نیست. این معمولاً زمانی اتفاق می افتد که در بانک ها یا NPCI که صاحب UPI هستند ، وجود داشته باشد. این به صورت موردی به صورت موردی حل می شود و بیشتر اوقات به این معنی است که ما یک شماره RRN (شماره مرجع منحصر به فرد برای انتقال UPI) دریافت می کنیم و FCM ها با بانک تماس می گیرند که به نوبه خود برای دریافت جزئیات معامله با NPCI تماس می گیرد. پس از موفقیت در جستجوی ، ما نقدی شناور را به روز می کنیم و سیگنال سبز را به سیستم DE ارسال می کنیم که می تواند اقدامات مناسب را انجام دهد (به عنوان مثال اجازه ورود به سیستم)

در دریافت تماس های API ، ما در سیستم خود ورودی هایی ایجاد می کنیم و پول نقد شناور را تنظیم می کنیم. بنابراین اگر در 500 روپیه سپرده می شود ، در نقدی بالاتر ، پول نقد شناور وی 150 می شود (از آنجا که FC قبلی 650 بود).

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

راه اندازی فروشگاه های Swiggy Genie و Swiggy

بعد از راه اندازی فروشگاه های Swiggy Genie و Swiggy ، همه چیز جالب تر شد. برای کسانی که نمی دانند ، Swiggy Genie توسط مشتریان ما برای سفارش مواردی که در Swiggy ذکر نشده اند استفاده می شود. به عنوان مثال ، می توان Swiggy Genie را برای خرید شیرین مورد علاقه خود رزرو کرد ، حتی اگر فروشگاه شیرین در Swiggy ذکر نشده باشد. از آنجا که ما دقیقاً قیمت کالا را نمی دانیم یا اینکه کالای موجود در مغازه موجود است ، روند عادی پس از رزرو موفقیت آمیز به مغازه می رود ، او قیمت اقلام را بررسی می کند و برای تأیید با شما تماس می گیرد. بنابراین اگر تصمیم گرفتید 1 کیلوگرم LADDU را برای INR 350 سفارش دهید ، DE مبلغ موجود در برنامه را وارد می کند و شما می توانید این مبلغ را پرداخت کنید. پس از پرداخت موفقیت آمیز مشتری ، ما این مبلغ را به جزئیات حساب بانکی منتقل می کنیم وسپس DE برای خرید Laddu مورد علاقه خود به فروشگاه شیرین پرداخت می کند. اما اگر DE درست قبل از سفارش شما سفارش COD از INR 500 را انجام داده باشد ، چه می شود. سپس پول نقد شناور وارد تصویر می شود. قبل از انتقال به حساب DE Bank ، سیستم داخلی ما با FCMS API تماس می گیرد. FCMS بررسی می کند که آیا DE دارای پول نقد شناور است و آیا DE می تواند از پول نقد در حال حاضر برای سفارش استفاده کند. در مثال بالا ، ما هیچ مبلغی را به DE منتقل نمی کنیم زیرا مانده نقدی شناور وی 500 است و سیستم به DE اطلاع می دهد که از پول نقد شناور برای پرداخت در فروشگاه شیرین استفاده کند. پس از اتمام پول نقد شناور او تنظیم می شود و پول نقد شناور جدید 150 (500 منهای 350) خواهد بود. همانطور که ما Genie را مقیاس می کنیم ، FCMS نقش مهمی در اطمینان از استفاده از پول نقد جمع آوری شده برای تحویل مواد غذایی در سایر خطوط تجارت ایفا می کند. FCMS همچنین بسیار مهم می شود زیرا هرگونه عدم موفقیت یا تأخیر به این معنی است که DE قادر به تکمیل سفارش در SLA نیست که Swiggy قبل از رزرو قول داده است. در برخی موارد شدید ، DE باید در فروشگاه ها منتظر بماند زیرا ممکن است در جیب خود پول نقدی برای پرداخت در فروشگاه نداشته باشد.

بنابراین به طور خلاصه ، FCMS سه مشکل اساسی را حل می کند

1. ارائه بینش به سفارشات COD و داده های قدرت که می توانند نقدی شناور را بر اساس ابعاد متعدد (شهر ، سن ، منطقه و غیره) گزارش دهند.
2. قابلیت پیکربندی حد پویا بر اساس مناطق/شهر و ارسال سیگنال به سایر سیستم ها که می توانند تعامل کاربر نهایی را بر اساس مانده نقدی شناور تغییر دهند.
3. راحتی را برای شرکای تحویل فراهم کنید تا از طریق ادغام با UPI ، ماشین سپرده نقدی ، بانک پرداخت Airtel و غیره ، سریعتر پول نقد را واریز کنند.

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

1. پرداخت در هنگام ردیابی - گزینه هایی را برای کاربران فراهم کنید تا از صفحه های ردیابی سفارش پرداخت کنند.
2. پرداخت در هنگام تحویل - کد QR را در مورد رسیدی که مشتریان می توانند هنگام تحویل شریک تحویل غذا ، اسکن و پرداخت کنند ، تهیه کنید.

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