Seyyed_arc/docs/INVOICE_ACCOUNTING_REVIEW.md

بررسی ثبت‌های حسابداری فاکتورها

خلاصه بررسی

این گزارش نتیجه بررسی کامل سیستم ایجاد فاکتورها و ثبت‌های حسابداری مرتبط است. بررسی شامل موارد زیر می‌شود:

• انواع فاکتورها (فروش، خرید، برگشت از فروش، برگشت از خرید، مصرف مستقیم، ضایعات، تولید)
• ثبت مالیات و تخفیف
• ثبت تراکنش‌های پرداخت (بانک، صندوق، تنخواه، چک، شخص)
• تعادل حسابداری اسناد

---

1. بررسی انواع فاکتورها

1.1 فاکتور فروش (INVOICE_SALES)

ثبت‌های حسابداری:

Dr. حساب شخص (10401) - مبلغ کل با مالیات
Cr. حساب درآمد (50001) - مبلغ ناخالص (قبل از تخفیف)
Dr. حساب تخفیفات فروش (50003) - مبلغ تخفیف
Cr. حساب مالیات خروجی (20101) - مبلغ مالیات

بررسی:

• ✅ ثبت‌های حسابداری صحیح است
• ✅ شخص به مبلغ کل با مالیات بدهکار می‌شود
• ✅ درآمد به مبلغ ناخالص (قبل از تخفیف) بستانکار می‌شود
• ✅ تخفیف به صورت جداگانه ثبت می‌شود (بدهکار)
• ✅ مالیات به صورت جداگانه ثبت می‌شود (بستانکار)

تعادل:

• بدهکار: شخص (total_with_tax) + تخفیف
• بستانکار: درآمد (gross) + مالیات
• net = gross - discount
• total_with_tax = net + tax
• ✅ تعادل برقرار است: (gross - discount + tax) = total_with_tax

فروش اقساطی:

• ✅ اگر طرح اقساط وجود داشته باشد، سود اقساط به دریافتنی اضافه می‌شود
• ✅ سود تحقق‌نیافته در حساب جداگانه ثبت می‌شود

پورسانت فروشنده:

• ✅ اگر فروشنده مشخص باشد، هزینه پورسانت ثبت می‌شود
• ✅ حساب پورسانت بدهکار و حساب پرداختنی فروشنده بستانکار می‌شود

---

1.2 برگشت از فروش (INVOICE_SALES_RETURN)

ثبت‌های حسابداری:

Cr. حساب شخص (10401) - مبلغ کل با مالیات
Dr. حساب برگشت از فروش (50002) - مبلغ ناخالص
Cr. حساب تخفیفات فروش (50003) - مبلغ تخفیف (برگشت)
Dr. حساب مالیات خروجی (20101) - مبلغ مالیات (تعدیل)

بررسی:

• ✅ ثبت‌های حسابداری صحیح است
• ✅ شخص به مبلغ کل با مالیات بستانکار می‌شود (کاهش دریافتنی)
• ✅ برگشت از فروش به مبلغ ناخالص بدهکار می‌شود
• ✅ تخفیف برگشت می‌شود (بستانکار)
• ✅ مالیات تعدیل می‌شود (بدهکار)

تعادل:

• بدهکار: برگشت از فروش (gross) + مالیات
• بستانکار: شخص (total_with_tax) + تخفیف
• ✅ تعادل برقرار است

پورسانت فروشنده:

• ✅ پورسانت فروشنده تعدیل می‌شود (معکوس)

---

1.3 فاکتور خرید (INVOICE_PURCHASE)

ثبت‌های حسابداری:

Dr. حساب GRNI (30101) - مبلغ ناخالص (قبل از تخفیف)
Cr. حساب تخفیفات خرید (40003) - مبلغ تخفیف
Dr. حساب مالیات ورودی (10104) - مبلغ مالیات
Cr. حساب شخص (20201) - مبلغ کل با مالیات

بررسی:

• ✅ ثبت‌های حسابداری صحیح است
• ✅ GRNI به مبلغ ناخالص بدهکار می‌شود
• ✅ تخفیف خرید به صورت جداگانه ثبت می‌شود (بستانکار)
• ✅ مالیات ورودی بدهکار می‌شود
• ✅ شخص به مبلغ کل با مالیات بستانکار می‌شود (افزایش پرداختنی)

