Phát triển bài toán tổng hợp xuất nhập tồn hàng hóa bằng các ngôn ngữ lập trình khác (1 người xem)

Liên hệ QC

Người dùng đang xem chủ đề này

Cá ngừ F1

( ͡° ͜ʖ ͡°)
Thành viên BQT
Moderator
Tham gia
1/1/08
Bài viết
2,579
Được thích
3,723
Donate (Momo)
Donate
Giới tính
Nam
Nghề nghiệp
Quan hệ.. và quan hệ..
Gửi các anh/chị,
Từ khá lâu, khởi nguồn từ một Cuộc thi tạo sổ tổ hợp nhập xuất tồn trong Excel tốc độ nhanh nhất của anh @Nguyễn Duy Tuân. Với việc tổng hợp offline (dữ liệu đã có trên sheet) thì Dictionary trong VBA đúng là vô địch về tốc độ.

Tuy nhiên, giờ đây với tiêu chí online, các dữ liệu đều được đưa lên mây. Do đó em có đưa dữ liệu file này lên OneDrive, File dữ liệu tại đường dẫn: https://onedrive.live.com/download?resid=9D22195809ABDE05%215236&authkey=AH8ldUa8sYEK9m4&em=2
File này gồm 3 sheet: (1) Mã HHDV; (2) Tồn đầu kỳ; (3) Phát sinh trong kỳ. File này anh @ptm0412 cấu trúc lại thành hơn 1tr dòng.

Sổ tổng hợp xuất nhập tồn em làm trong File Report bằng Power Query, get data trực tiếp từ đường dẫn trên.
Nguyên tắc tính các trường trong sổ (như bài gốc):
DateFrom (ô D1), DateTo (ô D2)
- Lượng Tồn đầu = lượng nhập với ngày < DateFrom - lượng xuất với ngày < DateFrom
- Lượng Nhập trong kỳ = lượng nhập với ngày >= DateFrom và ngày <= DateTo
- Lượng Xuất trong kỳ = lượng xuất với ngày >= DateFrom và ngày <= DateTo
- Lượng tồn cuối = Lượng Tồn đầu + Lượng Nhập trong kỳ - Lượng Xuất trong kỳ

Snag_6876478f.png

Quả thật, làm offline bằng Power Query cũng chậm không thể so sánh được với VBA trong bài toán này. Mà làm online thì cũng không nhanh. Như File em làm lấy cả năm thì mất khoảng 4 phút.

Gần đây, em thấy rất nhiều thành viên bàn luận sôi nổi về các ứng dụng lập trình cao cấp như Delphi/Python/Dax/PowerBI/SQL...
Nên em mạnh dạn đưa lại bài này, mong các thành viên có thể xử lý bằng các chương trình lập trình cao cấp trên để bài toán chạy nhanh hơn. Làm sao lấy dữ liệu từ onedrive (đường link như e đã viết ở trên), tính toán, dán xuống sheet như Form của báo cáo trong file excel.

Kể cả với bài PowerQuery này, chắc chắn Code cũng chưa tối ưu nên mới chậm vậy, em mong các thành viên hỗ trợ chỉnh sửa để nó nhanh hơn.

Em cảm ơn.
 

File đính kèm

File trong link dưới đây là file có số dư từng tháng, tạo ra theo code của chủ đề "tạo file nhập xuất tồn 1 triệu dòng". Trong chủ đề đó nhờ tạo các bảng tồn từng tháng nên số tồn đầu báo cáo được tính từ bảng tồn gần nhất, giảm thiểu được vòng lặp và tốc độ rất nhanh: Xử lý 1 triệu dòng bằng VBA, ra báo cáo 13 ngàn dòng trong khoảng 3 - 3.5 giây.

link file data trên OneDrive,
link để kết nối Power query: https://onedrive.live.com/download?resid=B9C418BAD6EBE6BA!1374&authkey=AKLqnHtbkOGWJy0&em=2

Và cũng theo xu hướng online ( :) :) )như @Cá ngừ F1 nói, tôi cũng thử làm bằng Power Query, tốc độ khoảng 1 phút. Trong đó cũng dùng những bảng số dư từng tháng như khi dùng VBA, đặc biệt query tồn đầu này là query động theo kỳ báo cáo, thậm chí là theo ngày đầu báo cáo để lấy bảng số dư gần nhất.
Phần code chính cũng theo thuật toán của VBA:
- Lấy tồn đầu gần nhất so với kỳ báo cáo (query TonDau)
- Tính nhập trừ xuất (phát sinh) trong khoảng từ ngày tồn đầu đến ngày đầu báo cáo (query DataPrevious)
- Lấy Tồn đầu gần nhất cộng phát sinh trước kỳ BC để ra tồn đầu kỳ báo cáo
- Tính nhập và xuất trong kỳ báo cáo (query DataCurrent)
- Tính tồn cuối kỳ.
- Lấy hết mặt hàng trong danh mục, nhưng lọc bỏ những mặt hàng không tồn và cũng không phát sinh, chỉ để lại những mặt hàng có tồn đầu và/ hoặc có phát sinh.

Tốc độ không ảnh hưởng khi chọn kỳ báo cáo đầu năm hay cuối năm, kỳ báo cáo ngắn vài ngày hay báo cáo cả năm, vì không sử dụng vòng lặp nên không giảm số lần lặp như VBA
 

File đính kèm

Gửi các anh/chị,
Từ khá lâu, khởi nguồn từ một Cuộc thi tạo sổ tổ hợp nhập xuất tồn trong Excel tốc độ nhanh nhất của anh @Nguyễn Duy Tuân. Với việc tổng hợp offline (dữ liệu đã có trên sheet) thì Dictionary trong VBA đúng là vô địch về tốc độ.

Tuy nhiên, giờ đây với tiêu chí online, các dữ liệu đều được đưa lên mây. Do đó em có đưa dữ liệu file này lên OneDrive, File dữ liệu tại đường dẫn: https://onedrive.live.com/download?resid=9D22195809ABDE05%215236&authkey=AH8ldUa8sYEK9m4&em=2
File này gồm 3 sheet: (1) Mã HHDV; (2) Tồn đầu kỳ; (3) Phát sinh trong kỳ. File này anh @ptm0412 cấu trúc lại thành hơn 1tr dòng.

Sổ tổng hợp xuất nhập tồn em làm trong File Report bằng Power Query, get data trực tiếp từ đường dẫn trên.
Nguyên tắc tính các trường trong sổ (như bài gốc):
DateFrom (ô D1), DateTo (ô D2)
- Lượng Tồn đầu = lượng nhập với ngày < DateFrom - lượng xuất với ngày < DateFrom
- Lượng Nhập trong kỳ = lượng nhập với ngày >= DateFrom và ngày <= DateTo
- Lượng Xuất trong kỳ = lượng xuất với ngày >= DateFrom và ngày <= DateTo
- Lượng tồn cuối = Lượng Tồn đầu + Lượng Nhập trong kỳ - Lượng Xuất trong kỳ

View attachment 267396

Quả thật, làm offline bằng Power Query cũng chậm không thể so sánh được với VBA trong bài toán này. Mà làm online thì cũng không nhanh. Như File em làm lấy cả năm thì mất khoảng 4 phút.

Gần đây, em thấy rất nhiều thành viên bàn luận sôi nổi về các ứng dụng lập trình cao cấp như Delphi/Python/Dax/PowerBI/SQL...
Nên em mạnh dạn đưa lại bài này, mong các thành viên có thể xử lý bằng các chương trình lập trình cao cấp trên để bài toán chạy nhanh hơn. Làm sao lấy dữ liệu từ onedrive (đường link như e đã viết ở trên), tính toán, dán xuống sheet như Form của báo cáo trong file excel.

Kể cả với bài PowerQuery này, chắc chắn Code cũng chưa tối ưu nên mới chậm vậy, em mong các thành viên hỗ trợ chỉnh sửa để nó nhanh hơn.

Em cảm ơn.
Tôi làm lại bằng power query refresh khoảng hơn 1 phút thôi, Dax/PowerBI nó giống power pivot tôi có làm rồi, Power query nó là dạng query ra kết quả luôn, nên thời gian của nó sẽ bằng thời gian load dữ liệu+thời gian tính toán, mà phần lớn là load dữ liệu nên power query không hề chậm, ví dụ bạn để dữ liệu trên onedrive thì nó sẽ phụ thuộc vào mạng, thì dùng ngôn ngữ hay tool nào thì cũng phải load load theo giới hạn của mạng thôi, còn với bài này thì nên dùng power pivot (không cần làm mới source), power query thì nên sử dụng khi cần real time (làm mới source liên tục). Python thì VBA chậm hơn khá nhiều dữ liệu càng lớn thì chênh lệch càng cao, tôi chạy với bài này mất khoảng 1.1s (0.7s connect dữ liệu, 0.4s tính +xuất excel). Python get dữ liệu từ onedrive được nhưng nó phụ thuộc vào mạng, nên tôi làm local để so với VBA luôn 1633719881356.png
 
Tôi làm lại bằng power query refresh khoảng hơn 1 phút thôi, Dax/PowerBI nó giống power pivot tôi có làm rồi, Power query nó là dạng query ra kết quả luôn, nên thời gian của nó sẽ bằng thời gian load dữ liệu+thời gian tính toán, mà phần lớn là load dữ liệu nên power query không hề chậm, ví dụ bạn để dữ liệu trên onedrive thì nó sẽ phụ thuộc vào mạng, thì dùng ngôn ngữ hay tool nào thì cũng phải load load theo giới hạn của mạng thôi, còn với bài này thì nên dùng power pivot (không cần làm mới source), power query thì nên sử dụng khi cần real time (làm mới source liên tục). Python thì VBA chậm hơn khá nhiều dữ liệu càng lớn thì chênh lệch càng cao, tôi chạy với bài này mất khoảng 1.1s (0.7s connect dữ liệu, 0.4s tính +xuất excel). Python get dữ liệu từ onedrive được nhưng nó phụ thuộc vào mạng, nên tôi làm local để so với VBA luôn View attachment 267403
Python mà offline tốc độ gớm thật.
Anh up file power query cho mọi người tham khảo M code với ạ.
 
Từ khá lâu, khởi nguồn từ một Cuộc thi tạo sổ tổ hợp nhập xuất tồn trong Excel tốc độ nhanh nhất của anh @Nguyễn Duy Tuân. Với việc tổng hợp offline (dữ liệu đã có trên sheet) thì Dictionary trong VBA đúng là vô địch về tốc độ.

Quả thật, làm offline bằng Power Query cũng chậm không thể so sánh được với VBA trong bài toán này. Mà làm online thì cũng không nhanh. Như File em làm lấy cả năm thì mất khoảng 4 phút.

Gần đây, em thấy rất nhiều thành viên bàn luận sôi nổi về các ứng dụng lập trình cao cấp như Delphi/Python/Dax/PowerBI/SQL...
Nên em mạnh dạn đưa lại bài này, mong các thành viên có thể xử lý bằng các chương trình lập trình cao cấp trên để bài toán chạy nhanh hơn. Làm sao lấy dữ liệu từ onedrive (đường link như e đã viết ở trên), tính toán, dán xuống sheet như Form của báo cáo trong file excel.

Ngoài lề Excel một chút, tôi xử lý offline bằng Access Query thì mất khoảng 17s, nếu xuất ra Excel luôn thì 21s.

