- 01सुरुवातको कारण “ठूलो खर्च जति पछि सारिनु” हो
- 02स्वचालित कार्यान्वयन भएकैले ध्यान दिइरहेको कुरा
- 03खर्चलाई 3 प्रकारमा बाँडी व्यवहार गर्ने
- 04“छलफल गर्नुपर्ने खर्च” को निर्धारण नियम
- 05Sync को ढिलाइलाई अंकमा व्यवहार गर्ने
- 06“प्रयोग नगरेको मात्र” र “जडानको खराबी” छुट्याउने
- 07बाहिरी API को call संख्यामा सीमा राख्ने
- 08“असामान्यता जारी रहेको” र “नयाँ असामान्यता” छुट्याउने
- 09Notification लाई जानाजान सादा बनाइएको छ
- 10गरेर महसुस भएको कुरा
- 11यस्ता व्यक्तिलाई उपयुक्त छ
- 12सारांश
नमस्ते, म まさきん हुँ।
पहिले, AI र freee लाई मिलाई घरायसी बजेट हरेक बिहान पुनरावलोकन गर्ने संरचना देखाएको थिएँ। यसपटक त्यसको रातको version हो। त्यो दिन प्रयोग गरेको कार्डको प्रयोगलाई, सुत्नुअघि AI ले स्वचालित रूपमा जाँच गरिदिने संरचनाको बारेमा लेख्छु।
बिहानको पुनरावलोकन “हिजोको प्रवृत्तिबाट चाल एक” हो भने, रातको संरचना अलि फरक स्वभावको हो। “आज, जाँचिराख्दा राम्रो खर्च छ कि छैन” लाई, त्यो दिनभित्रै टिप्ने संरचना हो। यसपटक निर्धारण नियमको सूत्र, वा कार्यान्वयनको समयको विस्तृत नियंत्रणसम्म समावेश गरी देखाउँछु।
सुरुवातको कारण “ठूलो खर्च जति पछि सारिनु” हो
दैनिक साना खर्चहरू, घरायसी बजेट app मा स्वाभाविक रूपमा रेकर्ड हुँदै जान्छ। तर, एकैचोटिको ठूलो खर्च फरक हो। “पछि कुरा गरौंला” भन्दै सोच्दा सोच्दै बिर्सिने हुन सक्छ।
त्यसैले, रकम ठूलो खर्च मात्र लक्षित गरी टिपेर, त्यो दिनभित्रै थाहा हुने बनाउने संरचना बनाएँ। यो संरचना मानिसले सुरु गर्ने होइन, तोकिएको समयमा स्वचालित रूपमा चल्ने “schedule task” को रूपमा चलिरहेको छ।
स्वचालित कार्यान्वयन भएकैले ध्यान दिइरहेको कुरा
तोकिएको समयमा स्वचालित रूपमा चलेपछि, त्यहीँ मानिससँग जाँच लिन सकिँदैन। त्यसैले, कार्यान्वयनको पूर्वाधारको रूपमा तलका नियम बनाइएको छ।
- बीचमा कतै प्राप्ति असफल भए पनि, त्यहाँ प्रक्रिया नरोकी बाँकी जारी राख्ने
- निर्णय गर्न नसकिएमा, जबर्जस्ती नबढी skip गरी log मा मात्र राख्ने
- बाहिरी API को प्राप्ति असफल भएको दिन, सामान्य जम्मा गर्ने कुरा छाडी सरल पुनरावलोकनमा fallback गर्ने
स्वचालित कार्यान्वयनको task लाई “पूर्ण रूपले चल्ने” भन्दा “हरेक दिन अनिवार्य रूपमा केही न केही परिणाम राख्ने” लाई प्राथमिकता दिने डिजाइन बनाइएको छ।
खर्चलाई 3 प्रकारमा बाँडी व्यवहार गर्ने
सबै खर्चलाई उही मापदण्डले जाँच गर्दा, notification ले भरिएर उल्टै नहेर्ने हुन्छ। त्यसैले, खर्चलाई तलका 3 प्रकारमा बाँडी व्यवहार गरिन्छ।
| प्रकार | सामग्री | जाँचको लक्ष्य हो? |
|---|---|---|
| निश्चित खर्च・subscription | हरेक महिना लगभग उही रकममा हुने भुक्तानी | लक्ष्य बाहिर राखिने |
| पहिल्यै सहमति भइसकेको ठूलो खरिद | पहिल्यै परिवारमा कुरा गरिसकेको खर्च | लक्ष्य बाहिर राखिने |
| त्यो बाहेकको खर्च | अचानक・स्वेच्छिक खर्च | जाँचको लक्ष्य |
निश्चित खर्च हरेक महिना उही भएकोले, हरेकपल्ट जाँच गर्दा पनि अर्थ हुँदैन। पहिल्यै सहमति भइसकेको खर्च पनि, पहिल्यै कुराकानी भइसकेकोले notification को आवश्यकता छैन। जाँच गर्नुपर्ने, त्यो बाहेकको “त्यहीँ उत्पन्न भएको खर्च” मात्र हो।
निश्चित खर्चको प्रतिनिधि, घर भाडा वा संचार खर्च हो। रकम लगभग नचल्ने भएकैले, दैनिक जाँचको लक्ष्यबाट बाहिर राखिएको हो।
Subscription को निर्धारणमा अलमल हुने व्यापारी एकैचोटि हो कि नियमित खरिद हो निर्णय नहुने, जबर्जस्ती “subscription” मा समावेश नगरी “निर्धारण होल्ड” को रूपमा छुट्टै एक line मा रेकर्ड गरिन्छ। यहाँ अस्पष्ट राखी अगाडि बढ्दा, पछि सम्पूर्ण जम्माको विश्वसनीयता डगमगाउँछ जस्तो लाग्छ।
तर, जाँचबाट बाहिर राखिएको खर्चमा पनि अपवाद छ। संचार खर्च जस्तो निश्चित खर्च नै, कहिलेकाहीं पुनरावलोकन गर्ने मूल्य छ जस्तो लाग्छ। दैनिक निगरानी स्वचालित बनाए पनि, निश्चित खर्चको स्तर आफैंले चलाउनु पर्छ।
थिच्दा राकुतेनको लगइन पेज खुल्छ। लगइन गरेपछि क्याम्पेनको विवरण देखिन्छ।
“छलफल गर्नुपर्ने खर्च” को निर्धारण नियम
जाँचको लक्ष्य खर्च मध्ये, निश्चित रकम भन्दा बढी हुने मात्रलाई “छलफल गर्नुपर्ने खर्च” को रूपमा व्यवहार गरिन्छ। AI लाई दिइरहेको निर्देशन सामान्यीकृत गरी देखाउँछु।
आजको कार्ड प्रयोग विवरणबाट, तलको तरिकाले "छलफल गर्नुपर्ने खर्च" निकाल्नुहोस्।
1. निश्चित खर्च・subscription मा वर्गीकृत भइसकेको transaction बाहिर राख्नुहोस्
2. पहिल्यै सहमति सूचीमा दर्ता भइसकेको transaction बाहिर राख्नुहोस्
3. बाँकी transaction मध्ये, 1 transaction प्रति निश्चित रकम अनुमानको लागि 10,000 येन वा बढी हुनेलाई निकाल्नुहोस्
4. निकालिएको transaction लाई "रकम" "प्रयोग स्थान" "समय" गरी 3 विषयमा सूची बनाउनुहोस्
निश्चित रकम भन्दा बढी transaction नभएमा, "आज कुनै छैन" भनेर मात्र जवाफ दिनुहोस्।
आधार बनाउने रकम घर अनुसार उचित स्तर फेरिन्छ जस्तो लाग्छ। महत्वपूर्ण कुरा “कति हो” भन्दा, “अगाडि नै आधार तय गरिराख्ने” हो जस्तो लाग्छ। आधार नभए, अन्तमा पछि “यो छलफल गर्नुपर्ने थियो कि थिएन” भनेर हरेकपल्ट छलफल गर्नुपर्ने हुन्छ।
Sync को ढिलाइलाई अंकमा व्यवहार गर्ने
घरायसी बजेट SaaS को कार्ड जडान, केही दिनजतिको प्रतिबिम्बन ढिलाइ सामान्य हो। लगातार बिदापछि झन् ढिलो हुन्छ। यसलाई “असामान्य” को रूपमा व्यवहार गर्दा, notification गलत पहिचानले भरिन्छ। त्यसैले, ढिलाइलाई तलको सूचकांकले अंकमा बनाइएको छ।
latest_txn_date: त्यो कार्डमा हालसालै observe गर्न सकिएको transaction को मितिlag_days: आजको मिति −latest_txn_dateदिन संख्यामाlag_status:lag_daysको आकारबाट तलका 4 चरणमा वर्गीकृत गर्ने
| Status | अनुमानित दिन | अर्थ |
|---|---|---|
| normal | 2 दिनभित्र | सामान्य प्रतिबिम्बन ढिलाइको दायरा |
| watch | 3-4 दिन | लगातार बिदापछि आदिमा पर्खने |
| delayed | 5-9 दिन | लम्बे बिदा आदिमा हुन सक्ने ढिलाइ |
| stalled | 10 दिन वा बढी | लम्बे समयसम्म, transaction प्रतिबिम्बित नभएको अवस्था |
महत्वपूर्ण कुरा, stalled लम्बे समय प्रतिबिम्बन नभएको लाई तुरुन्तै “जडानको खराबी” भनी निर्णय नगर्नु हो। सोझै “त्यो कार्ड केही समय प्रयोग नगरेको मात्र” भन्ने case वास्तवमा धेरै हुने भएकोले।
“प्रयोग नगरेको मात्र” र “जडानको खराबी” छुट्याउने
stalled observe भएमा, निर्णय गर्नु अघि विगत 30 दिनको transaction pattern जाँच गरिन्छ।
- विगत 30 दिनमा 1 वा बढी transaction भई, हालसालैको मात्र 10 दिन वा बढी खाली छ → सरल लम्बे समय अप्रयोग। जडान आफैं जीवित छ
- विगत 30 दिनमा transaction पूर्ण रूपमा 0 भई, वास्तवमा प्रयोग गरेको सम्झना छ → जडानको खराबीको शंका
तर, पछिल्लो मात्रैले पनि तुरुन्तै “खराबी” भनी निर्णय गर्दिनँ। तलका 3 सर्त सबै पूरा भएपछि मात्र, जडानको खराबीको रूपमा व्यवहार गरिन्छ।
- धेरै कार्डमा एकैसाथ
stalledउत्पन्न भएको - वास्तवमा प्रयोग गरेको रेकर्ड receipt वा note आदि छुट्टै रहेको तर घरायसी बजेट SaaS मा नआउने
- घरायसी बजेट SaaS तिरको screen मा, sync error को देखावट आँखाले जाँच गर्न सकिने
3 सर्त नपुगेसम्म, “N दिनसम्म कार्ड प्रयोग नगरेको बचत प्रवृत्ति जारी रहेको” भनी तटस्थ व्यवहार गरी, बेकारमा alert नदिने बनाइएको छ। यो छुट्याउने काम राख्नु अघि, सोझै प्रयोग नगरेको मात्र कार्डको बारेमा “जडान बिग्रिएको त होइन” भनी हरेकपल्ट चिन्तित हुँदै थिएँ।
बाहिरी API को call संख्यामा सीमा राख्ने
स्वचालित कार्यान्वयनको task भएकोले, केही कारणले असीमित API call गर्ने loop मा नफस्न, एक पटकको कार्यान्वयन प्रति call संख्यामा सीमा राखिएको छ।
- सामान्य pattern उही दिनको प्राप्ति・महिनाको सुरुदेखिको जम्मा प्राप्ति आदि मा, अगाडि नै अनुमानित call संख्या गनिराख्ने
- अनुमान बाहिरको error भए पनि, सीमा संख्यामा पुगेको बेला retry रोकी, तुरुन्तै “प्राप्ति असफल” को रूपमा fallback गर्ने
- “संख्या सीमामा पुगेकोले प्रक्रिया रोकिने” लाई, timeout पर्खनुभन्दा प्राथमिकता दिने
सीमा तय नगरे, authentication error आदि भएको बेला retry दोहोर्याई, बेकार request पठाइरहने जोखिम हुन्छ। स्वचालित कार्यान्वयनको संरचना जति, यस्तो रोक आवश्यक छ जस्तो लाग्छ।
“असामान्यता जारी रहेको” र “नयाँ असामान्यता” छुट्याउने
महिनाभित्रको खर्च अनुमानित निश्चित प्रतिशत नाघेको बेला notification दिने नियम राखिएको छ, तर यसलाई त्यसै दैनिक notification मा प्रयोग गर्दा, एकपटक नाघेपछि महिनाको अन्तसम्म हरेक रात उही notification जारी रहन्छ। यसले “नयाँ threshold नाघेको दिन” र “पहिल्यै नाघिसकेको र उहीजस्तै नाघिरहेको दिन” छुट्याउन सकिँदैन।
त्यसैले, नाघेको कति दिन जारी छ भनेर count गरी, “नाघेको जारी ◯ दिन” भन्ने रूपमा जोड्ने गरिएको छ। नयाँ असामान्यता र जारी रहेको असामान्यता छुट्याउन सकियो भने, साप्ताहिक पुनरावलोकन गर्दा पनि अवस्था सही रूपमा बुझ्न सजिलो हुन्छ।
Notification लाई जानाजान सादा बनाइएको छ
“छलफल गर्नुपर्ने खर्च” भेटिएको दिन पनि, notification लाई सहज सामग्री बनाइएको छ। रकम र प्रयोग स्थान प्रस्तुत गर्ने मात्र, राम्रो-नराम्रोको निर्णय गर्दिन।
निर्णय गर्ने आफूहरू हो। AI को भूमिका, “छुट्ने सम्भावना भएको खर्चमा चाल दिने” सम्म हो भनेर स्पष्ट राखेको छु।
गरेर महसुस भएको कुरा
सबैभन्दा ठूलो असर, ठूलो खर्चको बारेमा “भन्यो-भनेन” हराएको हो। त्यो दिनभित्रै जानकारी साझा हुने भएकोले, कुरा गर्ने समय छुट्न गाह्रो भयो।
अर्कोतिर, आधार रकमको सेटिङ सुरुदेखि नै पूर्ण गर्न सकिएन। धेरै कम भए notification धेरै भएर औपचारिक मात्र हुन्छ, धेरै बढी भए अर्थपूर्ण खर्च छुट्छ। धेरैपल्ट मिलाएर, अहिलेको स्तरमा स्थिर भएको छ।
यस्ता व्यक्तिलाई उपयुक्त छ
- घरायसी बजेट app मा कार्ड जडान गरेका तर ठूलो खर्चको साझेदारीमा time lag भएका व्यक्ति
- परिवारमा “खर्च छलफलको सीमा” स्पष्ट बनाउन चाहने व्यक्ति
- स्वचालित कार्यान्वयन task को गलत पहिचान・अधिक पहिचानलाई, बिस्तारै tuning गर्ने काममा अप्ठ्यारो नमानने व्यक्ति
सारांश
निश्चित खर्च र सहमति भइसकेको खर्च बाहिर राखी, त्यो बाहेकको ठूलो खर्च मात्र टिप्ने। यो सरल संकुचन, notification लाई औपचारिक हुनबाट जोगाउने कुरा हो जस्तो लाग्छ।
Sync ढिलाइलाई अंकमा बनाई “प्रयोग नगरेको मात्र” र “खराबी” छुट्याउने दृष्टिकोण, API को call संख्यामा सीमा राख्ने रोक, दुवै सादा छन् तर, स्वचालनलाई स्थिर रूपमा चलाइराख्नमा असर पारेको महसुस भएको छ।
यो संरचनाले टिप्ने, सधैं परिवर्तनशील खर्च हो। अर्कोतिर संचार खर्च जस्तो निश्चित खर्च, स्वभाव फरक हो। हरेकपल्ट जाँच गर्नुभन्दा, एकपटक पुनरावलोकन गर्दा असर लम्बे समय रहन्छ होइन र? स्वचालनसँगै, त्यतातिर पनि हेर्ने सोचिरहेको छु।
थिच्दा राकुतेनको लगइन पेज खुल्छ। लगइन गरेपछि क्याम्पेनको विवरण देखिन्छ।
यस लेखमा सम्बद्ध विज्ञापन समावेश छ। यस साइटको लिङ्क मार्फत उत्पादन वा सेवाको लागि आवेदन दिनुभयो भने, हामीले साझेदार कम्पनीबाट प्रतिफल पाउन सक्छौं। साथै, सञ्चालक राकुतेन समूहको कर्मचारी हो र कर्मचारी सिफारिस कार्यक्रम मार्फत प्रतिफल पाउन सक्छ। लेखको सामग्री र मूल्याङ्कन विज्ञापन भए वा नभएको भन्दा फरक रूपमा सञ्चालकको वास्तविक अनुभव र अनुसन्धानमा आधारित रहेर तयार गरिएको हो, तर माथिको सम्बन्ध बुझेर पढ्नुहोला। विस्तृत जानकारीका लागि अस्वीकरण र सम्बद्ध लिङ्क सूचना हेर्नुहोस्। अस्वीकरण र सम्बद्ध लिङ्क सूचना
यस लेखमा मेसिन अनुवाद समावेश छ। आधिकारिक सर्तका लागि राकुतेन मोबाइलको आधिकारिक साइटको बहुभाषी पृष्ठ हेर्नुहोस्।
राकुतेन मोबाइलको सञ्चार क्षेत्र वा सिग्नल अवस्थाको बारेमा चिन्ता भएमा, आधिकारिक सिग्नल सुधार·अनुसन्धान अनुरोध फारम मार्फत सोध्न सकिन्छ।
