Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

[Access2k]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Xem qua cái database của anh Lehongduc thấy nó đơn giản hơn trước. Nhưng tôi hơi bị xáo trộn vì thay đổi tên table, field.

- Theo tôi admin nên đưa ra doanh nghiệp chúng ta quản lý hàng hóa cụ thể là gì? nông sản, hàng tiêu dùng, thực phẩm v.v... nếu đưa ra chung chung thì có nhiều phương án lắm.
- Sau đó chốt lại các table gốc - Loại 1: Loại hàng hoá, Danh mục hàng hoá, Danh mục khách hàng và nhà cung cấp.
- Table loại 2: phục vụ các Form nhập-xuất-thu-chi.
- Table loại 3: phục vụ các report (làm sau cũng được).

 

[lehongduc]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Chào các Bạn,
Xin trao đổi thêm về vấn đề đăng ký giá hàng hoá ở đâu?
Theo tôi Giá hàng hoá nên được đăng ký ở những bảng dữ liệu sau đây:

1. Trong bảng đăng ký hệ thống đơn vị tính của hàng hoá: mục đích phục vụ cho việc tham chiếu nhanh đơn giá khi lập các chứng từ nhập hoặc xuất (sau đây xin ghi tắt là NX).
Cách xử lý đại khái như thế này: Khi lập chứng từ NX mỗi khi ta chọn 1 mã hàng ứng dụng sẽ tự động tham chiếu và đưa đơn giá ra cột đơn giá tương ứng với đơn vị tính đã chọn.

2. Vị trí thứ 2 để đăng ký đơn giá: trong trường hợp cần áp dụng đơn giá riêng cho từng khách hàng ta sẽ lập thêm bảng đăng ký đơn giá áp dụng riêng (thí dụ: bảng tbldongiarieng), trong đó sẽ có các field sau:
+ mã số khách hàng
+ mã số hàng hoá
+ đơn vị tính
+ đơn giá sỉ
+ đơn giá lẻ
+ là chiết khấu tỷ lệ?
+ mức chiết khấu cho 1 đơn vị hàng hoá (nếu đã xác định "là chiết khấu tỷ lệ" thì giá trị ghi tại cột này là tỷ lệ chiết khấu cụ thể, nếu không sẽ là mức chiết khấu cố định cho 1 đơn vị hàng hoá)
Tương tự như trên, khi lập chứng từ NX: ứng dụng sẽ tham khảo 2 yếu tố: mã khách hàng có liên quan (khách mua hoặc khách bán) và mã số hàng hoá đã chọn để tham chiếu bảng đơn giá riêng để đưa đơn giá ra.

Làm như vậy sẽ bảo đảm được tính nhất quán của dữ liệu và dễ theo dõi truy xuất và bảo trì.
-----------------------------------------------------------------------------------------

Tôi có ý kiến:
- Giả sử tôi muốn biết nhà cung cấp A có những sản phẩm nào: nếu dùng Group query thì chỉ tìm được những sản phẩm đã mua của nhà cung cấp mà không biết được nhà cung cấp có tất cả các sản phẩm gì. Khách hàng B đã mua những sản phẩm nào: cái này group query thì OK.
- Việc không có table trung gian liên kết giữa tblDMHH và tblDMKHNCC chương trình sẽ lỗi khi Group 2 nhà cung cấp mà cung cấp cùng một loại sản phẩm. Thứ 2: khi nhập mã hàng hóa thì phải nhập thêm tên nhà cung cấp sẽ bất tiện. Ví dụ: khi nhập mã số nhà cung cấp tại tblNHAP, sau đó nhập mã hàng hóa vào tblNHAPCT sẽ dẫn đến trường hợp thực tế mã hàng hóa ấy nhà cung cấp không có bởi không có mối liên hệ gì giữa tblDMHH và tblDMKHNCC .
- Có thể lưu giá bán vào tblDMHH được không? không tạo table mới nữa.

Về vấn đề này, xin góp ý như sau:
1. Để xác định hàng hoá chỉ do 1 Nhà cung cấp duy nhất cung cấp: cho đăng ký mã nhà cung cấp (lấy từ liên kết với bảng đăng ký danh sách khách hàng) như 1 thuộc tính của mặt hàng.
2. Để xác định 1 khách hàng xác định đã cung cấp những mặt hàng nào, số lương?,... Hoặc 1 mặt hàng xác định nào đó đã được những ai cung cấp cho ta: sẽ căn cứ vào các chứng từ nhập hàng phát sinh trong kỳ xác định.
Ta sẽ xác định được bởi chứng từ nhập đã ghi rõ 2 yếu tố: người bán và mặt hàng cụ thể
Cách thức xử lý ra sao chúng ta sẽ bàn ở công đoạn sau vậy.

 

