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

[phatnq2002]

Như đã thông báo, từ hôm nay (22-10-2008) tôi sẽ tiếp tục đăng phần 2.

Do có một số thay đổi trên máy nên hiện nay tôi không thể đính kèm file cho các bạn được.

Do vậy tôi sẽ nhờ SUYNGHIDI đăng bài, các bạn sẽ lấy file đính kèm về xem và cùng tham gia thảo luận.

Trước tiên tôi chỉ gửi cho các bạn mục A - Các table danh mục.

Các bạn có thể tham khảo và cho ý kiến:

• Thêm bớt table
• Thêm bớt field
• ...

Lưu ý sử dụng màu chữ để dễ kiểm soát: nội dung - xanh dương, yêu cầu thêm - đỏ, yêu cầu bớt - xanh lá.

Go on ...

 

[suynghidi]

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

Như đã thông báo, từ hôm nay (22-10-2008) tôi sẽ tiếp tục đăng phần 2.

Do có một số thay đổi trên máy nên hiện nay tôi không thể đính kèm file cho các bạn được.

Do vậy tôi sẽ nhờ SUYNGHIDI đăng bài, các bạn sẽ lấy file đính kèm về xem và cùng tham gia thảo luận.

Trước tiên tôi chỉ gửi cho các bạn mục A - Các table danh mục.

Các bạn có thể tham khảo và cho ý kiến:

• Thêm bớt table
• Thêm bớt field
• ...

Lưu ý sử dụng màu chữ để dễ kiểm soát: nội dung - xanh dương, yêu cầu thêm - đỏ, yêu cầu bớt - xanh lá.

Go on ...

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

 

[411]

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

Em mới xem qua bài của bác Phatnq2002, em thấy ý kiến 1 lưu thông tin khách hàng và nhà cung cấp chung vừa gọn mà cũng hay nưã.
Em chỉ có bổ sung một tí là nên thêm cả phần MST của khách hàng hoặc nhà cung cấp vào luôn cho tiện và thêm một cột ghi chú nữa để trong trường hợp có giảm giá hoặc khuyến mãi gì đó thì mình ghi thêm vào.Ý em thế không biết các bác thế nào?

 

[phatnq2002]

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

Em mới xem qua bài của bác Phatnq2002, em thấy ý kiến 1 lưu thông tin khách hàng và nhà cung cấp chung vừa gọn mà cũng hay nưã.
Em chỉ có bổ sung một tí là nên thêm cả phần MST của khách hàng hoặc nhà cung cấp vào luôn cho tiện và thêm một cột ghi chú nữa để trong trường hợp có giảm giá hoặc khuyến mãi gì đó thì mình ghi thêm vào.Ý em thế không biết các bác thế nào?

Cái phần khuyến mãi hiện thời chưa đưa vào đây vì thực tế nó còn nhiều điều phải bàn lắm. Khuyến mãi có khá nhiều hình thức: có những hình thức thông dụng như: mua n tặng m sản phẩm cùng loại (hoặc khác loại), mua n tính tiền n-1 cái, mua n giảm giá m%, mua từ n giá trị trở lên giảm m%, tích lũy điểm theo giá trị hàng mua để được đổi hàng, ... Rồi còn chính sách riêng của mỗi công ty.

Những field nhất thiết phải thêm, bớt sẽ thảo luận ở đây. Còn không cần thêm (có hay không cũng không sao ) thì tùy mỗi người để tiện cho công việc từng người.

 

[lehongduc]

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

Như đã thông báo, từ hôm nay (22-10-2008) tôi sẽ tiếp tục đăng phần 2.

Do có một số thay đổi trên máy nên hiện nay tôi không thể đính kèm file cho các bạn được.

Do vậy tôi sẽ nhờ SUYNGHIDI đăng bài, các bạn sẽ lấy file đính kèm về xem và cùng tham gia thảo luận.

