क्रेडिट कार्ड सिस्टम कार्यान्वयन?

Question

मेरी साइट पर क्रेडिट सिस्टम होने वाला है जो मूल रूप से क्रेडिट कार्ड की तरह काम करता है। प्रत्येक उपयोगकर्ता की असीमित क्रेडिट सीमा होती है, लेकिन प्रत्येक सप्ताह के अंत में, उन्हें इसे भुगतान करना होगा। उदाहरण के लिए, कोई उपयोगकर्ता 1 मार्च और 7 वीं के बीच कई खरीदारी कर सकता है, और फिर 7 मार्च के अंत में, उन्हें एक चालान ईमेल किया जाएगा जो सप्ताह के दौरान उनकी सभी खरीदारियां सूचीबद्ध करता है और कुल 14 वें के कारण होता है। अगर वे इसे भुगतान नहीं करते हैं, तो उनका खाता तब तक निष्क्रिय हो जाता है जब तक वे ऐसा नहीं करते। मैं बस इसे लागू करने के तरीके के आसपास अपने सिर को लपेटने की कोशिश कर रहा हूं।

मेरे पास उनकी सभी खरीदारियों की एक सूची है, यह कोई समस्या नहीं है, लेकिन मैं बस यह पता लगाने की कोशिश कर रहा हूं कि इसके साथ क्या किया जाए। 7 वें दिन के अंत में, मैं एक चालान उत्पन्न करने के लिए एक क्रोनबॉज स्थापित कर सकता था, जिसमें मूल रूप से एक आईडी और देय तिथि होगी, और फिर चालान में सभी खरीदारियों को जोड़ने के लिए मुझे कई से अधिक टेबल की आवश्यकता होगी । फिर जब कोई उपयोगकर्ता अपने खाते में पैसा जोड़ता है, तो मुझे लगता है कि यह उनके वर्तमान बकाया चालान के खिलाफ लागू है? और क्या होगा यदि वे एक नए चालान के आसपास अपने चालान का भुगतान नहीं करते हैं, तो अब उनके पास 2 उत्कृष्ट हैं, मुझे कैसे पता चलेगा कि इसे किसके खिलाफ लागू करना है? या क्या मैं किसी भी पिछले बकाया चालान के लिए क्रोनबॉज चेक करता हूं, उन्हें रद्द करता हूं, और नए चालान में "बैलेंस फॉरवर्ड (+ ब्याज)" के रूप में एक नया आइटम जोड़ता हूं? चालान के खिलाफ आप पैसे कैसे लागू करेंगे? क्या प्रत्येक भुगतान को चालान से जोड़ा जाना चाहिए, या क्या मैं इसे अपने खाते के क्रेडिट में जमा कर सकता हूं, और फिर किसी भी तरह से भुगतान किया गया है कि क्या भुगतान किया गया है और क्या नहीं है? क्या होगा यदि वे अपने चालान उत्पन्न होने से पहले, अग्रिम भुगतान करते हैं? क्या मैं इसे पीढ़ी पर चालान से या अपने सप्ताह के अंत में अपने क्रेडिट से कटौती करता हूं? ऐसा करने के कई तरीके हैं ...

क्या कोई वर्णन कर सकता है कि वे किस दृष्टिकोण को लेंगे?

---

यदि कोई दिलचस्पी लेता है, तो मेरा चालान मॉडल वर्तमान में निम्नानुसार दिखता है (Django में)। इनवॉइसइटम एक रिवर्स आईडी द्वारा वास्तविक "उत्पादों" से जुड़े होते हैं (एफके उत्पाद पर है, चालान आइटम नहीं है ताकि विभिन्न आइटम प्रकारों (विभिन्न तालिकाओं) को अनुमति दी जा सके), लेकिन मुझे लगता है कि मैं इसे चारों ओर स्विच करने जा रहा हूं।

class Invoice(models.Model): 
    user = models.ForeignKey(User, related_name='invoices') 
    created = models.DateTimeField(auto_now_add=True) 
    updated = models.DateTimeField(auto_now=True) 
    closed_date = models.DateTimeField(null=True, blank=True) 
    due_date = models.DateTimeField(default=_next_weekday()) 
    payment_date = models.DateTimeField(null=True, blank=True) # date the invoice was fully paid 
    total_payments = CurrencyField(default=0) 
    interest_charges = CurrencyField(default=0) 

    @property 
    def days_overdue(self): 
     dt = self.due_date - datetime.date.today() 
     return dt.days if dt.days > 0 else 0 

    @property 
    def item_total(self): 
     return self.items.filter(amount__gt=0).aggregate(t=Sum('amount'))['t'] or Decimal('0.00') 

    @property 
    def daily_interest(self): 
     return _round((self.item_total - self.total_payments) * settings.INTEREST_RATE/Decimal('365.242199')) 

    @property 
    def subtotal(self): 
     return self.item_total + self.interest_charges 

    @property 
    def tax(self): 
     return _round(self.subtotal * settings.GST) 

    @property 
    def total(self): 
     return self.subtotal + self.tax 

    @property 
    def balance_owing(self): 
     return self.total - self.total_payments 

    @property 
    def is_paid(self): 
     return self.payment_date != None 

    @property 
    def is_open(self): 
     return self.closed_date == None 

    @property 
    def is_overdue(self): 
     return not self.is_paid and self.due_date < datetime.date.today() 