Screen Shot 2021-10-09 at 07.59.50.png

Screen Shot 2021-10-09 at 07.57.16.png
 
Ngoài lề Excel một chút, tôi xử lý offline bằng Access Query thì mất khoảng 17s, nếu xuất ra Excel luôn thì 21s.
Theo tôi nghĩ thì query đang có sẵn, và tính toán sẵn, thời gian 21s chủ yếu là xuất ra excel. Nếu test trực tiếp trên Access thì nhanh hơn nhiều chứ không phải 17s:
- Mở query tại access (datasheet view)
- Code: Thay tham số ngày bắt đầu và/ hoặc ngày kết thúc, requery, tính giờ
 
Click thẳng vào cái link đó là download file về mà nhỉ? Đưa link đó vô VBA không được hả anh?
Tưởng phải download để xử lý bằng vba (và các code search trên mạng đều không tải được nếu không có url gồm tên file tường minh) nhưng sau đó tôi thử mở trực tiếp bằng Workbooks.Open thì được.
 
Tưởng phải download để xử lý bằng vba (và các code search trên mạng đều không tải được nếu không có url gồm tên file tường minh) nhưng sau đó tôi thử mở trực tiếp bằng Workbooks.Open thì được.
Vâng anh,
Nếu workbooks.open về, dùng ADO để get data về xong chạy, không biết có nhọc không?
 
Vâng anh,
Nếu workbooks.open về, dùng ADO để get data về xong chạy, không biết có nhọc không?
Bạn thử là biết mà
Còn thao tác với file của google hay microsoft thì phải có api của hãng theo cú pháp của tùy công ty quy định để bảo mật.
 
Lần chỉnh sửa cuối:

File đính kèm

Tôi làm lại bằng power query refresh khoảng hơn 1 phút thôi, Dax/PowerBI nó giống power pivot tôi có làm rồi, Power query nó là dạng query ra kết quả luôn, nên thời gian của nó sẽ bằng thời gian load dữ liệu+thời gian tính toán, mà phần lớn là load dữ liệu nên power query không hề chậm, ví dụ bạn để dữ liệu trên onedrive thì nó sẽ phụ thuộc vào mạng, thì dùng ngôn ngữ hay tool nào thì cũng phải load load theo giới hạn của mạng thôi, còn với bài này thì nên dùng power pivot (không cần làm mới source), power query thì nên sử dụng khi cần real time (làm mới source liên tục). Python thì VBA chậm hơn khá nhiều dữ liệu càng lớn thì chênh lệch càng cao, tôi chạy với bài này mất khoảng 1.1s (0.7s connect dữ liệu, 0.4s tính +xuất excel). Python get dữ liệu từ onedrive được nhưng nó phụ thuộc vào mạng, nên tôi làm local để so với VBA luôn View attachment 267403
Như code này của anh @excel_lv1.5 thì phải save as các sheet thành File CSV anh nhỉ? có thể Get trực tiếp File excel không anh?
 
Theo tôi nghĩ thì query đang có sẵn, và tính toán sẵn, thời gian 21s chủ yếu là xuất ra excel. Nếu test trực tiếp trên Access thì nhanh hơn nhiều chứ không phải 17s:
Tôi thử làm offline trên Access. Query có SQL là:
SQL:
Select dm.* , iif(dk.SL01 > 0,dk.SL01,0) +iif(pre.pssl > 0,pre.pssl,0) as SLdkBC,
iif(dk.ttien01>0,dk.ttien01,0)+ iif( pre.pstt>0,pre.pstt,0) as TTDkBC, dtps.sln,dtps.ttn, dtps.slx,dtps.ttx,
iif(SLdkBC>0,SLdkBC,0)+iif(dtps.sln>0,dtps.sln,0) - iif(dtps.slx,dtps.slx,0) as SLCky,
iif(TTDkBC>0,TTDkBC,0) + iif(dtps.ttn>0,dtps.ttn,0) - iif(dtps.ttx >0,dtps.ttx,0) as TTCky
from ( (danhmuc dm left join Ton1 dk on dm.MA_VLSPHH = dk.Ma01)
left join (select dt.MA_VLSPHH as Ma,sum(iif(dt.loai_phieu="N",dt.slg,- dt.slg)) as PSSL, 
    sum(iif(dt.loai_phieu="N",dt.THANH_TIEN,- dt.THANH_TIEN)) as PStt
    from data dt where dt.ngay_ct < dateserial(2013,2,1) group by dt.MA_VLSPHH ) as Pre  on pre.Ma=dm.MA_VLSPHH )
left join (select dt.MA_VLSPHH as Ma,sum(iif(dt.loai_phieu="N",dt.slg,0)) as sln,  sum(iif(dt.loai_phieu="N",dt.THANH_TIEN,0)) as ttn,
 sum(iif(dt.loai_phieu="X",dt.slg,0)) as slx,  sum(iif(dt.loai_phieu="X",dt.THANH_TIEN,0)) as ttx
    from data dt where dt.ngay_ct >= dateserial(2013,2,1) and dt.ngay_ct <= dateserial(2013,2,28) group by dt.MA_VLSPHH ) as dtps
     on dtps.Ma=dm.MA_VLSPHH