[muontennguoi]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Hic.
Ngay từ đầu đã đề nghị chúng ta viết PM cho DN nhỏ, ở DN đó bỏ qua phần quản trị Đơn đặt hàng mua và Hợp đồng bán hàng.

Các góp ý trong bài số #23 là thuộc về module đó - quản trị.
Trong các table ban đầu của anh Phát cũng có 1 table thuộc lĩnh vực này: table giá bán.

Tuy nhiên theo tôi viết PM bao gồm cả các phần đó cũng được.
Nhưng đối với các newbie thì dễ rối.

To newbies:
Bạn hãy nhìn vấn đề theo các bước:

1. Ghi nhận các phát sinh vào các table. Mỗi table theo dõi tình hình biến động (tăng-giảm) của mỗi thực thể (hàng, phiếu nhập, phiếu chi, phiếu xuất, hoá đơn ...)
2. Từ các số liệu đã có trên table ta bước sang:

• Lập các báo cáo. Đó là các báo cáo về thực trạng hiện có của các đối tượng.
• Lập các công cụ hổ trợ nhập liệu (kiểm tra số lượng hàng tồn so với số xuất mà người nhập liệu vừa gõ vào, tự động đề nghị số thuế GTGT cần có trên hoá đơn chuẩn bị in ra ...)

OK. Để ghi nhận các biến động, đối với kế toán cũng chính là việc nhập các phiếu vào máy, do đó ta phải chuẩn bị các table gồm các field để lưu các chỉ tiêu mà trên 1 phiếu có thể có. Người nhập liệu cầm phiếu đó trên tay, đọc và gõ vào máy.
Như vậy rất đơn giản khi bạn tạo các table, ví dụ tạo table lưu giữ thông tin các Phiếu Chi, bạn tạo các field để người dùng gõ vào:

• Số chứng từ
• Ngày
• Tên người nhận
• Nội dung chi
• Số tiền
• TK ghi Nợ
• TK ghi Có

Đến đây bạn sẽ thấy một số vấn đề:

Gõ tên người nhận tiền hoặc đơn vị nhận tiền sẽ rất khó. Mã hoá chúng để sau đó ta chỉ cần gõ mã số khách hàng hoặc mã nhân viên trong phần hành khác. Như vậy sẽ dễ hơn. Thế là ta thêm table MaKH-NCC và đặt relation vào table PC ở trên.​

Tương tự cho Phiếu Thu, Phiếu Nhập, Phiếu Xuất, Hoá Đơn ...​

TK Nợ, Có cũng là vấn đề tương tự, chỉ có điều là Nhà nước đã mã hoá sẵn giùm ta rồi. Chỉ cần gõ số hiệu thay vì gõ tên tài khoản.​

Rất đơn giản, ai cũng biết, phải không? Vậy đừng để những cái đơn giản này làm rối trí khi xem xét chi tiết phức tạp hơn.​

Đối với Phiếu Nhập, Xuất, Hoá Đơn còn có vấn đề: ghi nhận từng mã hàng hoá (mỗi phiếu có thể gồm nhiều mã hàng hoá). Hãy xem xét nó chung với vấn đề sau: Tại sao ta không ghi chung các PN, PX, PT, PC, HĐơn đầu vào, HĐơn đầu ra ... vào chung 1 table? Nếu công ty có nhiều kho hàng thì sao?

Công cụ để phân tích, lý giải là phương pháp luận hướng đối tượng.​

Hãy liên hệ với 2 đối tượng mà ta rất quen thuộc: File và Folder (thư mục).​

Bạn hãy tự tay mình tạo các table căn bản (để ghi nhận thực trạng của đối tượng).​

Sau khi bạn đã tự tạo các table căn bản đó rồi hãy xem xét tiếp các góp ý của lehongduc.​

Nhận xét về các table của phatnq2002 và lehongduc như sau:
- Phatnq2002 chia PN và PX thành 2 table.
- Lehongduc gộp chung thành 1 table.
Đối với kế toán ta thấy nó tương đương với 2 hình thức: Sổ nhật ký và Nhật ký chung.
Với hình thức Nhật ký riêng:

• sau đó gộp chung các Nhật ký riêng lại thành Nhật ký chung.
• mỗi loại nghiệp vụ tạo 1 sổ Nhật ký riêng: Nhật ký bán hàng, Nhật ký mua hàng, Nhật ký thu tiền, Nhật ký chi tiền ... tương ứng là tạo các table riêng biệt.
• khi cần in Sổ cái từng tài khoản thì phải lấy từ Nhật ký chung.

Với hình thức Nhật ký chung:

• khi cần in Nhật ký riêng thì lọc tách ra.

Xét về khía cạnh hướng đối tượng nhìn ở góc độ toàn bộ sổ kế toán của công ty là 1 đối tượng thì sử dụng Nhật ký chung sẽ có nhiều thuận lợi hơn.
Trong các table của lehongduc vừa đưa lên hiện vẫn còn tách rời Nhật ký thu-chi và Nhật ký mua-bán.

 