class InvoiceItem(models.Model): 
    invoice = models.ForeignKey(Invoice, related_name='items') 
    created = models.DateTimeField(auto_now_add=True) 
    updated = models.DateTimeField(auto_now=True) 
    description = models.CharField(max_length=200) 
    trans_date = models.DateTimeField(verbose_name='transaction date') 
    amount = CurrencyField() 

मैं एक crontab हर रात आधी रात को चलाने के लिए सभी अतिदेय आइटम के लिए ब्याज शुल्क जोड़ने के लिए की स्थापना की है, और चालान हर शुक्रवार की सुबह बाहर भेज रहे हैं।

Answer 1

जो आप यहां वर्णन कर रहे हैं वह मूल रूप से खुले आइटम एकाउंटिंग और बैलेंस अग्रेषण के बीच एक निर्णय है।

खुले आइटम एकाउंटिंग में, प्रत्येक चालान को "खुला" रखा जाता है, जबकि इसके पास शेष राशि होती है और भुगतान उन व्यक्तिगत चालानों के लिए जिम्मेदार होते हैं जिन्हें वे भुगतान कर रहे हैं। इससे ब्याज जैसी चीज़ों को काम करना आसान हो जाता है - उदाहरण के लिए यदि आप 30 दिनों से अधिक समय के दौरान शेष राशि पर ब्याज लेते हैं तो आपको पता होना चाहिए कि चालान के पास 30 दिनों से अधिक पुरानी शेष राशि क्या है।

बैलेंस अग्रेषण लेखांकन क्रेडिट कार्ड भुगतान के समान है, जब एकमुश्त शेष राशि है जो आगे की जाती है और भुगतान व्यक्तिगत चालान के बजाए उस कुल शेष राशि के विरुद्ध किया जाता है। जब केवल उत्पादों में से कुछ निश्चित चालान से जुड़े होते हैं स्पष्टीकरण के लिए

अद्यतन

ओपन आइटम लेखांकन, जटिल बिल की प्रक्रिया के लिए अच्छा है, उदाहरण के लिए। उदाहरण के लिए, एक निर्माता कुछ दर्जन उत्पादों को खरीदता है लेकिन उन्हें तीन अलग-अलग भवन परियोजनाओं में अलग से चालान किया जाना है।

ओपन आइटम एकाउंटिंग का भी उपयोग तब किया जाता है जब आपको भुगतान और विवाद समाधान उद्देश्यों के लिए प्रत्येक व्यक्तिगत चालान को ट्रैक करने की आवश्यकता होती है। उदाहरण के लिए, एक इमारत की आपूर्ति ग्राहक के लिए एक निर्माता है।कभी-कभी आपूर्ति किए गए सामान गलत या दोषपूर्ण होते हैं, इसलिए निर्माता अन्य सभी चालान (अधिक हालिया चालान सहित) का भुगतान करता है, जिसे छोड़कर ट्रैक किया जाता है और अलग से निपटाया जाता है - शायद प्रतिस्थापन सामान की आपूर्ति के दौरान भुगतान किया जा रहा है या शायद इसके खिलाफ क्रेडिट नोट प्राप्त हो रहा है चालान।

बैलेंस अग्रेषण एकाउंटिंग में, आप पूरी तरह से खाते के खिलाफ क्रेडिट लागू करके इस स्थिति से निपटेंगे, फिर प्रतिस्थापन सामान की आपूर्ति के दौरान लेनदेन को दोबारा जोड़ना होगा। शेष राशि पर लगाए गए किसी भी ब्याज को खाते के विरुद्ध भी उलट दिया जा सकता है।

Client  [ClientId, Name, AccountBalance] 
Product  [ProductId, Description, Cost] 
Invoice  [InvoiceId, ClientId, Date, TotalAmount, Outstanding] 
InvoiceItem [InvoiceId, ProductId, Quantity, Amount] 
Receipt  [ReceiptId, Date, TotalAmount] 
ReceiptItem [ReceiptId, InvoiceId, Amount] 

क्लाइंट जब बनाया गया चालान हो जाता है:

ओपन मद लेखा

आप निम्न तालिकाओं की जरूरत है:

