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