Trước tiên tôi chỉ gửi cho các bạn mục A - Các table danh mục.

Các bạn có thể tham khảo và cho ý kiến:

• Thêm bớt table
• Thêm bớt field
• ...

Lưu ý sử dụng màu chữ để dễ kiểm soát: nội dung - xanh dương, yêu cầu thêm - đỏ, yêu cầu bớt - xanh lá.

Go on ...

Chào các Bạn,
Với cấu trúc của bảng đăng ký danh mục hàng hoá như "chủ xị" đề nghị ta chỉ có thể sử dụng được 1 đơn vị tính duy nhất cho 1 mặt hàng.
Điều này sẽ gây khó khăn cho việc áp dụng trong thực tế, vì thực tế giao dịch thường sử dụng nhiều đơn vị tính cho 1 mặt hàng xác định (lúc thì thùng, lúc thì gói, ...)

Tôi đề nghị như sau:
Để lưu thông tin về danh mục hàng hoá ta tổ chức thành 2 bảng:
1. Bảng ghi thông tin chung về hàng hoá, bao gồm các field sau:
+ Mã số hàng hoá
+ Tên hàng hoá
+ Mã số nhóm hàng (xếp nhóm hàng hoá)
+ và các field ghi nhận các thuộc tính khác của hàng hoá mà ta cần quản lý (như: xuất xứ, đặc trưng kỹ thuật, chất liệu, ...)
2. Bảng ghi hệ thống đơn vị tính của hàng hoá, bao gồm các field như sau (gọi là hệ thống đơn vị tính vì các đơn vị tính này có quan hệ thống nhất với nhau, có thể tính quy đổi với nhau được):
+ Mã số hàng hoá
+ Cấp đơn vị tính (tính từ thấp đến cao với kiểu dữ liệu số nguyên)
+ kí hiệu đơn vị tính
+ Số lượng quy đổi về cấp 1 (đơn vị tính thấp nhất)
+ và một số field cần thiết khác tuỳ theo nhu cầu quản lý cụ thể

Làm như vậy khi ta cho đăng ký chi tiết hàng hoá của các chứng từ phát sinh sẽ linh hoạt và sát với thực tế hơn.

 

[lehongduc]

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

Em mới xem qua bài của bác Phatnq2002, em thấy ý kiến 1 lưu thông tin khách hàng và nhà cung cấp chung vừa gọn mà cũng hay nưã.
Em chỉ có bổ sung một tí là nên thêm cả phần MST của khách hàng hoặc nhà cung cấp vào luôn cho tiện và thêm một cột ghi chú nữa để trong trường hợp có giảm giá hoặc khuyến mãi gì đó thì mình ghi thêm vào.Ý em thế không biết các bác thế nào?

Chào các Bạn,
Tôi xin có ý kiến về bảng đăng ký danh sách khách hàng:
+ Với đối tượng doanh nghiệp mà chúng ta đang đề cập: không nhất thiết phân biệt Nhà cung cấp và Khách mua hàng ngay trong bảng danh sách khách hàng.
Một khách hàng vừa có thể là khách mua hàng lại vừa là nhà cung cấp hàng hoá (vừa mua của ta lại vừa bán cho ta)
+ Vậy ta căn cứ vào đâu sẽ phân biệt đâu là Nhà cung cấp, đâu là Khách mua hàng?
Ta sẽ căn cứ vào các chứng từ phát sinh (gắn liền với nghiệp vụ - hay giao dịch - cụ thể) để xác định:
Nếu là chứng từ nhập hàng mua vào: khách hàng là nhà cung cấp
Nếu là chứng từ xuất hàng bán ra: khách hàng là khách mua hàng
+ Điều này sẽ giúp chúng ta tổng hợp công nợ dễ dàng hơn khi khách hàng vừa là mua vừa là bán.

 

[Access2k]

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

Tôi xin góp ý về các table cơ bản:

