مرجع دقیق فیلدهای عملیات مالی
تمام فیلدهای ثبت سریع، خرید، هزینه، دریافت، سند، فاکتور، درخواست پرداخت و خزانه
مرجع فیلدبه‌فیلد ثبت عملیات مالی آناما؛ مقدار، اعتبارسنجی و اثر هر انتخاب
این مرجع از قرارداد واقعی backend/apps/erp/operation_catalog.py در نسخه مبنای راهنما تهیه شده است. نام فیلدهایی که داخل پرانتز آمده‌اند کلید داده‌اند؛ کاربر در پنل برچسب فارسی آن‌ها را می‌بیند. نام دقیق، اجباری‌بودن و نمایش شرطی ممکن است با انتخاب عملیات عوض شود. هرگز از مخفی‌بودن فیلد نتیجه نگیرید که مقدار قبلی آن بی‌اثر است؛ پیش از تأیید خلاصه داده‌ها را بخوانید.
تنظیمات مشترک در فرم‌های مالی
| فیلد | معنی | کنترل پیشنهادی | اگر نادرست باشد |
|---|---|---|---|
شخصیت حسابداری (legal_entity) | مالک حقوقی/حسابداری عملیات | شخصیت فعلی و حساب‌ها متعلق به یک مجموعه باشند | مغایرت شخص/حساب یا خطای اعتبارسنجی |
تاریخ (date) | تاریخ اقتصادی عملیات | با سند و دوره مالی تطبیق دهید | ثبت در ماه اشتباه |
دوره (period) | محدوده گزارش و قفل ثبت | بازبودن دوره را بررسی کنید | سند قابل ثبت قطعی نیست |
شرح (description) | دلیل و زمینه رویداد | نام کالا/خدمت، طرف، شماره مدرک | رسیدگی دشوار |
مبلغ (amount) | مقدار پول در واحد مورد انتظار فرم | واحد پول، صفرهای اضافی و اعشار را کنترل کنید | خطای ده‌برابری ریال/تومان |
طرف‌حساب (party) | شخصی که بدهی/طلب یا پرداخت به او منتسب است | برای نسیه و پرداخت شخصی ضروری در معنای تجاری | گزارش اشخاص ناقص |
حساب بانک (bank_account) | حساب بانکی خود کسب‌وکار | شخصیت، ارز، فعال‌بودن و سرفصل وجه نقد | مانده بانک اشتباه یا رد اعتبارسنجی |
حساب صندوق (cash_account) | سرفصل وجه نقد/تنخواه | آن را با حساب بانک یا واسط اشتباه نگیرید | برداشت صندوق به نام بانک ثبت می‌شود |
«هزینه یا خرید مصرفی روزانه» (daily-expense)
description شرح مخارج، amount مبلغ مثبت، category دسته اولیه، expense_account سرفصل اختصاصی اختیاری و payment_source تعیین‌کننده حساب مقابل است. دسته‌های فعلی لوازم و ملزومات، حمل‌ونقل، پذیرایی، قبوض و خدمات و سایر هستند. وجود دسته به‌تنهایی تضمین نمی‌کند در دفترکل سرفصل جدا ایجاد شود؛ انتخاب سرفصل تخصصی یا نگاشت پروفایل را کنترل کنید.
در روش bank باید حساب بانکی مرتبط انتخاب شود. در cash، سرفصل معتبر صندوق/تنخواه لازم است. روش personal یعنی شخصی با پول خودش خرج شرکت را داده و بانک شرکت هنوز کم نشده؛ روش unpaid بدهی پرداخت‌نشده می‌سازد و due_on سررسید آن است. فیلد party در این دو روش اهمیت اصلی دارد؛ ممکن است در حالت نقدی معمولی نمایش داده نشود. خرج با پول شخصی، «برداشت مالک» نیست.
«ثبت خرید ساده» (quick-purchase)
فیلد purpose دو مقدار دارد: expense برای مصرف کسب‌وکار و asset برای تجهیزات و دارایی. وقتی expense انتخاب است، category و expense_account ممکن است نمایش داده شوند. در asset، asset_category اهمیت پیدا می‌کند. فرم فعلی برای خرید انباری طراحی نشده؛ وجود مبلغ یا نام کالا باعث ورود موجودی نمی‌شود. payment_source و فیلدهای شرطی بانک/صندوق/شخص/سررسید همان منطق بالا را دارند. پیش از تغییر نوع خرید، فیلدهای پنهان‌شده قبلی را در تأیید نهایی بررسی کنید. برای ثبت شناسنامه تجهیزات به دارایی ثابت مراجعه کنید.
«ثبت دریافت وجه» (incoming-receipt)
party پرداخت‌کننده، amount مبلغ مثبت، method روش دریافت (بانکی، نقدی، کارت/حساب واسط)، bank_account حساب مقصد در روش بانکی و receipt_reference شماره پیگیری است. این عملیات دریافت گزارش‌شده را ثبت می‌کند؛ به‌تنهایی تضمین‌کننده وصول قطعی نزد بانک یا تخصیص به یک فاکتور نیست. اگر روش بانکی انتخاب شد، حساب مقصد را با رسید واقعی تطبیق دهید. شماره پیگیری را با مرجع صورتحساب یکی کنید تا یک وجه دوبار ثبت نشود.
«صدور فاکتور دستی» (manual-invoice)
در سربرگ: شخصیت، تاریخ، مشتری (party)، تاریخ سررسید (due_date) و شرح. در هر قلم: نام کالا یا خدمت آزاد (description)، واحد (unit) اختیاری، مقدار (quantity)، قیمت واحد (unit_price)، تخفیف (discount_amount) و مالیات (tax_amount) اختیاری. مبلغ کل باید از اقلام و قواعد محاسبه حاصل شود. فاکتور دستی، موجودی انبار را جابه‌جا نمی‌کند. اگر کالا فیزیکی فروخته‌اید، مسیر انبار و تحویل مستقل باید مدیریت شود؛ درج «۸۰۰ کیلو» در متن فاکتور، خروج ۸۰۰ کیلو نیست.
«صورتحساب هزینه تأمین‌کننده» (supplier-expense-invoice)
شخصیت، تاریخ، تأمین‌کننده (party)، سررسید (due_date)، expense_account و شرح سربرگ دارد. قلم هزینه دارای شرح، واحد اختیاری، مقدار، مبلغ واحد و تخفیف اختیاری است. این مسیر برای صورتحساب هزینه بدون ورود انبار معرفی شده و در توضیح قرارداد، تفکیک مالیات نیز ندارد. اگر خرید کالا یا اعتبار مالیاتی تفصیلی دارید، به‌جای تحمیل آن بر این فرم، جریان تخصصی را بررسی کنید.
«تنظیم سند حسابداری» (journal-entry)
legal_entity، date، period، description و حداقل دو قلم می‌خواهد. در هر قلم، account سرفصل، party اختیاری، debit یا credit مبلغ و description شرح سطر است. پیش از ثبت قطعی هم جمع و هم ماهیت حساب‌ها را کنترل کنید. این فرم به‌تنهایی کالا به انبار نمی‌برد، پول در بانک جابه‌جا نمی‌کند و فاکتور تجاری صادر نمی‌کند.
خزانه: «درخواست پرداخت آینده» (payment-request)
شخصیت، party ذی‌نفع، مبلغ، تاریخ پرداخت (due_on)، علت (purpose)، بانک مبدأ (source_account)، فاکتور پرداختنی اختیاری (invoice)، حساب بدهکار برای پرداخت بدون فاکتور (settlement_account) و شبای ذی‌نفع (beneficiary_iban) دارد. انتخاب فاکتور برای جلوگیری از هزینه‌کرد دوباره مهم است. درخواست، پرداخت اجراشده یا تأیید بانک نیست؛ وضعیت را جدا کنترل کنید.
خزانه: «انتقال بین حساب‌های شرکت» (internal-bank-transfer)
شخصیت، تاریخ، مبلغ مثبت، بانک مبدأ و مقصد دارد. مبدأ و مقصد نباید یک حساب باشند و باید در همان شخصیت معتبر قرار گیرند. انتقال موفق معمولاً نقد را بین دو حساب جابه‌جا می‌کند؛ درآمد و هزینه جدید فقط به‌علت انتقال ایجاد نمی‌شود. کارمزد واقعی بانک، رویداد جداگانه است.
سرمایه مالک (owner-capital) و برداشت (owner-withdrawal)
هر دو شخصیت، تاریخ، شرح اختیاری، مبلغ مثبت، بانک و سرفصل حقوق مالکانه (equity_account) دارند؛ party مالک یا شریک مرتبط اختیاری است. آورده، درآمد فروش نیست و برداشت شخصی، هزینه عملیاتی نیست. حساب برداشت/جاری مالک بهتر است از حساب سرمایه اولیه جدا باشد تا تحلیل سرمایه و گردش اشخاص مخدوش نشود.
کنترل نهایی قبل از ذخیره
رویداد را به زبان ساده برای خودتان بنویسید: «چه کسی، چه چیز، چه تاریخ، چه مبلغ، از کدام حساب، بابت کدام سند؟» اگر یکی از این پاسخ‌ها با فرم مطابقت ندارد، هنوز ثبت نکنید. پس از ذخیره شماره و وضعیت رکورد را نگه دارید؛ ذخیره با ثبت قطعی برابر نیست. برای اثر بدهکار/بستانکار از چرخه سند کمک بگیرید.
«تعریف سریع شخص» (quick-party) و «هزینه کسب‌وکار» (business-expense)
در تعریف سریع شخص، display_name نام واقعی و قابل جست‌وجو، kind نوع حقیقی (person) یا مجموعه (organization) و mobile شماره تماس اختیاری است. این عملیات، تأیید رسمی تأمین‌کننده یا تغییر مانده دفترکل نیست؛ فقط یک رکورد پایه برای اتصال عملیات بعدی می‌سازد. قبل از ثبت، شخص را جست‌وجو کنید تا برای یک فرد چند حساب جداگانه نسازید.
در business-expense، علاوه بر شخصیت، تاریخ، دوره و شرح، party دریافت‌کننده، amount مبلغ، expense_account سرفصل هزینه، payment_status وضعیت پرداخت (paid یا unpaid) و counterpart_account حساب وجه پرداختی یا بدهی را تعیین می‌کنند. این فرم نسبت به هزینه روزانه اطلاعات دفترکلی بیشتری می‌خواهد. اگر مبلغ واقعاً پرداخت شده، حساب مقابل باید با منبع وجه هماهنگ باشد؛ اگر نسیه است، آن را از بانک کم نکنید. سند این عملیات برای بررسی ذخیره می‌شود و تا ثبت قطعی اثر دفتری ندارد.
قاعده طلایی در تغییر گزینه‌های شرطی
در فرم‌های دارای visible_when، مثلاً وقتی روش پرداخت از bank به unpaid تغییر می‌کند، حساب بانکی قبلی دیگر نباید به‌عنوان منبع پرداخت در درخواست مؤثر بماند. لایه فرم از توابع اعتبارسنجی و نرمال‌سازی وضعیت استفاده می‌کند، اما در هر نسخه باید خلاصه نهایی را کنترل کرد. اگر خطای «ترکیب روش پرداخت و حساب بانکی نامعتبر» رخ داد، انتخاب قبلی و فیلدهای مخفی را بررسی کنید؛ اطلاعات حسابداری را برای دورزدن اعتبارسنجی جعل نکنید.