[交流] Palm史上最強的記帳軟件 Adarian Money

zombie

Originally posted by tylpk at 2005-11-22 12:59:
PipperL兄

可不可以請問你一個問題？

小弟之前試著把PMT的資料檔(.pdb)
想把他轉成一般的.CSV檔
但還看不出該檔案記錄資料的關聯性
是不是我的方向錯誤了?

還是說原廠有提供轉檔程式
我不需要自己去轉
不過我印象中四年前在palmgear買的時候
似乎並沒有提供此類程式

其實我是想知道如果要寫轉檔程式的順序是如何?

我原本的想法
PMT.pdb -> .CSV -> AM.pdb

但是要將我這快四年的pdb轉成CSV就破功
(突然想到..我應該新增一個資料庫
一筆一筆的交易加入在邊比對.pdb檔
應該比較能看出關聯性才對)

希望能提供我一個方向，謝謝。

新版的PMT (忘了從那版開始)，有附一個coundit，可以在同步過程中，直接轉出檔案，
在PMT的手冊裡也有說明檔案的格式。

PipperL

Originally posted by zombie at 2005-11-22 14:24:


新版的PMT (忘了從那版開始)，有附一個coundit，可以在同步過程中，直接轉出檔案，
在PMT的手冊裡也有說明檔案的格式。

zombie 說的沒錯，有現成的可用。
我的程式是從該 Conduit 所轉出的  csv 檔開始，產生 QIF ，最後用匯入功能進到AM 中。
所以理論上要從 PMT 跳槽到 SplashMoney / MS Money/ Quicken 的使用者也是可以用的。

PipperL

Originally posted by GAAP at 2005-11-22 13:17:


PipperL兄,聽小弟一言

1.我到現在為止還用過桌面端,所以我不評論
2.有關傳票輸入的順序,我覺的這是習慣的問題,不能要求作者改,因為我們習慣了PMT,如果改了我們同理心想一下,AM原來的USER也會不爽的

說這是「習慣」的問題，我並不是很同意。對原先 AM 的使用者，這是習慣。但是對於其他軟體的 user 或是完全沒用過記帳軟體的一般 user 而言，這是 UI 設計的流不流暢，好不好，不是習慣。

我在之前回文有說明整個思維，您可以再看一次。

想一想，如果你拿了一本空白筆記簿要記帳，你的書寫欄位順序是什麼，答案應該很明白。

當然，我回上文不是要求作者改，而是要我提缺點我就提了。作者改不改是他的自由，軟體好不好用(功能/流暢/順手)而讓人跳不跳槽則是使用者的自由。

3.我當初也和PipperL兄一樣不習慣,所以我中文化時,稍微改了順序,我覺的每個人習慣不同,像我就超不喜歡把交易對象放前面(用不到),所以我把部門別放在最前面,表示我每個交易一定要給它一個分類,接著我也移動計算機....等等
我想每個人的習慣不同,不能強制作者(當然最好的作法是作者能像報表一樣自訂,就不會有爭議了)

就寫軟體的人而言，這種「自訂」通常會給程式帶來很多額外的負擔，如執行效率，體積等考量。基本上作者可以提供一個適合大多數人的界面，自訂的功能反而是 Bonus。

中文化 .... 沒有用中文化的人就沒辦法享受「改順序」的好處了。

4.另外你提到的(2)~(4)點,我也讚成,都是很好的建議
2. 把一個小小三角形改成其他更方便的點選方式(如點選三角形左邊的欄位名稱如 Payee也可以下拉)
3. 把計算機裡的 Enter/Cancel 位置調一下(雖然,這點我感覺,但也是好的建議)
4. 下拉選單的 scroll bar 加寬，然後把下鍵改成 page down。

最後,我也發現AM有會計邏輯上的BUG,以及程式設計介面的小BGU,
先說一下會計邏輯的BUG:
1.如果交易只輸入一方科目,是可以存檔的(雖然程式背後是用權益方式來調整),但我不希望作者開放這種輸入方式