- Bảng lưu thông tin về hàng hóa tblDMHH: Field loaihh_ma là cần có, ví dụ để khách hàng xem và so sánh giá các loại sữa hộp đóng chai của các hãng cung cấp chẳng hạn.
- Bảng lưu thông tin về nhóm hàng hóa tblDMLAOIHH: OK.
- Nên sử dụng ý kiến 1 để dễ quản lý hơn. Bảng lưu thông tin về khách hàng và nhà CC tblDMKHNCC: OK. Trước mắt cần field cơ bản, sau bổ sung thêm, vd: mã số thuế cũng được.

- Tôi có ý kiến này nữa Bảng lưu thông tin về hàng hóa tblDMHH có quan hệ gì với bảng Bảng lưu thông tin về khách hàng và nhà CC tblDMKHNCC không (có thể thêm 1 bảng trung gian nữa)? Giả sử tôi muốn biết nhà cung cấp A có những sản phẩm nào, khách hàng B đã mua những sản phẩm nào?

- Tiện thể admin link cái relationship để hình dung rõ hơn quan hệ các bảng.

 

[lehongduc]

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

Như đã thông báo, từ hôm nay (22-10-2008) tôi sẽ tiếp tục đăng phần 2.

Do có một số thay đổi trên máy nên hiện nay tôi không thể đính kèm file cho các bạn được.

Do vậy tôi sẽ nhờ SUYNGHIDI đăng bài, các bạn sẽ lấy file đính kèm về xem và cùng tham gia thảo luận.

Trước tiên tôi chỉ gửi cho các bạn mục A - Các table danh mục.

Các bạn có thể tham khảo và cho ý kiến:

• Thêm bớt table
• Thêm bớt field
• ...

Lưu ý sử dụng màu chữ để dễ kiểm soát: nội dung - xanh dương, yêu cầu thêm - đỏ, yêu cầu bớt - xanh lá.

Go on ...

Để tiện cho Anh Chị Em ta góp ý, đề nghị "chủ xị" công bố luôn thiết kết cấu trúc của các bảng đăng ký các chứng từ phát sinh (Nhập - Xuất, Thu - Chi).

 

[phatnq2002]

Ðề: 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.

 

[suynghidi]

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

Tôi xin góp ý về các table cơ bản:

- Bảng lưu thông tin về hàng hóa tblDMHH: Field loaihh_ma là cần có, ví dụ để khách hàng xem và so sánh giá các loại sữa hộp đóng chai của các hãng cung cấp chẳng hạn.
- Bảng lưu thông tin về nhóm hàng hóa tblDMLAOIHH: OK.
- Nên sử dụng ý kiến 1 để dễ quản lý hơn. Bảng lưu thông tin về khách hàng và nhà CC tblDMKHNCC: OK. Trước mắt cần field cơ bản, sau bổ sung thêm, vd: mã số thuế cũng được.

- Tôi có ý kiến này nữa Bảng lưu thông tin về hàng hóa tblDMHH có quan hệ gì với bảng Bảng lưu thông tin về khách hàng và nhà CC tblDMKHNCC không (có thể thêm 1 bảng trung gian nữa)? Giả sử tôi muốn biết nhà cung cấp A có những sản phẩm nào, khách hàng B đã mua những sản phẩm nào?

- Tiện thể admin link cái relationship để hình dung rõ hơn quan hệ các bảng.

1/ "Giả sử tôi muốn biết nhà cung cấp A có những sản phẩm nào, khách hàng B đã mua những sản phẩm nào?" <---- Group Query + điều kiện là OK thôi, cái này thuộc phần thiết kế Report.
2/ "- Tiện thể admin link cái relationship để hình dung rõ hơn quan hệ các bảng" <--- Theo SND, cứ để mọi người thảo luận cấu trúc các bảng, sau khi thống nhất các vấn đề liên quan, chốt lại, ta sẽ có Relationship cả trong ý nghĩ (tất nhiên là sẽ phải có thiết kế Relationship rồi).

 

