پاسخ کوتاه
برای اتصال فروشگاه به حسابداری، ابتدا مرجع قیمت، موجودی، سفارش و شناسه کالا را تعیین کنید. سپس API و مجوز نسخه نرم‌افزار، رفتار قطعی، کنترل ثبت تکراری و قواعد لغو بررسی می‌شوند. قیمت اتصال پس از بررسی فنی برآورد می‌شود و نباید آن را داخل قیمت پایه ساخت سایت فرض کرد.
- نام و نسخه حسابداری و امکانات API قبل از سفارش بررسی شود.
- جهت انتقال هر داده مستقل مشخص شود؛ همه فیلدها نیازمند انتقال دوطرفه نیستند.
- قطعی، تکرار درخواست و مرجوعی باید در آزمون تحویل دیده شوند.
اتصال سایت فروشگاهی به نرم‌افزار حسابداری و انبار یعنی مشخص شود اطلاعات کالا، قیمت، موجودی، مشتری و سفارش چگونه میان دو سامانه جابه‌جا می‌شوند. هدف فقط حذف تایپ دستی نیست؛ باید بتوان هر سفارش را پیگیری کرد، خطا را دید و از ثبت دوباره فاکتور یا فروش ظرفیت ناموجود جلوگیری کرد.
اگر فروش حضوری و اینترنتی دارید، قبل از سفارش افزونه یا توسعه اختصاصی، مرجع هر داده و رفتار سیستم هنگام قطعی را روشن کنید. در این مقاله، مسیر تصمیم‌گیری، محدوده اجرا و چک‌لیست تحویل را با مثال توضیح می‌دهیم.
چه زمانی اتصال سایت به حسابداری ارزش بررسی دارد؟
وقتی قیمت و موجودی در چند محل تغییر می‌کند یا کارکنان هر سفارش را دوباره وارد نرم‌افزار می‌کنند، احتمال مغایرت بیشتر می‌شود. اما اگر هنوز کد کالا، تنوع محصول و روش ثبت فروش حضوری منظم نیست، اتصال خودکار به‌تنهایی آن بی‌نظمی را حل نمی‌کند.
- فروشگاه حضوری و سایت از یک انبار مشترک استفاده می‌کنند.
- تغییر قیمت کالاها زیاد است و به‌روزرسانی دستی دشوار شده است.
- ثبت مشتری، سفارش یا فاکتور دوباره‌کاری قابل توجه ایجاد می‌کند.
- مرجوعی و لغو سفارش در سایت و حسابداری وضعیت متفاوت دارند.
- واحد مالی نمی‌تواند شماره سفارش سایت را به سند مرتبط وصل کند.
برای شروع، چند سفارش واقعی را از خرید تا ارسال و مرجوعی دنبال کنید و محل تکرار کار را یادداشت کنید. این بررسی مشخص می‌کند کدام اتصال ضروری است و کدام قابلیت می‌تواند به مرحله بعد منتقل شود.
پیش از اجرا، مرجع هر اطلاعات را تعیین کنید
عبارت «همگام‌سازی دوطرفه همه‌چیز» مبهم است. ممکن است حسابداری مرجع قیمت و موجودی باشد، سایت مرجع توضیحات بازاریابی و عکس، و سفارش از سایت به حسابداری منتقل شود. برای هر فیلد، مسئول تغییر را جدا تعیین کنید.
| داده | مرجع پیشنهادی نمونه | قاعده‌ای که باید توافق شود |
|---|---|---|
| کد و تنوع کالا | فهرست استاندارد کالا | یک شناسه پایدار برای هر تنوع |
| قیمت پایه | حسابداری یا سامانه قیمت | واحد پول، مالیات و تخفیف |
| موجودی قابل فروش | سامانه انبار | انبارهای مجاز و کالای رزروشده |
| تصویر و توضیح محصول | پنل محتوای سایت | حفظ محتوا هنگام دریافت اطلاعات |
| سفارش اینترنتی | سایت | وضعیت مجاز برای انتقال |
این جدول یک الگوی طراحی است، نه قانون ثابت همه کسب‌وکارها. مثلاً قیمت مشتری عمده ممکن است از قرارداد او خوانده شود. مهم این است که دو سامانه هم‌زمان بر سر یک فیلد تصمیم متفاوت نگیرند.
برای هر نوع داده، مرجع و جهت انتقال را مستقل مشخص کنید.
شناسه کالا و تنوع؛ مهم‌ترین قدم قبل از همگام‌سازی
نام کالا برای اتصال قابل اتکا نیست؛ ممکن است دو محصول نام مشابه داشته باشند یا نام یک محصول تغییر کند. هر محصول و هر ترکیب قابل فروش، مانند رنگ و اندازه، باید شناسه مشخص داشته باشد. نگاشت یا Mapping، رابطه شناسه سایت و حسابداری را نگه می‌دارد.
فرض کنید یک میز در سه رنگ عرضه می‌شود. اگر حسابداری برای هر رنگ کد جدا دارد، سایت هم باید موجودی هر رنگ را جدا دریافت کند. اتصال موجودی کل میز به همه رنگ‌ها می‌تواند باعث پذیرش سفارش رنگ ناموجود شود.
پیش از انتقال اولیه، واحد شمارش، کالای غیرفعال، بسته چندتایی، محصول ترکیبی و اقلام بدون کد را بررسی کنید. رکورد مبهم را وارد صف بررسی کنید؛ حدس‌زدن تطبیق فقط از روی نام می‌تواند مغایرت ایجاد کند.
API، وب‌هوک یا فایل؛ کدام روش مناسب است؟
API یا رابط برنامه‌نویسی مسیر ساختاریافته خواندن و نوشتن داده است. وجود API به معنی پشتیبانی از تمام عملیات نیست؛ ممکن است خواندن کالا مجاز باشد ولی ثبت فاکتور، لغو یا چندانبار به مجوز و نسخه دیگری نیاز داشته باشد.
Webhook یا اعلان رویداد به سامانه دیگر خبر می‌دهد تغییری رخ داده است. ووکامرس امکان تعریف وب‌هوک برای رویدادهای مرتبط را دارد و برای آن تنظیمات امنیتی و گزارش تحویل فراهم می‌کند. دریافت اعلان را باید با بررسی اعتبار پیام و پردازش قابل پیگیری همراه کرد؛ تحویل ناموفق نباید بی‌خبر باقی بماند.
در روش زمان‌بندی‌شده، تغییرات در فاصله‌های معین خوانده می‌شوند. خروجی فایل هم برای مهاجرت اولیه یا تبادل دوره‌ای کاربرد دارد، اما نباید آن را «همگام‌سازی لحظه‌ای» معرفی کرد. روش مناسب به امکانات دو طرف، حجم کار و تأخیر قابل قبول بستگی دارد.
یک سفارش چه زمانی باید وارد حسابداری شود؟
ابتدا تعریف کنید منظور از انتقال چیست: ثبت پیش‌سفارش، پیش‌فاکتور یا فاکتور نهایی؟ سفارش پرداخت‌نشده، پرداخت موفق، بیعانه، پرداخت در محل و سفارش لغوشده رفتار مالی یکسانی ندارند.
- سایت سفارش را با شناسه پایدار ثبت می‌کند.
- پس از رسیدن به وضعیت توافق‌شده، عملیات انتقال وارد صف می‌شود.
- سیستم بررسی می‌کند همان سفارش قبلاً منتقل نشده باشد.
- اطلاعات به سرویس مقصد ارسال و نتیجه ثبت می‌شود.
- شناسه یا شماره سند مقصد کنار سفارش سایت ذخیره می‌شود.
- خطاهای قابل تکرار دوباره تلاش می‌شوند؛ موارد مبهم برای بررسی مشخص می‌مانند.
اگر پاسخ مقصد گم شد، ارسال مجدد بدون بررسی می‌تواند سند دوم بسازد. باید با شناسه یکتا یا جست‌وجوی سند قبلی، اثر تکرار کنترل شود. این اصل در طراحی اتصال به اندازه موفق‌بودن اولین درخواست اهمیت دارد.
نمونه مرتبط آونا، سیستم همگام‌سازی محک و پیام‌گستر است که انتقال مشتریان، محصولات و فاکتورها را با صف پردازش و نگاشت شناسه‌ها معرفی می‌کند. این پروژه اتصال ERP و CRM است؛ امکان اتصال نرم‌افزار فروشگاه شما باید جداگانه بررسی شود.
نمونه‌کار مرتبط با یکپارچه‌سازی داده؛ این تصویر، اتصال آماده برای هر نرم‌افزار حسابداری را نشان نمی‌دهد.
موجودی قابل فروش با موجودی فیزیکی فرق دارد
همه کالای داخل انبار الزاماً قابل فروش نیست. بخشی ممکن است برای سفارش دیگر رزرو شده، معیوب، در انبار غیرمجاز یا در انتظار بررسی مرجوعی باشد. یک الگوی ساده این است: موجودی قابل فروش برابر موجودی مجاز، منهای رزروها و ذخیره احتیاطی است؛ جزئیات را باید با واحد انبار تعیین کرد.
برای مثال فرضی، اگر از ۱۰ واحد کالا، ۳ واحد برای سفارش‌ها نگه‌داری شده و ۱ واحد ذخیره احتیاطی باشد، ظرفیت فروش ۶ واحد است. اگر نرم‌افزار انبار خودش رزرو را از عدد خروجی کسر می‌کند، اتصال نباید همان مقدار را دوباره کم کند.
در فروش هم‌زمان حضوری و اینترنتی، تأخیر انتقال را هم در نظر بگیرید. نمایش موجودی در صفحه کافی نیست؛ هنگام نهایی‌کردن سفارش باید کنترل مناسب سمت سرور انجام شود. اگر اتصال قطع است، تصمیم توقف فروش، محدودکردن تعداد یا استفاده موقت از آخرین وضعیت باید از پیش تعریف شود.
لغو، مرجوعی و تغییر قیمت را از محدوده حذف نکنید
اتصالی که فقط سفارش موفق جدید را منتقل می‌کند، بخش مهمی از کار واقعی را پوشش نمی‌دهد. درباره لغو قبل از ارسال، مرجوعی جزئی، تغییر تعداد، هزینه حمل، تخفیف و اختلاف واحد پول تصمیم بگیرید.
لغو سفارش به‌تنهایی به معنی برگشت وجه نیست. وضعیت پرداخت، سند مالی و موجودی را با قواعد مشخص تغییر دهید. همچنین در ویرایش سفارش، قیمت ثبت‌شده زمان خرید را با قیمت امروز محصول اشتباه نگیرید.
برای جلوگیری از حلقه انتقال، تغییر دریافت‌شده از یک سامانه نباید بی‌دلیل به‌عنوان تغییر تازه به همان سامانه بازگردد. ثبت منشأ تغییر و نسخه داده می‌تواند بخشی از راهکار باشد.
هزینه اتصال سایت به حسابداری چگونه تعیین می‌شود؟
برای این خدمت بدون بررسی نام و نسخه نرم‌افزار، مستندات API و محدوده عملیات نمی‌توان قیمت دقیق اعلام کرد. عوامل مهم شامل تعداد موجودیت‌ها، جهت انتقال، حجم داده، چندانبار، قواعد مالی، مهاجرت اولیه و سطح گزارش خطا هستند.
اگر هم‌زمان سایت جدید می‌سازید، قیمت پایه اعلام‌شده آونا برای فروشگاه وردپرسی از ۴۰ میلیون تومان و فروشگاه اختصاصی از ۱۸۰ میلیون تومان است. هزینه اتصال حسابداری را داخل این ارقام فرض نکنید؛ باید در برآورد پروژه صریح درج شود. جدول کامل در مقاله نرخ طراحی سایت آونا قرار دارد.
برای انتخاب روش اجرا، وردپرس یا توسعه اختصاصی را ببینید. در فرم سفارش طراحی سایت و توسعه اتصال حسابداری نام نرم‌افزار، نسخه و عملیات موردنیاز را بنویسید؛ اطلاعات محرمانه یا کلید API را در فرم عمومی ارسال نکنید.
چک‌لیست تحویل اتصال فروشگاه و حسابداری
- نمونه محصول ساده و تنوع‌دار با کد درست تطبیق داده شود.
- واحد تومان و ریال، تخفیف و مبلغ نهایی با داده نمونه کنترل شود.
- ارسال دوباره یک سفارش، سند تجاری تکراری نسازد.
- قطع ارتباط و برگشت سرویس آزمایش شود و عملیات معلق قابل بازیابی باشد.
- تغییر قیمت، فروش حضوری و کاهش موجودی به مقصد درست برسد.
- لغو و مرجوعی طبق محدوده قرارداد با سناریوی مشخص آزموده شوند.
- گزارش مغایرت و خطا در دسترس مسئول مجاز باشد.
- کلیدها در سرور نگه‌داری شوند و اطلاعات حساس در گزارش عمومی نمایش داده نشود.
یک گزارش ساده شامل تعداد عملیات موفق، معلق و نیازمند بررسی از یک چراغ سبز «اتصال برقرار است» مفیدتر است. سلامت اتصال را با نتیجه واقعی انتقال بسنجید.
پرسش‌های متداول
آیا هر نرم‌افزار حسابداری به هر سایتی وصل می‌شود؟
خیر. امکان اجرا به API، مجوز، نسخه، مستندات و عملیات مجاز بستگی دارد. قبل از سفارش باید این موارد بررسی شوند.
آیا برای ووکامرس حتماً افزونه اختصاصی لازم است؟
نه همیشه. اگر اتصال آماده معتبر نیازهای واقعی را پوشش دهد، می‌توان آن را ارزیابی کرد. قواعد ویژه یا عملیات پوشش‌داده‌نشده ممکن است توسعه جدا بخواهند.
آیا همگام‌سازی باید دوطرفه باشد؟
جهت انتقال برای هر داده جدا تعیین می‌شود. مثلاً موجودی از حسابداری به سایت و سفارش از سایت به حسابداری می‌رود؛ لازم نیست هر فیلد در هر دو طرف قابل تغییر باشد.
برای بررسی اولیه چه چیزهایی لازم است؟
نام و نسخه حسابداری، نوع سایت، تعداد تقریبی کالا و تنوع، روش ثبت فروش حضوری، فهرست عملیات و نمونه بی‌نام داده‌ها کافی است. دسترسی فنی در مرحله مناسب و از مسیر امن دریافت می‌شود.
برای ساخت یا توسعه فروشگاه، خدمات طراحی سایت آونا را بررسی کنید و درخواست بررسی اتصال فروشگاه به حسابداری را ثبت کنید.
نویسنده: کارشناس محتوای هوشمند آونا
منابع و روش بررسی
محتوا بر اساس بررسی ساختار فعلی مقالات آونا و نیازهای اجرایی پروژه نوشته شده است. قیمت‌ها، ارقام پایه اعلام‌شده آونا هستند و مبلغ نهایی به محدوده قرارداد وابسته است. کاور، تصویر مفهومی تولیدشده با هوش مصنوعی است؛ نمودارها آموزشی‌اند. رتبه و میزان فروش تضمین نمی‌شود.
