Tổng hợp các phương pháp tính trị giá hàng tồn kho

Liên hệ QC
Trị giá hàng tồn được tính theo giá bình quân liên hoàn

Với cách tính này, mỗi lần nhập hàng sẽ tính lại đơn giá cho lần xuất kế tiếp

Ta sẽ đi từ việc thiết lập các công thức tính toán từ dễ đến khó.

Giả sử ta có 2 Sheet :

Sheet DMMH có chứa mã MH và các số dư đầu kỳ. Tại Sheet này ta đặt 3 tên :
- TonMaMH cho cột chứa Mã MH,
- TonDauTG cho trị giá tồn đầu kỳ
- TonDauSL cho số lượng tồn đầu kỳ

BinhQuan06.jpg


Sheet thứ 2 là Sheet NhapXuatHH, Sheet này dùng để nhập các dữ liệu về Nhập Xuất HH phát sinh trong tháng

Tại Sheet này ta có các cột sau : Cột C là Mã MH, cột D là Số Lượng Nhap, cột E là TGNhap, cột F là SLXuat, cột G là TGXuat, cột H tính đơn giá vốn

BinhQuan05-1.jpg


Tại Cell đầu tiên tính đơn giá vốn, Cell H5, ta có công thức sau :

=IF(OR($C5="",SUMIF(TonMaMH,$C5,TonDauTG)=0),0,SUMIF(TonMaMH,$C5,TonDauTG)/SUMIF(TonMaMH,$C5,TonDauSL))

Bắt đầu Cell H6, công thức sẽ trở thành :

=IF(C6="",0,(SUMIF(TonMaMH,C6,TonDauTG)+SUMPRODUCT(($C$5:C5=C6)*($E$5:E5-$G$5:G5)))/(SUMIF(TonMaMH,C6,TonDauSL)+SUMPRODUCT(($C$5:C5=C6)*($D$5:D5-$F$5:F5))))

BinhQuan07-1.jpg


Một cách khác để rút gọn công thức là đặt tên cho từng đoạn công thức nhu sau :
Bạn đặt con trỏ ngay tại Cell H5 , rồi vào Insert / Name/ Define

Đặt tên cho các công thức sau :

SLDuDau = SUMPRODUCT((TonMaMH=NhapXuatHH!$C5)*TonDauSL)

BinhQuan08.jpg


TGDuDau = SUMPRODUCT((TonMaMH=NhapXuatHH!$C5)*TonDauTG)

BinhQuan09.jpg


Công thức trong Cell H5 sẽ trở thành :

=IF(OR(H5="",SLDuDau=0),0,TGDuDau/SLDuDau)

Bây giờ, ta đặt con trỏ tại Cell H6, và tiếp tục đặt tên cho công thức :

SLDuCuoi = SLDuDau+SUMPRODUCT((NhapXuatHH!$C$5:$C5=NhapXuatHH! $C6 )*(NhapXuatHH!$D$5:D5-NhapXuatHH!$F$5:F5))

TGDuCuoi = TGDuDau+SUMPRODUCT((NhapXuatHH!$C$5:$C5=NhapXuatHH!$C6)*(NhapXuatHH!$E$5:$E5-NhapXuatHH!$G$5:$G5)))

Công thức tại Cell H6 sẽ được viết thành :

=IF(OR(C6="",SLDuCuoi=0),0,TGDuCuoi/SLDuCuoi)

- Theo phương pháp này, giá vốn (average unit cost, UnitCost) được tính có thể là số rất lẻ và ko được làm tròn số. Thông thường phải lấy 4 chữ số hàng thập phân (ví dụ: 14.3555).

- Vì thế, Giá vốn hàng bán (Cost of Goods Sold) = SoldQty * UnitCost cũng rất lẻ.
- Khi tính tổng Nhập xuất tồn trong 1 kỳ (có thể là khoảng thời gian) thì sẽ xảy ra trường hợp:

Cuối kỳ (Lượng) = Đầu kỳ (Lượng) + PST (Lượng) - PSG (Lượng) = 0
Cuối kỳ (Giá trị) = Đầu kỳ (Giá trị) + PST (Giá trị) - PSG (Giá trị) <> 0 (Có thể là 1 con số lẻ rất nhỏ)