[lehongduc]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Chào các Bạn,
Xin trao đổi thêm về các "đối tượng" cần quản lý trong công việc quản lý mua - bán hàng hoá mà ứng dụng của chúng ta nhắm vào.
Nhìn một cách khái quát ứng dụng của chúng ta phải quản lý các đối tượng chính sau đây:
1. Hàng (bao gồm: hàng hoá và dich vụ)
2. Tiền
3. Khách hàng
Với 2 đối tượng Hàng và Tiền: ta quản lý các biến động chủ yếu thông qua việc thu thập các chứng từ phát sinh (nhập, xuất, thu, chi).
Để xây dựng cấu trúc các bảng một cách hợp lý chúng ta cần phải căn cứ vào đặc điểm của từng loại chứng từ phát sinh để quyết định những vấn đề sau:
+ cần có bao nhiêu bảng
+ cấu trúc cụ thể của từng bảng
Hãy xét đặc điểm của từng loại chứng từ:
+ loại chứng từ nhập, xuất hàng hoá: bao gồm các thông tin chung của chứng từ (nghiệp vụ phát sinh, khách hàng có liên quan, giá trị, ...) còn có thông tin chi tiết về từng mặt hàng phát sinh.
+ loại chứng từ thu, chi: chỉ bao gồm các thông tin chung về nghiệp vụ phát sinh, khách hàng có liên quan, số tiền.
Vì lý do trên, ta không thể gộp chung các chứng từ nhập, xuất và thu, chi vào đăng ký chung 1 bảng dữ liệu.

Vì Hàng luôn luôn có liên quan đến Tiền do việc thanh toán tiền mua bán hàng (dù với phương thức nào: ghi nợ, trả bằng tiền mặt, bằng chuyển khoản, ...) nên khi xử lý chứng từ nhập, xuất ta sẽ cho ứng dụng tự động ghi nhận các biến động của Tiền có liên quan bằng việc tự động lập chứng từ thu, chi tương ứng với nghiệp vụ Nhập, Xuất phát sinh.

 

[phatnq2002]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Thế là cuộc thảo luận đã đến hồi gay cấn.

Tuy nhiên xin lưu ý tất cả anh em là: như lúc đầu tôi đã ràng buộc giới hạn của bài toán để anh em có thể từng bước nắm được những thao tác căn bản nhất của Access. Ràng buộc của tôi là đây là một doanh nghiệp bán sỉ, cung cấp thực phẩm đóng gói, và việc quản lý gói trong mua bán và công nợ.

Nếu chúng ta xem đây là một "training online" - một dạng hướng dẫn trực tuyến để xây dựng một ứng dụng bằng Access dành cho các newbie - những người mới làm quen với Access thì khi chúng ta phân tích quá rộng, mở rộng bài toán quá lớn sẽ khiến họ bị ngợp.

Việc gộp bảng nhập, xuất, ... về cơ bản không có gì là không đúng cả. Tuy nhiên như quan điểm ban đầu, việc gộp bảng như thế sẽ khiến các anh em newbie khá lúng túng để hình dung, nhất là khi bước vào lập trình. Quá trình tách lọc xử lý sẽ không hề đơn giản đối với họ.

Đối với các junior và senior trong lĩnh vực này, tôi không dám đứng chiếu trên mà áp đặt hay gì gì đó, vì nếu như thế thì tôi làm luôn một cái topic xuyên suốt luôn, đâu cần thiết để anh em thảo luận chi cho nó cực và nhiều khi khiến anh em phiền lòng.

Vả lại, việc thiết kế ban đầu cũng là do thói quen và kinh nghiệm của từng người. Do vậy, chúng ta cũng không chắc rằng ai đúng, ai sai, mà chúng ta chỉ mong rằng thế nào là ổn.

Mong anh em góp ý thêm, nhất là các anh em mới làm quen Access. Vì khi có ý kuiến của anh em, chúng tôi mới có cơ hội hiểu thêm anh em cần gì.

 

[muontennguoi]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Chào các Bạn,
Xin trao đổi thêm về các "đối tượng" cần quản lý trong công việc quản lý mua - bán hàng hoá mà ứng dụng của chúng ta nhắm vào.
Nhìn một cách khái quát ứng dụng của chúng ta phải quản lý các đối tượng chính sau đây:
1. Hàng (bao gồm: hàng hoá và dich vụ)
2. Tiền
3. Khách hàng
Với 2 đối tượng Hàng và Tiền: ta quản lý các biến động chủ yếu thông qua việc thu thập các chứng từ phát sinh (nhập, xuất, thu, chi).
Để xây dựng cấu trúc các bảng một cách hợp lý chúng ta cần phải căn cứ vào đặc điểm của từng loại chứng từ phát sinh để quyết định những vấn đề sau:
+ cần có bao nhiêu bảng
+ cấu trúc cụ thể của từng bảng
Hãy xét đặc điểm của từng loại chứng từ:
+ loại chứng từ nhập, xuất hàng hoá: bao gồm các thông tin chung của chứng từ (nghiệp vụ phát sinh, khách hàng có liên quan, giá trị, ...) còn có thông tin chi tiết về từng mặt hàng phát sinh.
+ loại chứng từ thu, chi: chỉ bao gồm các thông tin chung về nghiệp vụ phát sinh, khách hàng có liên quan, số tiền.
Vì lý do trên, ta không thể gộp chung các chứng từ nhập, xuất và thu, chi vào đăng ký chung 1 bảng dữ liệu.