تعادل:

• بدهکار: GRNI (gross) + مالیات
• بستانکار: تخفیف + شخص (total_with_tax)
• ✅ تعادل برقرار است

نکته مهم:

• COGS و موجودی در پست حواله انبار ثبت می‌شود (نه در فاکتور)
• این رویکرد صحیح است و از جداسازی نگرانی‌ها (separation of concerns) پیروی می‌کند

---

1.4 برگشت از خرید (INVOICE_PURCHASE_RETURN)

ثبت‌های حسابداری:

Cr. حساب GRNI (30101) - مبلغ ناخالص (برگشت)
Dr. حساب تخفیفات خرید (40003) - مبلغ تخفیف (برگشت)
Cr. حساب مالیات ورودی (10104) - مبلغ مالیات (تعدیل)
Dr. حساب شخص (20201) - مبلغ کل با مالیات

بررسی:

• ✅ ثبت‌های حسابداری صحیح است
• ✅ GRNI به مبلغ ناخالص بستانکار می‌شود (کاهش GRNI)
• ✅ تخفیف برگشت می‌شود (بدهکار)
• ✅ مالیات ورودی تعدیل می‌شود (بستانکار)
• ✅ شخص به مبلغ کل با مالیات بدهکار می‌شود (کاهش پرداختنی)

تعادل:

• بدهکار: تخفیف + شخص (total_with_tax)
• بستانکار: GRNI (gross) + مالیات
• ✅ تعادل برقرار است

---

1.5 مصرف مستقیم (INVOICE_DIRECT_CONSUMPTION)

ثبت‌های حسابداری:

• ❌ هیچ ثبت حسابداری در فاکتور ایجاد نمی‌شود
• ثبت‌های موجودی و COGS فقط در پست حواله انبار انجام می‌شود

بررسی:

• ⚠️ مشکل احتمالی: اگر حواله انبار پست نشود، هیچ ثبت حسابداری ایجاد نمی‌شود
• این می‌تواند منجر به عدم ثبت هزینه مصرف مستقیم شود

پیشنهاد:

• بررسی شود که آیا باید ثبت حسابداری هزینه مصرف مستقیم در فاکتور ایجاد شود یا خیر

---

1.6 ضایعات (INVOICE_WASTE)

ثبت‌های حسابداری:

• ❌ هیچ ثبت حسابداری در فاکتور ایجاد نمی‌شود
• ثبت‌های موجودی و هزینه ضایعات فقط در پست حواله انبار انجام می‌شود

بررسی:

• ⚠️ مشکل احتمالی: مشابه مصرف مستقیم

---

1.7 تولید (INVOICE_PRODUCTION)

ثبت‌های حسابداری:

• ❌ هیچ ثبت حسابداری در فاکتور ایجاد نمی‌شود
• ثبت‌های موجودی و WIP فقط در پست حواله انبار انجام می‌شود

بررسی:

• ⚠️ مشکل احتمالی: مشابه مصرف مستقیم و ضایعات

---

2. بررسی ثبت تراکنش‌های پرداخت

2.1 منطق ایجاد سند دریافت/پرداخت

تعیین نوع سند:

is_receipt = invoice_type in {INVOICE_SALES, INVOICE_PURCHASE_RETURN}

بررسی:

• ✅ فاکتور فروش → سند دریافت (دریافت وجه از مشتری)
• ✅ برگشت از خرید → سند دریافت (دریافت وجه از تامین‌کننده)
• ✅ فاکتور خرید → سند پرداخت (پرداخت وجه به تامین‌کننده)
• ✅ برگشت از فروش → سند پرداخت (پرداخت وجه به مشتری)

نوع حساب شخص:

person_is_receivable = invoice_type in {INVOICE_SALES, INVOICE_SALES_RETURN}

بررسی:

• ✅ فاکتور فروش → حساب دریافتنی (10401)
• ✅ برگشت از فروش → حساب دریافتنی (10401)
• ✅ فاکتور خرید → حساب پرداختنی (20201)
• ✅ برگشت از خرید → حساب پرداختنی (20201)

---

2.2 ثبت تراکنش بانک

در سند دریافت:

Dr. حساب بانک (10203)
Cr. حساب شخص (10401 یا 20201)

در سند پرداخت:

Dr. حساب شخص (10401 یا 20201)
Cr. حساب بانک (10203)