當 Category 是空白，的確是可以輸入的。我倒不覺得這有什麼不好的。
以我而言，這有兩個用途：
1. 當執行 Adjuct Balance 時，程式會替差額產生一筆transaction，這一筆是空白的 Category。在說明書上也有提到。這是作者的用法。我則是另外設一個支出「呆帳」來作這件事。

2. 當我要快速記帳時(尤其是目前 AM 沒辦法讓我一邊移動一邊單手記帳)，我會先只輸入金額，然後其他欄位都空白，然後直接儲存。等到定點或回到 AM windows 時再找到空白項補資料。如果把這功能取消掉，然後又因為UI設計沒辦法移動中輸入，我想我會想辦法搬家回 PMT

其實我應該到AM的討論區去發言的，在這裡講作者又聽不到 :p

colussu

Originally posted by PipperL at 2005-11-22 02:29 AM:
從目前雙方開放的格式來看，要從 AM -> CSV 也是可行的。
只是在轉換之後勢必會損失某些資訊(兩邊欄位定義不對等)

這樣呀，那就可惜了，不能做到無痛換平台 |)

三來我想不出為什麼這樣 AM 的 user 會更多 8D

因為如果可以無痛轉換的話，PMT的user就可以放心地跳到AM，日後有什麼萬一還可以回到PMT  

supercat

另外還有一個小缺點, 很多畫面ok的選項不能用五向鍵達成
有一些可以有一些不行, 到底是為什麼呢??

daily

Originally posted by PipperL at 2005-11-22 02:29 AM:
從目前雙方開放的格式來看，要從 AM -> CSV 也是可行的。
只是在轉換之後勢必會損失某些資訊(兩邊欄位定義不對等)
...

AM 只有比 PMT 多了一個欄位，Class！

AM 的 Payee，就是 PMT 的 Description。僅僅是欄位名稱的不同。

AM 有 4 種 Status，PMT 也是有這 4 種
(PMT 勾 Cleared 就是 AM 的 Cleared；不勾 Cleared，就是 AM 的 Posted；
PMT 的 Menu 的 Do not post transaction 就是 AM 的 Unrealized；對帳，PMT 與 AM 都有。
另外，完成對帳，就表示一定 Clerared；沒有已完成對帳卻非 Cleared 的。兩者皆然)

AM 的 Check ，就是 PMT 的 Ref

日期，備註，金額，借貸科目，AM 與 PMT 都有。 (這是最基本的，有誰能少嗎？|) )

AM 的 Scheduled Transcation 就是 PMT 的 Repeat (兩者是不是有對等，我還沒有仔細研究。)

[ Last edited by daily on 2005-11-23 at 09:10 ]

daily

Originally posted by supercat at 2005-11-23 12:16 AM:
另外還有一個小缺點, 很多畫面ok的選項不能用五向鍵達成
有一些可以有一些不行, 到底是為什麼呢??

可以明確指出嗎？
「為什麼？」
當然是作者漏了

PipperL

在我寫轉換程式時，比較麻煩的其實是 PMT 的 Description 要對應到 AM 的哪一個欄位。
由於每個人用 PMT 的方式不一樣，使用 Description 的方式也不一樣。

以下是 PMTxl manual 上的說明：
"You can use the Description drop down to enter a description for the item; this is
especially useful for recurring descriptions, such as the name of a store you often
shop at. "

就我個人而言，比較把 Description 當作 Class 用。於是在轉換程式處理時，只好變成 Sub-category處理。

今天經daily 你提醒，的確有可能有人當 Payee 用。本來我等一下要釋出轉換程式的，我看再延一兩天好了，再加個可以把 Description 改對應到 Payee 的功能

其他的朋友，就請再耐心等一下下吧。

ps. 我完全沒有處理 check #(Ref) 的部份，因為我自己沒用到 :p

Originally posted by daily at 2005-11-23 09:08:


AM 只有比 PMT 多了一個欄位，Class！

AM 的 Payee，就是 PMT 的 Description。僅僅是欄位名稱的不同。