Ghi chú:
PST: Phát sinh tăng
PSG: Phát sinh giảm

Vậy theo mọi người, trường hợp này mọi người xử lý ra sao?

Nếu giả sử ta triệt tiêu Cuối kỳ (Giá trị) <> 0 đó đi khi Cuối kỳ (Lượng) = 0, thì khoản giá trị lệch bé xíu đó ta chuyển đi đâu? và ở kỳ tiếp theo, việc lệch về giá trị là sẽ tiếp tục xảy ra.
 
Lần chỉnh sửa cuối:
Mình đã biết vấn đề này và đã có cách giải quyết ở đây:
http://www.giaiphapexcel.com/forum/showthread.php?p=66930#post66930
trích:
Khi có giá bq rồi thì tính thành tiền xuất phải làm tròn:
ttxuat=round(giabq*sum(slxuat),0)
thành tiền cuối kỳ thì cộng trừ, đừng nhân. Mục đích là ra kết quả nguyên.
Để tránh trường hợp:

- nhập sl 3 x gbq 3,3333 = 10
xuất trong kỳ: sl 2 x gbq 3,3333 = 6,6666
tồn cuối: sl 1 x gbq 3,3333 = 3,3333

- Tương tự mặt hàng 2: nhập sl 11 x gbq 2,4545 = 27
xuất sl 8 x gbq 2,4545 = 19,63636
tồn cuối sl 3 x gbq 2,4545 = 7,3636

Lên báo cáo thường là định dạng số nguyên: (thực tế thì không)

XNTon.jpg


Sẽ thấy ngay dòng cộng : 3 + 7 = 11, không hay tí nào

Lâu ngày chầy tháng, xảy ra tình trạng hết số lượng, còn giá trị 1đ hoặc -1 đ, kiếm hoặc điều chỉnh mệt mỏi.

Hậu quả duy nhất là giá bình quân kỳ sau không giống giá bq kỳ trước, mà dù vậy có sao đâu?
 
Mình đã biết vấn đề này và đã có cách giải quyết ở đây:
http://www.giaiphapexcel.com/forum/showthread.php?p=66930#post66930
trích:
Khi có giá bq rồi thì tính thành tiền xuất phải làm tròn:
ttxuat=round(giabq*sum(slxuat),0)
thành tiền cuối kỳ thì cộng trừ, đừng nhân. Mục đích là ra kết quả nguyên.

Thanks ptm0412

Cách làm tròn số khi tính giá vốn hàng bán (COGS = SoldQty * Average unit cost) thì mình cũng đã nghĩ đến từ lâu rồi.

Tuy nhiên, tiền ngoại tệ ko thể làm tròn thế được. 0.01$ cũng có giá trị của nó. (Giả sử USD là based currency chứ ko phải VNĐ)

Ngoài ra, do mình nghiên cứu sách của nước ngoài thì có ghi chú thế này:

Cost of goods available for sale $280,000
Divided by units (4,000 + 6,000 + 8,000) 18,000
Average unit cost (note: do not round) $15.5555 per unit
Ending inventory (5,000 units @ $15.5555) $77,778
Cost of goods sold (13,000 units @ $15.5555) $202,222
 
Lần chỉnh sửa cuối:
Minh hoạ:

Bqgq.jpg


Qua kỳ 2 giá bq bị thay đổi, nếu còn tồn sang kỳ 3 như mặt hàng B, giá bq lại thay đổi. nhưng chả lẽ qua 3 kỳ mà không nhập thêm?
Vả lại thí dụ là 3 đồng và 2 đồng, nhưng thực sự có cái gì đơn giá dưới 1000 đồng?
Vậy thì tỷ lệ thay đổi giá 0,5 đồng /1000 đồng có là bao nhiêu?
 
hai2hai đã viết:
Tuy nhiên, tiền ngoại tệ ko thể làm tròn thế được. 0.01$ cũng có giá trị của nó. (Giả sử USD là based currency chứ ko phải VNĐ)