Vì Hàng luôn luôn có liên quan đến Tiền do việc thanh toán tiền mua bán hàng (dù với phương thức nào: ghi nợ, trả bằng tiền mặt, bằng chuyển khoản, ...) nên khi xử lý chứng từ nhập, xuất ta sẽ cho ứng dụng tự động ghi nhận các biến động của Tiền có liên quan bằng việc tự động lập chứng từ thu, chi tương ứng với nghiệp vụ Nhập, Xuất phát sinh.

Ở đoạn màu đỏ xin bàn thêm một chút.
Nhìn vào sổ Nhật Ký Chung của kế toán ta thấy tất cả chứng từ đều thể hiện chung vào 1 mẫu sổ.
Như vậy ta có thể làm 1 bảng đăng ký chung cho tất cả chứng từ kế toán được không?
Tất nhiên là được. Những chứng từ nào yêu cầu lưu trữ thông tin (thuộc tính - properties) riêng của nó thì sẽ có bảng riêng của nó.

Các chứng từ kế toán phải có các thuộc tính bắt buộc sau:
- Tên chứng từ (loại Ctừ: PT, PC, PN, PX, HĐ ...)
- Số, ngày.
- Họ tên, đơn vị thực hiện (người nộp tiền, người nhận tiền, người giao hàng - nhà cung cấp, người nhận hàng, người mua ...)
- Số tiền (bằng số và bằng chữ).
- TK ghi Nợ, Có.
- Nội dung, diễn giải.
- Chữ ký những người có trách nhiệm.

Như vậy với PN, PX thì cần có thêm thông tin chi tiết về mã hàng, số lượng ..
Đối với hoá đơn thì ngoài họ tên thì cần thêm: địa chỉ, mã số thuế. Ngoài ra có thể thêm: số điện thoại, ...

Kế toán qua mấy trăm năm phát triển của Chủ nghĩa tư bản nó cũng đồng thời phát triển thành 1 cái nghề với đầy đủ cơ sở lý luận toán học khoa học.
Phương pháp luận hướng đối tượng không phải là 1 phát kiến, nó chỉ là 1 phát minh: nâng lên thành lý luận của 1 thực tế đã tồn tại trước đó.
Do đó, vẫn có thể áp dụng hướng đối tượng vào hệ thống kế toán đã có sẵn.
Vậy sổ Nhật Ký Chung hay bất kỳ hình thức nào của kế toán cũng vẫn áp dụng tin học theo hướng đối tượng được. Ta chỉ cần dựa theo đó mà không cần phải phân tích gì nhiều.
Thực tế làm phần mềm kế toán rất đơn giản.
Quả trị ERP thì khó hơn vì nó chưa hình thành nên 1 hệ thống, do tài nghệ của GĐ là chủ yếu.
Nếu không làm kế toán mà làm phần mềm ERP thì chắc chắn sẽ nhiều tranh luận.
Nhưng ở đây ta chỉ giới hạn trong phạm vi kế toán tài chánh. Kế toán quản trị sẽ tính sau.

 

[phatnq2002]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Hôm nay vào lại topic sao thấy "im hơi lặng tiếng" quá.

Theo tiến độ thì nếu không có gì thay đổi lớn, đầu tháng 11 tới, tôi sẽ đăng tiếp phần thiết lập quan hệ (relationship) và hướng dẫn tạo một form nhập liệu danh mục.

Mong anh em tiếp tục góp ý, ủng hộ cho topic này.

Anh em nào đang có nhu cầu tự viết một ứng dụng quản lý mua bán có thể theo dõi tất cả các bài viết ở đây. Có thể thể chưa đầy đủ, nhưng sẽ được tổ chức theo một bài bản rõ ràng, từng bước để mọi người theo dõi.

 

[duong quang]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Thank ban nhieu nhe, tai liệu rất bổ ích !
Mình đang loay hoay vẽ sơ đồ thực thể liên kết giữa các thực thể (chưa vẽ bao giờ - ko rành lắm)
Bạn có sơ đồ thực thể nào cho loại bài trên ko share cho mình tham khảo với !

 

[muontennguoi]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Bạn có thể đơn giản là dùng Word hoặc Viso để vẽ.
Nhưng sau khi đã tạo các table thì bạn có thể dùng công cụ Ralationship của Access mà vẽ.