AM 有 4 種 Status，PMT 也是有這 4 種
(PMT 勾 Cleared 就是 AM 的 Cleared；不勾 Cleared，就是 AM 的 Posted；
PMT 的 Menu 的 Do not post transaction 就是 AM 的 Unrealized；對帳，PMT 與 AM 都有。
另外，完成對帳，就表示一定 Clerared；沒有已完成對帳卻非 Cleared 的。兩者皆然)

AM 的 Check ，就是 PMT 的 Ref

日期，備註，金額，借貸科目，AM 與 PMT 都有。 (這是最基本的，有誰能少嗎？|) )

AM 的 Scheduled Transcation 就是 PMT 的 Repeat (兩者是不是有對等，我還沒有仔細研究。)

[ Last edited by daily on 2005-11-23 at 09:10 ]

daily

我本來也是很疑惑，PMT 的 Description 與 AM 的 Payee & Class 有什麼關係？

為什麼我會提出， Description 就是 Payee，而 AM 的 Class 是特別增加的欄位？
我關注的重點，不是欄位的名稱，而是欄位的性質。
Description 與 Payee 都是針對整個 Transaction 的描述；而 Class 是要描述的對象是 Category/Account
我們可以在 AM 的 Split 畫面內，對同一個 Category/Account 設不同的 Class (如：用餐/個人，用餐/女朋友)。
在 PMT ，只好將不同的 Class 打成不同的科目來表示。

[ Last edited by daily on 2005-11-23 at 10:35 ]

溫開水

請問有人成功的裝上中文化嗎？  我試過兩個檔都不成功(是直接執行嗎?)

我的機型是Treo650

謝謝

daily

在 AM 上，Transaction 的 Status 有四個：Posted, Cleared, Reconciled, Unrealized  (PMT 也是如此！)
依照會計基礎所採用的「權責發生制」，未發生權責者，記 Unrealized。
已經發生權責者，記 Posted。
再根據「現金收付制」，若是已經發生權責，且現金收付完成者，記 Cleared。
已經跟銀行的對帳單核對無誤者，記 Reconciled。

平常的交易，多是已經完成收付的 (意思就是：該給的給了，該收的也收了)，所以，就要記 Cleared.
若是收到的支票還沒兌現，就記 Posted，而不是 Unrealized。
先把下個月的 ADSL 費用記上者，就記 Unrealized。

當然啦，自己的帳簿，自己記得爽也看得懂，就可以了。哪來那麼多規矩...

HHSL

Originally posted by daily at 2005-11-23 13:47:
在 AM 上，Transaction 的 Status 有四個：Posted, Cleared, Reconciled, Unrealized  (PMT 也是如此！)
依照會計基礎所採用的「權責發生制」，未發生權責者，記 Unrealized。
已經發生權責者，記 Posted。
再根據「現金收付制」，若是已經發生權責，且現金收付完成者，記 Cleared。
已經跟銀行的對帳單核對無誤者，記 Reconciled。

平常的交易，多是已經完成收付的 (意思就是：該給的給了，該收的也收了)，所以，就要記 Cleared.
若是收到的支票還沒兌現，就記 Posted，而不是 Unrealized。
先把下個月的 ADSL 費用記上者，就記 Unrealized。

當然啦，自己的帳簿，自己記得爽也看得懂，就可以了。哪來那麼多規矩...

daily兄，這是很棒的歸納。謝謝你的分享。
我最近忽然多了很多事情，在AM和PMT等財務軟體的試驗上，已經感到有點力不從心。
還好，發現多了PipperL兄，還有其他網友的加入，感謝！
等我忙玩了這幾天，再加入討論！

chrispinyang

Originally posted by PipperL at 2005-11-23 03:00 AM:
在我寫轉換程式時，比較麻煩的其實是 PMT 的 Description 要對應到 AM 的哪一個欄位。
由於每個人用 PMT 的方式不一樣，使用 Description 的方式也不一樣。

以下是 PMTxl manual 上的說明：
"You can use the Description drop down to enter a description for the item; this is
especially useful for recurring descriptions, such as the name of a store you often
shop at. "

就我個人而言，比較把 Description 當作 Class 用。於是在轉換程式處理時，只好變成 Sub-category處理。