[muontennguoi]

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.

Theo tôi ở vấn đề này, cũng xuất phát từ quản lý kho dược phẩm, ta áp dụng PP quản lý như ở 1 bệnh viện.
Nếu cần thiết thì chia ra làm 2 kho: kho chẵn và kho lẻ. Các bệnh viện áp dụng PP này từ rất lâu rồi.
Về lý luận, ta vừa đáp ứng yêu cầu quản lý riêng của DN, đồng thời qua khảo sát mà DN nhận được lời khuyên từ lập trình viên để cải thiện bộ máy quản lý của mình.
Vậy sơ lược về ý tưởng là: nếu nhập ĐVT nào thì xuất ĐVT ấy, nếu muốn xuất bằng ĐVT khác thì làm 1 phiếu xuất chuyển kho chẵn - kho lẻ và sau đó xuất bán từ kho lẻ.
Thực tế không nhất thiết phải là có kho lẻ, kho chẳn. CHỉ đơn giản là xuất chuyển kho (mà thực chất là chuyển ĐVT).
Vì lý do đó, nếu hàng hoá không quá thường xuyên thay đổi ĐVT thì chỉ cần đơn giản là mở Phiếu nhập cũ ra sửa lại ĐVT và SL tương ứng.
Khi đó 2 ĐVT khác nhau sẽ mang 2 mã số hàng hoá khác nhau.
Ví dụ: đã nhập 5 thùng bia, đã xuất bán 4 thùng, nay muốn bán 4 lon => Mở PN cũ sửa lại là nhập 4 thùng và 24 lon.

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.

Xin bổ sung thêm: Về nguyên lý thì các table vừa giới thiệu chỉ là danh mục mã hàng và mã khách hàng.
Sẽ phải có các table ghi nhận số luợng, số tiền phát sinh.
Và các table ghi nhận lý lịch PN, PX, Hoá đơn sẽ gồm các chỉ tiêu trên PN, PX và Hoá đơn ấy, trong đó có mã khách hàng.

2/ "- Tiện thể admin link cái relationship để hình dung rõ hơn quan hệ các bảng" <--- Theo SND, cứ để mọi người thảo luận cấu trúc các bảng, sau khi thống nhất các vấn đề liên quan, chốt lại, ta sẽ có Relationship cả trong ý nghĩ (tất nhiên là sẽ phải có thiết kế Relationship rồi).

Không nhất trí chút nào.
Chỉ mới có 4-5 table thì mở Access ra làm luôn đâu có tốn mấy công sức đâu.

 

[suynghidi]

Ðề: 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

Sau đây là bản thiết kế CSDL phần tiếp theo (file đính kèm - Nguồn : phatnq2002). Mời mọi người tiếp tục góp ý kiến.

 

[lehongduc]

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

Chào các Bạn,
Do vai trò hết sức quan trọng của giai đoạn phân tích và thiết kế các bảng dữ liệu cụ thể nên xin đề nghị:
+ Các "chủ xị" công bố luôn Relationship (bảng mô tả mối quan hệ giữa các bảng dữ liệu với nhau) để tiện cho Anh Chị Em ta góp ý;
+ Các "chủ xị" nên dành nhiều thời gian cho việc thảo luận, mổ xẻ công việc này;
+ Chúng ta nên tham gia thật cụ thể đến từng cấu trúc chi tiết của các bảng dữ liệu. Thậm chí có thể đề nghị 1 thiết kế cụ thể là 1 mdb có kèm lập luận vì sao phải như thế.

Theo kinh nghiệm của tôi nếu công đoạn này mà làm sơ sơ sẽ "đổ rất nhiều nợ" cho các công đoạn sau và cho suốt quá trình phát triển của ứng dụng về sau đó nữa.

 

