Một số vấn đề liên quan tới kế toán đa ngoại tệ

[hai2hai]

(*) Với mẫu phiếu thu, chi có thể vừa thanh toán bằng ngoại tệ (các loại:USD, UR,...), vừa nội tệ, ngoài các thông tin cơ bản của một chứng từ thì cần có một Grid/Table thể hiện việc hạch toán chi tiết:

|Mã chứng từ|Trạng thái|Diễn giải|Chiết khấu|Nợ còn phải trả|Thanh toán|Loại tiền|Tỷ giá| Tài khoản đối ứng|

(*) Nếu là Phiếu thu, căn cứ vào loại tiền-->Tài khoản ghi Nợ; Tài khoản đối ứng ghi Có.

(*) Nếu là Phiếu chi, căn cứ vào loại tiền-->Tài khoản ghi Có; Tài khoản đối ứng ghi Nợ.

Trong các chứng từ, nếu vào số âm (-) sẽ định khoản đảo.

Vì việc có nhiều loại tiền trong chi tiết thanh toán nên tài khoản ghi nợ, ghi có như Tuân nói sẽ được thiết kế nằm luôn trên dòng chi tiết thanh toán. TK đối ứng cũng vậy

Trường hợp thanh toán công nợ với khách hàng (phải thu: thu tiền bán hàng, phải trả: chi tiền cho hóa đơn khách hàng trả lại)

Cột "Chiết khấu thanh toán" mà Tuân nêu ở trên sẽ tùy trường hợp là thanh toán sớm hay thanh toán muộn (dựa theo PaymentTerms). Nếu thanh toán sớm (cho phải thu) thì nó có giá trị âm. Ngược lại, nếu là thanh toán muộn (cho phải thu) thì có giá trị dương.

Chi tiết hạch toán tài khoản sẽ như sau:

- S1: Sales Payment (In ra phiếu thu tiền)
Dr CashAcc (CurrencyID)
---Cr ReceivableAcc
Dr LatePaymentDiscountAcc (+)
or ---Cr EarlyPaymentDiscountAcc (-)

- S2: Sales Return Payment (In ra phiếu chi tiền)
Dr PayableAcc
---Cr CashAcc (CurrencyID)
Dr EarlyPaymentDiscountAcc (-)
or ---Cr LatePaymentDiscountAcc (+)

P/S: Ở trường hợp KH trả lại, tuy ít khi đề cập đến Chiết khấu thanh toán nhưng vẫn đề cập đến cho nó tổng quát (Giống như trường hợp phải trả NCC)

Mọi người cho ý kiến đóng góp thêm.

Dùng settlement discount hay là payment discount, cái nào là chính xác nhỉ? (hình như là settlement discount)

 

[Nguyễn Duy Tuân]

Dùng settlement discount hay là payment discount, cái nào là chính xác nhỉ? (hình như là settlement discount)

Khi nhận thanh toán
Nếu khoản discount khách hàng được hưởng do thanh toán sớm thì tên tài khoản sẽ là "Discounts Taken" thuộc nhóm (loại) Expense (hạch toán toán vào chi phí cho doanh nghiệp, chưa gồm thuế).

Nếu khách hàng phại chịu một khoản tiền (có thể do thanh toán muộn), số tiền đó được ghi vào tài khoản có tên là "Assess charges for late payment " thuộc nhóm (loại) Income (hạch toán vào doanh thu cho doanh nghiệp, chưa gồm thuế).

Ví dụ:

Khách hàng thanh toán cho 2 đơn hàng:
ĐH1:$2000, được hưởng chiết khấu thanh toán sớm $20
ĐH2:$3000, bị phạt tiền do thanh toán muộn $30

Hạch toán:

Dr: Cheque Account   5010 (=5000-20+30)
Dr: Discounts Taken                20
___Cr: Assess charges for late payment    30
___Cr: Accounts Receivable                 5000

Khi cty chi tiền thanh toán nợ
Nếu khoản discount cty được hưởng do thanh toán sớm thì tên tài khoản sẽ là "Discounts Given" thuộc nhóm (loại) Income (hạch toán vào doanh thu cho doanh nghiệp, chưa gồm thuế).