Ví dụ từ đề nghị thiết kế các table của anh Phatnq2002 tôi dùng Access vẽ ra 2 sơ đồ sau:

Và :

 

[behattieu]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Muốn góp ý nhưng coding thì kém, nghiệp vụ kế toán không biết nên chỉ ngồi

 

[lehongduc]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Muốn góp ý nhưng coding thì kém, nghiệp vụ kế toán không biết nên chỉ ngồi

Chào Bạn,
Để tham gia vào vấn đề chúng ta đang bàn luận ở đây không đòi hỏi phải biết 2 nội dung: "coding" và "nghiệp vụ kế toán".
Nếu Bạn đang là người bán hàng (cho mình hoặc làm cho người khác), hoặc thậm chí đã vài lần đi mua hàng, Bạn cũng có thể tham gia trao đổi được mà.
+ Nếu là người đang bán hàng: Bạn có thể cho biết Bạn đang gặp khó chỗ nào khi sử dụng máy tính cho việc bán hàng?
+ Nếu là người mua hàng: Bạn có thể cho biết Bạn đang muốn người Bán thông qua máy tính làm sao tạo cho Bạn nhiều thuận tiện hơn khi đến mua hàng, thanh toán, ...
+ Và theo Bạn trong cả 2 trường hợp trên làm sao là tốt nhất?

Hãy mạnh dạn tham gia cùng chúng tôi đi Bạn.

 

[phatnq2002]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Tôi có ý kiến thế này:
Vì bài toán của chúng ta đưa ra là quản lý hàng hoá - công nợ, không phải là một phần mềm kế toán hoàn chỉnh do đó không cần thiết đưa phần thuế suất vào sau này xử lý code sẽ thêm phức tạp (Giá nhập và giá bán sẽ là giá đã có thuế). Trong thực tế, những người quản lý, nhân viên bán hàng, theo dõi kho, theo dõi công nợ họ cũng không cần quan tâm đến việc tách riêng tiền hàng và tiền thuế vì họ không làm kế toán mà chỉ theo dõi và quản lý thôi.

Về thiết kế CSDL tôi đồng ý với ý kiến của anh lehongduc. Chúng ta nên thiết kế thêm một bảng nghiệp vụ (tblNghiepVu). Mỗi một chứng từ thu, chi, nhập, xuất sẽ có một số nghiệp vụ. Bảng này cũng có thể được người sử dụng khai báo lại tuỳ theo thực tế của từng đơn vị. Khi NSD lập một chứng từ (hay 1 bút toán) thì sẽ chọn nghiệp vụ phù hợp đã được khai báo. Căn cứ vào nghiệp vụ này mà chương trình có thể xác định được bút toán đó sẽ ảnh hưởng như thế nào đối với mỗi loại sổ sách báo cáo (Quỹ, kho, công nợ phải thu, công nợ phải trả). Vì các chứng từ đều có các thuộc tính cớ bản giống nhau (Mã CT, Số CT, Ngày , ...) nên nếu thiết kế chung trên 1 bảng thì việc tổng hợp, xử lý số liệu sẽ dễ hơn rất nhiều. Những chứng từ có các thuộc tính riêng ta có thể thiết kế thêm các bảng cho phù hợp

Còn một việc nữa chưa thấy mọi người nhắc đến: đó là CSDL của chúng ta sẽ tách ra từng năm một hay chỉ dùng một tệp MDB trong suốt quá trình ứng dụng? Nếu để chung thì CSDL sẽ ngày một lớn nhất là đối với những đơn vị có nhiều phát sinh, như vậy sẽ ảnh hưởng đến tốc độ và độ tin cậy của chương trình, mặt khác số lượng record trong một table không phải là vô hạn. Còn tách ra từng năm (mỗi năm tạo một cơ sở dữ liệu mới) sẽ thêm rất nhiều việc để xử lý code (Chuyển số dư năm trước sang năm sau, NSD xem báo cáo từ từ năm này sang năm khác)

Cảm ơn bạn đã có ý kiến.

Tuy nhiên, nếu bạn xem lại bài trước của tôi trong bõ này thì tôi đồng ý là các chứng từ có thể gộp lại thành 1 bảng, nhưng xét do với những ai đã có khá nhiều kinh nghiệm với Access + lập trình thì sẽ dễ dàng hiểu và xử lý code; nhưng những anh em mới thì lại là vấn đề khó đấy.

Bởi vậy tôi mới thiết kế tách ra. Cái vấn đề này bác lehongduc và bác muontennguoi cũng đã đề cập.

Tôi muốn rằng sau khi anh em đã được đi hết những phần căn bản rồi thì phần nâng cao, anh em có thể tự khám phá thêm và nếu cần thiết chúng ta có thể hỗ trợ tiếp.