[phatnq2002]

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

Chào các Bạn,
Do vai trò hết sức quan trọng của giai đoạn phân tích và thiết kế các bảng dữ liệu cụ thể nên xin đề nghị:
+ Các "chủ xị" công bố luôn Relationship (bảng mô tả mối quan hệ giữa các bảng dữ liệu với nhau) để tiện cho Anh Chị Em ta góp ý;
+ Các "chủ xị" nên dành nhiều thời gian cho việc thảo luận, mổ xẻ công việc này;
+ Chúng ta nên tham gia thật cụ thể đến từng cấu trúc chi tiết của các bảng dữ liệu. Thậm chí có thể đề nghị 1 thiết kế cụ thể là 1 mdb có kèm lập luận vì sao phải như thế.

Theo kinh nghiệm của tôi nếu công đoạn này mà làm sơ sơ sẽ "đổ rất nhiều nợ" cho các công đoạn sau và cho suốt quá trình phát triển của ứng dụng về sau đó nữa.

Thế anh lehongduc có tải file về để xem giúp chưa à?
Đồng ý với những quan điểm của anh, tuy nhiên tôi mong muốn anh em thảo luận đóng góp nhiều và sẽ dựa vào đó sẽ trình ra một database đã tổng hợp từ nhiều ý kiến của anh em.
Về relationship tất nhiên phải có nhưng chưa cần thiết "vẽ" ra luôn lúc này, do còn để anh em thảo luận kỹ.

 

[Access2k]

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

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.

 

[muontennguoi]

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

Về relationship tất nhiên phải có nhưng chưa cần thiết "vẽ" ra luôn lúc này, do còn để anh em thảo luận kỹ.

Đối với các chuyên gia nếu chưa vẽ ra thì cũng không thành vấn đề.
Chỉ cần đọc lướt qua các đối tượng là đã có thể hình dung.
Nhưng ở Diễn đàn này còn có nhiều người mới học sử dụng Access.
Lời khuyên cho các newbie là: hãy tự tay mình mở Access và tạo ngay các table và relationship.
Thao tác thành thục cũng là điều khá quan trọng.
Kèm theo đây là file đã tạo các table theo đề nghị ban đầu.
Mời các bạn tham khảo.

 

[thuydhpy]

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

Cho mình hỏi: Tại sao trong các phiếu chi tiết phiếu nhập hay chi tiết phiếu xuất, Primary key không chọn là Maso+mahang
Ví dụ: trong bảng TBLNHAPCT, primary có thể chọn là: NHAPID+hh_ma

 

[Access2k]

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

ID lấy từ 2 Field sẽ phức tạp, bản thân cái Autonumber làm ID cũng được rồi.

Bắt đầu phải nghiên cứu lâu đây.
Theo tôi các table như vậy tạm ổn.

Tạm phân loại table:
Các table gốc - Loại 1: tblDMHH, tblDMLHH, tblDMKHNCC, tblBANGGIA.
Các table khác - Loại 2: nhập, xuất, thu, chi, xuất trả, nhập trả.
MakeTable - Loại 3: TONKHODAUTHANG và các table còn lại.
Table chưa biết để làm gì: tblNHAPCT_XUAT.

 

[muontennguoi]

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

Cho mình hỏi: Tại sao trong các phiếu chi tiết phiếu nhập hay chi tiết phiếu xuất, Primary key không chọn là Maso+mahang
Ví dụ: trong bảng TBLNHAPCT, primary có thể chọn là: NHAPID+hh_ma

Giả sử trên 1 phiếu nhập (hoặc phiếu xuất) mà kế toán ghi 2 dòng với cùng 1 mã hàng thì sao?
Ai cấm? Có làm sai lệch điều gì không?
(Giả sử khi đang viết hoá đơn bán 10 thùng bia, bổng nhiên khách hàng bảo "Bán thêm thùng nữa", hoặc trong quán café ghi phiếu 3 ly café cho bàn đó rồi, lát sau thêm 1 người tới ngồi chung bàn lại kêu 1 ly café).

 