Nếu cty phại chịu một khoản tiền (có thể do thanh toán muộn), số tiền đó được ghi vào tài khoản có tên là "Pay charges for late payment" thuộc nhóm (loại) Expense (hạch toán vào chi phí cho doanh nghiệp, chưa gồm thuế).

Cty thanh toán cho 2 đơn hàng:
ĐH1:$2000, được hưởng chiết khấu thanh toán sớm $20
ĐH2:$3000, bị phạt tiền do thanh toán muộn $30

Hạch toán:

Dr: Accounts Payable                5000
Dr: Pay charges for late payment    30
___Cr: Discounts Given                        20
___Cr: Cheque Account                    5010 (=5000-20+30)

Với phiếu thu, chi theo em ở phần nhập chi tiết cho từng khoản tiền (gồm các số tiền, loại tiền theo các đơn hàng hay đối tượng thu/chi) có 2 cột đã phản ánh được tính Dr và Cr của định khoản rồi.

Với phiếu khách hàng thanh toán nợ
Cột "Loại tiền" sẽ chỉ ra account nào được ghi Nợ (Dr) (đã setup trong danh mục tiền tệ - DMTT)
Cột số tiền >0, ngầm định ghi Có(Cr) cho account 131 (ví dụ vậy)
Số tiền trên cột -Discount/+Charge, nếu được ghi vào account đã thiết lập trong "Tham số hệ thống..."

Với phiếu thu tiền, nhất thiết phải có cột TKĐƯ, cột này sẽ được ghi bên Có, Ghi Nợ cho các account theo cột "Loại tiền" (tìm đc account trong DMTT).

...

Em nghĩ thiết kế như trên là ổn, vẫn đảm bảo được sự bao quát về định khoản mà cấu trúc form gọn gàng hơn.

 

[hai2hai]

He he, có lẽ Tuân đang nói tới cái tên tiếng anh của Tài khoản chiết khấu thanh toán cho 2 trường hợp. Còn anh đang tìm cái từ nào ngăn ngắn để viết trên Database (FieldName). Anh dùng LateSettlementDiscountAccID (Link từ bảng Account Master sang) thay cho cụm từ: "Pay charges for late payment" (Kể ra "LateSettlementDiscountAccID" vẫn dài nhỉ)

Hệ thống Tài khoản dùng ID (Long) làm khóa chính thay cho AccountCode. Làm như thế sẽ có thể áp dụng cho nhiều nước ko dùng tới 111, 112, như của mình.

 

[Nguyễn Duy Tuân]

He he, có lẽ Tuân đang nói tới cái tên tiếng anh của Tài khoản chiết khấu thanh toán cho 2 trường hợp. Còn anh đang tìm cái từ nào ngăn ngắn để viết trên Database (FieldName). Anh dùng LateSettlementDiscountAccID (Link từ bảng Account Master sang) thay cho cụm từ: "Pay charges for late payment" (Kể ra "LateSettlementDiscountAccID" vẫn dài nhỉ)

Hệ thống Tài khoản dùng ID (Long) làm khóa chính thay cho AccountCode. Làm như thế sẽ có thể áp dụng cho nhiều nước ko dùng tới 111, 112, như của mình.

Vâng, tên thế này thì dài thật . Theo em dù nước ngoài không ép đặt mã TK nhưng mình làm PM vẫn nên quy ước cho nó.

Account List:

|AccountID (Long)|AccountName (VarChar)|ShortName(VarChar)|AccountTypeID(Long)|IsMoney (BOOL)|

Như chú MYOB, quy ước đầu mã:
1 - Asset
2 - Liability
3 - Equity
4 - Income
5 - Cost of sales
6 - Expense
8 - Other Income
9 - Other Expense