今天經daily 你提醒，的確有可能有人當 Payee 用。本來我等一下要釋出轉換程式的，我看再延一兩天好了，再加個可以把 Description 改對應到 Payee 的功能

其他的朋友，就請再耐心等一下下吧。

ps. 我完全沒有處理 check #(Ref) 的部份，因為我自己沒用到 :p

請問, 如果在 PMT 有設多層樹枝狀結構的科目, 這樣轉到 AM 會變成怎樣 ?

PipperL

Originally posted by chrispinyang at 2005-11-23 15:10:

請問, 如果在 PMT 有設多層樹枝狀結構的科目, 這樣轉到 AM 會變成怎樣 ?

由於 AM 只支援兩層，因此第三層以後的會被併到上層去。

GAAP

Originally posted by PipperL at 2005-11-23 03:26 PM:


由於 AM 只支援兩層，因此第三層以後的會被併到上層去。

好佳在,我用PMT只有兩層,有了AM,還要3層嗎??
我也要準備研究轉檔了,大概知道他們如何對應欄位

剛好REVIEW有一點點更新,提到如何避免3層的科目設置...我真的很不建議大家建3層科目....

GAAP

Originally posted by daily at 2005-11-23 01:47 PM:
在 AM 上，Transaction 的 Status 有四個：Posted, Cleared, Reconciled, Unrealized  (PMT 也是如此！)
依照會計基礎所採用的「權責發生制」，未發生權責者，記 Unrealized。
已經發生權責者，記 Posted。
再根據「現金收付制」，若是已經發生權責，且現金收付完成者，記 Cleared。
已經跟銀行的對帳單核對無誤者，記 Reconciled。

平常的交易，多是已經完成收付的 (意思就是：該給的給了，該收的也收了)，所以，就要記 Cleared.
若是收到的支票還沒兌現，就記 Posted，而不是 Unrealized。
先把下個月的 ADSL 費用記上者，就記 Unrealized。

當然啦，自己的帳簿，自己記得爽也看得懂，就可以了。哪來那麼多規矩...

其實必去分這麼多,如果有特別要分析的話,用posted就夠了.

GAAP

Originally posted by 溫開水 at 2005-11-23 11:19 AM:
請問有人成功的裝上中文化嗎？  我試過兩個檔都不成功(是直接執行嗎?)

我的機型是Treo650

謝謝

.
我Treo650,無法試...
很多人跟我反應Treo650無法中文化,自己用G-Mklocalizer&G-WLocalizer 解決吧

chrispinyang

Originally posted by GAAP at 2005-11-23 09:02 AM:


好佳在,我用PMT只有兩層,有了AM,還要3層嗎??
我也要準備研究轉檔了,大概知道他們如何對應欄位

剛好REVIEW有一點點更新,提到如何避免3層的科目設置...我真的很不建議大家建3層科目....

其實我實際用到的也只有兩層, 很少的一部分用到三層
其他的只是做為資產負債表/損益表的分類, subtotal 而已 (沒有實際拿來記帳用)

PipperL

熱騰騰的轉檔程式出爐囉!

<a href="http://forum.palmislife.com/viewthread.php?tid=58674" title="[分享] PMTexporter : PMT轉檔工具" target="_blank" >[分享] PMTexporter : PMT轉檔工具</a>

twhsi

昨天把tylpk，GAAP及自己的帳戶及帳項印出
以便比較分析

今天也由頭到尾看了這個討論串（GAAP的網頁為細看過，明天吧）
先應GAAP的要求作一下ULTRA MONEY及AM的優缺點比較

ULTRA MONEY有些特點
1. 可以輕易夫妻同時記帳，我買了兩個CODE，分裝在兩台PALM上
我們夫妻二人可以同時記帳，並在同步後相互看到對方的記帳內容
（聽說多人也可，所以我的兩歲兒子也可以加入 ：> ）

2. 傳票輸入介面不錯，之前大家討論的UI，在MS MONEY有一個做的不錯的地方是
輸入金額的計算機大而美（有點像PALM內建的計算機），不像AM的長得像DA計算機程式

3. 有一個FLAG功能，標示要注意的傳票。

