Một số vấn đề liên quan tới kế toán đa ngoại tệ (1 người xem)

[hai2hai]

Giới thiệu:

Trong quá trình kinh doanh thương mại, đặc biệt trong bối cảnh môi trường hợp tác kinh tế mang tính toàn cầu thì vấn đề "đa ngoại tệ" trở thành 1 bài toán bức xúc về quản lý và có nhu cầu khá lớn đối với các ứng dụng quản lý.

Ở đó, tại một công ty có thể có các giao dịch kinh tế phát sinh (như: báo giá, hợp đồng, đơn đặt hàng (mua và bán), hóa đơn mua/bán hàng...) được thể hiện theo các loại ngoại tệ khác nhau (mỗi giao dịch được thực hiện theo 1 loại ngoại tệ). Việc thanh toán cho các hợp đồng, hóa đơn mua/bán hàng cũng sẽ đa dạng với các trường hợp sau:

Trường hợp 1: Thanh toán cho 1 hóa đơn
a) Sử dụng loại ngoại tệ trên hóa đơn để thanh toán (ví dụ: Hóa đơn bán hàng thể hiện bằng USD, thanh toán cũng bằng USD)

b) Sử dụng loại ngoại tệ khác để thanh toán cho hóa đơn (ví dụ: Hóa đơn bán hàng thể hiện bằng USD, thanh toán bằng EUR HOẶC VND...)

c) Sử dụng 2 (hoặc nhiều hơn 2) loại ngoại tệ để thanh toán (ví dụ: Hóa đơn bán hàng thể hiện bằng USD, thanh toán bằng EUR VÀ VND...)

Trường hợp 2: Thanh toán cho 2 hoặc nhiều hơn 2 hóa đơn cùng 1 lúc

Ví dụ: Có 2 hóa đơn, hóa đơn 1 thể hiện tiền USD, hóa đơn 2 thể hiện tiền EUR

a) Sử dụng loại ngoại tệ tương ứng với từng hóa đơn
Ví dụ: Sử dụng 2 loại ngoại tệ tương ứng là USD và EUR để thanh toán cho từng hóa đơn (trên cùng 1 phiếu thu/chi)

b) Sử dụng 1 loại ngoại tệ để thanh toán cho cả 2 hóa đơn trên
Ví dụ: Có thể sử dụng hoặc USD hoặc EUR hoặc thậm chí đồng tiền cơ sở VND

c) Sử dụng nhiều loại ngoại tệ (kể cả ngoại tệ ko tương ứng với hóa đơn) để thanh toán
Ví dụ: Có thể sử dụng VND và YEN để thanh toán cho 2 hóa đơn trên

Bài toán liên quan tới đa nguyên tệ:

1. Thiết kế phiếu thu, phiếu chi cho phù hợp với các trường hợp trên (Chú ý các giá trị liên quan tới hóa đơn như tổng giá trị, đã thanh toán, chiết khấu thanh toán, tiền thanh toán và phần tổng tiền thanh toán ở dưới chứng từ trên các phiếu thu, phiếu chi)
2. Công nợ được theo dõi theo nhiều loại ngoại tệ (Chú ý: Dư đầu kỳ, cuối kỳ, phát sinh tăng, phát sinh giảm của từng đối tượng công nợ đều liên quan tới ngoại tệ. Ngoài ra, còn có báo cáo theo 1 loại ngoại tệ đã quy đổi để báo cáo cho đơn vị ở nước quản lý)
3. Các quỹ tiền mặt, tiền gửi tương ứng (111,112) (Cái này thì dễ rồi)
4. Đánh giá chênh lệch tỷ giá (giữa thời điểm hóa đơn và thời điểm thanh toán). Cái này thì kế toán nhà ta quen cả rồi.

Mọi người thử xem xét và đưa ra các tình huống khác, rồi trao đổi các giải pháp ở đây nhé.

Cheers!

 

[ptm0412]

Xin bàn trước về Database:
1. Trong dữ liệu hàng ngày thêm 1 trường mã Tiền tệ, 1 trường tỷ giá, 1 trường số tiền NT, 3 trường này sẽ xuất hiện trên form bán hàng (Xuất HĐ) và form thu tiền (111 và 112).
2. Trong table công nợ thêm 1 trường mã Tiền tệ và 2 trường số dư ĐầuKỳ, số dư CuốiKỳ bằng ngoại tệ.
3. trong table danh mục TK cũng thêm 1 trường mã Tiền tệ, số dư ĐK NT, cuối kỳ NT
3. tất nhiên là thêm 1 table Danh mục tiền tệ trong đó có cả VND và là Master cho mấy table trên.

Có các trường này, tôi nghĩ công việc sẽ bớt suy nghĩ rất nhiều.
Nguyên tắc là quy về 1 đơn vị tiền tệ chuẩn (có thể là VND), tỷ giá cũng là quy về đơn vị chuẩn này.
Nhưng bớt rồi không phải là hết chuyện, để nghĩ tiếp.

 

[hai2hai]

Xin bàn trước về Database:
1. Trong dữ liệu hàng ngày thêm 1 trường mã Tiền tệ, 1 trường tỷ giá, 1 trường số tiền NT, 3 trường này sẽ xuất hiện trên form bán hàng (Xuất HĐ) và form thu tiền (111 và 112).

Chỉ cần 2 trường:

- CurrencyID
- ExchageRate <-- trường này sẽ lấy từ bảng "ExchangeRate History" dựa trên ngày chứng từ và ngày lịch sử.

Trên hóa đơn bán hàng, có nhiều con số tiền đều phải thể hiện theo theo loại ngoại tệ đã chọn (đơn giá, giảm giá, chiết khấu, thuế GTGT, các giá trị khác, tổng tiền hàng, tổng tiền hóa đơn, số tiền thanh toán (trường hợp thanh toán ngay)). Vì thế không cần trường số tiền ngoại tệ (vì 1 trường đó thì ko đủ). Khi lưu vào CSDL, ta vẫn lưu như bình thường, chỉ cần kèm thêm 2 trường ở trên. Lúc hiển thị thì chỉ cần lấy các giá trị tiền trên hóa đơn (theo đồng tiền cơ sở) * tỷ giá (và format theo từng loại ngoại tệ)