(không dùng đầu 7 .

 

[hai2hai]

Vâng, tên thế này thì dài thật . Theo em dù nước ngoài không ép đặt mã TK nhưng mình làm PM vẫn nên quy ước cho nó.

Account List:

|AccountID (Long)|AccountName (VarChar)|ShortName(VarChar)|AccountTypeID(Long)|IsMoney (BOOL)|

Như chú MYOB, quy ước đầu mã:
1 - Asset
2 - Liability
3 - Equity
4 - Income
5 - Cost of sales
6 - Expense
8 - Other Income
9 - Other Expense

(không dùng đầu 7 .

Bắt đầu đi xa chủ đề rồi đây

Ở các phần mềm lớn, các đầu mã trên được sử dụng danh mục AccountGroup

Tức là, trong hệ thống ko dùng 1 PK nào là kiểu varchar hết, chỉ dùng kiểu Long thôi.

Ví dụ: Trong tb_M_Account sẽ có:

ID (PK), AccountGroupID (FK), Code, Name, v.v...

Trong đó AccountGroupID là FK, link với bảng tb_M_AccountGroup

Trong tb_M_AccountGroup sẽ có:

ID (PK), Code, Name,....

Data: (Khác với MyOb mà Tuân nêu ở trên)

1 01 Loại tài khoản 1 - Tài sản ngắn hạn
2 02 Loại tài khoản 2 - Tài sản dài hạn
3 03 Loại tài khoản 3 - Nợ phải trả
4 04 Loại tài khoản 4 - Vốn chủ sở hưu
5 05 Loại tài khoản 5 - Doanh thu
6 06 Loại tài khoản 6 - Chi phí SXKD
7 07 Loại tài khoản 7 - Thu nhập khác
8 08 Loại tài khoản 8 - Chi phí khác
9 09 Loại tài khoản 9 - Xác định kết quả kinh doanh
10 10 Loại tài khoản 0 - Tài khoản ngoại bảng

Ở các phần mềm lớn, table nào cũng đều có trường Code (Unique Index) cả - nhưng cái này thì có thể sửa thoải mái (ví dụ: Mã KH, Mã NCC, Mã TK, Mã hàng hóa, Mã Tài sản,...), nhưng ko dùng nó để làm PK vì khi join các tables với nhau thì nếu join qua ID có kiểu Long mới nhanh. Đây cũng là cách thiết kế CSDL mà Erwin hoặc phần lớn các phần mềm công cụ thiết kế CSDL giới thiệu (Thậm chí các ví dụ cơ bản của M$ cũng làm như thế). Tuy nhiên, không hiểu sao ở VN ko thấy phần mềm nào design theo kiểu này cả. Có rất nhiều người hỏi tại sao lại dùng ID kiểu long, sao ko dùng code (varchar) luôn đi,... )

Thôi, quay lại vấn đề chính:
Mục đích của câu hỏi là tên các trường khóa FK trong chi tiết chứng từ thanh toán, trong đó có 4 ID về tài khoản:

Payment Detail table:

ID (PK) <-- LineNo
-------------------------------------------
TransID (FK) <-- Hóa đơn cần thanh toán
CurrencyID (FK)
ExchangeRate
DrAccountID (FK) <--- 4 trường này sẽ link với tb_M_Account
CrAccountID (FK) <---
DrSettlementDiscountAccountID (FK) <-- Mục đích: tìm cái tên cho cái trường này
CrSettlementDiscountAccountID (FK) <-- Mục đích: tìm cái tên cho cái trường này
DiscountAmount <-- Settlement Discount Amount in based currency
DebtAmount (Display)
Amount <-- Payment Amount in based currency

Muốn hiển thị tiền theo ngoại tệ nào thì chỉ cần:
(Amount * 1 / ExchangeRate) AS AmountFC
Trường hợp ExchangeRate = 1 thì AmountFC = Amount (và CurrencyID chính là Based Currency).

Khi Select ra Grid, ra báo cáo thì ta muốn hiện thì cái gì, chỉ cần tạo Fake Field kiểu như trên. Không nhất thiết phải có trường AmountFC trong table như nhiều người suy nghĩ.

 

[hai2hai]

Sau khi đọc lại SAP R3, FI & CO (TFIN 10) thì phát hiện ra SAP họ dùng từ "Cash Discount" cho "Chiết khấu thanh toán" (chứ nó ko dùng Settlement Discount như đã ... nghĩ ở trên).

Đối với Gross Procedure (Including Taxes) thì dùng Cash Discount granted và Cash Discount taken. Cụ thể là trong Accounts Receivables thì dùng Cash Discount granted, còn trong Accounts Payable thì dùng Cash Discount taken.

Đối với Net Procedure (taxes not included) thì họ dùng Cash Discount Clearing và Lost Cash Discount

Còn cái khoản tiền chiết khấu theo đồng tiền cơ sở thì nó gọi là Cash Discount base Amount

Có lẽ phần mềm to nhất thế giới về ERP này ko viết sai nhỉ.

 

[hai2hai]

Hic, giờ mới đọc cái phần edit lại của Kiệt.

To: Anh hai2hai
Ý kiến về việc chỉnh sửa chứng từ:
Em cũng là dân kế toán, tuy nhiên em cũng không đồng tình với vấn đề chỉnh sửa chứng từ đã Posted,/Released, hoặc đã ghi sổ cái (tùy theo khái từng loại chứng từ). Nếu User làm sai, nhập sai thì phải điều chỉnh bằng một chứng từ khác, hoặc làm cũng với nghiệp vụ ấy nhưng ngược lại (bút toán đảo).

Nói vậy, nhưng cũng có mấy lần (nghĩa là nhiều lần) em phải chọc thẳng vào SQL và làm động tác (Update....set ...., Delete * from....). Nói vậy là anh biết rồi. Có những lúc chứng từ làm sai, nhưng mình không muốn thấy nó hiện hữu trên cõi đời (database) này. Ví dụ, nhân viên em hạch toán một nghiệp vụ với số tiền 300 triệu VND, vậy mà lại hạch toán 300 triệu USD mới chết chứ! Thế là tự nhiên lên Balance sheet nhìn .... không chịu được.

Đã là làm dâu trăm họ thì phải đáp ứng cả những nơi theo quy chuẩn lẫn những nơi ... ko thích sự chuẩn tắc (hoặc ko hiểu gì về nghiệp vụ). (Nếu ko thì ko bán được )

Cái mà em thấy hay nhất của phần mềm (hình như là Solomon thì phải). Nó cho phép cấp Admin có quyền chuyển trạng thái của chứng từ (nôm na gọi là bật cờ xanh). Ví dụ chuyển từ POSTED sang OPEN, RELEASED sang OPEN, PAID sang OUTSTANDING,etc. Cái hay ở chỗ, khi chuyển như vậy thì tất cả các động thái liên quan và record liên quan đều sẽ undo lại hết, coi như bút toán này chỉ vừa mới được tạo ra và lưu thôi chứ chưa POSTED; dĩ nhiên bút toản này sẽ được chuyển sang một trạng thái khác (ví dụ RE-OPEN chẳng hạn.). Sau đó khi chỉnh sửa xong, ta post lại chứng từ, các động tác như cập nhật chứng từ, tính số dư, lưu phát sinh gì gì đó thì cũng giống như một bút toán/nghiệp vụ bình thường và được gọi ra chạy khi ta ấn nút Lưu/Post/Release.

Không chỉ có phần mềm Solomon đâu. Rất nhiều phần mềm cho phép UnPost.

Tuy nhiên Kiệt cứ thử sửa lại chứng từ hóa đơn mua, bán hàng, v.v...

Ví dụ: Sửa ngày chứng từ, sửa giá cả, sửa số lượng, thay mặt hàng bằng mặt hàng khác, xóa mặt hàng, sửa loại tiền tệ đối với hóa đơn đã thanh toán hết, sửa mã kho phiếu nhập khi hàng trong kho đã xuất hết, sửa mã đối tượng công nợ, v.v...
Sau đó, thử nghĩ về sự ảnh hưởng tới: công nợ đối tượng, hàng tồn kho về lượng và giá trị, v.v...

 

[infotech]

Sao cái topic hấp dẫn này không tiếp tục nhỉ

 

[hai2hai]

Mục đích đã đạt được (#46) nên dĩ nhiên là tới hồi kết thúc rồi mà. Hôm nay đọc lại cũng thấy... hấp dẫn . Có lẽ phải lưu lại link này để tham khảo lại.