ULTRA MONEY的缺點
1. 很貴 $39.95 買第二個CODE時 $27.95            
2. CLASS只有兩層
3. PC版要安裝MS MONEY，適用於原來用MS MONEY的人

結論
ULTRA MONEY對我來說有一個很好的地方是夫妻記帳功能
次佳是在傳票輸入介面不錯
其他的部份在研究之中

PS. 請問大家股票交易是如何設定帳戶及帳項的？？？？

seawind

Originally posted by 溫開水 at 2005-11-23 11:19 AM:
請問有人成功的裝上中文化嗎？  我試過兩個檔都不成功(是直接執行嗎?)

我的機型是Treo650

謝謝

ME TOO
請問有人用Treo 650 + AM 3.6 Build 1039版能中文化成功的嗎？
還是跟Build 1039版有關呢？

PipperL

一定是我太大驚小怪：
我用英文版，在輸入新資料時，如果先點選 PAYEE，那麼在 Category 會自動出現之次同Payee 最後一次的 category

這點說明書上沒提，不過還真是貼心(如果照AM 的輸入流程來的話:p)

GAAP

本人已成功轉到AM了....爽!!!!
耗時約2小時,想節省時間的人,本人已當完試驗品...請到PipperL的文章去看吧,有很多東西要注意..
http://forum.palmislife.com/view ... id=Jrqndj#pid495580

本人在轉檔後,核對帳本時,
另外發現AM的會計邏輯BUG:
發現AM,不能同時記借:費用,貸:收入,我會記這樣的帳,情形是:老闆招待吃飯,旅遊,這些是我花費的,但不是我出錢,所以我會借: XX費用,貸:其它收入......我想大家應該人這樣記帳吧....呵..........
不過,我已想到變通方法....這一點要跟作者反應....本人偶而會被人請客,所以這一點,一定要改進

也發現PMT有一個大BUG:
某一時點的資產負債表的金額與分類帳不同...這可是一大BUG....算了,反正本人要跳糟了,管它去死...|)

[ Last edited by GAAP on 2005-11-25 at 01:13 ]

PipperL

Originally posted by GAAP at 2005-11-25 01:00:

本人在轉檔後,核對帳本時,
另外發現AM的會計邏輯BUG:
發現AM,不能同時記借:費用,貸:收入,我會記這樣的帳,情形是:老闆招待吃飯,旅遊,這些是我花費的,但不是我出錢,所以我會借: XX費用,貸:其它收入......我想大家應該人這樣記帳吧....呵..........
不過,我已想到變通方法....這一點要跟作者反應....本人偶而會被人請客,所以這一點,一定要改進

[ Last edited by GAAP on 2005-11-25 at 01:13 ]

這個情況我的處理辦法是：(從以前 PMT 就這樣處理了)
開一個實帳戶(account)，名為「暫收付款」
然後支出時就從Cash or 信帳卡 轉到 這帳戶，老闆/公司的錢撥下來時就從這帳戶轉到 Cash/Bank。

這樣的好處是，因為這種款不應該算在自己的「支出」和「收入」，而實帳戶間的轉帳 AM 不會算支出或收入，所以剛好。

所以會變成：

吃飯結帳時： 現金轉到 暫收付款  XXXX 元 (Note: 老闆請吃飯代墊)
老闆撥錢時： 暫收付款轉到現金 XXXX 元 (Note: 老闆請吃飯吐錢了)

這個作法還有一個好處，常常老闆/公司會一個月給一次錢，可以算算 Net 對不對

而且有時萬一某些公司的款一拖好幾個月，也不怕忘記.....

GAAP

Originally posted by PipperL at 2005-11-25 01:31 AM:


這個情況我的處理辦法是：(從以前 PMT 就這樣處理了)
開一個實帳戶(account)，名為「暫收付款」
然後支出時就從Cash or 信帳卡 轉到 這帳戶，老闆/公司的錢撥下來時就從這帳戶轉到 Cash/Bank。

這樣的好處是，因為這種款不應該算在自己的「支出」和「收入」，而實帳戶間的轉帳 AM 不會算支出或收入，所以剛好。