Theo quy luật làm phần mềm cho toàn thế giới thì không có khái niệm làm tròn tiền ngoại tệ theo cách round(amount, 0) vì 0.01$ cũng có giá trị của nó.

Giá vốn hàng bán là 1000.00$ khác hẳn với 1000.01$ bác ạ (vì ko được phép làm tròn tiền ngoại tệ 0.01$ thành 0.00$ được).

Có 1 số chuẩn trong khi sử lý số như sau:

Tiền VNĐ thì format dạng làm #,##0
Tiền ngoại tệ thì format dạng làm #,##0.00
Giá vốn thì format dạng làm #,##0.0000
Tỷ giá thì format dạng làm #,##0.0000
v.v...

Nếu Round(Amout$,0) thì bọn tây nó diệt tớ chết.

P/S: Cột "đơn giá" ở hình minh họa trên là ở thời điểm nào vậy?
 
Lần chỉnh sửa cuối:
Haì2hai post Bài nhanh quá!
Based currency là USD, thì quy ước report chắc là 2 số thập phân? Chắc nhìn báo cáo không đến nỗi 0 + 0 = 1 như VNĐ
 
Hai2hai post Bài nhanh quá!
Based currency là USD, thì quy ước report chắc là 2 số thập phân? Chắc nhìn báo cáo không đến nỗi 0 + 0 = 1 như VNĐ

