信用卡付款通知

[dominic]

我的結帳日是20號~付款日為10號

有一筆資料於10/30的信用卡刷卡記錄~
今天使用卻顯示在本期應付~10/20~11/19的款項不是應該要列為12月的應付嗎??

[o慕雲o]

我的結帳日是20號~付款日為10號

有一筆資料於10/30的信用卡刷卡記錄~
今天使用卻顯示在本期應付~10/20~11/19的款項不是應該要列為12月的應付嗎??

您好
結帳日是 20 日
我們假設是 10 月 20 日結帳(10月20日以前算 10 月)
而您是在 10/30 日支出
該日期是介於 10月20日的結帳日後
算入到 11 月份的應付是正常的喔
詳細的信用卡計算依據您可參考以下連結說明
http://blog.jigong.org/?cat=14

[dominic]

也許那個網頁理論上是對的~(還必須找更多資料證明)
但是實務上10/20~11/19的款項~事實上若繳款日在1號以後
繳款日就是12月了~

另外我覺得忽略掉一個問題就是領薪日。12/1~12/5大多人都是11月的薪水付~12/5以後是12月薪水付

我不確定到底是他的說法是對或不對~但是偏離人性就顯得不好用
明明我都用12月薪水去付信用卡~但是我11月就要看到他在那邊跳出來提醒

另外他的說法
---------------------------------------
結帳日10日，繳款日 25日，那就都會同一個月 (繳款日為本月25日)
結帳日20日，繳款日05日，那就是下一個月繳款(繳款日為下月的05日)
一般來說，
若 繳款日 < 結帳日 則以下月算
若 結帳日 > 繳款日 則以本月算

很明顯他漏掉了消費的時間點為何~若是結帳日前當然都是對的!!

[o慕雲o]

也許那個網頁理論上是對的~(還必須找更多資料證明)
但是實務上10/20~11/19的款項~事實上若繳款日在1號以後
繳款日就是12月了~

另外我覺得忽略掉一個問題就是領薪日。12/1~12/5大多人都是11月的薪水付~12/5以後是12月薪水付

我不確定到底是他的說法是對或不對~但是偏離人性就顯得不好用
明明我都用12月薪水去付信用卡~但是我11月就要看到他在那邊跳出來提醒

另外他的說法
---------------------------------------
結帳日10日，繳款日 25日，那就都會同一個月 (繳款日為本月25日)
結帳日20日，繳款日05日，那就是下一個月繳款(繳款日為下月的05日)
一般來說，
若 繳款日 < 結帳日 則以下月算
若 結帳日 > 繳款日 則以本月算

很明顯他漏掉了消費的時間點為何~若是結帳日前當然都是對的!!

這部份有很多人會有這樣的疑問
但這部份這樣的下判斷本身是沒有錯的
不過這部份我是覺的很覆雜(程式也很覆雜)
若要真的每一個情況都說明出來可能更是困難
不過就依您的情況來說就我上面的解釋其事實發生日還是在 10 月份上沒錯的

[dominic]

也許那個網頁理論上是對的~(還必須找更多資料證明)
但是實務上10/20~11/19的款項~事實上若繳款日在1號以後
繳款日就是12月了~

另外我覺得忽略掉一個問題就是領薪日。12/1~12/5大多人都是11月的薪水付~12/5以後是12月薪水付

我不確定到底是他的說法是對或不對~但是偏離人性就顯得不好用
明明我都用12月薪水去付信用卡~但是我11月就要看到他在那邊跳出來提醒

另外他的說法
---------------------------------------
結帳日10日，繳款日 25日，那就都會同一個月 (繳款日為本月25日)
結帳日20日，繳款日05日，那就是下一個月繳款(繳款日為下月的05日)
一般來說，
若 繳款日 < 結帳日 則以下月算
若 結帳日 > 繳款日 則以本月算

很明顯他漏掉了消費的時間點為何~若是結帳日前當然都是對的!!