بررسی:

• ✅ منطق صحیح است
• ✅ در دریافت: بانک بدهکار می‌شود (افزایش دارایی)
• ✅ در پرداخت: بانک بستانکار می‌شود (کاهش دارایی)

---

2.3 ثبت تراکنش صندوق

در سند دریافت:

Dr. حساب صندوق (10202)
Cr. حساب شخص (10401 یا 20201)

در سند پرداخت:

Dr. حساب شخص (10401 یا 20201)
Cr. حساب صندوق (10202)

بررسی:

• ✅ منطق صحیح است

---

2.4 ثبت تراکنش تنخواه

در سند دریافت:

Dr. حساب تنخواه (10201)
Cr. حساب شخص (10401 یا 20201)

در سند پرداخت:

Dr. حساب شخص (10401 یا 20201)
Cr. حساب تنخواه (10201)

بررسی:

• ✅ منطق صحیح است

---

2.5 ثبت تراکنش چک

چک دریافتی در سند دریافت:

Cr. حساب اسناد دریافتنی (10403) - چک خارج شد
Cr. حساب شخص (10401) - تسویه بدهی
Dr. حساب بانک/صندوق (10203/10202) - اگر چک به بانک/صندوق سپرده شود

چک پرداختی در سند پرداخت:

Dr. حساب اسناد پرداختنی (20202) - چک پرداخت شد
Dr. حساب شخص (20201) - تسویه بدهی
Cr. حساب بانک/صندوق (10203/10202) - اگر چک از بانک/صندوق پرداخت شود

بررسی:

• ✅ منطق صحیح است
• ✅ نوع چک بررسی می‌شود (خط 1372-1386)
• ✅ چک دریافتی فقط در فاکتور فروش/برگشت از خرید استفاده می‌شود
• ✅ چک پرداختی فقط در فاکتور خرید/برگشت از فروش استفاده می‌شود

نکته:

• اگر چک به بانک/صندوق سپرده شود، یک خط اضافی برای بانک/صندوق ایجاد می‌شود (خط 800-851)
• این منطق صحیح است

---

2.6 کارمزد تراکنش‌ها

در سند دریافت:

Dr. حساب کارمزد خدمات بانکی (70902)
Cr. حساب بانک/صندوق/تنخواه (10203/10202/10201)

در سند پرداخت:

Dr. حساب بانک/صندوق/تنخواه (10203/10202/10201)
Cr. حساب کارمزد خدمات بانکی (70902)

بررسی:

• ✅ منطق صحیح است
• ✅ کارمزد به صورت جداگانه ثبت می‌شود

---

3. بررسی محاسبه مالیات و تخفیف

3.1 محاسبه در فرانت‌اند

فرمول محاسبه:

subtotal = quantity * unitPrice
discountAmount = (discountType == 'percent') ? subtotal * (discountValue / 100) : discountValue
taxableAmount = subtotal - discountAmount
taxAmount = taxableAmount * (taxRate / 100)
total = taxableAmount + taxAmount

بررسی:

• ✅ فرمول صحیح است
• ✅ تخفیف از مبلغ ناخالص کم می‌شود
• ✅ مالیات روی مبلغ خالص (بعد از تخفیف) محاسبه می‌شود

---

3.2 محاسبه در بکند

تابع _extract_totals_from_lines:

gross += (qty * unit_price)
discount += line_discount
tax += tax_amount
net += line_total

بررسی:

• ✅ محاسبه صحیح است
• ✅ اگر line_total موجود باشد، از آن استفاده می‌شود
• ✅ در غیر این صورت: line_total = (qty * unit_price) - line_discount + tax_amount

---

4. مشکلات شناسایی شده

4.1 مشکل 1: عدم ثبت حسابداری برای مصرف مستقیم، ضایعات و تولید

موقعیت:

• فاکتورهای مصرف مستقیم، ضایعات و تولید هیچ ثبت حسابداری در فاکتور ایجاد نمی‌کنند
• ثبت‌های حسابداری فقط در پست حواله انبار انجام می‌شود

ریسک:

• اگر حواله انبار پست نشود، هیچ ثبت حسابداری ایجاد نمی‌شود
• این می‌تواند منجر به عدم ثبت هزینه/درآمد شود

پیشنهاد:

• بررسی شود که آیا باید ثبت حسابداری در فاکتور ایجاد شود یا خیر
• اگر باید ایجاد شود، باید منطق اضافه شود

---

4.2 مشکل 2: عدم بررسی تعادل در فاکتور

موقعیت:

• در تابع create_invoice، تعادل ثبت‌های حسابداری بررسی نمی‌شود
• اگر خطایی در محاسبه وجود داشته باشد، ممکن است سند نامتعادل ایجاد شود

ریسک:

• سند نامتعادل می‌تواند منجر به عدم تطابق در گزارش‌های مالی شود

پیشنهاد:

• اضافه کردن بررسی تعادل قبل از commit
• اگر تعادل برقرار نباشد، خطا برگردانده شود

---

4.3 مشکل 3: عدم بررسی تطابق مبلغ پرداخت با مبلغ فاکتور

موقعیت:

• در تابع create_invoice، مبلغ کل پرداخت‌ها با مبلغ فاکتور مقایسه نمی‌شود
• می‌توان مبلغی بیشتر یا کمتر از مبلغ فاکتور پرداخت کرد

ریسک:

• پرداخت بیشتر از مبلغ فاکتور می‌تواند منجر به پیش‌پرداخت شود
• پرداخت کمتر از مبلغ فاکتور می‌تواند منجر به بدهی باقی‌مانده شود

بررسی:

• این ممکن است یک ویژگی باشد (پیش‌پرداخت یا پرداخت جزئی)
• اما باید بررسی شود که آیا این رفتار مورد نظر است یا خیر

---

5. موارد صحیح

5.1 ثبت‌های حسابداری انواع فاکتور

• ✅ فاکتور فروش: ثبت‌های صحیح
• ✅ برگشت از فروش: ثبت‌های صحیح
• ✅ فاکتور خرید: ثبت‌های صحیح
• ✅ برگشت از خرید: ثبت‌های صحیح

5.2 ثبت تراکنش‌های پرداخت

• ✅ بانک: منطق صحیح
• ✅ صندوق: منطق صحیح
• ✅ تنخواه: منطق صحیح
• ✅ چک: منطق صحیح و بررسی نوع چک انجام می‌شود
• ✅ کارمزد: منطق صحیح

5.3 محاسبه مالیات و تخفیف

• ✅ محاسبه در فرانت‌اند صحیح است
• ✅ محاسبه در بکند صحیح است
• ✅ مالیات روی مبلغ خالص (بعد از تخفیف) محاسبه می‌شود

5.4 فروش اقساطی

• ✅ سود اقساط به دریافتنی اضافه می‌شود
• ✅ سود تحقق‌نیافته در حساب جداگانه ثبت می‌شود

5.5 پورسانت فروشنده

• ✅ هزینه پورسانت ثبت می‌شود
• ✅ حساب پورسانت و حساب پرداختنی فروشنده به درستی ثبت می‌شوند

---

6. نتیجه‌گیری

وضعیت کلی: ✅ خوب

اکثر بخش‌های سیستم به درستی پیاده‌سازی شده‌اند:

1. ✅ ثبت‌های حسابداری انواع فاکتور صحیح است
2. ✅ ثبت تراکنش‌های پرداخت صحیح است
3. ✅ محاسبه مالیات و تخفیف صحیح است
4. ✅ بررسی نوع چک انجام می‌شود
5. ✅ فروش اقساطی و پورسانت فروشنده به درستی پیاده‌سازی شده‌اند

مشکلات شناسایی شده:

1. ⚠️ عدم ثبت حسابداری برای مصرف مستقیم، ضایعات و تولید (نیاز به بررسی)
2. ⚠️ عدم بررسی تعادل در فاکتور (پیشنهاد بهبود)
3. ⚠️ عدم بررسی تطابق مبلغ پرداخت با مبلغ فاکتور (نیاز به بررسی - ممکن است یک ویژگی باشد)

پیشنهادات:

1. بررسی شود که آیا باید ثبت حسابداری برای مصرف مستقیم، ضایعات و تولید در فاکتور ایجاد شود
2. اضافه کردن بررسی تعادل قبل از commit
3. بررسی شود که آیا باید محدودیتی برای مبلغ پرداخت نسبت به مبلغ فاکتور وجود داشته باشد

---

تاریخ بررسی: 2025-01-XX بررسی کننده: AI Assistant