Về phiếu thu, phiếu chi: Mọi người chú ý là sẽ thanh toán chi tiết cho nhiều chứng từ trên cùng 1 phiếu thu/chi (có thể mỗi dòng 1 loại ngoại tệ khác nhau). Vì thế, ngoài phần header của phiếu thu, phiếu chi, còn phải thể hiện ngoại tệ trên từng dòng chứng từ nữa. (Đọc kỹ lại các trường hợp nêu ở #1)

 

[ptm0412]

Xin nói rõ lại là 3 trường thêm vào, không kể 1 trường "số tiền" có sẵn, nay gọi lại tên là "số tiền theo đơn vị TT quy chuẩn".
Trên hoá đơn bán hàng, các loại hai2hai kể như đơn giá, chiết khấu, thành tiền,... tại sao không tự làm đơn giản bằng cách chọn 1 loại ngoại tệ duy nhất? khi người khách hàng trả, họ có thể trả bằng 1 hay nhiều loại NT, giống hoặc không giống trên hoá đơn, nhưng hoá đơn chỉ có 1 loại tiền tệ.

Hơn nữa các khoản chiết khấu, giảm giá, chỉ nằm trong hợp đồng, không nhất thiết ghi vào hoá đơn.
nếu bắt buộc, thì chỉ ghi vào 1 trường discountRate, phần còn lại (phải thanh toán) sẽ là tính toán trên đơn giá, số lượng, DiscountRate ra kết quả không cần tách ra.

 

[cadafi]

Về phiếu thu, phiếu chi: Mọi người chú ý là sẽ thanh toán chi tiết cho nhiều chứng từ trên cùng 1 phiếu thu/chi (có thể mỗi dòng 1 loại ngoại tệ khác nhau). Vì thế, ngoài phần header của phiếu thu, phiếu chi, còn phải thể hiện ngoại tệ trên từng dòng chứng từ nữa. (Đọc kỹ lại các trường hợp nêu ở #1)

Việc này em thấy thực tế khó thực hiện. Vì mỗi một phiếu thu, phiếu chi chỉ nên ứng với một loại ngoại tệ. Ví dụ: Hệ thống tài khoản có 1111USD, 1111VND, 1111ERO, 1111CNY thì làm sao chỉ làm một phiếu chi/ một phiếu thu cho cả list ngoại tệ thế kia. Khi đó việc đọc số ra chữ nhìn là đã phát kinh rồi. Chưa nói đến việc hạch toán định khoản thu chi.

Như phần Mềm ACCPAC rất hay về mảng Multicurrency tuy nhiên nó cũng chỉ cho hạch toán tương ứng một nghiệp vụ bên module con (thu/Chi, công nợ) là một loại tiền tệ mà thôi. Nếu muốn hạch toán nhiều loại ngoại tệ thì phải tách ra làm nhiều nghiệp vụ tương ứng.

Ps: đang tìm lại cái schema database của ACCPAC, tìm xong sẽ gửi anh xem thử nhé!

 

[ptm0412]

ExchageRate <-- trường này sẽ lấy từ bảng "ExchangeRate History" dựa trên ngày chứng từ và ngày lịch sử.

Ý tưởng này có vẻ hay ở chỗ tổ chức CSDL tốt hơn, nhưng không hẳn là tốt nhất. Vì theo hợp đồng mua bán, 2 bên đồng ý sẽ lấy tỷ giá cuả 1 tổ chức tín dụng nào đó (ngân hàng chẳng hạn) tại thời điểm nào đó làm tỷ giá chấp nhận thanh toán. Nếu trong ngày thu tiền của 2 khách hàng khác nhau, KH thứ nhất thoả thuận lấy tỷ giá của ngân hàng A, KH thứ 2 lấy tỷ giá của ngân hàng B, thì dữ liệu ghi vào ExchangeRateHistory là tỷ giá nào?

 

[hai2hai]

Ý tưởng này có vẻ hay ở chỗ tổ chức CSDL tốt hơn, nhưng không hẳn là tốt nhất. Vì theo hợp đồng mua bán, 2 bên đồng ý sẽ lấy tỷ giá cuả 1 tổ chức tín dụng nào đó (ngân hàng chẳng hạn) tại thời điểm nào đó làm tỷ giá chấp nhận thanh toán. Nếu trong ngày thu tiền của 2 khách hàng khác nhau, KH thứ nhất thoả thuận lấy tỷ giá của ngân hàng A, KH thứ 2 lấy tỷ giá của ngân hàng B, thì dữ liệu ghi vào ExchangeRateHistory là tỷ giá nào?

Giá trị "Exchange Rate" lấy mặc định từ ExchangeRateHistory, sau đó cho sửa lại đúng ở thời điểm giao dịch mà (tức là vẫn có trường Exchange Rate trên chứng từ). Nhiều khi tỷ giá ko thay đổi mà cứ phải nhập đi nhập lại. Về sau, có chức ExchangeRateHistory tự động cập nhật biến động tỷ giá từ những nơi mà Ngân hàng công bố (Website,...). (hiện nay có nhiều nơi đã làm như thế rồi)

 

[hai2hai]

Việc này em thấy thực tế khó thực hiện. Vì mỗi một phiếu thu, phiếu chi chỉ nên ứng với một loại ngoại tệ. Ví dụ: Hệ thống tài khoản có 1111USD, 1111VND, 1111ERO, 1111CNY thì làm sao chỉ làm một phiếu chi/ một phiếu thu cho cả list ngoại tệ thế kia. Khi đó việc đọc số ra chữ nhìn là đã phát kinh rồi. Chưa nói đến việc hạch toán định khoản thu chi.

Như phần Mềm ACCPAC rất hay về mảng Multicurrency tuy nhiên nó cũng chỉ cho hạch toán tương ứng một nghiệp vụ bên module con (thu/Chi, công nợ) là một loại tiền tệ mà thôi. Nếu muốn hạch toán nhiều loại ngoại tệ thì phải tách ra làm nhiều nghiệp vụ tương ứng.

Ps: đang tìm lại cái schema database của ACCPAC, tìm xong sẽ gửi anh xem thử nhé!

Cố gắng tìm schema database của ACCPAC nhé. Đúng là các PM nước ngoài nhiều khi chưa chắc đã có.

Về bản chất, phân thân của phiếu thu/chi phải theo 1 loại ngoại tệ duy nhất mà thôi.
Đó chính là câu mà Hải nói: Chú ý phần tổng tiền.

Tuy nhiên, phần chi tiết thanh toán thì vẫn phải đa ngoại tệ (phải hiển thị thêm cột nữa là đồng tiền thanh toán chính và chỉ lấy tổng tiền theo cột đó)

Tại sao lại có chuyện trả tiền bằng nhiều loại tiền tệ:

Ví dụ: Khi 1 khách hàng đến trung tâm thương mại. Họ mua 1 mặt hàng giá 120$. Trong túi của họ chỉ có 100$, còn lại là tiền Việt. Họ sẽ trả tiền 100$ và số 20$ lẻ còn lại họ trả bằng tiền việt (tức là cty thu vừa tiền $, vừa tiền việt). Chuyện này là ko hiếm.

 

[ptm0412]

Việc này em thấy thực tế khó thực hiện. Vì mỗi một phiếu thu, phiếu chi chỉ nên ứng với một loại ngoại tệ. Ví dụ: Hệ thống tài khoản có 1111USD, 1111VND, 1111ERO, 1111CNY thì làm sao chỉ làm một phiếu chi/ một phiếu thu cho cả list ngoại tệ thế kia. Khi đó việc đọc số ra chữ nhìn là đã phát kinh rồi. Chưa nói đến việc hạch toán định khoản thu chi.

Phần thu tiền Khách hàng rõ ràng là phải tách ra từng dòng cho từng loại ngoại tệ rồi, không bàn cãi. Xử lý dữ liệu là máy làm nên càng rõ ràng càng tốt.
Còn về báo cáo các loại:
- phiếu thu chi ghi chi tiết theo từng ngoại tệ, nhưng tổng tiền tính theo đơn vị quy chuẩn.
- báo cáo tài khoản KT, báo cáo công nợ, bảng cân đối PS…. quy hết về đơn vị tiền tệ chuẩn.
Chỉ có bảng đối chiếu công nợ và báo cáo chi tiết công nợ từng KH mới chi tiết đến loại ngoại tệ, nhưng kết số dư theo tiền tệ chuẩn phải bằng số dư của TK công nợ Kế toán.

Đó chính là câu mà Hải nói: Chú ý phần tổng tiền.

vậy nên trường số tiền theo đơn vị tiền tệ chuẩn vẫn còn cần thiết.

 

[hai2hai]

Xin nói rõ lại là 3 trường thêm vào, không kể 1 trường "số tiền" có sẵn, nay gọi lại tên là "số tiền theo đơn vị TT quy chuẩn".
Trên hoá đơn bán hàng, các loại hai2hai kể như đơn giá, chiết khấu, thành tiền,... tại sao không tự làm đơn giản bằng cách chọn 1 loại ngoại tệ duy nhất? khi người khách hàng trả, họ có thể trả bằng 1 hay nhiều loại NT, giống hoặc không giống trên hoá đơn, nhưng hoá đơn chỉ có 1 loại tiền tệ.

Hơn nữa các khoản chiết khấu, giảm giá, chỉ nằm trong hợp đồng, không nhất thiết ghi vào hoá đơn.
nếu bắt buộc, thì chỉ ghi vào 1 trường discountRate, phần còn lại (phải thanh toán) sẽ là tính toán trên đơn giá, số lượng, DiscountRate ra kết quả không cần tách ra.

- Chiết khấu, giảm giá được ghi ngay trên hóa đơn bán hàng (trên màn hình hóa đơn bán hàng thì đúng hơn, in ra thì có thể ko cần). Tiền thuế (GTGT,...) thì phải hiển thị theo đúng loại ngoại tệ.

- Về việc: Trên hoá đơn bán hàng, các loại hai2hai kể như đơn giá, chiết khấu, thành tiền,... tại sao không tự làm đơn giản bằng cách chọn 1 loại ngoại tệ duy nhất?

Trong CSDL, dữ liệu của hóa đơn chỉ cần hiển thị 1 loại tiền tệ là đồng tiền cơ sở mà thôi. Muốn hiển thị ngoại tệ, chỉ cần * ExchangeRate lưu trên chứng từ là xong.

Tóm lại: Ở đâu cũng cho cái CurrencyID và ExchangeRate, các con số, giá trị vẫn giữ nguyên. Muốn hiển thị theo đồng tiền nào thì chỉ cần Giá trị * ExchangeRate

Ví dụ:

CurrencyID| CurrencyCode | ExchageRate
1 | VND | 1
2 | USD | 1/16,500
3 | EUR | 1/23,000

Trên tất cả các chứng từ, để hiển thị mọi giá trị có mặt trên chứng từ thì chỉ cần lấy Giá trị * ExchageRate của từng loại NT tương ứng. Nếu chọn NT là VND thì:

Số tiền (VND) = Giá trị (Tiền cơ sở) * 1 (vẫn là chính nó nếu VND là tiền cơ sở)

Khi làm các báo cáo theo NT, chỉ cần lấy các con số từ các chứng từ * ExchageRate (có trên chứng từ).

Về bản chất, phần thân của phiếu thu/chi phải theo 1 loại ngoại tệ duy nhất mà thôi.
Đó chính là câu mà Hải nói: Chú ý phần tổng tiền.

vậy nên trường số tiền theo đơn vị tiền tệ chuẩn vẫn còn cần thiết.

Chính xác là chỉ cần lưu số tiền theo đơn vị tiền tệ cơ sở (Ví dụ: VND), rồi cứ nhân với ExchageRate của NT chính thức (duy nhất) trên phiếu thu/chi (thường là ngoại tệ của hóa đơn thứ nhất hoặc hóa đơn có giá trị lớn nhất, hoặc theo đồng tiền cơ sở) mặc cho phần chi tiết thanh toán có thể theo ngoại tệ gì.

Xin bàn trước về Database:
2. Trong table công nợ thêm 1 trường mã Tiền tệ và 2 trường số dư ĐầuKỳ, số dư CuốiKỳ bằng ngoại tệ.

Đúng rồi. Việc kết chuyển số dư công nợ phải theo từng loại ngoại tệ. Vấn đề này sẽ làm cho việc kết chuyển sẽ chậm đi so với khi ko quản lý theo ngoại tệ.

 

[ptm0412]

Trong CSDL, dữ liệu của hóa đơn chỉ cần hiển thị 1 loại tiền tệ là đồng tiền cơ sở mà thôi. Muốn hiển thị ngoại tệ, chỉ cần * ExchangeRate lưu trên chứng từ là xong.

Sure! Mình muốn nói thế, nhưng tại bài trên Hải nói chỉ 1 trường số tiền ngoại tệ là không đủ! Chắc hiểu nhầm rồi.

 

[cadafi]

- Về việc: Trên hoá đơn bán hàng, các loại hai2hai kể như đơn giá, chiết khấu, thành tiền,... tại sao không tự làm đơn giản bằng cách chọn 1 loại ngoại tệ duy nhất?

Trong CSDL, dữ liệu của hóa đơn chỉ cần hiển thị 1 loại tiền tệ là đồng tiền cơ sở mà thôi. Muốn hiển thị ngoại tệ, chỉ cần * ExchangeRate lưu trên chứng từ là xong.

Tóm lại: Ở đâu cũng cho cái CurrencyID và ExchangeRate, các con số, giá trị vẫn giữ nguyên. Muốn hiển thị theo đồng tiền nào thì chỉ cần Giá trị * ExchangeRate

Ví dụ:

CurrencyCode | ExchageRate
VND | 1
USD | 1/16,500
EUR | 1/23,000

Trên tất cả các chứng từ, để hiển thị mọi giá trị có mặt trên chứng từ thì chỉ cần lấy Giá trị * ExchageRate của từng loại NT tương ứng.

Khi làm các báo cáo theo NT, chỉ cần lấy các con số từ các chứng từ * ExchageRate.
Chính xác là chỉ cần số tiền theo đơn vị tiền tệ cơ sở (Ví dụ: VND), rồi cứ nhân với ExchageRate của NT chính thức trên phiếu thu/chi

Em kết cái cách này đấy anh hai2hai, đây cũng là cách mà ACCPAC làm đấy.

 

[hai2hai]

Em kết cái cách này đấy anh hai2hai, đây cũng là cách mà ACCPAC làm đấy.

Mình đã phải mất 1 hôm ngồi đọc lại sách SAP R3 về FI đã từng học từ lâu, tham khảo thêm SAP B1 và 1 số sản phẩm nước ngoài khác. Tuy nhiên, phải làm đơn giản hóa nó đi vì nếu phức tạp hóa sợ ko release được sản phẩm đúng hạn

Mình nghĩ chắc sẽ còn những trường hợp khác mà chưa gặp phải. Cũng mong trao đổi thêm với mọi người để những người biết rồi thì biết thêm nữa, những người chưa biết thì có cơ hội tìm hiểu.

Ngoài bài toán tính giá vốn tức thời (đặc biệt trong trường hợp dữ liệu lớn, trường hợp sửa/xóa chứng từ sẽ xảy ra rất nhiều trường hợp), bài toán "đa ngoại tệ", về sau mình sẽ giới thiệu các vấn đề, trường hợp liên quan tới bài toán "đa đơn vị tính" (nhất là trong những trường hợp lắp ráp tháo dỡ, sản xuất).

 

[ptm0412]

Nhân nói đến chủ đề cũ về giá vốn tức thời, ở chủ đề này cũng phải quan tâm vấn đề làm tròn số khi lấy số tiền cơ sở nhân tỷ giá (theo thí dụ của Hải thì là phép chia vì là nhân với 1/16.000), nếu không khéo sẽ còn dư nợ 1, 2 cents

 

[hai2hai]

Nhân nói đến chủ đề cũ về giá vốn tức thời, ở chủ đề này cũng phải quan tâm vấn đề làm tròn số khi lấy số tiền cơ sở nhân tỷ giá (theo thí dụ của Hải thì là phép chia vì là nhân với 1/16.000), nếu không khéo sẽ còn dư nợ 1, 2 cents

Đúng rồi, ở danh mục tiền tệ, phải có lựa chọn định dạng format cho từng loại tiền tệ. Chính vì suy nghĩ 1 cách tổng quát, bao hàm trường hợp đồng tiền cơ sở không phải là VND mà là các ngoại tệ khác nên lần trước khi tính giá vốn mới nhắc tới chuyện làm tròn số như thế nào cho đúng.

Ví dụ: VND thì làm tròn tới hàng đơn vị và có format như sau (#,##0), USD hoặc các ngoại tệ khác thì làm tròn tới n dấu thập phân và có forrmat như sau (#,##0.00). Việc thống nhất định dạng và làm tròn (thông thường 2 cái đó đi cùng với nhau) phải được thống nhất cho từng ngoại tệ trên toàn chương trình.

Ví dụ:

Khi hiển thị số tiền theo ngoại tệ, ta sẽ làm như sau:

ExchangeRate = objCurrency.ExchangeRate(CurrencyID)
'// Trường hợp CurrencyID là BasedCurrency (Tức là có ExchangeRate =1) thì không cho phép nhập ExchangeRate trên màn hình chứng từ nữa.

strCurrencyFormat = objCurrency.NumberFormat
curSymbol = objCurrency.Symbol '// đ, $, ... <-- Cái này là biểu tượng của đồng tiền, được dùng khi hiển thị số tiền bằng chữ hoặc hiển thị biểu tượng bên cạnh các con số tiền.

....
txtFields(CST_FLD_MASTER_TOTAL_AMOUNT).Text = Format$(dblTotalAmount * 1/ExchangeRate, strCurrencyFormat)

'// ExchangeRate để là số to cũng được, trong code ra có thể dùng * 1 / ExchangeRate

Khi save vào CSDL thì ta lại:

dblTotalAmount = txtFields(CST_FLD_MASTER_TOTAL_AMOUNT).Text * ExchangeRate

...
objInvoice.TotalAmount = Format$(dblTotalAmount, strBasedCurrencyFormat)
...
if Not objInvoice.Insert() Then Goto PROC_DONE
...

Phần chi tiết chứng từ ta cũng phải chuyển đổi như vậy để save chứng từ.


Mọi người thử nghĩ thêm tới các trường hợp sau khi đang nhập liệu:

Trường hợp 1: Thay đổi loại tiền tệ (Chọn từ ComboBox) khi đang thêm mới chứng từ (ví dụ hóa đơn bán hàng). Khi đó các giá trị trên dòng chứng từ (đơn giá, thành tiền,...), các giá trị ở phần tổng tiền sẽ thay đổi như thế nào?

Trường hợp 2: Cũng là việc thay đổi ngoại tệ (Chọn từ ComboBox) nhưng ko phải ở trường hợp thêm mới mà là ở trường hợp đang sửa chứng từ. Đặc biệt sửa trong trường hợp hóa đơn đã thanh toán và hóa đơn chưa thanh toán (hoặc thanh toán 1 phần)

Mọi người sẽ thấy việc sửa chứng từ ngoài ảnh hưởng tới giá vốn, giá trị hàng tồn kho, số lượng hàng tồn kho thì nó còn ảnh hưởng rất nhiều tới các yếu tố khác nữa (ví dụ hóa đơn đã thanh toán bị sửa lại). Thế mà các kế toán nhà ta liên tục sửa chứng từ đó

 

[ptm0412]

Đang nghĩ các trường hợp thanh toán ở bài 1, gần ra; Hải nhanh quá đặt thêm vấn đề mới nữa.

Nói tiếp về Database:
Để theo dõi công nợ khách hàng cho rõ ràng trong trường hợp đồng tiền thanh toán khác với đồng tiền trên hoá đơn và mở rộng ra thanh toán 1 lần nhiều loại tiền tệ và hơn nữa là cho nhiều tờ hoá đơn:
- trong table MainData thu chi sẽ cần 1 field Ref_Invoice là hoá đơn liên quan. Thí dụ trả tiền 200$ cho hoá đơn 001, 100EUR cho hoá đơn 001, 300GBP cho hoá đơn 002
- tương ứng trong table công nợ sẽ có field Ref_Invoice cho biết dư nợ từng tờ hoá đơn, thêm vào các field có sẵn: loại ngoại tệ, tỷ giá và số tiền quy chuẩn.
- table công nợ cần thêm 1 field Finished kiểu Binary để kiểm soát hoá đơn đã thanh toán hết hay chưa.

Như vậy khi KH thanh toán sẽ phải tách ra theo hoá đơn, mỗi hoá đơn bao nhiêu tiền, loại tiền tệ nào, tỷ giá bao nhiêu. Căn cứ vào đó ngoài việc hạch toán cấn trừ tài khoản, còn phải cấn trừ chi tiết công nợ theo hoá đơn.

Công việc phải xử lý:
1- Nếu đồng tiền thanh toán khác với đồng tiền trên hoá đơn, phải so sánh tỷ giá 2 đồng tiền với đồng tiền chuẩn là BasedCurrency. Để biết giả sử với 220 EUR đã trừ hết nợ tờ hoá đơn 480USD hay chưa, dù cho 220EUR nhân tỷ giá quy đổi ra BasedCurrency có thể đã dư hoá đơn rồi.
Nếu đồng tiền thanh toán là bao nhiêu loại, phải thực hiện bằng ấy lần.
2- Khi biết rằng 220EUR chính xác bằng 480USD (mức độ chính xác do người dùng đặt), sẽ phải check vào field Finished (kiểu binary, kiểm soát bằng checkbox) nhằm đánh dấu hoá đơn đã thanh toán xong.
3- Cuối kỳ: Trong bảng table công nợ:
a. Lọc những hoá đơn đã check field Finished để tính chênh lệch tỷ giá
b. Lọc những hoá đơn chưa check chuyển số dư sang kỳ sau.

Không biết còn gì nữa không, (chưa nói đến sửa chứng từ). Mà cũng nên khoá những hoá đơn đã check Finished lại không cho sửa. Muốn sửa phải làm bút toán điều chỉnh riêng và phải có Phiếu đề nghị điều chỉnh (cho sợ đừng làm sai).

 

[Nguyễn Duy Tuân]

Em thoae luận sơ sơ thế này.

Trước tiên cần một "Danh mục tiền tệ" có cấu trúc:
|Mã tiền| Tên, diễn giải|Tài khoản hạch toán| Tỷ giá hiện thời| Đơn vị làm tròn|

(*) Trên các chứng từ có thêm 3 trường: Loại tiền, Tỷ giá, một trường Giá trị quy đổi (ra đồng tiền chính).
Trong các sổ nhật ký, có thêm 4 cột: Số tiền, Loại tiền, Tỷ giá, Tiền quy đổi (theo laọi đồng tiền chính - nội tệ).

(*) 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.

(*) Trong các chứng từ có trường "Giá trị quy đổi"

(*) Khi lập báo cáo, cho phép chọn loại đồng tiền để báo cáo = Tiền quy đổi/Tỷ giá.

(*) Vấn đề hàng mua, hàng bán bị trả lại. Làm theo trình tự:
+ Lập phếu điều chỉnh gửi cho bên bán
+ Căn cứ vào sự chấp thuận của bên bán thông qua chứng từ chấp nhận điều chỉnh (Credit Note), cần chia ra làm các trường hợp:

+ Điều chỉnh kho và giảm trừ công nợ
+ Điều chỉnh kho và giả lại tiền
+ Trả lại tiền không thay đổi kho
+...

Lập phiếu điều chỉnh (Credit Note) trong phần mềm, em thường cho nhập trong chính màn hình mua, bán nhưng vào số liệu (số lượng hàng nếu liên quan tới kho) là âm, việc xác định tài khoản giảm trừ doanh thu hay giảm trừ kho hay giá vốn sẽ lấy từ bảng danh mục hàng hóa. Trong danh mục hàng hóa em thường setup các tài khoản cho mỗi hàng hóa luôn (Hàng tồn kho, Giá vốn, Hàng bán bị trả lại,...)

Trong trường hợp chênh lệch tỷ giá, giá trị chênh lệch sẽ được định khoản theo thông tư hiện hành.

Vẫn theo luật, giá trị âm thì định khoản đảo.

Mời mọi người thảo luận tiếp!

 

[hai2hai]

(*) Trên các chứng từ có thêm 3 trường: Loại tiền, Tỷ giá, một trường Giá trị quy đổi (ra đồng tiền chính).
Trong các sổ nhật ký, có thêm 4 cột: Số tiền, Loại tiền, Tỷ giá, Tiền quy đổi (theo laọi đồng tiền chính - nội tệ).

Có nhất thiết có cột "Tiền quy đổi" trong CSDL không?

Cột "Tiền quy đổi" = Số tiền * Tỷ giá, khi cần tính toán thì lấy 2 trường đó cho chính xác, hạn chế việc tạo thêm cột "Tiền quy đổi" đó trong CSDL. Cột "Tiền quy đổi" chỉ hiển thị trên báo cáo, màn hình mà thôi.

Lập phiếu điều chỉnh (Credit Note) trong phần mềm, em thường cho nhập trong chính màn hình mua, bán nhưng vào số liệu (số lượng hàng nếu liên quan tới kho) là âm, việc xác định tài khoản giảm trừ doanh thu hay giảm trừ kho hay giá vốn sẽ lấy từ bảng danh mục hàng hóa. Trong danh mục hàng hóa em thường setup các tài khoản cho mỗi hàng hóa luôn (Hàng tồn kho, Giá vốn, Hàng bán bị trả lại,...)

Vẫn theo luật, giá trị âm thì định khoản đảo.

Chứng từ trả lại hàng nhiều khi (trong thực tế) nó ko giống như chứng từ nhập/xuất hàng (hoặc hóa đơn mua/bán) đâu. Vì thế ko chung nhau trên cùng 1 chứng từ (để ghi âm) được. Nhiều khi có trên chứng từ trả lại hàng bán nhưng có thêm tiền phạt nữa, v.v....

(*) 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|

Phiếu thu, phiếu chi thì chắc chắn phải có chi tiết rồi, nếu ko thì thanh toán làm sao được cho nhiều hóa đơn.

Nếu chỉ có 1 cột "Thanh toán" trong khi dòng 1 có Mã NT là USD, dòng 2 có Mã NT là EUR thì tính sao đây? Tổng tiền thanh toán theo theo cột nào? (Trường hợp thanh toán bằng 2 loại ngoại tệ trở lên mà)

- table công nợ cần thêm 1 field Finished kiểu Binary để kiểm soát hoá đơn đã thanh toán hết hay chưa.

Cái này ban đầu mọi người sẽ nghĩ làm cách này. Tuy nhiên, việc này lập trình ko cẩn thận nhiều khi hóa đơn được thanh toán hết rồi mà Finished (Kiểu boolean chứ) lại = False hoặc ngược lại

Ví dụ nhé:

1/ 1 hóa đơn có giá trị 100tr, phiếu thanh toán cho hóa đơn đó cũng là 100tr ==> Finished = True nhé

Giờ ta tiếp tục sửa hóa đơn làm cho giá trị của hóa đơn là 120tr. Vậy Finished = ?

2/ 1 hóa đơn có giá trị 100tr, phiếu thanh toán cho hóa đơn đó cũng là 80tr ==> Finished = False nhé

Giờ ta quay lại sửa hóa đơn làm cho giá trị của hóa đơn là 80tr. Vậy Finished = ?

Mọi người sẽ thấy nếu cứ dính đến chuyện sửa/xóa chứng từ thì sẽ còn nghĩ ra hàng trăm vấn đề nữa.

Vì thế, việc kiểm soát trạng thái hóa đơn ko làm kiểu đó được mà phải viết SQL để check tổng của các phần thanh toán cho hóa đơn đó so với tổng giá trị của hóa đơn.

Mà cũng nên khoá những hoá đơn đã check Finished lại không cho sửa. Muốn sửa phải làm bút toán điều chỉnh riêng và phải có Phiếu đề nghị điều chỉnh (cho sợ đừng làm sai).

Đây là điều mong ước, làm cho dân IT nhàn nhất đấy.

Mọi người có biết là ở nhiều đơn vị, họ bán hàng âm kho ầm ầm, sau mấy ngày họ mới làm phiếu chuyển kho/nhập hàng/phiếu điều chỉnh để cho dương kho (ngày ở phía sau mấy chứng từ xuất kho). Lúc đó mọi người thử tính giá vốn mà xem. Nếu xử lý ko cẩn thận, tràn số (giá trị tồn kho) là chuyện hiển nhiên (thế là KH bảo phần mềm lỗi rồi )

 

[cadafi]

To: Anh hai2hai

File đính kèm là schema cho phần khai báo Multi currency của ACCPAC, và giao diện nhập liệu tỳ giá . Anh tham khảo thử xem. Em đang lục lại phần database của Accpac về mảng Account Payable - Payment và Receivable - Receipt. Chắc thứ hai mới gửi lên được.
---------------------------------------

Ý 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.

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.

 

[hai2hai]

To: Anh hai2hai

File đính kèm là schema cho phần khai báo Multi currency của ACCPAC, và giao diện nhập liệu tỳ giá . Anh tham khảo thử xem. Em đang lục lại phần database của Accpac về mảng Account Payable - Payment và Receivable - Receipt. Chắc thứ hai mới gửi lên được.

Đang định cài lại ACCPAC lên máy (hic, đây là PM thứ 5 trong mấy ngày gần đây đã phải cài lên 1 máy tính), có lẽ thôi ko cài nữa nếu có sự giúp đỡ của ca_dafi.

 

[Mr Okebab]

Cẩn thận không vi phạm bản quyền đấy các bác ạ!!!

Thân!

 

[hai2hai]

Cẩn thận không vi phạm bản quyền đấy các bác ạ!!!

Thân!

ACCPAC cho phép download trial. Có đầy ở trên website của bác Đại Yukos. Đại Yukos gửi cho hai2hai 2 bộ trial rồi.

Một khi đã cài đặt trial lên thì có thể revert database để tham khảo (chứ làm sao mà làm y chang như nó được)

Hai2Hai hiện đang tham khảo SAP B1, Sage Accounts V12.00, MyOb 14, QuickBook, Peachtree Accounting, và 1 vài ứng dụng có tên tuổi khác nữa (toàn trial cả mà)

 

[hai2hai]

Mình chưa rõ được ý nghĩa (1), các trường hợp áp dụng (2) của các nhóm tỷ giá (Rate Type) được áp dụng như thế nào:

Rate types:
- Monthly average rate (AV)
- Daily spot rate (SP)
- Financial Translation-Average (TA)
- Financial Translation-Current (TR)

 

[ptm0412]

Finished (Kiểu boolean chứ)

Ừ, nhầm (lú lẫn thật)

việc kiểm soát trạng thái hóa đơn ko làm kiểu đó được mà phải viết SQL để check tổng của các phần thanh toán cho hóa đơn đó so với tổng giá trị của hóa đơn.

Check bằng tay hay bằng mã lệnh cũng cần field đó chứ nhỉ? Vì mình nghĩ đưa trạng thái vào 1 field thì xử lý tốt hơn, nhất là khi xử lý cuối kỳ. Nếu check bằng mã lệnh thì không đưa field đó lên màn hình, thế thôi.

Mình giả dụ những trường hợp sau:

1.Trường hợp hoá đơn số 001 trị giá 400USD tỷ giá 16.000 = 6.4tr, hoá đơn 002 trị giá 600USD tỷ giá cho đơn giản cũng là 16.000 = 9.6 tr
Khách hàng thanh toán lần đầu 500EUR cho cả 2 hoá đơn tỷ giá 23.000 = 11.5tr, tỷ giá USD thời điểm này là 16.100
Kế toán thu phải tính tay (hoặc tốt hơn lập 1 bảng chiết tính bằng Excel và in ra làm 1 chứng từ gọi tạm là "căn cứ hạch toán" có ký tên người tính) cho ra kết quả là:
=400 * 16.1 / 23 = 279.13 EUR cho hoá đơn 001, làm phiếu thu dòng thứ nhất.
Còn lại 220.87 EUR làm dòng thứ 2 cho hoá đơn 002

Cái này thì dễ rồi, code lệnh tự động tính và check finished cho hoá đơn thứ nhất, không check hoá đơn 002.

2.Nhưng cũng có trường hợp khách trả chỉ 279.00 EUR theo tỷ giá của nước họ, và tuyên bố hết nợ hoá đơn 001 (thực ra thiếu 0.13 EUR), trường hợp này phải check bằng tay

Vấn đề về sửa chứng từ:
- Khi sửa chứng từ đã có phiếu thu (đủ hoặc chưa đủ), người sửa phải kiểm tra dấu check này.
- Nếu không kiểm tra hoặc kiểm tra sót gây lỗi True -- False thì kế tóan công nợ sẽ phát hiện ra: Tổng bảng kê hoá đơn nợ, không bằng tổng dư nợ của từng khách hàng.
- Nếu Kế toán công nợ không phát hiện, thì kế toán tổng hợp sẽ phát hiện: Tổng bảng kê hoá đơn nợ không bằng tổng sô dư tài khoản 131
- Nếu kế toán tổng hợp không phát hiện, KTT phải phát hiện. (Nếu không thì nghỉ làm việc khác cho xong)

Còn cái chứng từ "căn cứ hạch toán" nêu trên mình nghĩ phải in ra và phải lưu file Excel là cũng có lý do: Để biết rằng hôm qua nhân viên A tính thế này cho con số để hạch toan phiếu thu này, còn năm ngoái nhân viên B tính thế kia cho phiếu thu kia.

 

[hai2hai]

Vấn đề về sửa chứng từ:
- Khi sửa chứng từ đã có phiếu thu (đủ hoặc chưa đủ), người sửa phải kiểm tra dấu check này.
- Nếu không kiểm tra hoặc kiểm tra sót gây lỗi True -- False thì kế tóan công nợ sẽ phát hiện ra: Tổng bảng kê hoá đơn nợ, không bằng tổng dư nợ của từng khách hàng.
- Nếu Kế toán công nợ không phát hiện, thì kế toán tổng hợp sẽ phát hiện: Tổng bảng kê hoá đơn nợ không bằng tổng sô dư tài khoản 131
- Nếu kế toán tổng hợp không phát hiện, KTT phải phát hiện. (Nếu không thì nghỉ làm việc khác cho xong)

- Nếu KTT ko phát hiện ra thì .... phần mềm phải phát hiện ra (Nếu ko thì vứt phần mềm đi mua phần mềm khác)

Nói vui vậy thôi, thông thường 1 hệ thống phần mềm tốt thường sẽ phải có chức năng ra soát lại toàn bộ nghiệp vụ hệ thống (dĩ nhiên là theo logic của nghiệp vụ) để đưa lên những cảnh báo, gợi ý, nhắc nhở nhằm giúp những người làm nghiệp vụ có thể thực hiện tốt các công việc của mình.

Ví dụ, khi theo dõi doanh thu, lãi gộp mà tự nhiên thấy lỗ nặng thì tức là "có vấn đề". Phải có chức năng theo dõi mặt hàng đó từ các chứng từ, xem lịch sử của mặt hàng đó diễn biến thế nào. Và kiểu gì cũng thấy hàng đó bị âm kho liên tục --> giá vốn có thể âm (và được gán = 0 khi bị âm).

Việc check tình trạng chứng từ là thường xuyên phải thực hiện (ví dụ: trạng thái của đơn hàng, tình trang thanh toán của hóa đơn, v.v...)

Việc check tình trạng của chứng từ thì hai2hai ko sử dụng trường boolean đó mà sử dụng SQL để check ở thời điểm đó. Ví dụ: sử dụng method objInvoice.PaymentStatus(). Ở đó, sẽ thực hiện việc kiểm tra tổng tiền thanh toán so với tổng giá trị hóa đơn để biết được 1 trong 4 trạng thái thanh toán của hóa đơn: Đã thanh toán, chưa thanh toán, thanh toán 1 phần, thanh toán vượt. (Không chậm hơn so với việc lấy giá trị của trường Finished kia đâu mà lại có tính tức thời, ko phải cập nhật Finished khi sửa chứng từ).

Việc kết chuyển công nợ hai2hai ko cần dựa vào trường Finished mà sử dụng 1 vài câu SQL là có thể kết chuyển được.

 

[cadafi]

Mình chưa rõ được ý nghĩa, các trường hợp áp dụng của các nhóm tỷ giá (Rate Type) được áp dụng như thế nào:

Đây là một reference option. Khi nói đến tỉ giá thì thường ta phải xác định đây là loại tỷ giá nào, ta đang áp dụng loại tỷ giá nào (giống như khi khấu hao phải xác định xem ta khấu hao theo phương pháp nào ý mà). Trước khi tạo tỷ giá cho loại tiền tệ nào phải setup loại tỳ giá trước và sau đó tham chiếu tỷ giá theo loại (phương pháp xác định tỷ giá) Ví dụ:

Tỷ giá bình quân tháng (Monthly Average Rate - cái này chắc chỉ có vài cty nhà nước xài)
Tỷ giá giao ngay. (Daily Spot - thường được áp dụng).
Tỷ giá chuyển đổi tài chính bình quân (cái này em đang nghiên cứu)
Tỷ giá chuyển đối tài chính hiện hành (cái này em cũng đang nghiên cứu luôn).

 

[cadafi]

To: Anh hai2hai

File đính kèm là Schema của database Accpac. Em gửi anh tham khảo nhé.
Không biết có dịp nào gặp được anh để thỏa lòng mong nhớ đây!

 

[ptm0412]

- Nếu KTT ko phát hiện ra thì .... phần mềm phải phát hiện ra (Nếu ko thì vứt phần mềm đi mua phần mềm khác)

Hai2hai thương KTT nhỉ! Thương không xuể đâu nhé! Chủ yếu trách nhiệm là của con người, PM do con người tạo ra và không bao giờ lường được hết mọi lỗi do người khác tạo ra. Mà bảo đảm 10 em KT thì sai ít nhất 11 kiểu. Mấy Ông/bà KTT phải bằng mọi cách, dùng mọi kinh nghiệm đã có, kết hợp đủ các loại phương pháp để phát hiện mọi sai sót dù chỉ 1 đồng, và 1 đồng sai sót nằm ở đâu. Ấy là mỗi KTT chỉ có từ 1 chục đến 2 chục nhân viên. Hải tính lường hết cho vài ngàn kiểu sai của vài ngàn người à?

 

[cadafi]

Hai2hai thương KTT nhỉ! Thương không xuể đâu nhé! Chủ yếu trách nhiệm là của con người, PM do con người tạo ra và không bao giờ lường được hết mọi lỗi do người khác tạo ra. Mà bảo đảm 10 em KT thì sai ít nhất 11 kiểu. Mấy Ông/bà KTT phải bằng mọi cách, dùng mọi kinh nghiệm đã có, kết hợp đủ các loại phương pháp để phát hiện mọi sai sót dù chỉ 1 đồng, và 1 đồng sai sót nằm ở đâu. Ấy là mỗi KTT chỉ có từ 1 chục đến 2 chục nhân viên. Hải tính lường hết cho vài ngàn kiểu sai của vài ngàn người à?

Người xưa có câu: Cái gì cũng có cái giá của nó!
Vì vậy mới có các phần mềm lên đến vài triệu, vài chục triệu USD. Không biết khi nào em mới có diễm phúc chiêm ngưỡng một phần mềm như thế!

 

[hai2hai]

Hải tính lường hết cho vài ngàn kiểu sai của vài ngàn người à?

Vâng, bên phần mềm biết là ko thể cover hết được mọi sai lầm của con người tạo ra. Nhưng sẽ cố gắng để chỉ ra những sai lầm đó (đến 1 mức có thể).

Làm dâu trăm họ nó khổ thế đấy. Họ sai nhưng họ kêu ca phần mềm của mình làm cho họ làm sai . Giả sử mọi chuyện "đã rồi" mà mình ko hỗ trợ họ thì họ lại bảo "chất lượng dịch vụ kém". Nhưng nếu muốn dịch vụ tốt thì lại chi phí vào đó cao (1 KH ko sao nhưng nhiều KH mà cứ gọi điện hay đi lại liên tục thì chỉ có lỗ vốn - chủ yếu là cái thời gian hỗ trợ nhiều, mà thời gian lại là tiền).

Thế nên, để tránh lỗi của người sử dụng, và khắc phục "hậu quả" do người dùng đem lại (mà vẫn được đánh giá là dịch vụ tốt) thì các nhà làm phần mềm phải nghĩ ra các công cụ hạn chế tối đa các trường hợp người dùng làm lỗi và khắc phục với chi phí thấp nhất những gì đã "chót" xảy ra.

Nhân tiện cái vụ Đa ngoại tệ vừa rồi. Mọi người cứ thử sửa chứng từ, chuyển đi chuyển lại cái tiền tệ giữa VNĐ và USD trên chứng từ. Sao cho 1 con số nó lẻ khi nhân với 1/ExchangeRate. Lúc chuyển lại lại, tự nhiên sẽ thấy con số tiền nó cứ chênh đi 1 vài đồng. Đó là vấn đề mà mọi người sẽ đau đầu khi xử lý đa nguyên tệ.

 

[ptm0412]

Lúc chuyển lại lại, tự nhiên sẽ thấy con số tiền nó cứ chênh đi 1 vài đồng. Đó là vấn đề mà mọi người sẽ đau đầu khi xử lý đa nguyên tệ

Theo mình cứ làm tròn từ 0 đến 2 số lẻ (tuỳ theo). Sau đó thế nào chẳng có chênh lệch tỷ giá, khi xử CLTG từng tờ hoá đơn, xử luôn cái số lẻ , xong chuyện.

Nhắc lại cái field finished (vẫn còn ấm ức!):

Ví dụ: sử dụng method objInvoice.PaymentStatus(). Ở đó, sẽ thực hiện việc kiểm tra tổng tiền thanh toán so với tổng giá trị hóa đơn để biết được 1 trong 4 trạng thái thanh toán của hóa đơn: Đã thanh toán, chưa thanh toán, thanh toán 1 phần, thanh toán vượt. (Không chậm hơn so với việc lấy giá trị của trường Finished kia đâu mà lại có tính tức thời, ko phải cập nhật Finished khi sửa chứng từ).

Vậy có phải Hai2hai vẫn dùng 1 field PaymentStatus không? nếu phải, thì cũng là mở rộng của field Finished từ 2 trạng thái lên 4 trạng thái, đúng không?
Nói "đúng" cái đi mà!

 

[hai2hai]

Vậy có phải Hai2hai vẫn dùng 1 field PaymentStatus không? nếu phải, thì cũng là mở rộng của field Finished từ 2 trạng thái lên 4 trạng thái, đúng không?
Nói "đúng" cái đi mà!

Không dùng fields PaymentStatus, mà PaymentStatus() là 1 method của objInvoice (ko phải thuộc tính)

Trong method đó, sẽ viết dạng như sau

Lấy tổng tiền hóa đơn (InvoiceID) - Tổng tiền thanh toán cho hóa đơn(InvoiceID)

Cái này chỉ 1 câu Select là ra thôi

 

[Nguyễn Duy Tuân]

Chứng từ trả lại hàng nhiều khi (trong thực tế) nó ko giống như chứng từ nhập/xuất hàng (hoặc hóa đơn mua/bán) đâu. Vì thế ko chung nhau trên cùng 1 chứng từ (để ghi âm) được. Nhiều khi có trên chứng từ trả lại hàng bán nhưng có thêm tiền phạt nữa, v.v....

Trên form nhập mua, bán hàng vẫn có thể kết hợp cho trường hợp hàng trả lại, phần lớn các thông tin có thể dùng chung. MYOB v17 em đang dùng cũng làm như vậy. Trong thực thế, mẫu phiếu trả lại hàng, mua, bán, nhập xuất không giống nhau. Vì thế, mặc dù chung một form nhập nhưng cho phép in ra các mẫu chứng từ khác nhau. Việc lập riêng mỗi đặc thù nghiệp vụ một form nó cũng rõ ràng nhưng sẽ mất công thiết kế. Việc kết hợp theo luồng nghiệp vụ, chỉ cần có một lựa chọn "Loại chứng từ" (Mua, Hàng mua trả lại,...) sẽ đỡ mất công hơn. Nếu có phát sinh tiền phạt, hay gì đó thì vẫn cho phép nhập tiếp trong cột "Item" của grid nhưng là nhập giá trị chứ không nhập số lượng. Trong các chứng từ mua, bán em vẫn ch phép nhập mã hàng, số lượng và các phí kèm theo.

Trên các hóa đơn vẫn nên có trường "Giá trị quy đổi" (theo đồng tiền chính), điều này đúng cho cả trường hợp có phiếu thu, chi mà thanh toán trên nhiều ngoại tệ.

Trong sổ nhật ký có thể không cần "Giá trị quy đổi" vì có thể kết hợp [Tỷ giá]*[Số tiền].

 

[hai2hai]

Theo mình cứ làm tròn từ 0 đến 2 số lẻ (tuỳ theo). Sau đó thế nào chẳng có chênh lệch tỷ giá, khi xử CLTG từng tờ hoá đơn, xử luôn cái số lẻ , xong chuyện.

Đơn giá tiền Việt là 20,000VNĐ
Đơn giá $ là 20,000 * 1 /tỷ giá

Quay đi quay lại (chọn cái danh sách tiền tệ trên chứng từ ấy). Thế là Đơn giá nó lẻ ko còn 20,000 như lúc đầu nữa (vì lúc mình chuyển qua USD mình format nó thành ###0.00 mà). Vụ này trên Excel thì nó lưu cả phần lẻ nên ko sao. Trên PM, các ô textbox thì phải cắt đi chứ. Thế là quay đi quay lại cái combo tiền tệ, mọi thứ lẻ linh tinh cả. Đang nghĩ kế để nó giữ nguyên các con số ban đầu. (vì lúc lưu vào Database thì lưu số tiền theo tiền cơ sở chứ có lưu tiền ngoại tệ đâu). Nếu ko nghĩ được cách thì đành mặc lẻ thôi.

 

[hai2hai]

Trên các hóa đơn vẫn nên có trường "Giá trị quy đổi" (theo đồng tiền chính), điều này đúng cho cả trường hợp có phiếu thu, chi mà thanh toán trên nhiều ngoại tệ.

Đúng rồi, cột "Giá trị quy đổi" thì nó chính là các cột giá trị trước kia mà thôi. Mặc định các cột giá trị trên mọi chứng từ là theo đồng tiền cơ sở mà. Nếu ko có cột đó thì lưu giá trị tiền (nào là tiền thuế, nào là tiền CK hóa đơn, nào là tiền phi phí khác, nào là tổng tiền hóa đơn) của hóa đơn vào đâu?

Nhưng Tuân quên mất là việc thanh toán cho 1 hóa đơn thì có thể thanh toán nhiều loại tiền cùng 1 lúc à?

Ví dụ: Tuân bán cho anh 1 phần mềm kế toán A-excel. Giá trị hóa đơn bán hàng là 120$
Anh trả tuân tiền mặt luôn. Nhưng anh chỉ có 100$ thôi, còn lại 20$ anh sẽ trả tiền VND.

Vấn đề là em sẽ phải thiết kế phiếu thu của em để cùng 1 lúc thanh toán được 2 (thậm chí nhiều hơn 2) loại tiền tệ. Nếu em chỉ có 1 cột tiền "Số tiền thanh toán" thì lúc em cộng tổng tiền thanh toán tính sao đây. Nếu thanh toán mà chỉ có 1 loại tiền thôi thì đơn giản quá.

 

[ptm0412]

Trong method đó, sẽ viết dạng như sau
Lấy tổng tiền hóa đơn (InvoiceID) - Tổng tiền thanh toán cho hóa đơn(InvoiceID)
Cái này chỉ 1 câu Select là ra thôi

Hiểu rồi, nghĩa là không phải 1 trường cố định trong table dữ liệu, mà khi cần sẽ gọi ra bằng mã lệnh. Nếu method đó có cấu trúc như kiểu select case sẽ được nhiều trạng thái (4).
Quay lại chuyện số lẻ:

Đơn giá tiền Việt là 20,000VNĐ
Đơn giá $ là 20,000 * 1 /tỷ giá

Mình tưởng rằng khi xuất 1 hoá đơn ngoại tệ, thì đơn gía ngoại tệ phải có trước chứ? Hình dung trình tự nhập chi tiết hoá đơn như sau: (bỏ qua phần header thuộc dữ liệu master)
- mã ItemID (chọn trong 1 list)
- mã tiền tệ CurrID (chọn trong 1 list)
- tỷ giá của loại tiền tệ đó, tự lookup từ ExchangeRateHistory, sửa tay lại nếu cần.
- Gõ Số lượng
- Gõ đơn giá ngoại tệ
- Thành tiền VND (based currency) tự tính bằng đgNT * Sl * tỷ giá

Nếu hoá đơn tiền việt cũng tương tự, tỷ giá = 1 hiện ra hoặc mờ đi do disable, thành tiền cũng tính tương tự với tỷ giá = 1

Đâu có cái vụ đơn giá 20.000VND, tính ra bao nhiêu tiền ngoại tệ? Chắc đang nói đến thành tiền ngoại tệ (do không được save vào data).

(vì lúc mình chuyển qua USD mình format nó thành ###0.00 mà). Vụ này trên Excel thì nó lưu cả phần lẻ nên ko sao. Trên PM, các ô textbox thì phải cắt đi chứ

Sao thế? thể hiện trên textbox bị cắt đi là do format, lưu lại thế nào là do định nghĩa thuộc tính của trường có bao nhiêu số lẻ. Như trường number trong access và FoxPro có thuộc tính Decimal Place do mình thiết lập khi create table. (Data của ngôn ngữ khác thì không biết).

Đang nghĩ kế để nó giữ nguyên các con số ban đầu. (vì lúc lưu vào Database thì lưu số tiền theo tiền cơ sở chứ có lưu tiền ngoại tệ đâu). Nếu ko nghĩ được cách thì đành mặc lẻ thôi

Nói về sửa dữ liệu thì là hoặc sửa đơn giá (NT), hoặc sửa số lượng, sửa tỷ giá, sửa mã tiền tệ, thì thành tiền VND (cơ sở) ban đầu sẽ phải thay đổi chứ.

Chỉ còn lại vấn đề khi thanh toán bằng các ngoại tệ khác, không phải loại NT trên hoá đơn, lúc này phải chấp nhận 1 mức độ sai số khi quy đổi các ngoại tệ thanh toán thành ngoại tệ ghi hoá đơn, qua trung gian tỷ giá đối với Based Currency (VND). Xem lại bài 16, các thao tác cần xử lý.
Trong mức độ cho phép đó thì hoá đơn đổi trạng thái. Còn tổng ngoại tệ thanh toán không có giá trị (vì 1: nhiều loại tiền tệ, 2: có sai số), chỉ có tổng thành tiền cơ sở (VND) có giá trị dùng để tính CL tỷ giá, lúc này xử luôn số lẻ nếu có của số chênh lệch hoá đơn giữa tổng tiền ghi hoá đơn và tổng tiền Thanh toán (tiền cơ sở, VND). Thế là chấm dứt 1 tờ hoá đơn. Mọi sửa chữa sau đó không cho phép sửa trực tiếp mà phải thực hiện bút toán điều chỉnh. Cada_fi cũng làm thế.

 

[hai2hai]

Quay lại chuyện số lẻ:

Mình tưởng rằng khi xuất 1 hoá đơn ngoại tệ, thì đơn gía ngoại tệ phải có trước chứ? Hình dung trình tự nhập chi tiết hoá đơn như sau: (bỏ qua phần header thuộc dữ liệu master)
- mã ItemID (chọn trong 1 list)
- mã tiền tệ CurrID (chọn trong 1 list)
- tỷ giá của loại tiền tệ đó, tự lookup từ ExchangeRateHistory, sửa tay lại nếu cần.
- Gõ Số lượng
- Gõ đơn giá ngoại tệ
- Thành tiền VND (based currency) tự tính bằng đgNT * Sl * tỷ giá

Nếu hoá đơn tiền việt cũng tương tự, tỷ giá = 1 hiện ra hoặc mờ đi do disable, thành tiền cũng tính tương tự với tỷ giá = 1

Đâu có cái vụ đơn giá 20.000VND, tính ra bao nhiêu tiền ngoại tệ? Chắc đang nói đến thành tiền ngoại tệ (do không được save vào data).

Đúng rồi, trên danh mục hàng hóa hiện nay ko lưu giá theo ngoại tệ mà chỉ lưu giá theo tiền cơ sở. Thực ra là do mới bổ sung tính năng đa nguyên tệ nên khi thử áp dụng ngoại tệ, lúc chuyển đổi theo tỷ giá thì tự nhiên thấy giá cứ lẻ lung tung. Trên thực tế, chắc giá hàng sẽ ko lẻ như thế vì họ sẽ dùng Giá Cơ sở = Giá NT * Tỷ giá.

Nhưng nếu trên hóa đơn dùng tỷ giá khác với tỷ giá trên danh mục thì Giá bán Cơ sở sẽ ko giống như giá bán ở trên danh mục.

- Gõ đơn giá ngoại tệ --> Thông thường ở bán lẻ, giá bán được nhà quản lý thiết lập sẵn chứ ko cho nhân viên bán hàng sửa giá. Dĩ nhiên, vẫn cho phép sửa giá bán nếu user có quyền sửa.

- Thành tiền VND (based currency) tự tính bằng đgNT * Sl * tỷ giá

Sao thế? thể hiện trên textbox bị cắt đi là do format, lưu lại thế nào là do định nghĩa thuộc tính của trường có bao nhiêu số lẻ. Như trường number trong access và FoxPro có thuộc tính Decimal Place do mình thiết lập khi create table. (Data của ngôn ngữ khác thì không biết).

Nói về sửa dữ liệu thì là hoặc sửa đơn giá (NT), hoặc sửa số lượng, sửa tỷ giá, sửa mã tiền tệ, thì thành tiền VND (cơ sở) ban đầu sẽ phải thay đổi chứ.

Chỉ còn lại vấn đề khi thanh toán bằng các ngoại tệ khác, không phải loại NT trên hoá đơn, lúc này phải chấp nhận 1 mức độ sai số khi quy đổi các ngoại tệ thanh toán thành ngoại tệ ghi hoá đơn, qua trung gian tỷ giá đối với Based Currency (VND). Xem lại bài 16, các thao tác cần xử lý.
Trong mức độ cho phép đó thì hoá đơn đổi trạng thái. Còn tổng ngoại tệ thanh toán không có giá trị (vì 1: nhiều loại tiền tệ, 2: có sai số), chỉ có tổng thành tiền cơ sở (VND) có giá trị dùng để tính CL tỷ giá, lúc này xử luôn số lẻ nếu có của số chênh lệch hoá đơn giữa tổng tiền ghi hoá đơn và tổng tiền Thanh toán (tiền cơ sở, VND). Thế là chấm dứt 1 tờ hoá đơn. Mọi sửa chữa sau đó không cho phép sửa trực tiếp mà phải thực hiện bút toán điều chỉnh. Cada_fi cũng làm thế.

CSDL lưu ngoại tệ dạng Numeric(14,2) thôi, ko cần lưu dài làm gì. Khi tính toán thì dùng số Double nên nó vẫn lưu số lẻ. Khi hiển thị lên TextBox thì dùng txtFields(CST_...).Text = Format$(dblTotalAmount, strNumericFormat)

Hàm format sẽ làm tròn số luôn trước khi hiện lên textbox.

Khi chọn ngoại tệ khác, nó lại lấy giá trị trên textbox đó (đã bị làm tròn) để quy đổi về giá trị cũ theo tỷ giá của NT trước (và khi đó giá trị đã khác đi vì giá trị trên Textbox đã bị làm tròn, khi nhân với tỷ giá thì ko còn như cũ nữa).

Nói tóm lại, cứ phải làm thì mới nhận ra điều đó.

 

[Nguyễn Duy Tuân]

Khi một trường đóng vai trò là trường số (kiểu Double), theo em nên làm thế này:

Trường đó có 2 property (mọi người hiểu như 2 biến thành viên) là

AsNumber : lưu số lẻ theo phép tính (nguyên bản)
AsText : lưu số sau khi đã format(...) (hình thức thể hiện trên form, không dùng để tính toán)

Như vậy khi cho tham gia vào biểu thức tính toán thì dùng AsNumber để làm, có thể kết hợp hàm Round(AsNumber,nRound) .

 

[ptm0412]

Hàm format sẽ làm tròn số luôn trước khi hiện lên textbox.
...
Nói tóm lại, cứ phải làm thì mới nhận ra điều đó.

Mình không bị điều đó, vì xài Property Textbox.format chứ không dùng hàm format, tại Access và Fox không có hoặc không học tới, --> tầm mắt chỉ tới đó (hii)

 

[hai2hai]

Khi một trường đóng vai trò là trường số (kiểu Double), theo em nên làm thế này:

Trường đó có 2 property (mọi người hiểu như 2 biến thành viên) là

AsNumber : lưu số lẻ theo phép tính (nguyên bản)
AsText : lưu số sau khi đã format(...) (hình thức thể hiện trên form, không dùng để tính toán)

Như vậy khi cho tham gia vào biểu thức tính toán thì dùng AsNumber để làm, có thể kết hợp hàm Round(AsNumber,nRound) .

Yeah, đúng thế. Phải sửa TextBox Control thôi. Nếu ko thì trong phần mềm thêm cả đống biến double, hoặc Database phải thêm cả đống trường thừa.

Hôm rồi thấy có người làm chứng từ có ngoại tệ, khi lưu thì lưu cả tiền cơ sở, tiền ngoại tệ ==> Thêm 1 cơ số trường vào bảng cả master lẫn detail của chứng từ. Lúc load lên form thì ẩn đi 1 cơ số textboxes (cho master) và cột (cho detail grid). Làm thế thì mệt lắm!

Solution tốt nhất: Textbox Control hỗ trợ .Text (lưu theo .DataFormat) và .Value (lưu giá trị thực). Còn khi ghi vào CSDL rồi thì chấp nhận làm tròn số thôi. Không có cách nào cả (vì còn trường hợp 10/3 = 3.333333... nữa mà, làm sao giải quyết được tận gốc)

Mình không bị điều đó, vì xài Property Textbox.format chứ không dùng hàm format, tại Access và Fox không có hoặc không học tới, --> tầm mắt chỉ tới đó (hii)

Yeah, vì VNUNI dùng bộ vnuniSuiteEdit Control tự phát triển nên chưa làm giống Access và Fox. Có lẽ sửa lại bộ control đó để khi .Text thì nó trả về giá trị đúng Format, .Value thì nó trả về đúng giá trị thật của Textbox

 

[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.