所以會變成：

吃飯結帳時： 現金轉到 暫收付款  XXXX 元 (Note: 老闆請吃飯代墊)
老闆撥錢時： 暫收付款轉到現金 XXXX 元 (Note: 老闆請吃飯吐錢了)

這個作法還有一個好處，常常老闆/公司會一個月給一次錢，可以算算 Net 對不對

而且有時萬一某些公司的款一拖好幾個月，也不怕忘記.....

PipperL兄,你的觀念不對哦
1.如果是代收代付的錢,你有吃到飯,你可以這麼做,例如:你幫公司墊錢.
但你的例子是,老闆請你吃飯,所以如果你這麼做,會造成你收入及費用低估

2.只要有花費,一定要入帳,如果別人請的,你可以貸記其它收入(如:員工出國旅遊,聚餐...等等),這才是真正的會計原則(收入與費用配合原則)
金額累計起來是很可觀的,損益表才能達到充份揭露原則,也可詳實的記錄自己的花費(不管誰出錢的)

3.我的變通做法和你不同,不要用過渡科目,假設你用現金科目,雖然可以沖平,但會影響現金流量,我是直接用AM的會計邏輯BUG來抵制另一個BUG,也就是我只記一個科目,因為AM容許借貸可以不平衡|)

PipperL

我知道你我的討論分歧點了：

你的老闆指的是「吃飯店家」的老闆，
我的老闆指的是「公司老闆/上司」。

所以我們倆個在討論完全不同的兩件事 :p

不過我還是不太了解你所採取的變通方法，可以說明得再清楚一些嗎?

Originally posted by GAAP at 2005-11-25 01:44:


PipperL兄,你的觀念不對哦
1.如果是代收代付的錢,你有吃到飯,你可以這麼做,例如:你幫公司墊錢.
但你的例子是,老闆請你吃飯,所以如果你這麼做,會造成你收入及費用低估

2.只要有花費,一定要入帳,如果別人請的,你可以貸記其它收入(如:員工出國旅遊,聚餐...等等),這才是真正的會計原則(收入與費用配合原則)
金額累計起來是很可觀的,損益表才能達到充份揭露原則,也可詳實的記錄自己的花費(不管誰出錢的)

3.我的變通做法和你不同,不要用過渡科目,假設你用現金科目,雖然可以沖平,但會影響現金流量,我是直接用AM的會計邏輯BUG來抵制另一個BUG,也就是我只記一個科目,因為AM容許借貸可以不平衡|)

GAAP

Originally posted by PipperL at 2005-11-25 02:07 AM:
我知道你我的討論分歧點了：

你的老闆指的是「吃飯店家」的老闆，
我的老闆指的是「公司老闆/上司」。

所以我們倆個在討論完全不同的兩件事 :p

不過我還是不太了解你所採取的變通方法，可以說明得再清楚一些嗎?

1.不管是那一個老闆,我們指的是同一件事啦(公司的老闆)....不管誰請你,只要你有吃到飯(費用已發生了,要立即入帳),你都要借記:費用及貸記:收入.

2.變通做法:
借記:XX費用,存檔.(交易只輸入一個科目)
貸記:其它收入,存檔.(交易只輸入一個科目)

PS.會計上的收入及費用配合原則,有3點
1.因果關係直接配屬(如:為了領薪水,才會發生上班的加油錢,吃飯錢...等等)
2.系統合理分攤(如:折舊)
3.立即認列費用(如:吃飯)

PipperL

Originally posted by GAAP at 2005-11-25 02:29:


1.不管是那一個老闆,我們指的是同一件事啦(公司的老闆)....不管誰請你,只要你有吃到飯(費用已發生了,要立即入帳),你都要借記:費用及貸記:收入.

我現在更確定我們講的是兩件事了