Thế mà EndOfPeriod_Qty = 0, EndOfPeriod_Amt = 0.02 mới chết chứ --=0. Nếu làm tròn thì đẹp lắm (vì trước lấy VND làm BCur mà). Nhưng chẳng nhẽ đối với Based currency là USD mình cũng làm tròn Round(COGS, 0) thì ko biết có được ko. Based currency của khách hàng là đồng tiền của Séc (họ nói ko được làm tròn kiểu VN, mà cái này thì tớ lại nói với họ là ko bao giờ làm tròn tới hàng đơn vị nếu FC (foreign currency # VNĐ) được chọn là BC (Based currency). Hay là cứ ... kệ, làm tròn cho đẹp nhỉ :-=
 
Lần chỉnh sửa cuối:
Thì round(amount,2) vậy. vì:
Tiền ngoại tệ thì format dạng làm #,##0.00
Còn EndOfPeriod_Amt mình cộng trừ, đừng nhân. Phùuu. Đừng cười nhé!
Thực ra khách hàng đánh giá phần mềm chủ yếu nhìn trên report các loại (tức là kết quả), nếu kỹ hơn thì đánh giá thêm mấy cái form (giao diện), mà dù kỹ hơn nữa, mấy ai mà click chuột vào textbox coi thử có giấu số thập phân đằng sau không.
Chả lẽ khách hàng đòi coi code D:
 
Thì round(amount,2) vậy. vì:

Còn EndOfPeriod_Amt mình cộng trừ, đừng nhân. Phùuu. Đừng cười nhé!

EndOfPeriod_Amt tức là dư Cuối kỳ (Giá trị)

Cuối kỳ (Giá trị) = Đầu kỳ (Giá trị) + SUM{PST (Giá trị)} - SUM{PSG (Giá trị)}

Vì các giá trị SUM{PST (Giá trị)}, SUM{PSG (Giá trị)} nó lẻ nên Cuối kỳ (Giá trị) mới bị lẻ như vậy.

Có lẽ nên thay:

Cuối kỳ (Giá trị) = Round(Đầu kỳ (Giá trị) + SUM{PST (Giá trị)} - SUM{PSG (Giá trị)},0)

Không cho giá trị tồn kho (đầu, cuối) lẻ nhỉ. Còn kệ, cho PST, PSG nó muốn lẻ thế nào thì mặc. Nhỉ!
 
Lần chỉnh sửa cuối:
Thực ra khách hàng đánh giá phần mềm chủ yếu nhìn trên report các loại (tức là kết quả), nếu kỹ hơn thì đánh giá thêm mấy cái form (giao diện), mà dù kỹ hơn nữa, mấy ai mà click chuột vào textbox coi thử có giấu số thập phân đằng sau không.
Chả lẽ khách hàng đòi coi code D:
 
Thực ra khách hàng đánh giá phần mềm chủ yếu nhìn trên report các loại (tức là kết quả), nếu kỹ hơn thì đánh giá thêm mấy cái form (giao diện), mà dù kỹ hơn nữa, mấy ai mà click chuột vào textbox coi thử có giấu số thập phân đằng sau không.
Chả lẽ khách hàng đòi coi code D:

Họ ko cần coi code đâu, khách hàng họ có bộ dữ liệu chạy thử trên Excel của họ (vẫn để lẻ như thường). Sau đó, họ nhập y trang những dữ liệu như vậy vào PM của mình.

Rồi họ so sánh 2 kết quả. Phải ko được khác nhau kể cả 1 con số, 1 dấu phảy,... thì mới được chấp nhận (Đó là 1 trong nhiều loại test, và sử dụng phương pháp gọi là black test)

@ptm0412: Cột "đơn giá" ở hình minh họa trên là ở thời điểm nào vậy?

Ah, về việc tính giá vốn, mình tính giá vốn ngay ở chứng từ nhập hàng. lúc bán hàng (xuất hàng), mình lấy giá vốn đó ở ngay giao dịch phía trước nó.

vì thế, SUM(PST, PSG) mình lấy ngay từ các giá trị hàng nhập (receipt amount) và giá vốn hàng bán (COGS) ngay trên các giao dịch trong kỳ lựa chọn.

Dĩ nhiên, khi kinh doanh thì ko chỉ có mỗi mua (nhập mua) với bán (xuất bán), còn có trả lại hàng (mua & bán), chuyển kho (mỗi kho có thể tự nhập hàng nên khi chuyển kho cũng làm thay đổi giá vốn tại kho đó), điều chỉnh kho (tăng/giảm), phiếu lắp giáp, tháo dỡ.
 
Lần chỉnh sửa cuối:
Cột đơn giá đó là đơn giá thời điểm (at moment), vì trong bảng tính thực sự thì :
- tồn đầu (sl và tt) lấy từ kỳ trước
- cột nhập(sl và tt) tổng hợp từ chứng từ nhập. Hễ có phát sinh là nó cộng dồn vào
- cột đơn giá là = (tt DK + ttnhap) / (slDK + slnhap), hễ có phát sinh nhập là tính lại.(đủ loại nhập). Giá này ổn định để tính giá xuất cho đến lần nhập sau

Theo kiểu Việt nam thì bảng này cuối kỳ mới in nên đơn giá khi in là giá bq cả tháng, giá xuất và thành tiền xuất cũng tính 1 lần cuối tháng.
Trước đó nếu cần tính COGS thì cũng lấy nó, nhưng chỉ là tạm tính, cuối tháng mới tính lại lần cuối và in ra.
-----------
Chi phí vận chuyển, tháo lắp, ... cũng là 1 giao dịch, số lượng bằng 0, thành tiền theo chứng từ, của mặt hàng nào tính cho mặt hàng đó, (cũng có 1 dòng giao dịch với mã hàng, số lượng, ttiền như phiếu nhập kho, chỉ khác số lượng bằng không, nên thành tiền cũng cộng dồn vào cột thành tiền nhập trong bảng thí dụ ==> TĂNG GIÁ TỒN KHO)
 
Lần chỉnh sửa cuối:
Cột đơn giá đó là đơn giá thời điểm (at moment), vì trong bảng tính thực sự thì :
- tồn đầu (sl và tt) lấy từ kỳ trước
- cột nhập(sl và tt) tổng hợp từ chứng từ nhập. Hễ có phát sinh là nó cộng dồn vào
- cột đơn giá là = (tt DK + ttnhap) / (slDK + slnhap), hễ có phát sinh nhập là tính lại.(đủ loại nhập). Giá này ổn định để tính giá xuất cho đến lần nhập sau

Theo kiểu Việt nam thì bảng này cuối kỳ mới in nên đơn giá khi in là giá bq cả tháng, giá xuất và thành tiền xuất cũng tính 1 lần cuối tháng.
Trước đó nếu cần tính COGS thì cũng lấy nó, nhưng chỉ là tạm tính, cuối tháng mới tính lại lần cuối và in ra.

Bqgq.jpg


Theo như báo cáo trên thể hiện thì đó là báo cáo Nhập Xuất tồn theo từng kỳ (vì có chữ "Đầu" và "Cuối")

Một khi đã theo kỳ thì tức là ko phải theo thời điểm, nếu ko thì phải ghi rất rõ đó là Giá vốn ở cuối kỳ hay ở đầu kỳ.

Hình vẽ sau đây mới chỉ rõ về MOVING AVERAGE
http://www.turboimagehost.com/p/306420/gonzalespertualavg.v2.PNG.html
 
Lần chỉnh sửa cuối:
Tại Việt nam chỉ yêu cầu vậy. thực ra vào ngày giữa kỳ mà nhìn vào nó, hoặc in nó ra, thì nó là giá tại thời điểm đó.
 
Theo em thay vì viết code để chạy giá trung bình theo từng lần nhập, thì ta viết code để chạy giá trung bình theo ngày. Đến cuối ngày, những mặt hàng nào còn số lượng và thành tiền thì không cần để ý tới; những mặt hàng nào có số lượng = 0, thành tiền <> 0 thì tùy thuộc vào yêu cầu của ngời làm kế toán, ta viết code để phân bổ hoặc là vào giá vốn của mặt hàng xuất cuối cùng hoặc là vào chi phí ...
 
Do dùng công thức Excel nên nó cứ tự tính lại như thế, nếu dùng code tính từng lần xuất và gán giá trị vào cell, thì đúng chính xác là giá thời điểm từng lần xuất. Các phần mềm không phải Excel cũng tính như thế. Sẽ có lợi là phiếu xuất kho có giá trị (amount) ngay để in ra chính thức và hạch toán luôn.
(Trong Access mình tính bằng code trên form nhập liệu)
Lúc này trên bảng tổng hợp nhập xuất tồn (như ví dụ), cột thành tiền xuất cũng phải tính tổng từng lần xuất cho mỗi mặt hàng, không được lấy tổng số lượng nhân đơn giá nữa.
 
Theo em thay vì viết code để chạy giá trung bình theo từng lần nhập, thì ta viết code để chạy giá trung bình theo ngày. Đến cuối ngày, những mặt hàng nào còn số lượng và thành tiền thì không cần để ý tới; những mặt hàng nào có số lượng = 0, thành tiền <> 0 thì tùy thuộc vào yêu cầu của ngời làm kế toán, ta viết code để phân bổ hoặc là vào giá vốn của mặt hàng xuất cuối cùng hoặc là vào chi phí ...

Đó cũng là 1 cách hay. Tớ tính lượng và giá trị tồn theo từng thời điểm cho từng chứng từ 1 (mỗi khi save chứng từ) một cách cực nhanh (mà ko cần đợi tới cuối ngày, tính tức thời lãi gộp của hàng hóa ngay tại thời điểm bán). Có lẽ sẽ kiểm tra luôn lượng tồn = 0, giá trị tồn <> 0 ở từng thời điểm đó để "xử lý" (phân bổ vào giá vốn của mặt hàng xuất cuối cùng) nó luôn.

Dĩ nhiên khi sửa hoặc xóa chứng từ thì sẽ tự động chạy update lại từ chứng từ đó tới thời điểm hiện tại.
 
Lần chỉnh sửa cuối:
Đó cũng là 1 cách hay. Tớ tính lượng và giá trị tồn theo từng thời điểm cho từng chứng từ 1 (mỗi khi save chứng từ) một cách cực nhanh (mà ko cần đợi tới cuối ngày). Có lẽ sẽ kiểm tra luôn lượng tồn = 0, giá trị tồn <> 0 ở từng thời điểm đó để "xử lý" (phân bổ hoặc là vào giá vốn của mặt hàng xuất cuối cùng) nó luôn.

Dĩ nhiên khi sửa hoặc xóa chứng từ thì sẽ tự động chạy update lại từ chứng từ đó tới thời điểm hiện tại.
Thực hiện được việc tính giá trị tồn theo từng thời điểm thì quả là quá tuyệt. Nhưng vẫn còn một số vấn đề em thấy hơi gợn (chưa được tối ưu trong việc tính giá):
1- Liệu có đảm bảo là không sửa, xóa phiếu nhập không?
2- Nếu có thì việc giá của các phiếu xuất được trong khoảng thời gian từ lúc mở phiếu nhập được sửa tới lúc sửa xong phiếu nhập đó là như thế nào? VD: Thời điểm mở phiếu nhập số 10 (có nhập mặt hàng A) là 13h21'25"; Thời điểm mở phiếu xuất số 15 (có xuất mặt hàng A) là 13h30'18"; Thời điểm sửa phiếu nhập số 1 (sửa lại số lượng hoặc giá của mặt hàng A) là 14h22'00". Vậy giá của mặt hàng A trong phiếu xuất số 15 lấy theo thời điểm nào?
3- Người nhập số liệu nhận cùng một lúc các tập phiếu nhập và phiếu xuất thì việc lựa chọn vào phiếu nhập trước hay phiếu xuất trước cũng sẽ ảnh hưởng rất nhiều đến việc tính giá.
4- Việc tự update giá liên tục ngay sau khi save chứng từ cũng ảnh hưởng không nhỏ tới tốc độ làm việc của máy.
 
Thực hiện được việc tính giá trị tồn theo từng thời điểm thì quả là quá tuyệt. Nhưng vẫn còn một số vấn đề em thấy hơi gợn (chưa được tối ưu trong việc tính giá):
1- Liệu có đảm bảo là không sửa, xóa phiếu nhập không?
2- Nếu có thì việc giá của các phiếu xuất được trong khoảng thời gian từ lúc mở phiếu nhập được sửa tới lúc sửa xong phiếu nhập đó là như thế nào? VD: Thời điểm mở phiếu nhập số 10 (có nhập mặt hàng A) là 13h21'25"; Thời điểm mở phiếu xuất số 15 (có xuất mặt hàng A) là 13h30'18"; Thời điểm sửa phiếu nhập số 1 (sửa lại số lượng hoặc giá của mặt hàng A) là 14h22'00". Vậy giá của mặt hàng A trong phiếu xuất số 15 lấy theo thời điểm nào?
3- Người nhập số liệu nhận cùng một lúc các tập phiếu nhập và phiếu xuất thì việc lựa chọn vào phiếu nhập trước hay phiếu xuất trước cũng sẽ ảnh hưởng rất nhiều đến việc tính giá.
4- Việc tự update giá liên tục ngay sau khi save chứng từ cũng ảnh hưởng không nhỏ tới tốc độ làm việc của máy.

Re 1: Với phần mềm "chuyên nghiệp", việc tính lại giá vốn, rồi tính lại balance ngay từ thời điểm đó tới tận thời điểm giao dịch cuối cùng với tốc độ khá nhanh là điều không vấn đề gì vì theo phương pháp là nó chỉ làm việc tới những đối tượng bị thay đổi. chứ ko chạy lại tất cả mọi thứ.
Ví dụ: Khi thay đổi thông tin trên 1 (hoặc nhiều) dòng hàng của 1 chứng từ thì nó sẽ thay đổi kết quả dữ liệu bao gồm các vấn đề sau:
- Số lượng tồn (chỉ của những mặt hàng đã bị thay đổi mà thôi)
- Giá vốn (chỉ của những mặt hàng đã bị thay đổi mà thôi)
- Giá trị tồn (chỉ của những mặt hàng đã bị thay đổi mà thôi, chuyển kỳ ngay khi chạy tính lại giá vốn)
- Công nợ của khách hàng
- Các số dư của các đối tượng, tài khoản khác liên quan

Khi đó, ta chỉ chạy UpdateBatch tính từ thời điểm (chứng từ đó) trở về sau. Việc này sẽ hỏi ngay người dùng khi sửa chứng từ.

Việc delete chứng từ cũng làm tương tự như vậy (nhưng affect to all line items in transaction detail)

Re 2: Giả sử phiếu nhập bị sửa lại (tức là có 2 thời điểm cập nhật giá)
Giá vốn sẽ được tính dựa trên thứ tự của các giao dịch theo quy tắc sau:
- TransDate (ngày chứng từ)
- TransNo (Số chứng từ - được sắp xếp tăng dần đối với mọi loại chứng từ - có thể đổi lại thứ tự này theo đúng thứ tự của giao dịch)
- ID (thứ tự tạo chứng từ - gọi là TransID - số này có kiểu Long, là duy nhất, tự tăng lúc tạo chứng từ)

Như vậy, sẽ ko dựa trên thời gian lúc sửa chứng từ mà dựa trên quy tắc trên để tính giá vốn

Re 3: Trong trường hợp môi trường "Đa người dùng", vẫn dựa trên quy tắc thứ tự giao dịch ở trên (dĩ nhiên số chứng từ phải được quy định cái nào trước, cái nào sau theo đúng thời điểm giao dịch thực tế xảy ra). Như vậy, sẽ ko ảnh hưởng gì đến sự chính xác của giá vốn theo đúng thực tế giao dịch KT phát sinh.

Re 4: Việc cập nhật, tính toán lại mỗi khi sửa/xóa chứng từ sẽ có lựa chọn trong phần lựa chọn (options) của phần mềm. Các option đó như sau:
- Tính lại ngay mọi thứ khi save chứng từ (không hỏi han gì cả)
- Hỏi tính lại (nhắc nhở) trước khi save chứng từ nếu có thay đổi (this option is Default)
- Không tính toán gì cả (lúc nào thích tính lại thì tính)

Đấy là vấn đề chạy lại (từ thời điểm đó tới thời điểm cuối cùng) thì mới hỏi han, lựa chọn như vậy. Dĩ nhiên, như Re 1 đã nói, tốc độ là ko đáng kể (tính theo giây) đối với dữ liệu khoảng vài trăm nghìn dòng chứng từ, vài phút đối với triệu dòng hàng chứng từ. Dĩ nhiên, sẽ phải tự động chuyển sang chế độ hỏi (nhắc nhở) nếu số lượng dữ liệu là quá lớn hoặc cần thao tác nhập liệu nhanh liên tục.

Còn việc tính TỨC THỜI giá vốn, balance_qty, balance_amt (theo phương pháp lưu ngay ở mỗi thời điểm thì tính nhanh kinh khủng) vì ... có phải tính toán gì nhiều đâu. Tớ nghiên cứu cả tuần nay (đập đi đập lại cái thiết kế ít nhất 3 lần) mới ra cái cách này đấy :).

Hope that clear!

Thanks
 
Lần chỉnh sửa cuối:
Đụng đến lập trình, update balance, nhiều người dùng... mình thua, không dám bàn.
Nhưng còn chỗ này, Hai2hai xem lại:

Hai2hai đã viết:
Có lẽ nên thay:
Cuối kỳ (Giá trị) = Round(Đầu kỳ (Giá trị) + SUM{PST (Giá trị)} - SUM{PSG (Giá trị)},0)
Không cho giá trị tồn kho (đầu, cuối) lẻ nhỉ. Còn kệ, cho PST, PSG nó muốn lẻ thế nào thì mặc. Nhỉ!

Bỏ qua cột đơn giá, vì đã dùng code tính từng thời điểm rồi. Nhưng nếu làm tròn tồn cuối mà không làm tròn xuất (dù based Currency là gì: đồng thì round(amount,0) USD thì round(amount,2) cũng như round(cent,0)) :

Giatron.jpg


Ở từng dòng thì chưa thấy có vấn đề nhưng ở dòng cộng: (Khi lên báo cáo có định dạng) thì 620 - 332 = 289
Giatron2.jpg


Ngoài ra những báo cáo sẽ không khớp nhau khi kiểm tra chéo: như dùng dòng tài khoản lợi nhuận trên bảng cân đối phát sinh để kiểm tra lợi nhuận trên báo cáo Kết quả hoạt động kinh doanh có thể không khớp. Vì BCKQHĐKD dựa trên phát sinh, cộng trừ phát sinh nhiều tài khoản, mỗi TK lệch một chút nhéo.
 
Web KT
Back
Top Bottom