فروش اعتباری و تسویه در سامانه B2B
در خردهفروشی، پرداخت پایان سفارش است. در فروش سازمانی پرداخت اتفاقی است که شصت روز بعد از سفارش میافتد، و بین این دو، شما کالا دادهاید و پول نگرفتهاید. هر سامانه فروش B2B باید این فاصله را مدیریت کند، وگرنه ابزاری ساختهاید که فروش را آسان میکند و ریسک را ندیده میگیرد.
سه عددی که باید همیشه معلوم باشند
مدیریت اعتبار روی سه عدد میچرخد و اگر هر سه در دسترس نباشند، بقیه ماجرا حدسزدن است.
سقف اعتبار، که در قرارداد تعیین شده و بیشترین بدهی مجاز مشتری است.
مانده بدهی، مجموع فاکتورهای تسویهنشده. این عدد در نرمافزار مالی شماست، نه در سامانه فروش.
اعتبار در دسترس، که سقف منهای مانده است، منهای سفارشهای ثبتشدهای که هنوز فاکتور نشدهاند.
آن قلم آخر جایی است که پیادهسازیها اشتباه میکنند. اگر سامانه فقط بدهی فاکتورشده را کم کند، مشتری میتواند در یک روز پنج سفارش ثبت کند که هیچکدام جدا از سقف عبور نمیکنند ولی جمعشان دو برابر سقف است. سفارش ثبتشده و ارسالنشده هم باید اعتبار را قفل کند.
سفارشی که از سقف عبور میکند
سه رفتار ممکن است و انتخاب بین آنها تصمیم کسبوکار است، نه تصمیم فنی.
رد کردن. صریح و ساده، و در بیشتر موارد اشتباه. مشتریای که سفارشش رد میشود تلفن را برمیدارد و کار به همان جایی میرسد که میخواستید از آن دربیایید.
پذیرش و ارسال به تأیید مالی. سفارش ثبت میشود، مشتری میبیند که در انتظار تأیید است، و واحد مالی تصمیم میگیرد. این گزینه در عمل بهترین است چون فرصت فروش را از دست نمیدهد و کنترل را هم حفظ میکند.
پذیرش با پرداخت نقدی مازاد. تا سقف اعتباری، مازاد نقدی. برای بخشی از بازار جواب میدهد، ولی پیادهسازیاش پیچیده است چون یک سفارش دو روش پرداخت پیدا میکند.
هر کدام را انتخاب کنید، باید بدانید در حالت انتظار تأیید، کالا رزرو میشود یا نه. اگر رزرو نشود و کالا کم باشد، ممکن است سفارش تأیید شود و کالایی نمانده باشد. اگر رزرو شود و تأیید طول بکشد، موجودی بیدلیل قفل مانده است. برای کالاهای کمموجودی معمولاً رزرو با مهلت انقضا پاسخ درست است.
اتصال به نرمافزار مالی
مانده بدهی در سامانه فروش تولید نمیشود. در نرمافزار حسابداری شماست و باید از آنجا بیاید. کیفیت این اتصال، کیفیت کل قابلیت مدیریت اعتبار را تعیین میکند.
سه الگو در عمل استفاده میشود.
فراخوانی لحظهای. سامانه فروش هنگام ثبت سفارش، مانده را از نرمافزار مالی میپرسد. دقیقترین حالت، و وابسته به اینکه آن سرویس همیشه در دسترس باشد. باید از قبل تصمیم بگیرید اگر پاسخی نیامد چه میشود: سفارش رد شود، یا با آخرین مانده شناختهشده ثبت شود و علامت بخورد؟ حالت دوم عملیتر است.
همگامسازی دورهای. مانده هر چند دقیقه یا چند ساعت بهروز میشود. مقاومتر و ناهمگامتر. برای مشتریانی که سقفشان با حجم سفارش روزانه فاصله زیادی دارد کافی است؛ برای مشتریای که همیشه نزدیک سقف کار میکند، خطا میسازد.
فایل واسط. برای نرمافزارهای مالی قدیمی که API ندارند. کار میکند، ولی تأخیرش زیاد است و باید بپذیرید که مدیریت اعتبارتان تقریبی خواهد بود.
پیش از شروع پروژه، نام و نسخه نرمافزار مالیتان را مشخص کنید و بپرسید کدام الگو ممکن است. برآوردهایی که در پروژههای B2B از دست میروند، بیشتر از هر جای دیگری از همینجا میآیند. الگوهای یکپارچهسازی این بخش را بازتر توضیح میدهد.
چرخه سفارش تا وصول
نگاهکردن به این چرخه بهعنوان یک کل، چیزی را نشان میدهد که نگاه به سفارش تنها پنهان میکند.
سفارش ثبت میشود. اعتبار سنجیده و قفل میشود. سفارش تأیید میشود. کالا از انبار خارج میشود. فاکتور صادر و صورتحساب الکترونیکی ثبت میشود. مهلت تسویه شروع میشود. پرداخت میرسد. مانده آزاد میشود.
هر یک از این حلقهها میتواند نشتی داشته باشد و شایعترینشان دو مورد است: کالایی که از انبار خارج شده و فاکتور نشده، و پرداختی که رسیده و به مانده مشتری اعمال نشده. مورد دوم اثر مستقیم روی فروش دارد، چون مشتریای که پول داده و اعتبارش آزاد نشده، نمیتواند سفارش بعدی را ثبت کند و شما فروش را از دست دادهاید بدون اینکه بفهمید.
صورتحساب الکترونیکی
الزامات سامانه مؤدیان بخشی از همین چرخه است و موکولکردنش به بعد، فرایندی میسازد که باید بازش کنید. اگر فاکتور در نرمافزار مالی صادر میشود، معمولاً ثبت صورتحساب هم از همانجا انجام میشود و سامانه فروش فقط باید شماره و وضعیت را نگه دارد. اگر قرار است سامانه فروش خودش صادر کند، این یک بخش مستقل از پروژه است با برآورد جدا.
هر دو مسیر قابل قبول است؛ چیزی که قابل قبول نیست تصمیمنگرفتن است. تصویری از این تلفیق را در ساهوما میبینید که تمرکزش روی قواعد مالیاتی است.
چیزی که باید در پرتال مشتری دیده شود
مشتریای که مانده حساب و سقفش را میبیند، برای دانستنش تماس نمیگیرد، و مهمتر: قبل از رسیدن به سقف تسویه میکند.
حداقلی که ارزش دارد نمایش داده شود: اعتبار در دسترس، فهرست فاکتورهای تسویهنشده با تاریخ سررسید، و وضعیت سفارشهای در انتظار تأیید مالی.
آن قلم آخر ساده است و بیشتر از انتظار اثر دارد. مشتریای که نمیداند سفارشش در انتظار تأیید است، فکر میکند سامانه کار نکرده و سفارش را تلفنی تکرار میکند.
پیش از پیادهسازی
پاسخ این پنج سؤال را مکتوب کنید: سقف اعتبار هر کلاس مشتری چقدر و چه کسی تغییرش میدهد؛ سفارش عبورکرده از سقف چه سرنوشتی دارد و تأییدش با کیست؛ در حالت انتظار تأیید کالا رزرو میشود یا نه؛ مانده از کدام سامانه و با چه تأخیری میآید؛ و اگر آن سامانه در دسترس نبود، سفارش رد میشود یا مشروط ثبت میشود.
پنج جواب کوتاه که اگر نباشند، در ماه سوم پروژه پنج جلسه میشوند.