forked from hesabix/arc
449 lines
16 KiB
Markdown
Executable file
449 lines
16 KiB
Markdown
Executable file
# بررسی ثبت‌های حسابداری فاکتورها
|
|
|
|
## خلاصه بررسی
|
|
|
|
این گزارش نتیجه بررسی کامل سیستم ایجاد فاکتورها و ثبت‌های حسابداری مرتبط است. بررسی شامل موارد زیر می‌شود:
|
|
- انواع فاکتورها (فروش، خرید، برگشت از فروش، برگشت از خرید، مصرف مستقیم، ضایعات، تولید)
|
|
- ثبت مالیات و تخفیف
|
|
- ثبت تراکنش‌های پرداخت (بانک، صندوق، تنخواه، چک، شخص)
|
|
- تعادل حسابداری اسناد
|
|
|
|
---
|
|
|
|
## 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 منطق ایجاد سند دریافت/پرداخت
|
|
|
|
**تعیین نوع سند:**
|
|
```python
|
|
is_receipt = invoice_type in {INVOICE_SALES, INVOICE_PURCHASE_RETURN}
|
|
```
|
|
|
|
**بررسی:**
|
|
- ✅ فاکتور فروش → سند دریافت (دریافت وجه از مشتری)
|
|
- ✅ برگشت از خرید → سند دریافت (دریافت وجه از تامین‌کننده)
|
|
- ✅ فاکتور خرید → سند پرداخت (پرداخت وجه به تامین‌کننده)
|
|
- ✅ برگشت از فروش → سند پرداخت (پرداخت وجه به مشتری)
|
|
|
|
**نوع حساب شخص:**
|
|
```python
|
|
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 محاسبه در فرانت‌اند
|
|
|
|
**فرمول محاسبه:**
|
|
```dart
|
|
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`:**
|
|
```python
|
|
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
|
|
|