Trong đó DateFrom là dateserial(2013,2,1) và DateTo là dateserial(2013,2,28) (nguyên tháng 2)
Từ SQL view sửa DateTo thành ngày khác (thí dụ dateserial(2013,3,31), nhấn nút xem DataSheet view thì khoảng 2 giây.

Hình 1: SQL view, nhấn nút datasheet view
1633794119794.png

Hình 2: Datasheet view

1633794187513.png
 
Lần chỉnh sửa cuối:
Tôi thử làm offline trên Access. Query có SQL là:
SQL:
Select dm.* , iif(dk.SL01 > 0,dk.SL01,0) +iif(pre.pssl > 0,pre.pssl,0) as SLdkBC,
iif(dk.ttien01>0,dk.ttien01,0)+ iif( pre.pstt>0,pre.pstt,0) as TTDkBC, dtps.sln,dtps.ttn, dtps.slx,dtps.ttx,
iif(SLdkBC>0,SLdkBC,0)+iif(dtps.sln>0,dtps.sln,0) - iif(dtps.slx,dtps.slx,0) as SLCky,
iif(TTDkBC>0,TTDkBC,0) + iif(dtps.ttn>0,dtps.ttn,0) - iif(dtps.ttx >0,dtps.ttx,0) as TTCky
from ( (danhmuc dm left join Ton1 dk on dm.MA_VLSPHH = dk.Ma01)
left join (select dt.MA_VLSPHH as Ma,sum(iif(dt.loai_phieu="N",dt.slg,- dt.slg)) as PSSL, 
    sum(iif(dt.loai_phieu="N",dt.THANH_TIEN,- dt.THANH_TIEN)) as PStt
    from data dt where dt.ngay_ct < dateserial(2013,2,1) group by dt.MA_VLSPHH ) as Pre  on pre.Ma=dm.MA_VLSPHH )
left join (select dt.MA_VLSPHH as Ma,sum(iif(dt.loai_phieu="N",dt.slg,0)) as sln,  sum(iif(dt.loai_phieu="N",dt.THANH_TIEN,0)) as ttn,
 sum(iif(dt.loai_phieu="X",dt.slg,0)) as slx,  sum(iif(dt.loai_phieu="X",dt.THANH_TIEN,0)) as ttx
    from data dt where dt.ngay_ct >= dateserial(2013,2,1) and dt.ngay_ct <= dateserial(2013,2,28) group by dt.MA_VLSPHH ) as dtps
     on dtps.Ma=dm.MA_VLSPHH

Trong đó DateFrom là dateserial(2013,2,1) và DateTo là dateserial(2013,2,28) (nguyên tháng 2)
Từ SQL view sửa DateTo thành ngày khác (thí dụ dateserial(2013,3,3), nhấn nút xem DataSheet view thì khoảng 2 giây.

Hình 1: SQL view, nhấn nút datasheet view
View attachment 267456

Hình 2: Datasheet view

View attachment 267457
Up file đi sư phụ. Access quá mạnh mà gần như em chưa mở nó lên bao giờ :(
 
Tôi thử làm offline trên Access. Query có SQL là:


Trong đó DateFrom là dateserial(2013,2,1) và DateTo là dateserial(2013,2,28) (nguyên tháng 2)
Từ SQL view sửa DateTo thành ngày khác (thí dụ dateserial(2013,3,3), nhấn nút xem DataSheet view thì khoảng 2 giây.
Lấy dữ liệu từ 1/2/2013 - 30/6/2103 cho giống đề bài nha bác.
 
Lấy dữ liệu từ 1/2/2013 - 30/6/2103 cho giống đề bài nha bác.
2 tháng như bài trên = hơn 2 giây.
từ 1/2/2013 - 30/6/2103 = 6.22 giây

1633826449576.png

Up file đi sư phụ. Access quá mạnh mà gần như em chưa mở nó lên bao giờ :(
File 139 Mb :). Mở form và nhấn nút Open query. Có thêm 1 report và có thể nhấn nút Open report.
Link download
 
Lần chỉnh sửa cuối:
Nếu lấy làm ứng dụng thực tế thì không nên dùng dữ liệu kiểu này (ở Excel), nên Cần tổ chức lại thì mới nhanh hay chậm được
Và quan trọng bài toán kinh tế không phải nhanh chậm, mà là độ chính xác và Nhanh là tức thời với phản ứng
----
Nội dung trên định viết từ hôm trước rồi, mà quên post
Data chuyển qua Access nở ra kinh khủng quá ạ.
Access cũng là trình quản lý dữ liệu tầm tầm và ứng dụng cho desktop offline là chính
Còn như mục đích bài 1 thì có vẻ phải đặt lại vấn đề
 
Nếu lấy làm ứng dụng thực tế thì không nên dùng dữ liệu kiểu này (ở Excel), nên Cần tổ chức lại thì mới nhanh hay chậm được
Và quan trọng bài toán kinh tế không phải nhanh chậm, mà là độ chính xác và Nhanh là tức thời với phản ứng
----
Nội dung trên định viết từ hôm trước rồi, mà quên post

Access cũng là trình quản lý dữ liệu tầm tầm và ứng dụng cho desktop offline là chính
Còn như mục đích bài 1 thì có vẻ phải đặt lại vấn đề
vâng anh, với bài này làm offline nhiều giải pháp, nhanh, chính xác.
Tuy nhiên, tinh thần bài này là làm online.
Dữ liệu gốc nặng nề đẩy lên Drive.
File báo cáo nhẹ tênh, gửi mail cho đối tác để họ tự chạy.
 
2 tháng như bài trên = hơn 2 giây.
từ 1/2/2013 - 30/6/2103 = 6.22 giây

Link download

Bác xem lại công thức tính tồn đầu kỳ nhé, nó bị sai.

Mới test trên Access 2013 - 32bit, không hiểu sao nhanh hơn 2016 - 64bit.

Mở trực tiếp Query:
Screen Shot 2021-10-10 at 10.54.33.png

Xuất ra Excel:
Screen Shot 2021-10-10 at 10.57.08.png

Data chuyển qua Access nở ra kinh khủng quá ạ.
Đúng là data nó phình lên gấp đôi nhưng bạn mở file Access thấy nó cực nhanh so với mở file data Excel không?

Link file demo: https://www.mediafire.com/file/g72sunrp549cnqg/NXT_Access.7z/file
Bài đã được tự động gộp:

vâng anh, với bài này làm offline nhiều giải pháp, nhanh, chính xác.
Tuy nhiên, tinh thần bài này là làm online.
Dữ liệu gốc nặng nề đẩy lên Drive.
File báo cáo nhẹ tênh, gửi mail cho đối tác để họ tự chạy.

Sao bạn không tạo folder chứa file data trên máy rồi đồng bộ nó lên cloud. Khi bạn xử lý thì file data đó vẫn là file trên máy thay vì làm trực tiếp file trên Cloud.
 
Bác xem lại công thức tính tồn đầu kỳ nhé, nó bị sai.

Mới test trên Access 2013 - 32bit, không hiểu sao nhanh hơn 2016 - 64bit.

Mở trực tiếp Query:
View attachment 267467

Xuất ra Excel:
View attachment 267468


Đúng là data nó phình lên gấp đôi nhưng bạn mở file Access thấy nó cực nhanh so với mở file data Excel không?

Link file demo: https://www.mediafire.com/file/g72sunrp549cnqg/NXT_Access.7z/file
Bài đã được tự động gộp:



Sao bạn không tạo folder chứa file data trên máy rồi đồng bộ nó lên cloud. Khi bạn xử lý thì file data đó vẫn là file trên máy thay vì làm trực tiếp file trên Cloud.
Data vẫn làm trực tiếp trên máy trạm ạ. Rồi save trên onedrive/cloud đó anh.
 
Data vẫn làm trực tiếp trên máy trạm ạ. Rồi save trên onedrive/cloud đó anh.
Hình như cách này dữ liệu thay đổi liên tục onedrive nó thông báo gì đó và nó lưu có file tạm ... mấy na9m trước có vọc theo hướng này xong bỏ
 
Bác xem lại công thức tính tồn đầu kỳ nhé, nó bị sai.
Tôi xin lỗi, file của tôi lấy dữ liệu từ file excel khác, giống cấu trúc nhưng số liệu không giống file của @Cá ngừ F1. Link file trong bài 2, lúc đó tôi viết power query. Table đầu kỳ trong file đó 36 cột cho 12 tháng, và tôi dùng Power query động để lấy tồn tháng gần nhất
 
Tôi thử nhiều cách nhưng không thể truy vấn SQL trực tiếp từ cái link OneDrive đó. Nếu làm offline thì Excel chạy hết 73s. Nếu mở sẵn file nguồn lên thì nhanh hơn (khoảng 34s)
 
Bác xem lại công thức tính tồn đầu kỳ nhé, nó bị sai.
Bạn cũng xem lại:
Cách tính tồn đầu kỳ = tồn đầu năm (bảng TonDK) + PS nhập trước ngày đầu báo cáo - PS xuất trước ngày đầu báo cáo

Query qrTDKPS của bạn lấy phát sinh nhập xuất between(ngày đầu, ngày cuối)

Hỏi thêm:
Tôi thấy trong SQL view, câu SQL của bạn có hàm Nz đó là gì, vì tôi không có nó cũng ra kết quả?
 
Bạn cũng xem lại:
Cách tính tồn đầu kỳ = tồn đầu năm (bảng TonDK) + PS nhập trước ngày đầu báo cáo - PS xuất trước ngày đầu báo cáo

Query qrTDKPS của bạn lấy phát sinh nhập xuất between(ngày đầu, ngày cuối)

Hỏi thêm:
Tôi thấy trong SQL view, câu SQL của bạn có hàm Nz đó là gì, vì tôi không có nó cũng ra kết quả?
Tôi cũng tính tồn đầu theo công thức trên đó anh. qryTDK = TonDK + qry TonDKPS (Phát sinh N/X trước ngày báo cáo)
Còn hàm Nz() là hàm khử Null (Nếu gặp giá trị Null nó sẽ chuyển về =0). Trong bài này có những mã hàng TDK có nhưng phát sinh N/X không có, khi nối (Join) 2 bảng lại với nhau thì Access tự động ghi Null cho các giá trị N/X không có dữ liệu --> khi tính toán +/- sẽ bị sai kết quả. Nên chắc ăn nhất là cứ khử giá trị Null trước khi tính toán.
Còn trong câu lệnh SQL của anh có dùng hàm IIF() để thay thế Null bằng các giá trị 0 rồi. Dùng Nz() thì nó gọn hơn.
Tôi không dùng các subquery lồng nhau mà tách riêng ra để dễ kiểm tra từng hạng mục. Thường cũng chỉ dùng 1 subquery lồng vô thôi.

Mới test kiểu dùng linked Table link tới file Excel luôn để xử lý thì tốc độ cũng khá nhanh với điều kiện là phải duy trì kết nối liên tục tới file Excel trong qua trình truy vấn dữ liệu, nếu không thì mất hơn 1 phút mới ra kết quả.

Screen Shot 2021-10-10 at 15.52.41.png

Đây cũng là một cách dã chiến mà ứng dụng Access thiết kế cho nhiều người dùng nhập liệu (Font end) qua Internet mà không cần các tool hỗ trợ khác ngoại trừ một tài khoản Cloud Drive (One Drive, Google Drive). Tốc độ đồng bộ cũng 3, 4 s tuỳ hạ tầng mạng. Data back end lưu trên ổ đám mây, còn các máy con thì dùng ứng dụng Font end trên máy họ mà nhập liệu, xem báo cáo.
 
Lần chỉnh sửa cuối:
Tôi cũng tính tồn đầu theo công thức trên đó anh. qryTDK = TonDK + qry TonDKPS (Phát sinh N/X trước ngày báo cáo)
Cám ơn bạn về việc giải thích Nz. Do không biết hàm đó nên phải IIf >0.
Còn công thức trên bạn ghi đúng nhưng trong SQL lại between (ngày đầu báo cáo, ngày cuối báo cáo). Đúng ra phải là between(ngày 1/1/2013, ngày đầu báo cáo). Thậm chí không dùng between vì between lấy luôn giá trị ngày 1/2. Phải là >= 1/1/2013 and < ngày đầu BC
 
Tôi thử nhiều cách nhưng không thể truy vấn SQL trực tiếp từ cái link OneDrive đó. Nếu làm offline thì Excel chạy hết 73s. Nếu mở sẵn file nguồn lên thì nhanh hơn (khoảng 34s)
Vâng anh.
Chắc onedrive không cho SQL trực tiếp.
Anh làm offline bằng ADO anh cứ share cho anh em học hỏi. Vì em hình dung với bài này ADO join các bảng không biết phức tạp không.
 
Vâng anh.
Chắc onedrive không cho SQL trực tiếp.
Anh làm offline bằng ADO anh cứ share cho anh em học hỏi. Vì em hình dung với bài này ADO join các bảng không biết phức tạp không.
ADO cũng dùng câu lệnh SQL, tương tự SQL troong Access vậy. Xem file của anh @ongke0711 và của tôi để tham khảo. Chỉ là viết trong môi trường VBA của Excel mà thôi
 
Khi tính thời gian chúng ta nên tính cả lúc load data lên. Khi dùng các công cụ thì nó đã load data lên rồi và phần này mọi người quên không tính mà chỉ tính lúc “Run” chạy array trong RAM. Nếu viết VBA để tính sau khi đã có array (load datta lên RAM rồi) thí tốc độ cũng nhanh. Bài này có lẽ chủ ý của người hỏi là một click ra ngay và tính toàn bộ thời gian.
 
Lần chỉnh sửa cuối:
Tốc độ khủng thật. Chắc cũng là cơ chế đẩy hết lên Ram để xử lý.
Vâng anh, đúng là nó dùng Ram nhiều, 1 file Power Bi Nặng nó xài 4gb ram là bình thường, cho nên nếu mở vài file như vậy+ mở các file khác thì Ram cỡ 32Gb mới chạy tạm. Power Bi nó cũng dùng Power Querry để get data và dùng Dax giống như trong Excel nhưng nó chạy nhanh hơn nhiều so với khi chạy trên excel( Khoản này thì em cũng biết, có thể nó là một tool riêng nên nó có những điểm tối ưu riêng). Phần lâu nhất là nạp data vào Data model và thiết kế Model chuẩn, xong công đoạn này mà viết hàm nó chạy thì VBA hay mấy Tool kiểu vậy không có cửa so với nó.
À nếu tính cả thời gian Load Data từ ondrive về Power Bi thì mất 16s load+0,1s tính toán, sơ bộ Power Bi chạy cái này dưới 20s( Tùy vào cấu hình máy tính + tốc độ mạng nữa). Như em đã nói ở trên thì lâu nhất là công đoạn Get data.
 
Vâng anh, đúng là nó dùng Ram nhiều, 1 file Power Bi Nặng nó xài 4gb ram là bình thường, cho nên nếu mở vài file như vậy+ mở các file khác thì Ram cỡ 32Gb mới chạy tạm. Power Bi nó cũng dùng Power Querry để get data và dùng Dax giống như trong Excel nhưng nó chạy nhanh hơn nhiều so với khi chạy trên excel( Khoản này thì em cũng biết, có thể nó là một tool riêng nên nó có những điểm tối ưu riêng). Phần lâu nhất là nạp data vào Data model và thiết kế Model chuẩn, xong công đoạn này mà viết hàm nó chạy thì VBA hay mấy Tool kiểu vậy không có cửa so với nó.

Như vậy là bạn đã bỏ qua thời gian load và xử lý trung gian của công cụ rồi. VBA nó làm tự động từ A-Z và bị tính tất cả. Nếu trong VBA, load hết data vào array và không tính thời gian phần này, sau đó mới tính thời gian chạy kết quả cuối thì cũng rất nhanh, không khác gì chủ để cũ mà bài đầu tiên đưa link.
 
Khi tính thời gian chúng ta nên tính cả lúc load data lên. Khi dùng các công cụ thì nó đã load data lên rồi và phần này mọi người quên không tính mà chỉ tính lúc “Run” chạy array trong RAM. Nếu vjeets VBA để tính sau khi đã cí array (load datta lên RAM rồi) thí tốc độ cũng nhanh. Bài này có lẽ chủ ý của người hỏi là một click ra ngay và tính toàn bộ thời gian.
Tinh thần chạy online, tính hết cả thời gian load dữ liệu, tính toán, dán xuống sheet anh nhé.
 
Như vậy là bạn đã bỏ qua thời gian load và xử lý trung gian của công cụ rồi. VBA nó làm tự động từ A-Z và bị tính tất cả. Nếu trong VBA, load hết data vào array và không tính thời gian phần này, sau đó mới tính thời gian chạy kết quả cuối thì cũng rất nhanh, không khác gì chủ để cũ mà bài đầu tiên đưa link.
Em nghĩ dữ liệu nhỏ nhỏ như bảng tính excel thì cũng không có quá nhiều sự khác biệt, có lẽ chủ thớt nên mở rộng nó lên cỡ 100 triệu dòng trở lên khi đó đưa ra các giải pháp so sánh thì sẽ có nhiều thứ đáng bàn hơn, chứ chênh nhau một hay vài chục giây thì cũng không giải quyết vấn đề gì.
 
Tinh thần chạy online, tính hết cả thời gian load dữ liệu, tính toán, dán xuống sheet anh nhé.

Anh hiểu ý em mà. Nếu muốn so sánh chạy offline một cách công bằng với VBA thì sẽ làm như sau.
1. Chạy SQL để JOIN các bảng có quan hệ và liên quan đến kết quả, từ đây ta có Recortset - Đây tạm coi là Data Model. Nếu các bạn không tính trên Power BI, thì cũng không tính phần này trên VBA. Tương tự nếu có các dataset khác cũng không tính.
2. Từ Recordset chạy vòng lặp với giải thuật Dictionary hay array thuần tùy. Bước này hãy tính thời gian cùng nhau. Chưa chắc chênh lệch nhau nhiều đâu.
 
Đối với file và yêu cầu của chủ đề này, và làm với dữ liệu online bằng Power query trên excel hoặc Power BI, tôi có ý như sau:
- Thời gian tạo lập query, kiểm tra kết quả, ... không tính
- Thời gian nên tính là thời gian query đó liên kết lấy dữ liệu, tính toán và hiển thị ra kết quả. Nếu việc tính toán phải qua những query trung gian, thì khi hiển thị ra kết quả cuối cũng đã được tính rồi.
Vậy vấn đề là phương pháp test thời gian.
1. Nếu chỉ nhấn nút refresh thì cái action refresh của phần mềm có bao gồm việc load dữ liệu về hay không?
2. Nếu thay đổi tham số (ngày bắt đầu, ngày kết thúc) rồi nhấn nút refresh, thì có load lại dữ liệu không?

Tôi cho rằng query trong trường hợp này load lại dữ liệu, vì khi refresh, mặc định là dữ liệu nguồn có thể đã thay đổi, nên phải load dữ liệu mới về. Nếu không làm sao gọi là refresh?

Nếu so sánh với các ngôn ngữ lập trình khác như VBA, Python, Java, ... thì cứ so sánh thoải mái, vì công việc phải làm là như nhau.
1. Chạy SQL để JOIN các bảng có quan hệ và liên quan đến kết quả, từ đây ta có Recortset - Đây tạm coi là Data Model. Nếu các bạn không tính trên Power BI, thì cũng không tính phần này trên VBA. Tương tự nếu có các dataset khác cũng không tính.
2. Từ Recordset chạy vòng lặp với giải thuật Dictionary hay array thuần tùy. Bước này hãy tính thời gian cùng nhau. Chưa chắc chênh lệch nhau nhiều đâu.
Power query với dữ liệu ở bài 1 cũng phải merge 3 table (merge tương đương join của SQL *), và merge cả 1 hoặc 2 query trung gian (tùy thuật toán). Và khi refresh phải tính toán tuần tự như vậy chứ không phải thuần là lôi ra hiển thị.

(*) Bản chất của Merge là như vậy: cũng xác định trường khóa, trường liên kết, loại liên kết (left join, right join, full join, join)
 
Anh hiểu ý em mà. Nếu muốn so sánh chạy offline một cách công bằng với VBA thì sẽ làm như sau.
1. Chạy SQL để JOIN các bảng có quan hệ và liên quan đến kết quả, từ đây ta có Recortset - Đây tạm coi là Data Model. Nếu các bạn không tính trên Power BI, thì cũng không tính phần này trên VBA. Tương tự nếu có các dataset khác cũng không tính.
2. Từ Recordset chạy vòng lặp với giải thuật Dictionary hay array thuần tùy. Bước này hãy tính thời gian cùng nhau. Chưa chắc chênh lệch nhau nhiều đâu.
Hi anh,
Sau đề tài gốc của anh, em thấy rất happy với các code dùng Dictionary, nó nhanh, mạnh, chính xác.

Nếu làm offline, kể cả việc download file, dùng ADO import data về, rồi chạy VBA cũng sẽ rất nhanh thôi.

Tuy nhiên, giờ dữ liệu gốc đưa lên mạng, thay vì phải download file thì getdata trực tiếp, thì có giải pháp nào nhanh/mạnh hơn dùng PowerQuery không?
 
Ví dụ thế này: Tôi có 1 file B để trên drive, và file đó đồng bộ với 1 file A tại máy tính của tôi. Tôi tạo 1 file excel hoặc Power BI trên máy ông sếp, liên kết đến file B trên drive để tạo báo cáo.
Hiện tại tôi đã nhập liệu đến ngày 01/10/2021 trên file A, đã đồng bộ vào file B, ông sếp đã xem báo cáo nhập xuất tồn tháng 10/2021: Ngày bắt đầu là 01/10/2021, kết thúc là 31/10/2021
Hôm nay tôi nhập liệu vào file A tiếp đến ngày 05/10 theo chứng từ tôi có trong tay mới nhận được (50 chứng từ). Sau đó file A được đồng bộ với file B.
Vậy thì hôm nay ông sếp mở file báo cáo, để nguyên thông số tháng 10, nhấn refresh để xem báo cáo. Thì kết quả phải bao gồm 50 chứng từ mới nhập vào chứ? Nghĩa là Power query của Excel hoặc Power BI phải load lại data mới từ file B (!)
 
Ví dụ thế này: Tôi có 1 file B để trên drive, và file đó đồng bộ với 1 file A tại máy tính của tôi. Tôi tạo 1 file excel hoặc Power BI trên máy ông sếp, liên kết đến file B trên drive để tạo báo cáo.
Hiện tại tôi đã nhập liệu đến ngày 01/10/2021 trên file A, đã đồng bộ vào file B, ông sếp đã xem báo cáo nhập xuất tồn tháng 10/2021: Ngày bắt đầu là 01/10/2021, kết thúc là 31/10/2021
Hôm nay tôi nhập liệu vào file A tiếp đến ngày 05/10 theo chứng từ tôi có trong tay mới nhận được (50 chứng từ). Sau đó file A được đồng bộ với file B.
Vậy thì hôm nay ông sếp mở file báo cáo, để nguyên thông số tháng 10, nhấn refresh để xem báo cáo. Thì kết quả phải bao gồm 50 chứng từ mới nhập vào chứ? Nghĩa là Power query của Excel hoặc Power BI phải load lại data mới từ file B (!)
Vâng ạ
Việc load lại là cần thiết, biết đâu kể cả chứng từ cũ nhập sai xong sửa lại thì sao.
Ông Sếp chỉ cần refresh là có thể theo dõi được.
 
Vâng ạ
Việc load lại là cần thiết, biết đâu kể cả chứng từ cũ nhập sai xong sửa lại thì sao.
Ông Sếp chỉ cần refresh là có thể theo dõi được.
Cho nên tôi đang nghi ngờ con số 114ms giây ở bài 37, công cụ Perfomance analysis của Power BI không biết tính toán phân tích những gì và trong trường hợp nào. Phải tính thời gian của việc nhấn nút refresh mới chính xác.
 
Cho nên tôi đang nghi ngờ con số 114ms giây ở bài 37, công cụ Perfomance analysis của Power BI không biết tính toán phân tích những gì và trong trường hợp nào. Phải tính thời gian của việc nhấn nút refresh mới chính xác.
Ở trên em có nói là bao gồm 16s load data đó anh, nên nó là 16s+0,14s tính toán đó ah
 
Vâng ạ
Việc load lại là cần thiết, biết đâu kể cả chứng từ cũ nhập sai xong sửa lại thì sao.
Ông Sếp chỉ cần refresh là có thể theo dõi được.
Báo cáo hiện tại thì Sếp ko cần refresh gì đâu bạn, bạn gửi Báo cáo cho sếp thì cái báo cáo đấy bạn phải tự refresh, Sếp chỉ coi report thôi, Sếp cũng không cần cài phần mềm power bi hay tool tương tự để xem được Report. Vì nếu dữ liệu lớn và phân tích phức tạp thì Sếp không có thời gian chờ Refresh. Report sẽ dạng như Public mà bạn vẫn coi trên các trang web ý, vẫn bấm coi bình thường mà không cần tự cập cập nhật dữ liệu.
 
Tôi chưa thạo Power Bi lắm, cũng chưa từng đo khoảng thời gian như thế nào, khoản này anh @excel_lv1.5 chắc biết rõ hơn tôi.
Tôi lấy dữ liệu về viết hàm xong xuất thì báo 114 ms.
View attachment 267492
Thời gian này chưa bao gồm thời gian load số liệu và chỉ là thời gian của top danh sách (thời gian measure+ load visualize+others), tức là như cái hình bạn chụp no show khoảng 30 mã hàng nếu load full 13.000 con số nó sẽ khác, bạn vẫn giữ performace analyzer đồng thời cuộn xuống dưới xem danh sách sẽ có thêm thời gian tính, power BI cơ chế nó là vậy nó chỉ hiện đủ danh sách cho size report thôi, nên nó tính rất nhanh kéo xuống nó mới tính tiếp, thực tế bài này tôi có làm power pivot rồi chạy full cũng dưới 1s sau nạp đủ source rồi, VBA nó nhanh ở chỗ nạp source (nạp từ excel là sân nhà của VBA rồi), chứ riêng việc tính toán nó vẫn thua tool hay các ngôn ngữ khác vì cơ chế vẫn quét theo Row dữ liệu càng nhiều thì sẽ càng chậm
Muốn đo đúng bạn tính bằng calculated table là biết?
 
Lần chỉnh sửa cuối:
Báo cáo hiện tại thì Sếp ko cần refresh gì đâu bạn, bạn gửi Báo cáo cho sếp thì cái báo cáo đấy bạn phải tự refresh, Sếp chỉ coi report thôi, Sếp cũng không cần cài phần mềm power bi hay tool tương tự để xem được Report. Vì nếu dữ liệu lớn và phân tích phức tạp thì Sếp không có thời gian chờ Refresh. Report sẽ dạng như Public mà bạn vẫn coi trên các trang web ý, vẫn bấm coi bình thường mà không cần tự cập cập nhật dữ liệu.
Sếp ở đây là nói ví dụ vậy thôi.
Chắc bạn chưa hiểu ý của đề bài. Dữ liệu gốc có thể thay đổi, bổ sung, chỉnh sửa bất ký lúc nào, nó đâu có cố định.
Người xem báo cáo muốn cập nhật chuẩn cần phải refresh, để load lại từ đầu.
 
Như em cũng nói ở trên là load data mất 16s, còn đo thời gian em nghĩ tính từ đoạn mình bấm export ra kết quả file cuối cùng, đo thời gian từ đó đến khi xong file để so sánh giữa các loại là phù hợp nhất.
 
Sếp ở đây là nói ví dụ vậy thôi.
Chắc bạn chưa hiểu ý của đề bài. Dữ liệu gốc có thể thay đổi, bổ sung, chỉnh sửa bất ký lúc nào, nó đâu có cố định.
Người xem báo cáo muốn cập nhật chuẩn cần phải refresh, để load lại từ đầu.
Power BI nó có 2 chế độ là direct và import , direct thì sẽ xem real time tuy nhiên tốc độ xem các report sẽ rất chậm và phần lớn sẽ không dùng Dax được sẽ mất tính analytics , 2 là import toàn bộ dùng Dax sẽ tính toán thì tốc độ xem report nhất nhanh chỉ vài ms khi dùng các slicer điều khiển, BI nó không refresh thường xuyên mà refresh theo lịch (giới hạn 8 lần/ ngày với Pro), vì refresh import thường xuyên sẽ ảnh hưởng đến tài nguyên hệ thống Database (nếu chưa có data warehouse) khi số liệu quá lơn, nên BI nó sẽ refresh trước sau đó thông cho mọi người xem thôi, ví dụ công ty tôi hệ report Sales nó refresh 2 lần/ ngày mỗi lần refresh khoảng 20 phút tôi cài lịch là 7h và 12 giờ , nên tôi sẽ thông báo mọi người có thể xem mới lúc 8h/13h. End users chỉ quan tấm đến tốc độ xem report thôi (thông thường tiêu chuẩn của một báo cáo BI là phải dưới 3s), Excel cũng vậy nhưng không bị giới hạn số làn refresh, nhưng thông thường người ta sẽ làm ở power pivot để lưu source luôn, power query chỉ là trung gian ETL cho power pivot, không ai chơi đẩy thẳng kết quả từ power query cả, vì như vậy chỉ tạo được 1 report, trong khi đưa vào power pivot nó tạo thêm được hàng tá các report khác mà không cần load lại dữ liệu
 
Sếp ở đây là nói ví dụ vậy thôi.
Chắc bạn chưa hiểu ý của đề bài. Dữ liệu gốc có thể thay đổi, bổ sung, chỉnh sửa bất ký lúc nào, nó đâu có cố định.
Người xem báo cáo muốn cập nhật chuẩn cần phải refresh, để load lại từ đầu.
Chắc tôi hiểu lầm ý của bạn, Tôi nghĩ đơn giản hơn, người coi thì chỉ cần coi thôi, còn tính toán là trách nhiệm của người làm báo cáo trừ khi làm chung một nhóm, mỗi người làm một phần vào cái chung thì dùng chung.
 
Quý vị đang thi đấu với nhau về nghề lập trình hay xây dựng phần mềm vậy?
Cái chỉ tiêu (metrics) mà quý vị đưa ra là tốc độ. Từ thuở biết lập trình đến giờ, tôi chỉ thấy mấy phần mềm chuyên real-time (như đặt vé, xoát vé,...) mới cần tốc độ. Báo cáo là công việc rất ít cần tốc độ.

Chỉ tiêu chung của phần mềm ứng dụng CSDL là dễ dùng và chỉnh sửa. "Phát triển" (nhìn tiêu đề) theo tôi có nghĩa là:
1. người dùng có sự tin tưởng rằng phần mềm đáp ứng được nhu cầu của mình (rất tiếc rằng dân hỏi bài ở đây đã được làm quen với "tốc độ", cho nên họ chỉ chú ý đến điểm này)
2. người viết phần mềm hiểu rõ phạm vi và giới hạn của phần mềm. Khi cần triển khai, người ta nhanh chóng nhận định rằng phần mềm có thể chỉnh sửa hay phaiur dùng phầnn mềm khác.
3. cả người dùng và người viết đều có sự tin tưởng rằng giao diện (xuất nhập dữ liệu sang các nơi khác) đáp ứng đầy đủ.

Điển hình, đối với tôi thì cuộc thi "phát triển ngôn ngữ" này của các bạn đã thất bại hoàn toàn ở đây:
 
Quý vị đang thi đấu với nhau về nghề lập trình hay xây dựng phần mềm vậy?
Cái chỉ tiêu (metrics) mà quý vị đưa ra là tốc độ. Từ thuở biết lập trình đến giờ, tôi chỉ thấy mấy phần mềm chuyên real-time (như đặt vé, xoát vé,...) mới cần tốc độ. Báo cáo là công việc rất ít cần tốc độ.

Chỉ tiêu chung của phần mềm ứng dụng CSDL là dễ dùng và chỉnh sửa. "Phát triển" (nhìn tiêu đề) theo tôi có nghĩa là:
1. người dùng có sự tin tưởng rằng phần mềm đáp ứng được nhu cầu của mình (rất tiếc rằng dân hỏi bài ở đây đã được làm quen với "tốc độ", cho nên họ chỉ chú ý đến điểm này)
2. người viết phần mềm hiểu rõ phạm vi và giới hạn của phần mềm. Khi cần triển khai, người ta nhanh chóng nhận định rằng phần mềm có thể chỉnh sửa hay phaiur dùng phầnn mềm khác.
3. cả người dùng và người viết đều có sự tin tưởng rằng giao diện (xuất nhập dữ liệu sang các nơi khác) đáp ứng đầy đủ.

Điển hình, đối với tôi thì cuộc thi "phát triển ngôn ngữ" này của các bạn đã thất bại hoàn toàn ở đây:
Tinh thần của bài này là học hỏi, không có thi đấu gì đâu anh.
Vì thời gian gần đây em thấy mọi người hay nói đến Delphi, Python (bài lấy dữ liệu tỷ giá từ website của Vietcombank), có thể sẽ giải bài này tốt hơn Power Query thôi anh.

Link bài anh gửi em cũng có trả lời. Nói chung không có một bài nào để ứng dụng cho tất cả, chỉ chung chung giải pháp vậy thôi
 
...

Link bài anh gửi em cũng có trả lời. Nói chung không có một bài nào để ứng dụng cho tất cả, chỉ chung chung giải pháp vậy thôi
Đối với tôi, phát triển cho cả đống nhưng không thể ứng dụng là thất bại.

Đó là lý do tại sao tôi không góp ý nào về "ngôn ngữ" hay "giải thuật" nào cả ở đây.
Kiểm soát vật tư (Inventory Control) chủ yếu là quy trình. Quy trình không rõ rệt thì phần mềm chỉ là chắp vá.
Đồ chắp vá rất khó so sánh nhau. Mỗi CSDL có điểm mượt của chúng đối với từng thiết kế phần mềm. Phải dựng được một mô hình (prototype) áp dụng cho khoảng 70% trường hợp thì mới so sánh được.
 
Lần chỉnh sửa cuối:
Đối với tôi, phát triển cho cả đống nhưng không thể ứng dụng là thất bại.

Đó là lý do tại sao tôi không góp ý nào về "ngôn ngữ" hay "giải thuật" nào cả ở đây.
Kiểm soát vật tư (Inventory Control) chủ yếu là quy trình. Quy trình không rõ rệt thì phần mềm chỉ là chắp vá.
Đồ chắp vá rất khó so sánh nhau. Mỗi CSDL có điểm mượt của chúng đối với từng thiết kế phần mềm. Phải dựng được một mô hình (prototype) áp dụng cho khoảng 70% trường hợp thì mới so sánh được.
Có thể ứng dụng được anh, nếu người dùng thay đổi dữ liệu đầu vào.
Một ứng dụng gọi là ăn liền khi mà dữ liệu đầu vào phải đồng nhất/hoặc phải chế biến cho nó về đồng nhất. Chứ không thì ứng dụng cũng sẽ thất bại.
 
Có thể ứng dụng được anh, nếu người dùng thay đổi dữ liệu đầu vào.
Một ứng dụng gọi là ăn liền khi mà dữ liệu đầu vào phải đồng nhất/hoặc phải chế biến cho nó về đồng nhất. Chứ không thì ứng dụng cũng sẽ thất bại.
Tôi khẳng định là "không ứng dụng được".
Quý vị bàn sâu quá về tốc độ nên chủ quan, lãng quên nhu cầu của người dùng.
Chả có "người dùng" nào đọc thớt này mà tin rằng một trong những giải pháp trong thớt có thể ứng dụng cho mình.

Ở diễn đàn này, quý vị đã nhồi sọ thành viên với tư tưởng "tốc độ" đã thành thói quen rồi. Trên thực tế, phát triển phần mềm đâu có như vậy.
Tốc độ, theo cách đo lường của quý vị (không phải cách đo của tôi) thì nó là cái quý vị làm được.
Các yếu tố khác, đối với quý vị chúng là xa lạ. Nói thẳng ra là do quý vị không biết đo, và không hề thấy nổ lực nào để học hỏi về khía cạnh này.

Bởi vậy, đối với tôi thì ở đây chỉ là trò chơi cho quý vị tán gẫu nhau. Nói "phát triển" (development) hơi quá đáng.
 
Tôi nghĩ thớt này thì người ứng dụng thì áp dụng được một phần rất nhỏ( coi mỗi nhập xuất tồn thôi), công ty nào vẫn quản lý bằng excel xíu xíu thì sẽ dùng được chút chút. Đa phần không áp dụng được, với kinh nghiệm xíu xíu của tôi khoảng 10 năm trong lĩnh vực Logistics và Quản lý chuỗi cung ứng thì cái này đúng là áp dụng thực tế không có được, đúng như anh @VetMini có nói, quản lý tồn kho, vật tư thì quy trình là thứ quyết định(Nó liên quan tới dòng chảy hàng hóa như nào, quy định từng thành phần trong chuỗi hoạt động ra sao,...). Chủ thớt chắc chỉ nói cải thiện cho một vấn đề cụ thể chứ cũng không tham vọng phát triển phần mềm, tôi hiểu là vậy.
 
Hình như cách này dữ liệu thay đổi liên tục onedrive nó thông báo gì đó và nó lưu có file tạm ... mấy na9m trước có vọc theo hướng này xong bỏ
Onedrive hay lỗi, thỉnh thoảng lại bắt lưu file khác,
Xong thì lại báo không upload được,
Dữ liệu làm trên OneDrive em cũng đang thấy bất an lắm,
Không biết mất gì còn gì. Mất lúc nào, lúc nào còn.
 
Tôi gửi chủ thớt gợi ý 1 chút ở góc độ sử dụng dữ liệu Online thôi

1/ Chuyển hết dữ liệu trên File Excel ở bài số 1 vào 1 File Access
2/ bạn viết code tính nhập xuất tồn kiểu gì là do bạn tự viết
3/ sau khi tính toán xong mục số 2 thì bạn muốn xuất nó ra cái gì thì do khả năng và phù sự hợp của bạn
4/ Sử dụng cái SQL TCP/IP của tôi Úp trên GPE này mà truy xuất dữ liệu Nhập - Xuất - Tồn ... sẻ rất nhanh vì khi tính toán NXT xong thì xuất dữ liệu ra rất ít chỉ cô đọng lại các chỉ mục của nó
5/ xong từ bất cứ máy nào có kết nối Internet cứ thế mà truy xuất dữ liệu theo Folder bạn đã chia Sẻ

Tôi tải Files Access + Excel trên này về chỉ mở lên thôi cũng rất lâu vì vậy từ máy chủ bạn làm hết mọi thao tác xong xuất ra NXT thì từ máy khác cái Data NXT đó nó rất ít + nhẹ thì truy xuất rất nhanh

Xem hình minh họa tôi lấy File trên thớt này thử tí

Còn lại những vấn đề khác liên quan thớt này tôi ko bàn ... chỉ khuyên thế dùng được thì dùng ko thì cho vào thùng RÁC = thế thôi

1633938484158.png
 
Lần chỉnh sửa cuối:
Onedrive hay lỗi, thỉnh thoảng lại bắt lưu file khác,
Xong thì lại báo không upload được,
Dữ liệu làm trên OneDrive em cũng đang thấy bất an lắm,
Không biết mất gì còn gì. Mất lúc nào, lúc nào còn.
Microsoft, Google, Facebook... không biết là chúng ta đang dùng họ hay là họ đang dùng chúng ta. Mới đây FB bị mất kết nối cả ngày, vì vậy cũng cần chấp nhận vào một ngày đẹp trời, vào tài khoản trắng băng thôi bạn.
 
Onedrive hay lỗi, thỉnh thoảng lại bắt lưu file khác,
Xong thì lại báo không upload được,
Dữ liệu làm trên OneDrive em cũng đang thấy bất an lắm,
Không biết mất gì còn gì. Mất lúc nào, lúc nào còn.
mấy năm trước tôi có để 1 cái Data.accdb trên OneDrive chi tiết là D:\OneDrive\Data.accdb
xong từ 2 máy tính tôi thử lưu liên tục vào đó xem sao .... thì nó tạo ra File Tạm + Thông báo +...
Tóm lại ko hiệu quả mà lỗi có khi mất dữ liệu xong bỏ cho nhanh
 
Đề bài này chỉ là một dạng cơ bản của cách tính nhập xuất tồn thôi và theo tôi chủ thớt chủ yếu để xem đối với các ngôn ngữ khác thực hiện cùng một cách giải có cải thiện được tốc độ xử lý dữ liệu thôi chứ không phải xây dựng nên một hệ thống tính NXT chuẩn mực đâu.
Bởi vì nếu là tôi, đơn giản tôi sẽ có thêm bảng tồn đầu kỳ mỗi tháng. Khi đó tính tồn thời điểm sẽ không cần phải truy vấn toàn bộ dữ liệu từ đầu đến thời điểm tính tồn, đó là một cách đơn giản để xây dựng dữ liệu tồn kho. Trong thực tế còn có thêm tính giá trị tồn kho theo giá nào, tính đơn giá xuất bình quân v.v...khi đó cũng sẽ tốn thêm nhiều thời gian để xử lý. Nói chung còn nhiều khoản mục liên quan mà đề bài này không tham vọng bao hết được đâu.
 
Thời gian tới tôi mới triển khai báo giá cho khác khàng online ... cho họ cái Addins SQLTCP/IP xong chỉ kích chọn là tải file báo giá về thôi ...rất đơn giản gọn nhẹ

Con tôi chỉ ngồi máy tính chơi và chuyện linh tinh vui vẻ thế thôi có gì chỉnh giá 1 phát là bất cứ đâu có kết nối Internet cứ thế truy xuất dữ liệu Online -0-0-0-
 
Onedrive hay lỗi, thỉnh thoảng lại bắt lưu file khác,
Xong thì lại báo không upload được,
Dữ liệu làm trên OneDrive em cũng đang thấy bất an lắm,
Không biết mất gì còn gì. Mất lúc nào, lúc nào còn.
Bất kỳ lưu trữ dữ liệu trên đâu điều phải có công tác lưu dự phòng định kỳ. Cty trước đây tôi làm có 1 cái két sắt riêng để lưu các ổ đĩa backup từ server ra ổ đĩa ngoài, định kỳ cuối tuần một lần.
Đám mây thì cũng có dịch vụ backup đám mây, vấn đề là tiền thôi.
 
Đề bài này chỉ là một dạng cơ bản của cách tính nhập xuất tồn thôi và theo tôi chủ thớt chủ yếu để xem đối với các ngôn ngữ khác thực hiện cùng một cách giải có cải thiện được tốc độ xử lý dữ liệu thôi chứ không phải xây dựng nên một hệ thống tính NXT chuẩn mực đâu.
Bởi vì nếu là tôi, đơn giản tôi sẽ có thêm bảng tồn đầu kỳ mỗi tháng. Khi đó tính tồn thời điểm sẽ không cần phải truy vấn toàn bộ dữ liệu từ đầu đến thời điểm tính tồn, đó là một cách đơn giản để xây dựng dữ liệu tồn kho. Trong thực tế còn có thêm tính giá trị tồn kho theo giá nào, tính đơn giá xuất bình quân v.v...khi đó cũng sẽ tốn thêm nhiều thời gian để xử lý. Nói chung còn nhiều khoản mục liên quan mà đề bài này không tham vọng bao hết được đâu.
Cảm ơn anh đã nói một cách khách quan,
Thực tế em chưa đủ kiến thức để làm một phần mềm nào đó, chủ đề gốc ban đầu cũng là chủ để hay để học hỏi về Dictionary.
Còn với bài này, phát triển đúng tinh thần là có thêm những giải pháp khác, học hỏi xem trên môi trường online có giải pháp nào tốt hơn để trải nghiệm.
 
mấy năm trước tôi có để 1 cái Data.accdb trên OneDrive chi tiết là D:\OneDrive\Data.accdb
xong từ 2 máy tính tôi thử lưu liên tục vào đó xem sao .... thì nó tạo ra File Tạm + Thông báo +...
Tóm lại ko hiệu quả mà lỗi có khi mất dữ liệu xong bỏ cho nhanh
Chắc chắn bạn thiết kế sai bài rồi. Người ta viết ứng dụng Access cho nhiều người dùng, kết nối qua internet bằng Cloud drive này dùng bao nhiêu năm rồi mà có bị vấn đề tạo ra file tạm đâu. Bạn nào mới viết, chưa khai thác đúng Access sẽ bị lỗi này. Còn cách xử lý, xin lỗi các bạn tự tìm hiểu nhé :D
 
Ngay từ đầu phương án có phần hơi kỳ cục rồi.
Nếu là lưu trữ file kiểu vậy thì cứ đồng bộ vào file đó, khi cần làm gì với nó cứ thong thả tải về rồi làm gì thì làm.

Muốn kiểu đúng chuẩn online, truy vấn tức thời thì người ta sẽ thuê/ dựng một cái server, tạo một database với các truy vấn, báo cáo các thể loại.
Về giao diện có thể là web, hoặc desktop app.
Có thể tạo thêm mớ API gì đó để phục vụ những tác vụ khác.
 
Bất kỳ lưu trữ dữ liệu trên đâu điều phải có công tác lưu dự phòng định kỳ. Cty trước đây tôi làm có 1 cái két sắt riêng để lưu các ổ đĩa backup từ server ra ổ đĩa ngoài, định kỳ cuối tuần một lần.
Đám mây thì cũng có dịch vụ backup đám mây, vấn đề là tiền thôi.
Em chưa nói đến đoạn backup, vì việc đó em đang làm hàng ngày.
Em chỉ nói đến sự an toàn ổn định của OneDrive thôi ạ.
Em dùng hàng ngày trên OneDrive, nhưng thỉnh thoảng lại báo lỗi, hôm sau mở ra thì không còn dữ liệu ngày hôm trước làm đâu.
Với bản free tình trạng này xảy ra thường xuyên hơn bản có phí,
Bản trả phí thì ít, nhưng vẫn có.
Độ tin tưởng trên Cloud em thấy không ổn bằng GG driver.
 
Ngay từ đầu phương án có phần hơi kỳ cục rồi.
Nếu là lưu trữ file kiểu vậy thì cứ đồng bộ vào file đó, khi cần làm gì với nó cứ thong thả tải về rồi làm gì thì làm.

Muốn kiểu đúng chuẩn online, truy vấn tức thời thì người ta sẽ thuê/ dựng một cái server, tạo một database với các truy vấn, báo cáo các thể loại.
Về giao diện có thể là web, hoặc desktop app.
Có thể tạo thêm mớ API gì đó để phục vụ những tác vụ khác.
Tôi còn đang tính rãnh sẽ chuyển cái data này lên SQL Server, để server nó xử lý rồi từ Excel, Access Font end kết nối qua internet tải về xem như thế nào nữa đây...:p
 
mấy năm trước tôi có để 1 cái Data.accdb trên OneDrive chi tiết là D:\OneDrive\Data.accdb
xong từ 2 máy tính tôi thử lưu liên tục vào đó xem sao .... thì nó tạo ra File Tạm + Thông báo +...
Tóm lại ko hiệu quả mà lỗi có khi mất dữ liệu xong bỏ cho nhanh
Em xem trên Onedrive nó hay sinh ra file tạm gì đó, Dữ liệu gốc có mấy trăm mb, mà trong onedrive lên tận mấy gb, hình như nó lưu từng bản chỉnh sửa của người dùng ạ.
Em đã từng ứng dụng thất bại 1 lần khi dùng OneDrive, nên phải quay về offline,
Giờ em đang dùng bản trả phí, tiếp tục ứng dụng lần nữa, nhưng độ bất an chỉ giảm đi, chứ không mất đi ạ.
 
Ngay từ đầu phương án có phần hơi kỳ cục rồi.
Nếu là lưu trữ file kiểu vậy thì cứ đồng bộ vào file đó, khi cần làm gì với nó cứ thong thả tải về rồi làm gì thì làm.

Muốn kiểu đúng chuẩn online, truy vấn tức thời thì người ta sẽ thuê/ dựng một cái server, tạo một database với các truy vấn, báo cáo các thể loại.
Về giao diện có thể là web, hoặc desktop app.
Có thể tạo thêm mớ API gì đó để phục vụ những tác vụ khác.
Hi anh,
On/Off cũng chỉ là khái niệm tương đối.
Nếu ai đó ứng dụng bài này, không nhất thiết cần đưa lên mạng. Giờ công ty ai cũng dùng mạng Lan, giả sử Data để trên một máy chủ nào đó.
Máy khách sửa đường dẫn đến File nguồn, chạy Report thì cũng có thể gọi là Online.
 
Bởi vì nếu là tôi, đơn giản tôi sẽ có thêm bảng tồn đầu kỳ mỗi tháng. Khi đó tính tồn thời điểm sẽ không cần phải truy vấn toàn bộ dữ liệu từ đầu đến thời điểm tính tồn, đó là một cách đơn giản để xây dựng dữ liệu tồn kho.
Bạn nói rất đúng ý tôi: Đó là giải pháp tôi xây dựng trong chủ đề "thi nhanh nhất" năm xưa. Cụ thể là file tôi sử dụng trong chủ đề này ở bài #2. Lúc đó có thảo luận về việc này do đề bài gốc của anh @Nguyễn Duy Tuân lưu trữ dữ liệu tồn ngay trong bảng dữ liệu nhập xuất hàng ngày dưới dạng "phiếu nhập trước ngày đầu tiên của bảng dữ liệu". Lúc đó tôi có hỏi nếu dữ liệu liên tục 5 năm, 10 năm cũng phải tính lại từ khi thành lập công ty hay sao.

Thuật toán VBA dựa trên bảng tồn gần nhất của tôi lúc đó được xem là nhanh nhất/ nhì của lúc đó. Sau khi kết thúc chủ đề thi tôi mới thực hiện lại được việc thêm bảng tồn từng tháng. Lý do dữ liệu bài thi có 50 ngàn dòng, lại không đủ cho tất cả các tháng mặc dù trải dài 2 năm. Tôi mới dùng cấu trúc đó tạo file giả lập 1 triệu dòng, đủ tất cả các ngày, các tháng của 1 năm.

Tuy vậy, cấu trúc dữ liệu của file này cũng còn cần phải bàn (có lẽ đã được anh Tuân rút gọn để chỉ dùng cho chủ đề thi, lại ghi chú "không sửa"). Các vấn đề của cấu trúc file này trong 1 phần mềm quản lý inventory là:
- Thông số kho lưu trữ bị bỏ qua, coi như chỉ có 1 kho
- Không có loại chứng từ chuyển kho từ kho này qua kho kia (cũng phải thôi, vì chỉ có 1 kho).
- Không có loại chứng từ điều chỉnh hàng tồn sau kiểm kê (điều chỉnh tăng, giảm do kiểm kê)
- Không có loại chứng từ hàng trả người bán, người mua trả hàng.
Các mục trên đây tôi bỏ qua mà không bàn, vì đối với thủ kho và kế toán kho, đơn giản là hàng tăng lên và hàng giảm xuống, tăng gọi là nhập và giảm gọi là xuất. Thủ kho chịu trách nhiệm về báo cáo số lượng, kế toán kho chịu trách nhiệm báo cáo giá trị thành tiền. Kế toán công nợ và kế toán tổng hợp mới quan tâm những vấn đề khác. Chỉ có gọi "tồn đầu" là nhập thì tôi mới thấy kỳ kỳ thôi.


Còn ở chủ đề này, tôi biết chủ đích của tác giả chủ đề là muốn tham khảo những cách thực hiện của những ngôn ngữ khác ngoài Power query, (có lẽ là để định hướng học thêm 1 ngôn ngữ mới chăng).
 
Lần chỉnh sửa cuối:
Em xem trên Onedrive nó hay sinh ra file tạm gì đó, Dữ liệu gốc có mấy trăm mb, mà trong onedrive lên tận mấy gb, hình như nó lưu từng bản chỉnh sửa của người dùng ạ.
Em đã từng ứng dụng thất bại 1 lần khi dùng OneDrive, nên phải quay về offline,
Giờ em đang dùng bản trả phí, tiếp tục ứng dụng lần nữa, nhưng độ bất an chỉ giảm đi, chứ không mất đi ạ.
thì mấy na9m trước tôi quây nát nó rồi ... xong kết quả là chạy nhanh và lẹ
 
On/Off cũng chỉ là khái niệm tương đối.
Nếu ai đó ứng dụng bài này, không nhất thiết cần đưa lên mạng. Giờ công ty ai cũng dùng mạng Lan, giả sử Data để trên một máy chủ nào đó.
Máy khách sửa đường dẫn đến File nguồn, chạy Report thì cũng có thể gọi là Online.
Mình dùng từ 'online' chưa chuẩn.
Theo như bạn nêu thì là tầm vực/ phạm vi hệ thống mạng mà thôi.

Ở phạm vi internet, như bài #75, hệ thống vài cửa tiệm tạm hóa chẳng hạn, chỉ cần xây dựng ban đầu là xong. Phần giao diện web có phần cho khách hàng vào đặt hàng, có phần cho người quản trị vào kiểm tra kho hàng.
Tại mỗi cửa hàng nhập, xuất hàng thì dữ liệu đều về một database. Xem báo cáo là tức thời luôn.

Quy mô lớn hơn thì có các phần mềm ERP dùng qua internet, cho LAN (như bạn nói) đều được.

Phạm vi ở đây, có thể mọi người quen thuộc với Access, Excel nên cứ bám theo vậy. Như phương án trên thì Excel chỉ là các bảng dữ liệu tạm mà thôi, có thể còn không dùng gì tới Excel.
 
Cài cái ms Server bản Free đi mà dùng cho khỏe bản Free = 10 GB lưu cũng nhiều lắm đấy
Bài đã được tự động gộp:

Chắc chắn bạn thiết kế sai bài rồi. Người ta viết ứng dụng Access cho nhiều người dùng, kết nối qua internet bằng Cloud drive này dùng bao nhiêu năm rồi mà có bị vấn đề tạo ra file tạm đâu. Bạn nào mới viết, chưa khai thác đúng Access sẽ bị lỗi này. Còn cách xử lý, xin lỗi các bạn tự tìm hiểu nhé :D
giờ có cái SQLTCP/IP rồi thì cách này vị trí của nó trong thùng RÁC rùi ... ko cần tìm nữa
 
Kiểm soát vật tư (Inventory Control) chủ yếu là quy trình. Quy trình không rõ rệt thì phần mềm chỉ là chắp vá.
Đồ chắp vá rất khó so sánh nhau. Mỗi CSDL có điểm mượt của chúng đối với từng thiết kế phần mềm. Phải dựng được một mô hình (prototype) áp dụng cho khoảng 70% trường hợp thì mới so sánh được.
Như tôi đã nói ở bài trên, dữ liệu chủ đề này được lấy từ 1 chủ đề khác, mà chủ đề đó lại là chủ đề "thi tốc độ", nên nó không phải là 1 prototype áp dụng cho 70% trường hợp được. Hà huống tác giả lại không phải chuyên ngành quản lý kho :p :p
Có thể tác giả chủ đề đang muốn tham khảo cách tính toán của ngôn ngữ khác (ghi trong bài 1 là Python, Delphi, SQL, ...), cũng bởi vì xài Power query mất tới 4 phút.
Báo cáo hiện tại thì Sếp ko cần refresh gì đâu bạn, bạn gửi Báo cáo cho sếp thì cái báo cáo đấy bạn phải tự refresh, Sếp chỉ coi report thôi,
Đó là ông sếp thụ động. Ông sếp chủ động phải tuyên bố: tôi muốn xem lúc nào là xem, muốn xem khoảng thời gian nào là xem, không phải là 1 báo cáo cố định của 1 tháng và khi nào nhân viên gởi mới xem được. Tôi lại phải hỏi và đốc thúc mới có báo cáo mà xem à?
Ông sếp ngon là còn đòi hỏi báo cáo real time nữa kia: lúc sáng tồn bằng này, phòng vật tư báo hàng về 9 giờ sáng, sao giờ này 17 giờ báo cáo tồn kho chưa thấy tăng lên?
 
Như tôi đã nói ở bài trên, dữ liệu chủ đề này được lấy từ 1 chủ đề khác, mà chủ đề đó lại là chủ đề "thi tốc độ", nên nó không phải là 1 prototype áp dụng cho 70% trường hợp được. Hà huống tác giả lại không phải chuyên ngành quản lý kho :p :p
Có thể tác giả chủ đề đang muốn tham khảo cách tính toán của ngôn ngữ khác (ghi trong bài 1 là Python, Delphi, SQL, ...), cũng bởi vì xài Power query mất tới 4 phút.

Đó là ông sếp thụ động. Ông sếp chủ động phải tuyên bố: tôi muốn xem lúc nào là xem, muốn xem khoảng thời gian nào là xem, không phải là 1 báo cáo cố định của 1 tháng và khi nào nhân viên gởi mới xem được. Tôi lại phải hỏi và đốc thúc mới có báo cáo mà xem à?
Ông sếp ngon là còn đòi hỏi báo cáo real time nữa kia: lúc sáng tồn bằng này, phòng vật tư báo hàng về 9 giờ sáng, sao giờ này 17 giờ báo cáo tồn kho chưa thấy tăng lên?
Nói đến cái đoạn giờ nữa thì em thấy Power Query nó Change Type ngày sang dạng Datetime, nếu chuẩn ra có thể tính chuẩn đến giờ phút giây luôn :) (Sếp choáng)
 
Lần chỉnh sửa cuối:
Như tôi đã nói ở bài trên, dữ liệu chủ đề này được lấy từ 1 chủ đề khác, mà chủ đề đó lại là chủ đề "thi tốc độ", nên nó không phải là 1 prototype áp dụng cho 70% trường hợp được. Hà huống tác giả lại không phải chuyên ngành quản lý kho :p :p
Có thể tác giả chủ đề đang muốn tham khảo cách tính toán của ngôn ngữ khác (ghi trong bài 1 là Python, Delphi, SQL, ...), cũng bởi vì xài Power query mất tới 4 phút.

Đó là ông sếp thụ động. Ông sếp chủ động phải tuyên bố: tôi muốn xem lúc nào là xem, muốn xem khoảng thời gian nào là xem, không phải là 1 báo cáo cố định của 1 tháng và khi nào nhân viên gởi mới xem được. Tôi lại phải hỏi và đốc thúc mới có báo cáo mà xem à?
Ông sếp ngon là còn đòi hỏi báo cáo real time nữa kia: lúc sáng tồn bằng này, phòng vật tư báo hàng về 9 giờ sáng, sao giờ này 17 giờ báo cáo tồn kho chưa thấy tăng lên?
Không phải muốn là được đâu bạn nhìn ở góc độ excel dữ liệu ít thì không sao, dữ liệu lớn người ta chia ra nhiều tầng database để đảm bảo hệ thống trơn tru, từ database chuyển sang data lake cũng phải có lịch , xuống data pipeline hay warehouse cũng phải có lịch , sau đó mới tới hệ thống report thì cũng phải có lịch và nó chậm hơn mấy thằng data kia, bây giờ báo cáo người ta xem daily, dữ lắm là vài tiếng xem 1 lần chứ ai đâu mà coi liên tục, dữ liệu lớn refresh import liên tục thì database nào chịu nổi, sài direct hay live connect report nó quay vòng vòng hoài ai mà đợi được, sếp thì cũng phải theo tool, theo database hiện có, chỉ cần tăng số lần hay đổi giờ refresh phải phải xem xét hỏi It xem có ổn không xem có đụng thời gian refresh của các báo cáo khác không? cả một vấn đề chứ không hề đơn giản, nhất là mấy tool connect trực tiếp database mà doanh nghiệp không có data warehouse hay data lake
 
Nói đến cái đoạn giờ nữa thì em thấy Power Query nó Change Type ngày sang dạng Datetime, nếu chuẩn ra có thể tính chuẩn đến giờ phút giây luôn :) (Sếp choáng)
Lý thuyết nghe thì dễ vậy chứ thực tế nó đơn giản vậy đâu bạn. Bạn tưởng tượng bạn có 300 ngàn điểm bán nhỏ, công ty bạn bán hàng trăm sku, dăm bảy chục brand. Một tháng tính 26 ngày(trừ chủ nhật) thì mỗi ngày bạn sẽ nạp dữ liệu cho 12 ngàn điểm, mỗi điểm đó ví dụ tính dăm ba chục Sku thôi, chưa kể những điểm lớn 1 tuần bạn phải đi vài lần, bạn nhân số lượng đó cho việc đặt hàng, tính trưng bày, tính hàng tồn,....Chưa kể việc bạn quản lý tính chính xác của dữ liệu đầu vào không hề đơn giản. Bạn sẽ thấy dữ liệu một ngày nó lớn tới mức nào, bạn nhân 1 tháng, 1 năm sẽ thấy phải hệ thống khủng mới chơi được. Cho nên real time là việc ai cũng muốn nhưng để thực hiện nó không phải là chuyện cứ muốn mà được.
 
@Cá ngừ F1: Theo tôi việc để riêng hẳn 1 bảng số dư đầu năm là không hợp lý và làm cho việc truy vấn phức tạp hơn. Tại bảng danh mục, thêm 2 trường SLG và STIEN để ghi nhận số dư thì tốt hơn.
 
@Cá ngừ F1: Theo tôi việc để riêng hẳn 1 bảng số dư đầu năm là không hợp lý và làm cho việc truy vấn phức tạp hơn. Tại bảng danh mục, thêm 2 trường SLG và STIEN để ghi nhận số dư thì tốt hơn.
Phải có chứ anh.
Cái số liệu này là giả định. Anh thử tưởng tưởng số liệu nó liên tục năm nay qua năm khác. Việc tính tồn đầu phải tính những thứ nhập/xuất < ngày FromDate.
 
@Cá ngừ F1: Theo tôi việc để riêng hẳn 1 bảng số dư đầu năm là không hợp lý và làm cho việc truy vấn phức tạp hơn. Tại bảng danh mục, thêm 2 trường SLG và STIEN để ghi nhận số dư thì tốt hơn.
Theo tôi thì có bảng Tồn đầu riêng là hợp lý chỉ có cái là chưa đầy đủ. Phải có thêm cột Ngày và cứ cuối tháng sẽ làm nghiệp vụ kết chuyển Tồn đầu tháng đưa vô bảng này. Khi do sẽ giảm lượng dữ liệu cần truy xuất để tính NXT.
Ví dụ:

Screen Shot 2021-10-11 at 18.32.57.png
 
Theo tôi thì có bảng Tồn đầu riêng là hợp lý chỉ có cái là chưa đầy đủ. Phải có thêm cột Ngày và cứ cuối tháng sẽ làm nghiệp vụ kết chuyển Tồn đầu tháng đưa vô bảng này. Khi do sẽ giảm lượng dữ liệu cần truy xuất để tính NXT.
Ví dụ:

View attachment 267527
Tôi lại nghĩ khác. Nếu muốn đưa tồn đầu tháng vào thì chỉ việc thêm mỗi tháng 2 cột vào danh mục là ổn
1633954824817.png
 
Lý thuyết nghe thì dễ vậy chứ thực tế nó đơn giản vậy đâu bạn. Bạn tưởng tượng bạn có 300 ngàn điểm bán nhỏ, công ty bạn bán hàng trăm sku, dăm bảy chục brand. Một tháng tính 26 ngày(trừ chủ nhật) thì mỗi ngày bạn sẽ nạp dữ liệu cho 12 ngàn điểm, mỗi điểm đó ví dụ tính dăm ba chục Sku thôi, chưa kể những điểm lớn 1 tuần bạn phải đi vài lần, bạn nhân số lượng đó cho việc đặt hàng, tính trưng bày, tính hàng tồn,....Chưa kể việc bạn quản lý tính chính xác của dữ liệu đầu vào không hề đơn giản. Bạn sẽ thấy dữ liệu một ngày nó lớn tới mức nào, bạn nhân 1 tháng, 1 năm sẽ thấy phải hệ thống khủng mới chơi được. Cho nên real time là việc ai cũng muốn nhưng để thực hiện nó không phải là chuyện cứ muốn mà được.
Chắc bạn đang nói đến một đơn vị kinh doanh bán lẻ (kiểu siêu thị). Họ sẽ có app có khi vài triệu đô, chip qr/mã vạch hàng vào/ra mới quản lý được.
Còn excel ở đây ai cũng biết chỉ làm cỡ nhỏ gọn. Đến a Bill cũng chỉ cho sheet có hơn triệu dòng.
Bản thân tôi nếu data có lớn quá cũng phải chia nhỏ để làm. Trước thì chia theo quý, sau tháng, nở ra thì chia thành nửa tháng, rồi tuần một…
 
Tôi lại nghĩ khác. Nếu muốn đưa tồn đầu tháng vào thì chỉ việc thêm mỗi tháng 2 cột vào danh mục là ổn
Đối với dữ liệu lớn và sử dụng hệ cơ sở dữ liệu như SQL server, MS SQL, ... sẽ dùng câu lện SQL để truy vấn, thì dùng bảng dọc như bạn @ongke0711 sẽ hợp lý hơn, bảng ngang như bạn thích hợp với excel hơn. Vì Excel thêm cột tùy ý, cứ thêm tháng là thêm cột cho đến chục năm chưa hết cột. Còn hệ CSDL thì số lượng cột tạo lập ban đầu là cố định.
Dù vậy, tôi quan niệm tách bảng số dư ra khỏi bảng danh mục vì:
- Bảng danh mục là bảng có biến động số dòng: mặt hàng luôn luôn có khai báo thêm, thỉnh thoảng loại bớt ra (loại bớt bằng cách đánh dấu chứ không phải xóa), do vậy số lượng record cứ tăng thêm. Những mặt hàng không dùng nữa thì loại bỏ ra cho các báo cáo kỳ hiện tại và tương lai.
- Bảng số dư thì không phải lúc nào cũng >0 cho tât cả mặt hàng, và biến động theo kiểu khác: một mặt hàng lúc thì tồn lúc thì hết. Những mặt hàng trước đây có tồn nhưng giờ không dùng nữa vẫn phải truy xuất số dư để làm báo cáo cho kỳ quá khứ, ...
 
Tôi lại nghĩ khác. Nếu muốn đưa tồn đầu tháng vào thì chỉ việc thêm mỗi tháng 2 cột vào danh mục là ổn
View attachment 267529
Nếu trích tồn ĐK tháng nào đó bạn sẽ phải tính ra số cột tương đương tháng, còn nếu có cột Ngày thì bạn chỉ cần điều kiện lọc Ngày, theo tôi sẽ truy vấn nhanh hơn. Tôi không biết Excel như thế nào chứ đối với các hệ CSDL nói chung thì ưu tiên phát triển theo dòng, chứ không theo cột vì tốc độ truy vấn sẽ ảnh hưởng rất nhiều nếu bảng dữ liệu quá nhiều cột, dòng thì không giới hạn.
 
Nếu trích tồn ĐK tháng nào đó bạn sẽ phải tính ra số cột tương đương tháng, còn nếu có cột Ngày thì bạn chỉ cần điều kiện lọc Ngày, theo tôi sẽ truy vấn nhanh hơn. Tôi không biết Excel như thế nào chứ đối với các hệ CSDL nói chung thì ưu tiên phát triển theo dòng, chứ không theo cột vì tốc độ truy vấn sẽ ảnh hưởng rất nhiều nếu bảng dữ liệu quá nhiều cột, dòng thì không giới hạn.
Tôi nghĩ kết hợp 2 bảng danh mục và tồn kho lại với nhau để đơn giản lệnh SQL. Còn với việc chỉ để lưu số tồn kho thì cũng chỉ có thêm 24 cột chứ không nhiều nhặn gì. Nhưng thôi, cách nào rồi cũng query được, hãy để mọi người quay lại với việc chính của thớt thôi.
 
Tôi nghĩ kết hợp 2 bảng danh mục và tồn kho lại với nhau để đơn giản lệnh SQL. Còn với việc chỉ để lưu số tồn kho thì cũng chỉ có thêm 24 cột chứ không nhiều nhặn gì. Nhưng thôi, cách nào rồi cũng query được, hãy để mọi người quay lại với việc chính của thớt thôi.
Bảng này lưu tồn kho ĐK qua các năm luôn chứ không phải 1 năm rồi xoá bạn.
 
Rất cảm ơn mọi người đã tham gia trao đổi ở Topic này.

Ngay từ đầu tôi chạy bằng PowerQuery mất 4-5 phút, thuật toán groupby và cộng với nhiều điều kiện (cả nhập/xuất và khoảng thời gian), nhưng sau bài của anh @ptm0412 và anh @excel_lv1.5 tôi học hỏi, thay đổi thuật toán, cần Filter khoảng thời gian trước rồi mới Groupby, thì thời gian cũng đã giảm 1 nửa.

Anh @VetMini nhận xét dùng từ "phát triển" là hơi quá. Thực tế chủ đề gốc chạy offline, giải pháp dùng VBA Dictionary. Thì giờ các giải pháp cũng trăm hoa đua nơ, nào Python, BI (Dax), Access, SQL... thì chứng tỏ qua thời gian GPE cũng phát triển hơn, không chỉ dùng VBA thuần túy. Chủ để gốc của anh @Nguyễn Duy Tuân và em vẫn đang chờ đợi một giải pháp bằng Delphi từ anh (hoặc bất kỳ ai). Có thể anh @VetMini nói "thi đấu" là đúng, đến Slogan của Olympic cũng là "Faster - Higher - Stronger, Together", cả thế giới vẫn luôn tìm những kỷ lục mới, còn "quy trình" là điều đương nhiên phải theo, không chỉ là bài toán xuất/nhập này.

Anh @befaint nhận xét bài này kỳ kỳ, thì tinh thần của em nói ngay từ đầu, dữ liệu gốc đẩy đâu đó trên 9 tầng mây. Một người ở bất kỳ đâu (có internet), refresh, đợi 2, 3 phút nhâm nhi cốc cafe, hút điếu thuốc là có một báo cáo đẹp, chỉnh chu. Có thể sau này phát triển thêm về cách đưa dữ liệu lên mạng, như a gơi ý có thể qua web chẳng hạn, giống như bài lấy tỷ giá ngoại tệ VCB (thì sẽ nhanh hơn).

TB: chúc mọi người một ngày làm việc hiệu quả.
 
Rất cảm ơn mọi người đã tham gia trao đổi ở Topic này.

Ngay từ đầu tôi chạy bằng PowerQuery mất 4-5 phút, thuật toán groupby và cộng với nhiều điều kiện (cả nhập/xuất và khoảng thời gian), nhưng sau bài của anh @ptm0412 và anh @excel_lv1.5 tôi học hỏi, thay đổi thuật toán, cần Filter khoảng thời gian trước rồi mới Groupby, thì thời gian cũng đã giảm 1 nửa.

Anh @VetMini nhận xét dùng từ "phát triển" là hơi quá. Thực tế chủ đề gốc chạy offline, giải pháp dùng VBA Dictionary. Thì giờ các giải pháp cũng trăm hoa đua nơ, nào Python, BI (Dax), Access, SQL... thì chứng tỏ qua thời gian GPE cũng phát triển hơn, không chỉ dùng VBA thuần túy. Chủ để gốc của anh @Nguyễn Duy Tuân và em vẫn đang chờ đợi một giải pháp bằng Delphi từ anh (hoặc bất kỳ ai). Có thể anh @VetMini nói "thi đấu" là đúng, đến Slogan của Olympic cũng là "Faster - Higher - Stronger, Together", cả thế giới vẫn luôn tìm những kỷ lục mới, còn "quy trình" là điều đương nhiên phải theo, không chỉ là bài toán xuất/nhập này.

Anh @befaint nhận xét bài này kỳ kỳ, thì tinh thần của em nói ngay từ đầu, dữ liệu gốc đẩy đâu đó trên 9 tầng mây. Một người ở bất kỳ đâu (có internet), refresh, đợi 2, 3 phút nhâm nhi cốc cafe, hút điếu thuốc là có một báo cáo đẹp, chỉnh chu. Có thể sau này phát triển thêm về cách đưa dữ liệu lên mạng, như a gơi ý có thể qua web chẳng hạn, giống như bài lấy tỷ giá ngoại tệ VCB (thì sẽ nhanh hơn).

TB: chúc mọi người một ngày làm việc hiệu quả.

Bài toán này chúng ta không cần bàn tới cấu trúc CSDL. Chủ đề là tìm giải pháp chạy online, tốc độ nhanh (theo mặc định dữ liệu là như vậy) nên ta chỉ dựa vào mẫu dữ liệu trên mây đó để tìm hay ngó nghiêng giải pháp công nghệ. Khi nào chúng ta tạo chủ đề như là "Thiết kế cơ sở dữ liệu quan hệ trong quản lý kho" thì chúng ta mới mổ sẻ cấu trúc sao cho hợp lý. Thời gian này anh đang vướng bận nên chưa thể làm demo trên Delphi. Sau này làm được với đúng yêu cầu online thì sẽ demo lên đây.
 
Lần chỉnh sửa cuối:

Bài viết mới nhất

Back
Top Bottom