我的想法是：
如果是公司老闆請我，我沒有掏出錢來，也沒有現金流量。GAAP的想法是有支出(我吃了飯)及收入(賺到一頓飯)，而且支出和收入同時發生，筆數相同，金額相同。事實上，我之前的做法是當作這交易沒有發生。因為我雖吃了飯，但並沒有支出。回老家吃飯也是同樣的道理。不算支出，但也不算收入。朋友請吃大餐也是如此。這種情況GAAP是使用收入直拉到支出的作法。好處是可以看得到「被請客」的收入，但缺點是許多交易無法計量(如回老家吃飯/朋友請吃一塊蛋糕 )等，只能計量可量化的數據(ex: 餐費是用人頭計算)。(這是GAAP指的老闆。)

公司老闆請客，我先墊錢，我有掏出錢來，有現金流量。拿錢出去和收錢進來不一定同時發生。我只是代墊(不管是不是我吃到飯還是一群同事吃到飯)，因為我只是代墊，不算支出，因此到時老闆月底給我錢也不算收入。但是我代墊的錢算是跑到一個過渡帳戶(資產)中。而且可能我開始付款時用信用卡，到最後公司給我錢時卻是用現金 or 進我 Bank，所以會影響到各個實帳戶的現金流量。這裡如果算進 income跟 expanse 時，會因為代墊的金額太大(如整部門聚餐的費用往往很大) 而造成在分析 income/expense 時失真。所以我選擇使用過渡帳戶，然後不計支出/收入。(這是我指的老闆。)

我現在的想法是，盡量把我自己 share 的(這裡的 share 指的不是出錢，而是我吃東西原本應該要支出的費用)這一份用 支出/收入處理(也就是 GAAP 說的)，然後只要有墊錢的部份用過渡帳戶處理，其中自己share的那一份(指的一樣是原本應該要支出的費用)用支出/收入去處理。這樣一來應該可以達到某個程度的「兼顧」，也可以避免 income/expense 的失真。

以上的想法和觀念可能不符合「正統會計」的想法及原則，歡迎指正

2.變通做法:
借記:XX費用,存檔.(交易只輸入一個科目)
貸記:其它收入,存檔.(交易只輸入一個科目)

PS.會計上的收入及費用配合原則,有3點
1.因果關係直接配屬(如:為了領薪水,才會發生上班的加油錢,吃飯錢...等等)
2.系統合理分攤(如:折舊)
3.立即認列費用(如:吃飯)

[ Last edited by PipperL on 2005-11-25 at 03:53 ]

daily

Originally posted by GAAP at 2005-11-25 01:00 AM:

本人在轉檔後,核對帳本時,
另外發現AM的會計邏輯BUG:
發現AM,不能同時記借:費用,貸:收入,我會記這樣的帳,情形是:老闆招待吃飯,旅遊,這些是我花費的,但不是我出錢,所以我會借: XX費用,貸:其它收入......我想大家應該没人這樣記帳吧....呵..........
不過,我已想到變通方法....這一點要跟作者反應....本人偶而會被人請客,所以這一點,一定要改進

[ Last edited by GAAP on 2005-11-25 at 01:13 ]

我認為，AM 應該把 借方科目/貸方科目 都開放出來給大家使用。

現在 AM 的作是，不管你的 Transaction type 是什麼， Acct: 處，一律不讓你選 Category；
另外，若是 Transaction type 選 Transfer，那麼，Catg: 處，就不讓你選 -- Split --
這是什麼世界呀！

當然 Transfer 還有變通方式，就是，Type 不要選 Transfer，請先用 Withdrawal
那麼，在 Catg: 處，可以選 Split，進到 Split 後，在 Catg: 處，再選 -- Show Accounts --。

我的建議是：
1.  Acct:處，比照 Split 的作法，在 -- Edit Accounts -- 下，增加一個 -- Show Categories -- ，
讓大家可以在「貸方科目」使用 收入類、費用類。 (這樣就解決 GAAP 兄的「收入轉費用」的問題了。)
2.  Type 選 Transfer 時，To: 處， -- Edit Accounts --  下，要增加一個 -- Split --。
3.  Type 選 Deposit 時，Catg: 處，要將 收入類 攞在前頭。不然，我花時間來選 Deposit，一點獎勵也沒有。

twhsi

請問一下
我介紹這個討論串給我的朋友
但他用的機子是WINCE的
不知CE上有無合適的記帳程式（可看財務報表的）