[suynghidi]

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

Sau đây là những góp ý của anh Hồng Đức kèm theo file thiết kế của anh Đức. Vì anh lehongduc chưa có quyền đính kèm file nên SND xin trích những góp ý cho topic + Các file liên quan trong file zip đính kèm của anh Đức (trong đó có file phân tích, Database và Relationship).

Để tham gia ý kiến cụ thể cùng Anh Chị Em trong chủ đề xây dựng 1 ứng dụng mẫu http://danketoan.com/forum/showthread.php?p=253082#post253082
Mình gửi Trường tài liệu góp ý chi tiết trong file zip đính kèm. Tài liệu gồm có:
1. Bản thuyết minh chi tiết
2. File mdb
3. File ảnh chụp màn hình Relationship của các bảng trong file mdb

Thêm mấy ý sau:
1. Theo mình, các Bạn "chủ xị" nên hướng Anh Chị Em đi các bước một cách bài bản, vì bước ban đầu không bài bản sẽ làm cho người mới dễ bị "lạc đường" tạo nên vết hằn trong tâm thức sẽ khó sửa chữa về sau.
2. Còn vấn đề này nữa, để Anh Chị Em là người mới tiếp cận với MS. Access tìm thấy được hứng thú liên tục khi tìm hiểu công cụ này, các bạn "chủ xị" cần hướng việc xây dựng ứng dụng này vào mục tiêu ứng dụng thiết thực, không nên chỉ dừng lại ở mức 1 bài tập làm quen.
3. Về cụ thể, các "chủ xị" cần cân nhắc việc tổ chức đăng ký đơn vị tính của hàng hoá. Ngay từ đầu nên xây dựng theo hướng 1 mặt hàng có nhiều đơn vị tính (lập thành hệ thống đơn vị tính của 1 mặt hàng). Điều này có ý nghĩa ứng dụng thực tế, đồng thời làm đơn giản cho việc tính toán về sau.
Với kinh nghiệm xây dựng ứng dụng "Quản trị bán hàng": Ban đầu mình cũng cho xây dựng cơ sở dữ liệu theo mục tiêu đăng ký 1 đơn vị tính cho 1 mặt hàng. Đến khi chỉnh lại theo hướng 1 mặt hàng có nhiều đơn vị tính để đáp ứng được với nhu cầu thực tế phát sinh mình đã mất rất nhiều công sức và thời gian để chỉnh sửa "một rừng" các object đã thiết kế có liên quan.
4. Làm sao để trong quá trình xây dựng ứng dụng mẫu này các "chủ xị" giúp Anh Chị Em tránh được tâm lý bất lợi: xem Access là "thần tượng", dẫn đến coi các công cụ khác "nhẹ ký". Cần phải làm cho tất cả chúng ta có cái nhìn khách quan và thực tế để tận dụng hết thế mạnh của từng công cụ đang có trong tay, nhằm đạt được mục tiêu "hiệu quả ứng dụng"

Công việc các bạn đang làm thật hữu ích và hết sức thú vị. Mình rất cảm kích.
Luôn mong các Bạn nhiều sức khoẻ.

@All: Xem các đóng góp của anh Muontennguoi, anh Phatnq2002 và anh HongDuc càng thấy mình nên đầu tư suynghithem
@Ban Quản trị: Đề xuất Admin bổ sung quyền gửi file đính kèm cho anh lehongduc để ảnh có thể gửi file góp ý đính kèm
@Tham vọng: Nếu những dự án này thành công, sau này chúng ta có hy vọng tạo ra những sản phẩm khác mang thương hiệu Danketoan để giúp đỡ miễn phí anh chị em trong diễn đàn. Mong mọi người tiếp tục ủng hộ. Thanks all