Simplistically, यहाँ एक तरह से आप अपने डेटाबेस में इन सेट कर सकते हो रहा है उत्पादों को खरीदना खरीदे गए प्रत्येक उत्पाद के लिए, उस उत्पाद के लिए एक चालान आइटम बनाया जाता है जो खरीदी गई मात्रा और राशि दिखाता है। जब चालान अपडेट किया जाता है, चालान का बकाया राशि चालान का कुल होता है और ग्राहक खाता शेष राशि अपडेट की जाती है (फ्लाई पर गणना की जा सकती है लेकिन स्वचालित रूप से बनाए रखा जाने वाला आसान और तेज़)। जब ग्राहक एक या अधिक चालान का भुगतान करता है, तो रसीद बनाई जाती है और भुगतान किए जाने वाले प्रत्येक चालान को रसीद आइटम आवंटित किए जाते हैं। चालान की बकाया राशि ग्राहक के खाते की शेष राशि के साथ अपडेट की जाती है। ध्यान दें कि ओवरपेयमेंट को अलग से निपटाया जाना चाहिए। एक चालान आइटम के रूप में अगले चालान (या एक अलग चालान) पर ब्याज शुल्क उठाए जाते हैं (यह एक कस्टम उत्पाद हो सकता है)।

शेष आगे लेखा

आप निम्न तालिकाओं की जरूरत है:

Client  [ClientId, Name, AccountBalance] 
Product  [ProductId, Description, Cost] 
Invoice  [InvoiceId, ClientId, Date, Amount] 
Transaction [TransactionId, ClientId, InvoiceId, ProductId, Date, Quantity, Amount] 

जब एक उत्पाद खरीदा है, एक सौदे के उत्पाद की मात्रा और राशि और दिखा ग्राहक के खाते पर किया जाता है ग्राहक का खाता शेष अपडेट किया गया है। जब रसीद की जाती है, तो फिर ग्राहक के खाते पर एक लेनदेन किया जाता है और ग्राहक का खाता शेष अपडेट किया जाता है। ओवरपेमेंट्स और ब्याज भुगतान सिर्फ एक लेनदेन भी हैं। चालान समय पर, आप बस सभी लेनदेन (खरीद, रसीदें, ब्याज भुगतान, आदि) को पकड़ते हैं जिन्हें चालान के लिए आवंटित नहीं किया जाता है और उन्हें आपके नए चालान में शामिल किया जाता है। चालान लेनदेन सूची में प्रकट नहीं होता है, यह केवल उन लेनदेन को ट्रैक करने में सुविधा के लिए है जो चालान किए गए हैं और भुगतान करते समय अपने ग्राहकों को संदर्भ संख्या देने के लिए। आप इस मॉडल में रसीदों को ट्रैक करना भी चाह सकते हैं।

अन्य विचार

• इस खाते में सामान्य खाता बही पोस्टिंग जो टेबल के एक बिल्कुल अलग सेट हो जाएगा नहीं लेता है। यह केवल प्रबंधन लेखांकन के लिए है, न कि वित्तीय लेखांकन।
• प्रैक्टिस में, क्लाइंट और चालान के बीच एक परियोजना तालिका हो सकती है ताकि प्रत्येक ग्राहक व्यक्तिगत परियोजनाओं को आपके साथ ट्रैक कर सके।
• यह आपको एक विचार देने के लिए वास्तव में सरल है। पूर्ण कार्यान्वयन के लिए अधिक सारणी और फ़ील्ड में कोई संदेह नहीं होगा।

क्या होता है यदि बिलिंग के समय आने पर वे अपने चालान का भुगतान नहीं करते हैं, तो किसी भी प्रणाली में इससे कोई फर्क नहीं पड़ता - आप समय पर वापस नहीं जाते हैं और पिछली लेखांकन प्रविष्टियों को बदलते हैं। जो कुछ भी होता है वह अब एक नए चालान पर जाता है।निस्संदेह, नए चालान पर "लाइन पर पहले बकाया राशि" कहने के लिए पूरी तरह से उचित है जो कि पहले से देय राशि दिखाता है (या अधिक भुगतान के लिए क्रेडिट में है)।

आप भी एक स्टेटमेंट ऑफ अकाउंट तैयार करने में सक्षम होना चाहते हैं, जो एक चालान नहीं है, यह सिर्फ उन्हें याद दिलाने वाले पत्र की तरह है कि उनके पास बकाया शेष हैं। इसका उपयोग तब किया जाता है जब उत्पन्न होने के लिए कोई नया चालान नहीं होता है लेकिन ग्राहक को अपने खाते की शेष राशि के बारे में अनुस्मारक की आवश्यकता होती है।

मैं अपने सिस्टम के लिए ओपन आइटम एकाउंटिंग पसंद करता हूं लेकिन आपके विवरण संतुलन से आगे लेखांकन अच्छी फिट की तरह लगता है।