Về số lượng record lưu trữ trong file MDB thì bạn không nên quá lo lắng, thứ nhất theo kinh nghiệm của cá nhân thì một table có số record cỡ chừng 100 ngàn đến 200 ngàn thì không có vấn đề. Nếu một doanh nghiệp "ăn nên làm ra" mà xài ứng dụng do anh em cùng làm này thì bình quân khoảng bao nhiêu lần nhập hàng trong ngày? Không nhiều lắm đâu. Xuất cũng vậy. Mà đã từng có ứng dụng lưu đến gần 500 ngàn record/bảng đấy.

Thứ hai, chúng ta đâu cần thiết phải tải hết dữ liệu của một bảng, chúng ta có thể gọi một query để lọc những nội dung chúng ta cần để xử lý thôi. Như thế tốc độ tải dữ liệu cũng không đáng lo ngại.

Thứ ba, việc sao lưu cũng là một kỹ thuật mà chúng ta sẽ bàn sau khi đã hoàn chỉnh cái sườn của ứng dụng.

 

[lehongduc]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Cảm ơn bạn đã có ý kiến.

Tuy nhiên, nếu bạn xem lại bài trước của tôi trong bõ này thì tôi đồng ý là các chứng từ có thể gộp lại thành 1 bảng, nhưng xét do với những ai đã có khá nhiều kinh nghiệm với Access + lập trình thì sẽ dễ dàng hiểu và xử lý code; nhưng những anh em mới thì lại là vấn đề khó đấy.

Bởi vậy tôi mới thiết kế tách ra. Cái vấn đề này bác lehongduc và bác muontennguoi cũng đã đề cập.

Tôi muốn rằng sau khi anh em đã được đi hết những phần căn bản rồi thì phần nâng cao, anh em có thể tự khám phá thêm và nếu cần thiết chúng ta có thể hỗ trợ tiếp.

Về số lượng record lưu trữ trong file MDB thì bạn không nên quá lo lắng, thứ nhất theo kinh nghiệm của cá nhân thì một table có số record cỡ chừng 100 ngàn đến 200 ngàn thì không có vấn đề. Nếu một doanh nghiệp "ăn nên làm ra" mà xài ứng dụng do anh em cùng làm này thì bình quân khoảng bao nhiêu lần nhập hàng trong ngày? Không nhiều lắm đâu. Xuất cũng vậy. Mà đã từng có ứng dụng lưu đến gần 500 ngàn record/bảng đấy.

Thứ hai, chúng ta đâu cần thiết phải tải hết dữ liệu của một bảng, chúng ta có thể gọi một query để lọc những nội dung chúng ta cần để xử lý thôi. Như thế tốc độ tải dữ liệu cũng không đáng lo ngại.

Thứ ba, việc sao lưu cũng là một kỹ thuật mà chúng ta sẽ bàn sau khi đã hoàn chỉnh cái sườn của ứng dụng.

Chào các Bạn,
Xin tham gia ý kiến về vấn đề "nên tổ chức file dữ liệu riêng hay chung trong file ứng dụng?"
Theo tôi, nên tách file dữ liệu thành file dữ liệu riêng, độc lập với file ứng dụng. Đây cũng là cách tối ưu mà các tài liệu hướng dẫn của Microsoft về MS. Access đều đề nghị.
Với cách tổ chức file dữ liệu độc lập nêu trên khi file ứng dụng được nạp ta sẽ cho liên kết (MS. Access gọi là link data) các bảng dữ liệu từ file dữ liệu chỉ định vào ứng dụng.
Tất nhiên, chúng ta sẽ bàn đến vấn đề này ở các bước sau theo sắp xếp của "chủ xị". Các Bạn mới tìm hiểu cũng đừng lo lắm về việc này vì Bác Bill rất chu đáo đã bố trí sẵn trong MS. Access 1 tiện ích để giúp ta làm việc này rất dễ dàng và nhanh chóng.
Về việc nạp dữ liệu từ file độc lập, các Bạn có quan tâm có thể tham khảo các trao đổi tại: http://danketoan.com/forum/showthread.php?t=90807

 

[MEBO]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Về việc thêm một bảng đơn vị tính:

Cảm ơn anh lehongduc đã có ý kiến. Tuy nhiên nếu anh đọc kỹ ở phần mô tả thì tôi đang mô tả cho một doanh nghiệp bán sỉ. Kiểm soát đơn vị tính sẽ rất tốt cho các doanh nghiệp vừa bán lẻ vừa bán sỉ, khi lập báo cáo có thể theo dõi được mình tồn bao nhiêu theo "cách đọc" đơn vị tính mà mình lựa chọn.

Nghe theo cách anh cần có lẽ anh cũng đã từng đụng tới các doanh nghiệp bán hàng dược phẩm rồi thì phải.