這部份有很多人會有這樣的疑問
但這部份這樣的下判斷本身是沒有錯的
不過這部份我是覺的很覆雜(程式也很覆雜)
若要真的每一個情況都說明出來可能更是困難
不過就依您的情況來說就我上面的解釋其事實發生日還是在 10 月份上沒錯的

應付日期卻不是在10月~這樣信用卡就不信用卡了

[o慕雲o]

應付日期卻不是在10月~這樣信用卡就不信用卡了

系統所顯示的 [本期應付] 是針對該月份的應付金額,而非實際上的應繳月份,系統為提示您該月已消費金額,不是您該月應付的金額

PS：如您對這樣的算法有疑慮而不符合您使用的話,可否請您留一下您的銀行帳號資料,我們將您的匯款退還給您,我們並沒辦法依據每一個人的需求去作一次系統的定義

[dominic]

應付日期卻不是在10月~這樣信用卡就不信用卡了

系統所顯示的 [本期應付] 是針對該月份的應付金額,而非實際上的應繳月份,系統為提示您該月已消費金額,不是您該月應付的金額

PS：如您對這樣的算法有疑慮而不符合您使用的話,可否請您留一下您的銀行帳號資料,我們將您的匯款退還給您,我們並沒辦法依據每一個人的需求去作一次系統的定義

退款倒不用~金額並不高
只是我遇到的問題~就是部份使用者會遇到的問題~

今天有個管道能讓我表達使用者的想法~當然接不接受還是在開發者了..

[o慕雲o]

應付日期卻不是在10月~這樣信用卡就不信用卡了

系統所顯示的 [本期應付] 是針對該月份的應付金額,而非實際上的應繳月份,系統為提示您該月已消費金額,不是您該月應付的金額

PS：如您對這樣的算法有疑慮而不符合您使用的話,可否請您留一下您的銀行帳號資料,我們將您的匯款退還給您,我們並沒辦法依據每一個人的需求去作一次系統的定義

退款倒不用~金額並不高
只是我遇到的問題~就是部份使用者會遇到的問題~

今天有個管道能讓我表達使用者的想法~當然接不接受還是在開發者了..

因不同人有不同的想法
有些人希望這樣
有些人希望那樣
我們實在沒辦法為每一個人的想法去設計
我們剛剛前面有提到

系統所顯示的 [本期應付] 是針對該月份的應付金額,而非實際上的應繳月份,系統為提示您該月已消費金額,不是您該月應付的金額

這部份就要看每一個人的解讀方式
或許您要的是當月份的應繳金額
但或許也有人想要的是當月份的消費
且信用卡的計算相當覆雜(尤其是多張信用卡時)
每改變一種方式都會改到很多東西
所以在盡可能的情況下是最好依現行的方式作業(這方式也是前人提供)
我們只是認同這樣的管理模式是可以接受的才這樣去設計
當然您給我們的建議我們都會加以考慮
我們也很歡迎使用者能給予我們好的建議
但我們有時也會考慮這樣修改後會產生什麼樣的影響
帳務小管家是歷經多年時間設計改善而成
而我們的使用者也有好幾千人
我想這樣的管理模式若有重大問題的話應該會有更多人反應
所以基本上若現行管理模式是屬於大眾化可接受的管理範圍模式下
我們均會以現行的管理方式處理

[dominic]

恩~謝謝~抱歉造成您的困擾

[o慕雲o]

恩~謝謝~抱歉造成您的困擾

不會
我們只是希望我們的軟體能夠幫助到需要幫助的人
而如您有使用上的無法接受問題
我們也會將您的匯款退還給您
因我們不希望我們的軟體收了費用但確幫助不了使用者
這就有違我們設計此軟體的初衷(不然我們就賣跟外面的價格一樣 300 就好)
當然您有更好的建議都隨時歡迎您跟我們建議
我們也希望此軟體能夠作的更好更方便