Về mặt góp ý của anh, tôi xin ghi nhận, nhưng chúng ta sẽ thêm vào sau nhé? Sau khi anh em đã có nền tảng sẵn rồi, chúng ta sẽ tiếp tục nâng cấp nó lên.

Về việc không cần phân loại khách hàng và nhà cung cấp:

Nhất trí với anh lehongduc về việc không cần phân loại khách hàng và nhà cung cấp nếu chúng ta sử dụng bảng gộp chung.

Tuy nhiên để nói rõ hơn với anh và mọi người là tại sao tôi sử dụng field đó. Khi thiết kế cụ thể, mặc định nó sẽ là 3. Chỉ khi nào người sử dụng định lại thôi. Mục đích là để thống kê sau này, ai là chỉ mua không bán, ... Cho nó nhanh thay vì phải query từ các chứng từ khác.

Về việc theo dõi hàng hóa do ai cung cấp (tức theo dõi nguồn cung cấp):

Cái này theo tôi không cần thiết đâu Access2k à. Vì để biết ai cung cấp mặt hàng nào, chúng ta chỉ cần làm một cái query đơn giản dựa trên phiếu nhập là ra ngay, kể cả có thể tìm được cùng một mặt hàng, ai là người bán giá tốt nhất tính đến thời điểm gần nhất khi thống kê. Bạn lưu ý giúp tôi cái này luôn nhé, để khi mình vào xử lý sẽ làm luôn cái query này.

Về việc phải có bảng giá bán:

À cái này tất nhiên rồi, sẽ có thôi nhưng ở mục tiếp theo.

Do có một số trở ngại về thời gian nên tôi chưa xong phần tiếp theo: các table chứng từ, mong anh em thông cảm. Ngày mai (23-10-2008) tôi sẽ gửi tiếp lên.

Mời mọi người tiếp tục. Bắt đầu xôm tụ rồi.

Phân tích như thế em bắt đầu nắm được vấn đề rồi, sẽ ráng theo đến hết dự án này, thank mọi người

 

[muontennguoi]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Chào các Bạn,
Xin tham gia ý kiến về vấn đề "nên tổ chức file dữ liệu riêng hay chung trong file ứng dụng?"
Theo tôi, nên tách file dữ liệu thành file dữ liệu riêng, độc lập với file ứng dụng. Đây cũng là cách tối ưu mà các tài liệu hướng dẫn của Microsoft về MS. Access đều đề nghị.
Với cách tổ chức file dữ liệu độc lập nêu trên khi file ứng dụng được nạp ta sẽ cho liên kết (MS. Access gọi là link data) các bảng dữ liệu từ file dữ liệu chỉ định vào ứng dụng.
Tất nhiên, chúng ta sẽ bàn đến vấn đề này ở các bước sau theo sắp xếp của "chủ xị". Các Bạn mới tìm hiểu cũng đừng lo lắm về việc này vì Bác Bill rất chu đáo đã bố trí sẵn trong MS. Access 1 tiện ích để giúp ta làm việc này rất dễ dàng và nhanh chóng.
Về việc nạp dữ liệu từ file độc lập, các Bạn có quan tâm có thể tham khảo các trao đổi tại: http://danketoan.com/forum/showthread.php?t=90807

Ý kiến về mở data:

Theo tôi ta nên tập cách mở data như phương thức server-cleint.
Mặc dù cách mở link data là cái có sẵn trong Access, sử dụng nó sẽ dễ dàng hơn.

Nhưng cái lợi của việc làm quen các câu lệnh cũng như phương pháp mở data dạng server-cleint thì đáng để xem xét:

Nếu như ta mở data bằng Access và viết ứng dụng khai thác bằng các lệnh connect dạng server-cleint thì nó cho phép ta viết ứng dụng bằng phần mềm khác mà vẫn giữ nguyên data, chẳng hạn như viết bằng Vísual Foxpro, .NET ... thậm chí là bằng Excel, Word ...

Ngược lại nếu như lúc nào đó là chuyển data thành SQL server hoặc Foxpro thì khi đó ứng dụng của ta trong Access chỉ cần thay đổi câu lệnh connect mà thôi.

Việc đó giúp cho dự án này rộng hơn cho mọi người. Ai cũng có thể tham gia.


========

Giống như chính Diễn đàn này, khi ta xem bài hoặc xóa, sửa bài ... thì lúc này ta không hề connect đến data.

Chỉ khi ta nhấn nút "Gửi" hoặc click vào 1 cái link xem bài khác thì máy của ta mới chạy lên server và chính server lúc này mới mở và thao tác trên data.

Trong Form của Access nếu cũng làm thế, các dữ liệu gõ vào chỉ nằm trên recordset của máy cleint. Chỉ trong method save ta mới cho mở và nên dùng lệnh SQL để Insert, Update, Delete ...

 

[Access2k]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Tôi đã tải dbkhohang và xem RelationShip (mối quan hệ các bảng), chao ôi như rừng rậm amazôn. Tôi đã tham khảo Northwind.mdb thấy nó mạch lạc hơn nhiều. Những gì thể hiện trong RelationShip chủ yếu là 1-nhiều và toàn vẹn tham chiếu, những liên kết khác như không toàn vẹn tham chiếu chúng ta có thể làm khi thiết kế query làm nguồn cho form.

Vừa rồi mọi người lại bàn tách CSDL ra, theo tôi chưa cần thiết, vì phải viết code link Database con với Database mẹ. Mà việc tách ra ta phải tự làm lấy, để Access tách ra sẽ không theo ý muốn.

Theo quan điểm của tôi cần chốt lại các table trong database đã.

Các table gốc: tblLOAIHH (loại hàng hoá); tblDMHH (danh mục hàng hóa); tblBANGGIA (bảng giá - nếu cần thiết); tblDMKHNCC (khách hàng và nhà cung cấp). Ngoài ra có thể có table về nghiệp vụ và phải có 1 table lưu trữ dữ liệu của công ty sử dụng phần mềm này - admin đặt tên cho ứng dụng của chúng ta đi - PHẦN MỀM QUẢN LÝ HÀNG HOÁ VÀ THU CHI?

Các table quản lý tiền: tblTHU-tblTHUCT; tblCHI-tblCHICT.

Các table quản lý hàng: tblNHAP-tblNHAPCT; tblXUAT-tblXUATCT; tblNHAPTRA-tblNHAPTRACT; tblXUATTRA-tblXUATTRACT. Tôi có băn khoăn này table nhập trả và xuất trả có cần thiết không? các field trong table nhập trả, xuất trả có cần phải tương đồng với table nhập, xuất không?

Các table còn lại: phục vụ cho report - hoàn toàn make table được mà không cần tạo table.

Khi tạo RelationShip chỉ cần đưa 3 loại table trên.

Nếu muốn tách CSDL thì các table gốc sẽ nằm lại ở CSDL mẹ, các table gốc là các table đã có dữ liệu trước khi chúng ta thiết kế form và lập trình.

Các table quản lý tiền và hàng chưa có dữ liệu gì trước khi lập trình, là những table có thể tách ra CSDL con.

Theo tôi các field trong tblNHAP phải tương đồng với tblXUAT để khi lấy xuất trừ nhập thì ra tồn.

Thiết kế CSDL trong dbkhohang là đã tách nhập-xuất và thu-chi; theo tôi nhập-xuất có thể gộp lại làm 2 table Nhậpxuất và NhậpxuấtCT; tương tự như thu chi cũng vậy. Tương tự như đã gộp khách hàng và nhà cung cấp vào 1 table.

 

[meo_luoi]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Sao mèo ko đọc được vậy?giúp mèo với được không?híc

 

[muontennguoi]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Sao mèo ko đọc được vậy?giúp mèo với được không?híc

Không đọc được cái gì chứ? Hổng hiểu.

 

[thuhien]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

Theo sự ủy nhiệm của anh Phát, SND xin đính kèm file giới thiệu thiết kế Cơ sở dữ liệu (bước 2). Thanks anh Phát, mời mọi người tham khảo và góp ý thêm

em đọc trong file pdf này chỉ mô tả một ít table thôi. Trong khi thực tế thì lại nhiều hơn table mô tả, làm em thật sự khó hiểu nổi những table này lưu gữi gì và các thuộc tinh nó ý nghĩa ra sao
tblNHAPCT,tblNHAPTRACT,tblXUATCT.....các thành phần trong tbl cũng ko hiểu nổi nó là gì, toàn từ viết tắt ko thôi, mình chả hiểu gì. Minh mới học nên còn nhiều cái chưa biết rất mong mọi người giúp đỡ mình

 

[suynghidi]

Ðề: Quản lý mua bán hàng - Phần 2: Thiết kế CSDL

em đọc trong file pdf này chỉ mô tả một ít table thôi. Trong khi thực tế thì lại nhiều hơn table mô tả, làm em thật sự khó hiểu nổi những table này lưu gữi gì và các thuộc tinh nó ý nghĩa ra sao
tblNHAPCT,tblNHAPTRACT,tblXUATCT.....các thành phần trong tbl cũng ko hiểu nổi nó là gì, toàn từ viết tắt ko thôi, mình chả hiểu gì. Minh mới học nên còn nhiều cái chưa biết rất mong mọi người giúp đỡ mình

Trong file đính kèm chỉ nêu ra những mô tả ban đầu, và theo thời gian, mọi người cùng phân tích, thảo luận rồi mới đi đến thống nhất cuối cùng. Khi đã thống nhất, lúc đó mới có file CSDL cuối cùng, đi kèm là bản mô tả, giải thích chi tiết. Hiện tại quá trình làm dự án này đang bị "chựng lại" vì nhiều lý do.
Hy vọng trong thời gian đến sẽ được làm tiếp..........