Dự án quản lý công nợ (2 người xem)

Liên hệ QC

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

handung107

Thành viên gắn bó
Thành viên danh dự
Tham gia
30/5/06
Bài viết
1,630
Được thích
17,443
Nghề nghiệp
Bác sĩ
Công ty A phân loại khách hàng như sau :

- Doanh thu mua hàng hàng tháng đạt từ 10.000.000 trở lên : nhóm khách hàng 1
- Doanh thu mua hàng hàng tháng đạt từ 5.000.000 đến nhỏ hơn 10.000.000 : nhóm khách hàng 2
- Doanh thu mua hàng hàng tháng ít hơn 5.000.000 : nhóm khách hàng 3

Với từng nhóm khách hàng có các yêu cầu về công nợ sau đây:

1/ Nhóm 1 :
- Thanh toán 50% mỗi lần mua hàng
- Số tiền tồn nợ tối đa là 7.000.000đ
- Thời hạn thanh toán là 2 tháng cho mỗi lần mua hàng

2/ Nhóm 2 :
- Thanh toán 70% mỗi lần mua hàng
- Số tiền tồn nợ tối đa là 3.500.000đ
- Thời hạn thanh toán là 1 tháng cho mỗi lần mua hàng

3/ Nhóm 3 :
- Thanh toán 80% mỗi lần mua hàng
- Số tiền tồn nợ tối đa là 2.000.000đ
- Thời hạn thanh toán là 1 tuần cho mỗi lần mua hàng

Từ những yêu cầu trên, hàng ngày, sẽ có những phiếu báo công nợ cần thanh toán đến các khách hàng theo mẫu đính kèm

Các bạn lưu ý, đây sẽ là bài thực hành đầu tiên, và phương pháp làm việc của chúng ta sẽ là làm việc theo nhóm. Có thể chúng ta sẽ chia ra 3 nhóm làm việc, mỗi nhóm sẽ có trưởng nhóm, và mỗi nhóm sẽ có Box riêng để trao đổi thảo luận với nhau, chúng ta sẽ có thi đua giữa các nhóm làm việc, và tôi sẽ đề cử Mod Hai2Hai tổ chức thực hiện phương pháp thực hiện dự án đầu tiên của Giaiphapexcel

Thời gian thực hiện đề tài này là 1 tháng. Các bạn đăng ký tham gia làm việc theo các nhóm nhé
 

File đính kèm

TodoList - Excel: QLCông nợ

hai2hai hơi bận nên tạm thời chỉ đưa ra cái TodoList đơn giản để mọi người tham khảo.

Vẫn nhấn mạnh với mọi người là: Quan trọng nhất là bước 1 (làm rõ yêu cầu) và bước 2 (làm thế nào để thực hiện yêu cầu = phần mềm - nghĩa là phân tích thiết kế). Khi bài toán đã rõ, cách làm đã rõ thì mỗi người có thể thực hiện công việc theo những gì mình biết về Excel

Mọi người giả như mình chưa biết về chuyện quản lý công nợ như thế nào, hãy thử xem là các thông tin chị Dung đưa ra thế đã đủ chưa?

Ví dụ:

- Thông tin khách hàng cần quản lý gồm những thông tin gì. (Để còn biết mà thiết kế DB chứ)
- Khi khách hàng mua hàng, hóa đơn mua hàng là như thế nào? (dĩ nhiên, nếu cho cái này ai cũng biết thì phải viết ra để KH (là chị Dung) confirm là đúng)
- Chính sách thanh toán (như chị Dung đã viết), có cần làm sáng tỏ gì thêm nữa không? Nếu có thì hỏi thêm nhé.
- Phiếu thanh toán thì như thế nào? các trường hợp thanh toán (thanh toán trước, thanh toán theo hóa đơn, thanh toán nhiều lần cho 1 hóa đơn, v.v...) các kiểu thanh toán: Thanh toán ngay = tiền mặt, mua nợ, v.v...
- Ngoài báo cáo chị DUng đưa ra cần báo cáo gì nữa ko? Hình thức báo cáo như thế nào (layout + nội dung)

Sau đó, hãy thử list ra các chức năng của PM xem sao.
Từ đó, xem cần hỏi bổ sung gì nữa ko thì tiếp tục hỏi chị Dung.

Mỗi nhóm, ai xung phong viết tài liệu yêu cầu phần mềm (nghĩa là tài liệu đầu vào để cho người phân tích thực hiện ấy)

Hỏi: Tại sao phải viết vày dù bài toán là nhỏ?
Trả lời:
- Tại vì ko phải ta làm 1 mình mà còn nhiều người khác muốn hiểu (nếu ko thì mỗi người hiểu 1 kiểu)
- Tại vì ko phải lúc nào ta cũng biết hết mọi trường hợp đặc biệt xảy ra.
- Tại vì nếu ko làm rõ ràng, có thể làm xong chị Dung (đại diện cho khách hàng) sẽ nói là ... thiếu rồi, thế này làm sao đáp ứng đủ.
- Tại vì nếu ko nói ra, ai cũng tưởng là người kia hiểu, mình hiểu, nhưng cuối cùng là chẳng ai hiểu nhau (hoặc thậm chí hiểu sai ý của nhau).
- v.v...

Mọi người cố gắng nhé. Ai tham gia vị trí nào thì xung phong và làm theo từng nhóm 1.

Cheeers
 

File đính kèm

Cám ơn Hải nhé. Chị bắt đầu thấy thú vị với cách làm việc và phương pháp em đề ra rồi đấy. Mong mọi người nhiệt tình bắt tay vào nhé.
 
Giả sử những câu hỏi của Hai2Hai đã được công ty A cung cấp thông tin như sau :
- Thông tin của khách hàng : tên Kh, địa chỉ, điện thọai, mã số thuế, nhóm khách hàng (nhóm 1, 2,3 như phân loại ở trên)
- Thông tin về nợ tồn đọng của khách hàng sẽ được cập nhật mỗi lần khách hàng tiến hành giao dịch. Nợ tồn đọng tối đa là 7.000.000 đ cho nhóm KH1, 3.500.000đ cho nhóm KH2 và 2.000.000đ cho nhóm 3. Nếu có giao dịch mới, sẽ kiểm tra xem nợ tồn là bao nhiêu, quá giới hạn tối đa sẽ không được thiếu
- Hóa đơn mua hàng là hóa đơn GTGT thông thường
- Phương thức thanh toán bằng tiền mặt chia làm 2 lần, thanh toán lần đầu là 50 %, cho nhóm 1, 70% cho nhóm 2 và 80% cho nhóm 3.
- Thời hạn thanh toán cho lần kế tiếp tối đa sẽ tùy vào nhóm KH như trên. Thời gian này được tính cho từng lần mua hàng. Và khi đến hạn sẽ thông báo bằng phiếu báo công nợ cho hóa đơn mua hàng số...
- Yêu cầu về PM : có các Form nhâp liệu thông thường
- Các BC cần có của công ty :
1/ Hàng tháng :
- BC công nợ của các KH
- BC mua hàng của các KH trong tháng để có thể theo dõi và cập nhật, điều chỉnh lại các nhóm KH cho KH
2/ Hàng ngày :
- BC danh sách các KH đến hạn thanh tóan
- BC danh sách các KH đã có nợ tồn đọng đạt mức tối đa như đã nói ở trên
Các biểu mẫu BC không bắt buộc theo mẫu, nhưng phải đảm bảo đủ nội dung cần thiết
 
Dạ, em hơi thắc mắc chị Dung ơi:
1. Thanh toán % cho mỗi lần mua hàng:
- Mỗi lần mua hàng: có phải là cho một đơn hàng hay không? Ở đây, cứ 1 phiếu giao hàng được xem là một đơn hàng hay không?
- Thanh toán ở đây có phải là thanh toán trước hay theo tỷ lệ quy định? Hay thanh toán nợ cũ.
- Và có quy định thêm giá trị của mỗi lần giao hàng không?
2. Thời hạn thanh toán: có phải tính từ ngày giao hàng?
3. Trường hợp, doanh thu mua hàng thay đổi thì nhóm khách hàng có thay đổi không?

Để em coi, em hỏi thêm chị Dung.
 
1/ Xem như mỗi lần mua hàng là một đơn hàng. Một phiếu giao hàng sẽ giao hàng cho một đơn hàng
2/ Được thanh toán trước theo tỷ lệ % cho mỗi nhóm khi nợ tồn chưa vượt quá giới hạn tối đa quy định cho các nhóm
3/ Không quy định giá trị của mỗi lần giao hàng mà quy định theo doanh thu mua hàng trong tháng
4/ Thời hạn thanh toán sẽ tính từ ngày giao hàng
5/ Trường hợp doanh thu thay đổi, có thể xếp nhóm lại. (Nhóm khách hàng có thể thay đổi tùy vào chế độ ưu đãi của công ty)
Các bạn hãy khởi động tham gia dự án đi nào....
 
/(/gười phá đám đây!

Cơ quan tôi QĐịnh đến ký HĐồng để 60 ngày sau phải đảm bảo đủ hàng theo hợp đồng cho tôi với tiền cộc là 15%. Yêu cầu lãi xuất ngang với ngân hàng Nhà nước được không anh chị?!
 
Hiện tại mình không có thời gian vào NET, làm sao những nội dung thảo luận được gởi đến mỗi người khi tham gia dự án?
Thân,

Lê Văn Duyệt.
 
levanduyet đã viết:
Hiện tại mình không có thời gian vào NET, làm sao những nội dung thảo luận được gởi đến mỗi người khi tham gia dự án?
Thân,

Lê Văn Duyệt.

Đơn giản kinh khủng.

1. Phân nhóm, trưởng nhóm:
- Mọi người tự chọn những người làm cùng nhóm với mình (YM!, ĐT,...). Sau khi đã thống nhất thành viên trong nhóm, các thành viên để lại thông tin liên lạc như Email, YM!, Skype, ĐT, v.v... Tốt nhất là dùng Group mail (Dùng GoogleMail có thể dùng Group mail được), nếu ko thì CC to All members
- Bầu cử trưởng nhóm (Việc này rất quan trọng). Trưởng nhóm có trách nhiệm đề ra phương án làm việc, quản lý công việc, theo dõi và đốc thúc tiến độ của công việc, giao việc cho các thành viên, tập hợp kết quả công việc của mọi người, v.v...

2. Thực hiện công việc theo công việc được giao: Công việc giao phải rõ ràng:
- Đầu vào: (Ví dụ: Yêu cầu của chị Dung là đầu vào của việc tao tại liệu yêu cầu phần mềm)
- Kết quả: (Ví dụ tài liệu yêu cầu phần mềm, cách viết tài liệu thế nào thì thực ra cũng có chuẩn để viết, anyways mọi người cứ thử nghĩ xem & thống nhất cách viết như thế nào sao cho người thiết kế đọc là có thể hiểu được đầy đủ bài toán)
- Thời gian bắt đầu
- Thời gian kết thúc (deadline)
- Ai thực hiện

3. Báo cáo tiến độ công việc & kết quả

Không có thời gian lên NET nghĩa là sao? Ví dụ 1 tuần vào 1 lần thì ko ổn rồi anh Duyệt ạ. Làm Online, nhất là làm phần mềm mà ko có net thì chả khác gì ....mất điện :)

Thực ra việc làm nhóm Online (hay bất cứ việc gì) ko khó. Nhưng em sure là ko làm được vì chủ yếu là con người không muốn làm ấy anh ạ.

Thử ecomotion này cái ++--//*

Ah, nội dung thảo luận là gì? Là 1 ai đó đưa ra ý kiến, người khác bổ sung ý kiến. Nếu ko ai đưa ra ý kiến thì sẽ ko có gì để thảo luận cả.

2 ngày rồi mà hình như ko thấy ai, nhóm nào công bố Tên nhóm cả. Dự án này 10 năm cũng ko thực hiện được
 
Lần chỉnh sửa cuối:
Hu hu, có một miếng Net nào đâu mà làm. Lâu lâu ra IS làm một phát, hơi bất tiện.
 
1. Phân tích yêu cầu

Giả sử những câu hỏi của Hai2Hai đã được công ty A cung cấp thông tin như sau :
1- Thông tin của khách hàng : tên Kh, địa chỉ, điện thọai, mã số thuế, nhóm khách hàng (nhóm 1,2,3 như phân loại ở trên)
2- Thông tin về nợ tồn đọng của khách hàng sẽ được cập nhật mỗi lần khách hàng tiến hành giao dịch. Nợ tồn đọng tối đa là 7.000.000 đ cho nhóm KH1, 3.500.000đ cho nhóm KH2 và 2.000.000đ cho nhóm KH3. Nếu có giao dịch mới, sẽ kiểm tra xem nợ tồn là bao nhiêu, quá giới hạn tối đa sẽ không được thiếu.
3- Hóa đơn mua hàng là hóa đơn GTGT thông thường
4- Phương thức thanh toán bằng tiền mặt chia làm 2 lần, thanh toán lần đầu là 50 %, cho nhóm 1, 70% cho nhóm 2 và 80% cho nhóm 3.
5- Thời hạn thanh toán cho lần kế tiếp tối đa sẽ tùy vào nhóm KH như trên. Thời gian này được tính cho từng lần mua hàng. Và khi đến hạn sẽ thông báo bằng phiếu báo công nợ cho hóa đơn mua hàng số...
6- Yêu cầu về PM : có các Form nhâp liệu thông thường
7- Các BC cần có của công ty :
a/ Hàng tháng :
- BC công nợ của các KH
- BC mua hàng của các KH trong tháng để có thể theo dõi và cập nhật, điều chỉnh lại các nhóm KH cho KH
b/ Hàng ngày :
- BC danh sách các KH đến hạn thanh tóan
- BC danh sách các KH đã có nợ tồn đọng đạt mức tối đa như đã nói ở trên
Các biểu mẫu BC không bắt buộc theo mẫu, nhưng phải đảm bảo đủ nội dung cần thiết
Các thắc mắc về yếu cầu:
1.Hỏi
Dạ, em hơi thắc mắc chị Dung ơi:
1. Thanh toán % cho mỗi lần mua hàng:
- Mỗi lần mua hàng: có phải là cho một đơn hàng hay không? Ở đây, cứ 1 phiếu giao hàng được xem là một đơn hàng hay không?
- Thanh toán ở đây có phải là thanh toán trước hay theo tỷ lệ quy định? Hay thanh toán nợ cũ.
- Và có quy định thêm giá trị của mỗi lần giao hàng không?
2. Thời hạn thanh toán: có phải tính từ ngày giao hàng?
3. Trường hợp, doanh thu mua hàng thay đổi thì nhóm khách hàng có thay đổi không?
Trả lời
1/ Xem như mỗi lần mua hàng là một đơn hàng. Một phiếu giao hàng sẽ giao hàng cho một đơn hàng
2/ Được thanh toán trước theo tỷ lệ % cho mỗi nhóm khi nợ tồn chưa vượt quá giới hạn tối đa quy định cho các nhóm
3/ Không quy định giá trị của mỗi lần giao hàng mà quy định theo doanh thu mua hàng trong tháng
4/ Thời hạn thanh toán sẽ tính từ ngày giao hàng
5/ Trường hợp doanh thu thay đổi, có thể xếp nhóm lại. (Nhóm khách hàng có thể thay đổi tùy vào chế độ ưu đãi của công ty)
 
2. Tài liệu yêu cầu về phần mềm

(Mạn phép)
_Yêu cầu chương trình có thể chạy trên mạng LAN, có thể nhiều người cùng sử dụng.
_Phân cấp (chỉ giả tạo thôi) người sử dụng, khi truy cập vào thì phải nhập user name/Pass.
_Yêu cầu nhập liệu dễ dàng, có trợ giúp cho việc nhập mã.
_Báo cáo được định dạng theo yêu cầu của khách hàng. (Chị Dung đưa lên các định dạng)
_Về phần 1.2; 1.4 sẽ cho người sử dụng định nghĩa một cách linh động.
Vâng còn gì nữa xin các bạn tiếp.
hai2hai góp ý với.

Lê Văn Duyệt
 
Mẫu tham khảo về Software Requirement Spec (Index Only)

Phải công nhận anh Duyệt là người rất tích cực và đam mê lập trình (nói chính xác ra là làm phần mềm chứ lập trình chỉ là 1 phần nhỏ) đấy. (Vì hình như chỉ có mỗi anh thực hiện, ko làm việc với ai cả)

Xin gửi mẫu SRS dưới dạng Index để mọi người tham khảo.

Dĩ nhiên, tài liệu này viết thì cực dài, nhưng ông cha ta có câu: "Liệu cơm mà gắp mắm". Vì thế, cũng tùy từng tính chất và độ lớn của dự án mà sẽ phải bỏ đi rất nhiều mục mà ko cần viết. Chủ yếu là viết được cái mục 4 của tài liệu: Yếu cầu về chức năng sản phẩm.

Mục này ko có nghĩa là copy cái đoạn yêu cầu của chị Dung (tức là của Khách hàng) mà viết dưới dạng thật rõ ràng sao cho người thiết kế đọc là phải hiểu rõ về chương trình trong tương lai như thế nào. Chương trình sẽ có bao nhiêu chức năng, mỗi chức năng có nhiệm làm công việc gì, có những vài trò (roles) gì trong mỗi chức năng, đầu vào của chức năng là gì, kết quả của mỗi chức năng ra sao, các ràng buộc nếu có trong mỗi chức năng đó, v.v... (Tham khảo USC1(1).Jpg, USC1(2).Jpg)

Còn các mục khác mục 4, nếu chỉ là dự án trên Excel thì mọi người chỉ đại khái thôi.
 

File đính kèm

Lần chỉnh sửa cuối:
Simple SRS

Hoặc đơn giản hơn nữa, mọi người chỉ viết như ví dụ trong file Simple SRS thôi
 

File đính kèm

Về việc thiết kế database em không có ý kiến – Không biết các anh chị nghĩ như thế nào nhưng chúng ta cần biết các yêu cầu đặt ra của người dùng (nghĩa là của các doanh nghiệp). Bởi vì thà chúng hoạch định kế hoạch đầy đủ, chính xác hơn là viết một phần mềm không hiệu quả và một điều là dự án chúng ta làm xong có được áp dụng rộng rãi vào thực tế không.
Nói là file quản lý công nợ, nhưng chúng ta có thể theo dõi thêm cả phần nhập xuất tồn hàng hóa, công nợ đầu vào và doanh thu của cả DN luôn nữa.
Ở đây, em chỉ xin nêu ra ý kiến của người sử dụng, người quản lý công nợ; còn các bạn có quan tâm vui lòng cho ý kiến thêm:

1. Những vấn đề chị Dung đã nêu ở trên xem như là một phần yêu cầu của doanh nghiệp. Tuy nhiên, các doanh nghiệp có thể yêu cầu thêm các điểm sau đây cần phải giải quyết:

2. Về kho hàng: các DN có nhiều kho (giả sử có tối đa 3 kho). Mỗi lần nhập, xuất hàng có thể xuất phát một lúc từ nhiều kho chứ không phải riêng một kho. Giả sử, các kho hàng này đều đứng tên một công ty.

3. Về khách hàng: theo em chúng ta nên phân nhóm lại KH sau mỗi cuối tháng. Tuy nhiên, theo em việc phân nhóm để phục vụ cho chiến lược của DN, do đó DN tự biết điều này. Nhưng theo thời gian, nhóm sẽ thay đổi liên tục thì có khó khăn trong việc thiết kế hay không. Thực tế thì các DN thường phân nhóm KH theo khu vực và loại hình kinh doanh của đối tượng mua hàng.

4. Kết thúc mỗi 3 tháng, 6 tháng, 1 năm; các DN sẽ đánh giá lại từng KH: thông thường sẽ dựa trên doanh số mua của từng KH và chủ DN sẽ có chiến lược cho từng nhóm KH, từng KH. Dĩ nhiên, các số liệu có thể so sánh và phân tích được ở nhiều kỳ với nhau.

5. Các báo cáo có thể có. Xin xem file đính kèm bên dưới. Sau đó, vui lòng cho ý kiến điều chỉnh và bổ sung thêm.

6. Về phiếu báo công nợ: Theo em nên thay thế bằng tên “Bảng đối chiếu công nợ”. Vì đôi lúc ta có thể sử dụng bảng này để phục vụ cho sổ sách thuế, nhất là các khách hàng phải xuất hóa đơn tài chính. Riêng cuối tháng, quý, năm; Chúng ta nên chỉ liệt kê chi tiết theo từng hóa đơn thôi hoặc chỉ liệt kê số dư nợ đầu kỳ, phát sinh tăng, giảm cuối kỳ và số dư nợ cuối kỳ là đủ.

7. Hình thức thanh toán: nêu rõ hình thức thanh toán, trong đó bao gồm cả thanh toán ngoại tệ và VNĐ.

8. Liên quan giữa đặt mã khách hàng và nhân viên bán hàng: chúng ta có thể đặt mã KH có lồng vào mã của nhân viên bán hàng. Theo em nên đặt mã nhân viên riêng để dễ kiểm soát và nhập liệu nhanh, như vậy có thêm một danh mục nhân viên bán hàng nữa.

9. Về Form nhập liệu: việc này chắc mấy bác lập trình có kinh nghiệm hơn. Tuy nhiên, em thấy có thể dùng 2 form là: Form nhập-xuất kho; Form bán hàng (dùng chung). Cụ thể, ta có các cột như sau:
9.1 Ngày, tháng, năm
9.2 Số phiếu
9.3 Mã khách hàng
9.4 Tên khách hàng (không nhập liệu)
9.5 Mã nhân viên bán hàng
9.6 Họ tên nhân viên bán hàng (không nhập liệu)
9.7 Diễn giải/Nội dung nghiệp vụ
9.8 Mã kho hàng
9.9 Tên kho hàng (không nhập liệu)
9.10 Số lượng nhập
9.11 Đơn giá nhập
9.12 Thành tiền nhập (tự tính toán)
9.13 Số lượng xuất bán
9.14 Đơn giá xuất bán
9.15 Thành tiền xuất bán (tự tính toán)
9.16 Hàng giảm giá
9.17 Hàng bị trả lại (nếu phát sinh, đồng thời chúng ta phải ghi giảm công nợ)
9.18 KH phải thanh toán (= 9.15 - 9.16 - 9.17) (tự tính toán)
9.19 KH đã thanh toán
9.20 Còn lại KH chưa thanh toán
9.21 Số ngày nợ (tính cho từng lô hàng)
9.22 Ghi chú
Ở đây, em chưa đề cập đến giao dịch bằng ngoại tệ. Xin các bác cho ý kiến thêm.

10. Phần nhập công nợ: khi khách hàng trả nợ cũ cho nhiều lô hàng, chúng ta phải phân bổ KH trả cho lô hàng nào, ngày, số phiếu của lô hàng đó. Thay vì, chúng ta phải tìm kiếm từng lô hàng phải phân bổ, phần mềm sẽ hiển thị 01 form phân bổ nợ khách hàng. Trong đó, liệt kê có cả mã KH, mã NV, số phiếu… ta chỉ đánh số tiền vào, dữ liệu sẽ tự cập nhật công nợ.

Trên đây, chỉ là ý kiến nhỏ của em. Mong các anh chị em vui lòng đóng góp ý kiến; vì tôi thấy rất cần thiết cho chúng ta đặc biệt là dân kế toán và người quản lý.

Cám ơn.--=0
 

File đính kèm

hai2hai đã viết:
Phải công nhận anh Duyệt là người rất tích cực và đam mê lập trình (không chuyên) đấy. (Vì hình như chỉ có mỗi anh thực hiện, ko làm việc với ai cả-=09= )
Bây giờ anh ít giờ lên internet, nên hơi bị khó.
Lê Văn Duyệt
 
To tsf:
Rất cám ơn tsf vì đã công phu làm 1 post khá dài và tâm huyết. Bài toán thực tế, bài toán lớn, v.v... thì mình và chị Dung cũng đã mấy lần nói đến (từ khi chưa có GPEX cơ) nhưng ko phải là dễ làm (làm cá nhân thì ko có vấn đề gì, làm kiểu bài bản để KD thì lại là chuyện khác), SP thương mại phải bao gồm:
- Chương trình dạng mã đã dịch (Có tính đáp ứng cho ...tất cả các DN chứ ko chỉ 1 DN với tất cả các nghành nghề - vì là SP thương mại mà)
- Chương trình dạng mã nguồn (theo chuẩn thiết kế)
- Tài liệu sản phẩm (Hướng dẫn sử dụng, hướng dẫn cài đặt, v.v...)
- Tài liệu MKT (Brochures, datasheets, product presentation, v.v...)
- Tài liệu phát triển (cái này thì nhiều vô kể: tài liệu yêu cầu, tài liệu thiết kế, tài liệu test, tài liệu chuẩn này chuẩn nọ, tài liệu dự án (phát triển), v.v...)

Bây giờ mình xin trả lời câu hỏi của tsf:
Re 1: Tại sao phải đưa dự án nhỏ lên trước?
- Tại vì đây là dự án đầu tiên của GPE, nhỏ còn chưa thấy ai làm nữa là lớn (với lại, thông thường bao giờ người ta cũng phải bắt đầu từ những công việc nhỏ đã, làm tốt việc nhỏ thì sẽ làm được việc to).
- Các module khác có thể làm tích hợp rất dễ dàng (ví dụ như kho hàng - thực ra cái này nên làm trước công nợ), cứ nêu ra yêu cầu nghiệp vụ rõ ràng (và viết lại được thành tài liệu yêu cầu phần mềm) thì khắc sẽ làm được.

Re 2:
tsf đã viết:
"3. Về khách hàng: theo em chúng ta nên phân nhóm lại KH sau mỗi cuối tháng. Tuy nhiên, theo em việc phân nhóm để phục vụ cho chiến lược của DN, do đó DN tự biết điều này. Nhưng theo thời gian, nhóm sẽ thay đổi liên tục thì có khó khăn trong việc thiết kế hay không. Thực tế thì các DN thường phân nhóm KH theo khu vực và loại hình kinh doanh của đối tượng mua hàng.

4. Kết thúc mỗi 3 tháng, 6 tháng, 1 năm; các DN sẽ đánh giá lại từng KH: thông thường sẽ dựa trên doanh số mua của từng KH và chủ DN sẽ có chiến lược cho từng nhóm KH, từng KH. Dĩ nhiên, các số liệu có thể so sánh và phân tích được ở nhiều kỳ với nhau."

2 vấn đề trên, nếu xét trên phương diện thiết kế, mình đã tính cả rồi. Không thể nhóm khách hàng lại cho vào DM khách hàng luôn đâu. Cái đó gọi là diễn biến, là lịch sử. Ví dụ: năm ngoái KH này thuộc nhóm A, năm sau, KH đó lại thuộc nhóm B. Và chuyện năm ngoái là nhóm nào, năm nay là nhóm nào đều phải ghi nhận lại hết.

Thanks for share 2 ý kiến trên.

Re Còn lại: Các yêu cầu sau của bạn nên được bổ sung thêm vào tài liệu yêu cầu phần mềm (ko biết có ai đã bắt tay vào làm hay chưa nhỉ? :))

Các biểu mẫu báo cáo của bạn sẽ rất tốt cho những ai muốn thực sự tham gia làm dự án. Nhóm đầu tiên đâu rồi? Sao ko lên tiếng?
 
Lần chỉnh sửa cuối:
hai2hai đã viết:
Re Còn lại: Các yêu cầu sau của bạn nên được bổ sung thêm vào tài liệu yêu cầu phần mềm (ko biết có ai đã bắt tay vào làm hay chưa nhỉ? :))
Các biểu mẫu báo cáo của bạn sẽ rất tốt cho những ai muốn thực sự tham gia làm dự án. Nhóm đầu tiên đâu rồi? Sao ko lên tiếng?
Chắc anh sẽ tham gia nhóm khác, vì phần nghiệp vụ anh không rành lắm.
Lê Văn Duyệt
 
Mỗi nhóm sẽ có nhiều thành viên, và không phải ai cũng có thể rành hết được. Về công nợ, cũng là một bài toán bình thường, chưa liên quan gì đến các nghiệp vụ kế tóan. Chúng ta sẽ thảo luận quanh nhiều vấn đề, để có thể tiến hành chuyên nghiệp hóa khi nhận thực hiện một dự án. Chị đề nghị chúng ta chia thành 3 nhóm, và các thành viên sau sẽ được đề cử tham gia dự án này gồm : Hai2hai, Lê Văn Duyệt, Bình OverAC, Tsf, TuânVNUI, Đào Việt Cường, Adam_tran, YeuDoi, SA_DQ, WhoamI, Secret Grasses...Các bạn hãy tự tin và nhiệt tình tham gia, dự án đầu tiên có thể thất bại, không thành công như chúng ta mong muốn, nhưng chúng ta sẽ có nhiều bài học kinh nghiệm, và chúng ta sẽ còn các dự án khác.
Xin lỗi chị không tham gia được, vì mẹ chị đang trong tình trạng rất nặng, những ngày sắp tới chưa biết sẽ ra sao...Nhưng chị thành thật mong các em tham gia nhé
 
Mọi người cứ triển khai đi, phần em chắc chỉ tham gia phần test thử thôi chứ... công việc giờ như cái núi... bùi nhùi!

Ngày xưa mình quản lý công nợ và NXT kho theo nghiệp vụ kép, có nghĩa là sẽ có 1 nhập - 1 xuất (1 nợ - 1 có) như vậy thì sẽ quản lý được n kho cũng như n khách hàng... nhưng các yêu cầu ràng buộc thì chưa có cũng như chưa biết gì về VBA.
 
levanduyet đã viết:
Chắc anh sẽ tham gia nhóm khác, vì phần nghiệp vụ anh không rành lắm.
Lê Văn Duyệt

Anh đương nhiên ban đầu là ko rành nghiệp vụ rồi (trả phải anh, em cũng vậy :)), nhưng anh tham gia với nhóm, nhóm sẽ cử người viết nghiệp vụ và nhìn vào nghiệp mà anh thiết kế và lập trình. Thế mới gọi là làm việc nhóm chứ. Trong nhóm sẽ có người viết tài liệu nghiệp vụ cho anh đọc và anh sẽ tạo tài liệu thiết kế (dạng gì cũng được, miễn là người lập trình Excel hay ngôn ngữ .NET của anh nhìn vào là biết lập trình :)).

Nếu xem tài liệu yêu cầu phần mềm đó mà anh ... đọc ko hiểu để thiết kế được thì nghĩa là có vấn đề ở hoặc: là do tài liệu viết đó ko thỏa mãn là tài liệu SRS, hoặc là do ... người thiết kế ...ko chịu hiểu. :-=

Nhận làm dự án phần mềm mà nói câu "Tôi ko rành về nghiệp vụ" là hỏng rồi đấy anh ạ --=0
 
Lần chỉnh sửa cuối:
Hi hi hi

hai2hai đã viết:
Nhận làm dự án phần mềm mà nói câu "Tôi ko rành về nghiệp vụ" là hỏng rồi đấy anh ạ --=0
Đồng ý với em. Nhưng sao các bước đầu các bạn rành nghiệp vụ sau không thấy nói năng gì vậy? Anh có kinh nghiệm trước đây khi anh gọi làm dự án thì các bạn đều bận hết nên cuối cùng dự án đi vào quên lãng!

LVD
 
Xin nhắc lại với các bạn rằng : dự án này là có thật, đã có một cửa hàng bán tạp hóa đặt viết dự án này trên Access, và chị đã nghĩ rằng có thể làm bằng Excel. Rất tiếc vì bận công việc nên chị đã không nhận làm File này mà thôi. Vậy thì các bạn đừng ôm đồm quá nhiều vào việc nghĩ ngợi như phải lên các BC giống như một PM KT. Đơn thuần là họ theo dõi côngnợ của KH mà thôi. Nếu chỉ đơn thuần là cá nhân làm, chắc hẳn chúng ta ai làm cũng được. Vậy mục đích của việc triển khai dự án này là gì ?
Đó là chị muốn học tập cách làm việc chuyên nghiệp hơn để sau này chúng ta sẽ thực hiện các dự án lớn hơn. Chị nghĩ chúng ta nên đi một cách bài bản, dù cho dự án này nhỏ xíu đi chăng nữa, giống như ta xây một cái nhà vậy. Các em đọc những bài viết rất tâm huyết của Hai2Hai, nếu chúng ta muốn, chắc chắn Hải sẽ truyền đạt, chia xẻ tất cả những kiến thức mà Hải có, và chị tin chắc với mục tiêu đề ra như trên, chúng ta sẽ vững vàng hơn rất nhiều trong công việc của chúng ta sau này
 
Để dự án nàc có thể bắt đầu và đi vào hiện thực cần có nhân sự thực hiện, việc nêu ra ở đây như là một đề bài thách đố, để mọi người cùng nhau làm. Chia đội ra mà thực hiện, rồi từ đó có thể học hỏi lẩn nhau. Mỗi đội sẽ có 1 box cho riêng đội mình, các bài trong box này sẽ chỉ có các thành viên trong đội post được, xem được. (hiện tại các box đã được lập ra nhưng chưa ai được set quyền để thấy nó)
Em xin được là 1 đội, hoan nghinh nếu có ai đó tham gia vào đội của em. Đồng thời em cũng đề cữ bác Đào Việc Cường, bác HYen, Yeudoi, inkpot_pencil lập ra những đội khác để cùng nhau thực hiện và thi thố.
 
Về phần lâp trình, cái này xin lỗi, em chịu thua à nghen. Em sẽ nêu ý kiến và phác thảo về vấn đề công nợ mà thực tế cần đến. Còn nhiều vấn đề chúng ta cần nêu ra thêm, nhưng em nghĩ bao nhiêu đó cũng đã đuối hàng rồi.
Anh Duyệt ơi, 3 con cò làm chung 1 nhóm đi nào.
Ok không 2 con cò kia.&&&%$R
 
Lần chỉnh sửa cuối:
Tôi đi làm nhiều, bị nợ cũng nhiều.
Bác nào lập ra cái chương trình gì đó để họ trả cho tôi nhanh chóng được ko? :-=

;;;;;;;;;;; )(&&@@
 
OverAC đã viết:
Mỗi đội sẽ có 1 box cho riêng đội mình, các bài trong box này sẽ chỉ có các thành viên trong đội post được, xem được. (hiện tại các box đã được lập ra nhưng chưa ai được set quyền để thấy nó)
Dear OverAC,
-------------
OverAC set quyền để "thấy nó" đi, anh chưa biết cơ cấu các đội tuyển khác như thế nào để mà lượng sức!
Hiện tại đội của mình gồm: Đào Việt Cường và WhoamI, lấy tên là đội "Con Gà Đen" (vì nghe đâu con gà đen liên quan đến OK thì phải!)
...
thôi, chắc không nói nữa kẻo lộ hết chiến thuật.
 
???

Mọi người ơi ! Hình như ý của các bạn đi hơi bị lệch?
Theo tôi nghĩ, dự án này là chỉ một dự án. Nhưng chia thành những phần nhỏ, và mỗi nhóm thực hiện một phần, chứ không phải chia thành các đội rồi thi với nhau?!
Có phải như vậy không?

Lê Văn Duyệt
 
Dự án này nhỏ, nên chỉ cần 2-3 người là có thể thực hiện. Dự định là có nhiều nhóm nhỏ, mỗi nhóm sẽ tự chọn những ai có thể cùng thực hiện. Thời gian thự chiện là 1 tháng, và khi hết thời hạn, chúng ta sẽ có 3-4 sản phẩm để cùng xem xét và rút kinh nghiệm
 
Như vậy, tạm thời đến lúc này, chúng ta có 3 nhóm :
- Nhóm 1 : 3 con cò adam_tran, Lê Văn Duyệt, tsf
- Nhóm 2 : Con gà đen, Đào Việt Cường, WhoamI
- Nhóm 3 : BìnhOverAC và ...???
Các bạn tiếp tục đăng ký tham gia thành lập nhóm đi nhé
 
Đào Việt Cường đã viết:
Dear OverAC,
-------------
OverAC set quyền để "thấy nó" đi, anh chưa biết cơ cấu các đội tuyển khác như thế nào để mà lượng sức!
Hiện tại đội của mình gồm: Đào Việt Cường và WhoamI, lấy tên là đội "Con Gà Đen" (vì nghe đâu con gà đen liên quan đến OK thì phải!)
...
thôi, chắc không nói nữa kẻo lộ hết chiến thuật.
Nhóm Con Gà Đen đã được thành lập. Các bác có thể làm việc với nó được rùi.
Hiện tại thành viên nhóm Con Gà Đen gồm có : bác Đào Việt Cường và WhoamI
 
Các bạn đã biết các công việc liên quan đến:
1/ Xác định yếu cầu phần mềm
a) Đầu vào: Các tài liệu yêu cầu đã Khảo sát (chính là yêu cầu của chị Dung đưa ra), tài liệu nghiên cứu tham khảo (có thể do ban tham khảo thêm),...
b) Đầu ra:
- Tài liệu yêu cầu cấp cao (cái này mình ko làm)
- Tài liệu đặc tả yêu cầu phần mềm (SRS)

2/ Phân tích thiết kế (với bài toán nhỏ thì làm theo cách làm đơn giản là phương pháp top-down: nghĩa là làm phân rã chức năng từ trên xuống)
a) Đầu vào:
- Tài liệu SRS
b) Đầu ra: (Cái này hơi nhiều nhưng vì ta làm đơn giản nên bỏ bớt đi, làm theo top down thôi)
- Sơ đồ chức năng của chương trình, kèm theo mô tả chức năng đó: điều kiện thực hiện, ai thực hiện, thực hiện như thế nào, thực hiện khi nào, kết quả là gì, những trường hợp đặc biệt (nếu có).
- Sơ đồ phân rã thực thể: Bảng quan hệ giữa các thực thể (sơ đồ dữ liệu: tables, query, relationships,...)
- Bảng mô tả chức năng nào dùng thực thể nào
Ví dụ:
Chức năng nhập hàng sử dụng các thực thể sau:
+ Hóa đơn mua hàng
+ Phiếu nhập hàng
+ Nhà cung cấp
+ Kho hàng
+ Hàng hóa
+ Danh mục thuế
+ Danh mục nhân viên
+ v.v...
Chú ý: Chức năng thì dùng ĐỘNG TỪ, thực thể thì dùng DANH TỪ (giống như thuộc tính thì dùng danh từ, phương thức thì dùng động từ ấy)

3) Lập trình & tự Unit Test (quên, phải gọi là tự kiểm tra từng đơn vị nhỏ nhất của lập trình - là module)
Module ở đây có thể hiểu là 1 chức năng lớn, một hàm tính toán, một method, một màn hình, một báo cáo, v.v... tùy theo mỗi nhóm tự quy định. Thông thường nhóm lập trình tự "unit test" cho phần việc của mình được giao (và theo tài liệu thiết kế chi tiết - nhưng ở đây mình ko làm tài liệu thiết kế chi tiết vì dự án nhỏ và làm thiết kế chi tiết rất tốn time + nhân lực)
Về chuyện nhóm lập trình thì lắm vấn đề lắm nhưng thôi, chắc trong các nhóm nhỏ chỉ có 1 lập trình viên nên coi đó là trưởng nhóm lập trình luôn)
4) Test (Kiểm tra)
A. Kiểm tra tích hợp và kiểm tra hệ thống
Thế nào là kiểm tra tích hợp (Intergration Test): Giả sử làm xong module 1, test xong module 1 thì gọi là Unit Test, làm tiếp module 2, test tiếp module 2 xong thì vẫn gọi là Unit test. Nhưng lúc đó quay lại test xem sau khi làm xong module 2 thì module 1 có chạy tốt ko, phân giao tiếp giữa 2 module đó có hoạt động hay ko? cái đó gọi là kiểm tra tích hợp. Khi kiểm tra tích hợp toàn bộ chương trình thì mình phải dựa vào từng nghiệp vụ cụ thể được mô tả trong tài liệu thiết kế.
Thế nào là kiểm tra hệ thống (System Test)?: Dựa vào tài liệu đặc tả yêu cầu phần mềm, dựa vào các tài liệu thiết kế, trưởng nhóm test sẽ lập ra kế hoạch test trong đó chỉ ra các trường hợp để test (gọi là Test Case). Dựa trên từng test case đó, người thực hiện test (gọi là tester) sẽ thực hiện test từng use case 1 theo kế hoạch.
Ví dụ về kế hoạch test (Test plan)
Usecase 1: Nhập hàng
USC1.1: Thêm phiếu nhập
- Thông tin đầu vào: Số PN, ngày ct, v.v...
- Điều kiện ràng buộc: Bắt buộc: Mã kho hàng, mã thủ kho, v.v...; không bắt buộc: người giao hàng, v.v...
- Kết quả thành công: Chứng từ nhập hàng được ghi sổ, màn hình chuyển sang nhập phiếu mới, con trỏ để ở vị trí Số chứng từ,....
- v.v... nhưng thôi, ta chỉ làm đơn giản thế thôi
USC1.2: Sửa chứng từ
...
USC1.3: Xóa chứng từ
...

USC1.n: v.v....

USC2: Xuất hàng
...

B. Kiểm tra chấp nhận (Acceptant Test)
Thông thường công việc này do 2 bên: Nhà cung cấp và Khách hàng (là chị Dung) cùng thực hiện.

Dựa trên tài liệu SRS đã thỏa thuận giữa 2 bên (NCC & KH), NCC tạo ra 1 tài liệu Acceptant Test List trong đó chỉ ra các công việc cần test khi nghiệm thu chương trình (nghiệm thu xong mới thanh lý được hợp đồng mà :))
Sau đó 2 bên đưa ra 1 buổi nghiệm thu kỹ thuật và cứ dựa trên Acceptant Test List & SRS để kiểm nghiệm lại chương trình xem chương trình có chạy đúng hay ko. Nếu OK thì coi như nghiệm thu và HĐ đã được thanh lý (còn thanh lý đến đâu là do 2 bên thỏa thuận với nhau trong HĐ :))

Tiếp theo giải đoạn Acceptant Test là giai đoạn go live (Hệ thống sẽ được đưa vào chạy thử (và cũng là chạy thật luôn) để theo dõi tính ổn định, v.v.. gì đó của chương trình - theo như mô tả trong SRS)

Nôm na mọi chuyện nó là như vậy (dĩ nhiên là ko thể đầy đủ hết được). Dĩ nhiên, tùy vào từng tình huống mà ta có thể đơn giản hóa từng khâu (nhưng tốt nhất vẫn nên có các tài liệu đầu ra của các khâu đó cho dù nó đơn giản thế nào đi nữa)
 
Lần chỉnh sửa cuối:
Ngoài các phương tiện liên lạc nhóm như email, mailling list, chat, voice chat, gặp trực tiếp, v.v... thì các bạn có thể quản lý các dự án một cách online thông qua ứng dụng iteamwork tại: http://www.iteamwork.com/. Đây là 1 ứng dụng dạng webform quản lý dự án online rất hiệu quả.
 
Hic, nghe các anh chị thảo luận sôi nổi quá. Em cũng muốn tham gia nhưng hơi bị thiếu tự tin.(Hỏng hiểu sao, em ko sử dụng đc smiley của GPE?!)
 
Secret Grasses ơi, đề nghị câu tham gia vào nhóm của tớ nhé

Các nhóm hiện nay đã có gồm:
 

File đính kèm

  • untitled.JPG
    untitled.JPG
    28.6 KB · Đọc: 151
OverAC đã viết:
Secret Grasses ơi, đề nghị câu tham gia vào nhóm của tớ nhé

Tks! SG tham gia nhóm nào cũng đc nhưng sợ SG ở nhóm nào, nhóm đó sẽ ko giành đc giải thui.

P/S: Bữa nay sao lại "cậu" với "tớ" kỳ quá!
 
Secret_grasses đã viết:
Tks! SG tham gia nhóm nào cũng đc nhưng sợ SG ở nhóm nào, nhóm đó sẽ ko giành đc giải thui.

P/S: Bữa nay sao lại "cậu" với "tớ" kỳ quá!

Con nhỏ này, thằng OverAC nó "Câu" em chứ không phải cậu đâu. Sướng nghe.--=0
 
Riêng đây, Chị Dung va anh Hai2Hai, rút lại yêu cầu bài toán và các báo cáo lại một lần nữa luôn đi, để các bạn hình dung cho dễ.
Cám ơn.
 
Ơ, Đã là KH thì làm sao mà biết đưa ra yêu cầu nhỉ???? --=0

Mọi người là nhà cung cấp, khi có "nhu cầu" từ khách hàng (là chị Dung) thì phải tìm cách mà hỏi chứ. Phải khảo sát nghiệp vụ, nếu chưa rõ điều gì thì lại hỏi "khách hàng" để khách hàng làm sáng tỏ yêu cầu. Sau đó mọi người viết lại những gì mình hiểu vào SRS. Thế mới gọi là nhà cung cấp chứ? Nếu KH mà có thể đưa ra yêu cầu chuẩn ngay từ đầu NCC quá sướng (nhưng mà 100% là ko bao giờ có KH nào có thể đưa rõ ràng mọi yêu cầu ngay từ đầu được :D)

Các bạn chú ý nhé. Khi đã làm phần mềm cho KH mà làm thiếu thì dĩ nhiên là ko được rồi. Nhưng nếu mà làm thừa thì nghĩa là các bạn đã tốn resources (time, human, money) đấy. Vì thế chỉ làm đúng những gì KH yêu cầu mà thôi (làm thừa đâu có được trả thêm tiền, đúng ko?). Nghĩa là tính năng của phần mềm = đúng yêu cầu của KH.

Ví dụ: KH yêu cầu: Tôi chỉ quản lý công nợ, ko quản lý kho hàng mà các bạn cứ viết vào SRS rồi thiết kế, rồi code là có các tính năng về kho hàng là ... chỉ có các bạn thiệt thôi (mất time, mất nhân lực cho dự án khác, và dĩ nhiên mất cả tiền - vì KH có trả thêm tiền cho những tính năng làm thêm đâu)

Như vậy, người làm nghiệp vụ phải tìm mọi cách xác định phạm vi của bài toán. Sau khi làm xong SRS thì NHỚ CONFIRM LẠI VỚI KHÁCH HÀNG LÀ SRS ĐÓ ĐÃ ĐÁP ỨNG ĐÚNG YÊU CẦU CỦA KH CHƯA NHÉ (gửi SRS cho chị Dung (cc to haixhai@yahxx.com)). Sau đó KH (chị Dung) sẽ review lại tài liệu và 2 bên cùng trao đổi với nhau cho đến khi SRS được TẠM công nhận là đáp ứng đúng yêu cầu. (và lúc đó mới ký kết hợp đồng kinh tế --=0 )

Tuy nhiên, đó là cách mà chúng ta làm dự án theo yêu cầu của KH. Nếu chúng ta làm phần mềm mang tính thương mại cao thì phải nghiên cứu tính tổng quát, phải đưa thêm các tính năng mới để đáp ứng số đông - tức là ko chỉ có những yêu cầu của KH (như các PM QL bán hàng, PMKT,... đang có trên thị trường). Dĩ nhiên, tính năng đó nhiều đến đâu thì phụ thuộc vào rất nhiều yếu tố: nào là chiến lược SP & thị trường của cty, nào là khả năng của NCC, v.v.... Điều này chúng ta ko cần đả động đến vội. Chúng ta đang giả sử dự án đầu tiên này là làm theo yêu cầu của KH chứ ko phải dự án phần mềm thương mại. Vì thế chúng ta chỉ làm theo yêu cầu của KH mà thôi.

PS: Các bạn nên confirm tài liệu SRS với khách hàng (chị Dung) nhé. Đừng hục hục làm từ đầu đến cuối mà chẳng liên hệ với KH gì cả. Có thể trong quá trình làm SRS thì cứ thiết kế dần dần nhưng thiết kế chính xác chỉ khi SRS đã được chấp nhận bởi KH.

Trong quá trình làm nên liên tục thông báo tình trạng dự án (làm đến đâu rồi) cho khách hàng nữa.

Bây giờ ai đã có thể đưa ra được 1 bản SRS draft rồi nhỉ?
 
Lần chỉnh sửa cuối:
Trên thực tế, chưa hẳn là KH sẽ không đưa ra yêu cầu từ đầu cho NCC. Tôi thấy nhiều KH khi lựa chọn NCC, họ cũng đã dự tính họ sẽ cần gì (vì thực tế đã xảy ra rồi) hoặc là chưa xảy ra nhưng nó đã nằm trong chiến lược của KH.

Ở đây, KH là chị Dung, chị có đưa thêm yêu cầu gì không. Vì trong nhóm dự án, người lập trình có thể là một thôi, có thể chưa hiểu rõ KH mình muốn gì và trải nghiệm ở thực tế nhiều nữa. Đây có thể là trường hợp của anh Duyệt (mà cái ông này hơi bận chị ạ), cho nên cho ổng làm một lúc cho xong. Còn em, đưa ra yêu cầu chi tiết để anh viết chứ. Yêu cầu ít quá, ông Duyệt mập lạng quạng quên luôn đó chứ, hi hi.

Chị Dung nhớ nhe. Cám ơn.
 
Theo mình thấy cơ bản chị Dung đưa ra yêu cầu đủ để làm rồi đấy. Cứ làm theo như thế đi. Nếu thấy thiếu thì thử hỏi xem. Nhưng chú ý là ko làm thêm nhé vì đây là dự án đầu tiên nên càng đơn giản càng tốt. Mục tiêu là để mọi người nắm được cách tiếp cận bài toán & giải quyết bài toán thế nào (ko chỉ lập trình). Nếu là mình đưa ra dự án đầu tiên thì mình sẽ đưa ra bài toán cực đơn giản (hơn cả cái quản lý công nợ này)

Rất đơn giản, bạn cứ hình tổ chức lại thông tin từ "mớ" yêu cầu của chị Dung:

- Để làm được thì phải có những chức năng nào: Ví dụ: Danh mục A, danh mục B, Nhập hàng, Xuất hàng, Thanh toán cho NCC, KH Thanh toán, Báo cáo A, Báo cáo B, v.v...
- Mỗi chức năng đó dùng để làm gì (mục đích), thực hiện chức năng như thế nào? Điều kiện để chạy chức năng đó, v.v...
- Chức năng đó cần những loại thông tin nào cho đầu vào/đầu ra (chính là để ra các thực thể đó), mỗi loại thông tin đó gồm có những thông tin nào? (chính là các fields đó), các thông tin đó có quan hệ gì với nhau? (Chính là relationships của các quan hệ đó)

Mình đọc qua đã nhìn thấy vô số thứ để ngồi làm SRS rồi.

PS: À, ko phải KH nào cũng đưa ra yêu cầu 1 cách rõ ràng đâu. Mình chuyên đi làm dự án theo yêu cầu KH thì thấy rằng khoảng 99,99% số KH mà mình tiếp cận là ko thể đưa ra yêu cầu rõ ràng và đầy đủ ngay từ ban đầu (trừ 1 trường hợp thuê tư vấn xịn). Có lẽ tsf đang hình dung ra chuyện quản lý công nợ phức tạp hơn cả KH (và quên là đây là 1 bài tập để làm quen với cách tiếp cận và giải quyết vấn đề. Vì thế càng đơn giản càng tốt). Ví dụ, phần thanh toán NCC thì ta xem nhẹ vì chị Dung chỉ đặt ra đối với KH thanh toán mà thôi.

Mà dựa vào mấy cái hình trong tài liệu SRS, trích lược bớt đi, bổ sung thêm phần Điều khoản thanh toán, v.v... là OK thôi mà.

Mà quan trọng nhất là.... đã đội nào có file SRS dạng winword hay PDF chưa? (thậm chí là có trang nào chưa). Đó mới là điều quan trọng.

Kể từ ngày chị Dung đưa bài toán (17-08-06) đến nay đã 7 ngày rồi mà hình như chưa thấy 1 file nào gửi cho chị Dung thì phải. Đáng ra trong 7 ngày đó, mỗi ngày bỏ ra chỉ có 30 phút thôi (lúc nghỉ trưa hoặc nghỉ chiều) là mọi người có 7 * 30 phút để viết SRS rồi. Thời gian đó có thể viết được mấy cái SRS cho bài toán này rồi.
 
Lần chỉnh sửa cuối:
Cuộc phát động này thật thú vị và thiết thực mong các thành viên không kể cũ mới chúng ta chọn nhóm rồi bắt tay vào làm. Quá trình làm việc chúng ta sẽ hiểu về nhiều điều hơn (lao động, quản lý, nghiệp vụ,...).
Rất tiếc trong thời gian này mình không trực tiếp tham gia được, tuy nhiên mình vẫn muốn đóng góp một cái gì đó cho cuộc phát động này.
 
Đọc dự án của các bạn mà thấy mê, tuy trình độ về excel thì còn thấp bé, vì vậy chỉ là người ủng hộ các kế hoạch của các đội.

Về nghiệp vụ, và có kiến nghị thì còn được, chứ lập trình thì bó tay.
 
Đâu chỉ có lập trình hả AC3K ơi. Lập trình ở dự án này là thứ yếu mà (vì đề bài đâu có khó gì, ai cũng làm được: ko excel bình thường thì Excel VBA, ko VBA thì ... Visual Studio 2k5 như anh Duyệt làm :-=). Thứ quan trọng nhất ở dự án này là.... Có làm hay ko thôi. Nếu làm thì đọc lại từ trang đầu đến trang cuối và bắt tay ngay (mỗi ngày chỉ khoảng 15 đến 30 phút - ko thể nói là bận được - post 1 bài lên forum còn tốn time hơn nhiều). Còn nếu ko làm thì coding hay lập trình gì gì đó cũng ko thể có được. Ko nhẽ vài trang (thậm chí chỉ cần 3 hay 4 trang thôi) winword khó đến thế sao? Đến mai đã là 10 ngày, 1/3 quãng thời gian rồi mà KH chưa thấy confirm gì về yêu cầu cả.
Chả nhẽ suốt đời online + partime vẫn chỉ là con số 0? :-=
 
Lần chỉnh sửa cuối:
Thật tình lâu nay thấy mọi người thảo luận có vẻ quá hấp dẫn đấy vả lại thấy mọi người cũng rất nhiệt tình với lại dự án này. Mình cũng muốn diễn đàn mình phải có một dự án nào để triển khai chứ không lẽ toàn phat chứ chảng thấy động thì cũng kỳ.Thiệt tình mình cũng rất muốn tham gia với mọi người nhưng nghĩ sợ không đủ trình độ quá và mình cũng nghĩ những thành viên mới của diẽn đàn cũng vậy nên vẫn thấy ít thành viên mới tham gia.Không biết có đúng không.
 
Kính thưa các bác, theo tình báo của nhóm 3 (không dùng quyền admin để xem trộm đâu àh nha) thì tình hình hiện đang được các đội so kè nhau rất sát.

Nhóm 3 con cò: theo sự tiết lộ của cò Tsf thì đã thiết kế xong database.
Nhóm Con gà đen: chưa tìm kiếm được thông tin gì đặc biệt. Nhưng nghe đồn 2 thành viên của nhóm này là Đào Việt Cường và WhoamI có đi đêm đi ngày với nhau.
(Nhóm dự án số 3, chưa có tên nay ra thông cáo đặt tên là: "những con chim trong bụi mận gai")
Nhóm "những con chim trong bụi mận gai": đả thiết kế xong gần như toàn bộ từ database, form, và báo cáo. Đang ráo riết đi tìm người phụ coding cho nó.

Nhân dây cũng xin mời nhưng con chim thất lạc hãy cùng chui vào bụi mận gai với chúng tôi. Xin mời, xin mời.

To bác Yeudoi: bác thấy sao ạh. Bác có muốn tham gia vào nhóm những con chim trong bụi mận gai không ạh?
 
Ơ, thế đã thiết kế DB, form, reports rồi cơ à? Chị Dung đã nhận được tài liệu yêu cầu phần mềm của các nhóm & đã confirm các yêu cầu đó với mọi người rồi à? Thế mà chẳng gửi cho hai2hai này 1 bản :(. Hay là mọi người hiểu đến đâu rồi lại cứ thế ngấm ngầm tiến hành mà ko cần biết có thực sự phù hợp với yêu cầu của KH hay chưa.
 
Chị chưa nhận được gì cả, nếu nhận được, chị sẽ chuyển cho Hải ngay. Các bạn chú ý đọc lại hướng dẫn của Hải và làm theo thứ tự các bước nhé, coi chừng không đúng yêu cầu của KH, Kh này khó tính lắm đấy nhé.
 
hic em thì VBA ít dùng nhưng mấy ngày nay cũng đã bắt đầu viết bằng VB6 rùi. Mới làm được có ít lắm. Ngặt nỗi em cũng không có nhiều thời gian lắm để mà làm. Hy vọng có thể hoàn thành được theo thời hạn. nếu các anh đã thiết kế được DB rồi thì có thể đưa cái file đó lên cho bọn em tham khảo được không? em cũng chỉ làm sơ sơ bình thường chứ cũng chưa định hướng cụ thể vì cũng không biết đến kế toán lắm.
 
Nghe chừng dự án này có vẻ khủng khiếp thế, quy tụ toàn những chuyên gia về Excel. Lĩnh vực này thì em mù tịt, đành cổ vũ các bác vậy và có mặt lúc liên hoan tổng kết :-=
 
PhanTuHuong đã viết:
Nghe chừng dự án này có vẻ khủng khiếp thế, quy tụ toàn những chuyên gia về Excel. Lĩnh vực này thì em mù tịt, đành cổ vũ các bác vậy và có mặt lúc liên hoan tổng kết :-=

Nó cũng đời thường thôi mà bác, bác cứ tham gia cùng anh em đi em sẽ cổ vũ và hỗ trợ thêm nếu cần.
 
skyonline đã viết:
hic em thì VBA ít dùng nhưng mấy ngày nay cũng đã bắt đầu viết bằng VB6 rùi. Mới làm được có ít lắm. Ngặt nỗi em cũng không có nhiều thời gian lắm để mà làm. Hy vọng có thể hoàn thành được theo thời hạn. nếu các anh đã thiết kế được DB rồi thì có thể đưa cái file đó lên cho bọn em tham khảo được không? em cũng chỉ làm sơ sơ bình thường chứ cũng chưa định hướng cụ thể vì cũng không biết đến kế toán lắm.

Nghe chừng dự án này có vẻ khủng khiếp thế, quy tụ toàn những chuyên gia về Excel. Lĩnh vực này thì em mù tịt, đành cổ vũ các bác vậy và có mặt lúc liên hoan tổng kết

Đã là dân phần mềm thì chả có gì là "mù tịt" cả. Khách hàng đưa ra yêu cầu thì cố mà hiểu. Nếu ko hiểu thì hỏi lại. Cái gì cũng có logic của nó mà.

Ngày trước tớ phải viết 1 phần mềm do bọn nhật thiết kế có tên là MD. Tớ viết xong chương trình trong 3 tháng, chương trình chạy cực tốt (ko phải do lập trình mà do bọn nhật thiết kế quá chi tiết) mà tớ vẫn chả hiểu chương trình đó làm về cái gì, tên MD có nghĩa là gì. --=0

Tương tự như vậy, ở công ty cũ của tớ có người đã từng viết phần mềm quản lý .... lắp ráp máy bay A76, hệ thống .... rà soát văn bản pháp luật (toàn những đầu bạc về luật học tư vấn nghiệp vụ), v.v... Rất nhiều ứng dụng dân IT chả hiểu nghiệp vụ gì cả nhưng họ biết cách "chuyển" kiến thức của khách hàng thành "yêu cầu phần mềm" để từ đó có thể thiết kế và coding được.

Mà nói chung nghiệp vụ thì có gì mà "ko thể hiểu được", 1 lần ko hiểu, thì hỏi lại, lần 2 ko hiểu thì hỏi tiếp, v.v... đến khi nào hiểu thì viết ra.
 
Lần chỉnh sửa cuối:
Em làm cái DB có các table sau :
danh mục khách hàng( gồm mã khách hàng, tên khách hàng,địa chỉ số điện thoại) , danh mục hàng hóa (gồm mã hàng , tên hàng quy cách , đơn vị tính, giá bán, số lượng tồn, tổng giá trị tồn), danh mục thu chi(gồm mã sản phẩm mã khách hàng ,diễn giải, ngày , số tiền), danh mục tồn kho (mã hàng, ngày , tồn đầu, nhập , xuất, tồn cuối, đơn giá), danh mục nhật kí bán gồm mã sản phẩm, mã hàng số lượng đơn giá thành tiền. và một cái form danh mục khách hàng . Không biết như thế còn thiếu những gì nữa. Mong các anh chị chỉ giúp.
 
hai2hai đã viết:
Rất nhiều ứng dụng dân IT chả hiểu nghiệp vụ gì cả nhưng họ biết cách "chuyển" kiến thức của khách hàng thành "yêu cầu phần mềm" để từ đó có thể thiết kế và coding được.

Hic!anh oi, cai kho no nam o cho nay ne!
 
Secret_grasses đã viết:
Hic!anh oi, cai kho no nam o cho nay ne!

Thì mình đang tập làm cái khó đó mà. Làm cái SRS cho dự án "Quản lý công nợ" này đó. Đấy có thể nói là công việc khó và quan trọng nhất của người làm phần mềm. Mọi người cứ quen ngày bụp vào cái Database, cái "lập trình", v.v... ngay là vẫn làm kiểu cũ - cách đó ko phải là cách làm khoa học và khó có thể làm dự án lớn hơn được (và chỉ làm theo kiểu cá nhân - rất khó làm tập thể được vì mọi thứ ở trong đầu của mỗi người).
 
Lần chỉnh sửa cuối:
Chỉ còn 10 ngày nữa...
Thật đáng tiếc, các bạn thiếu tự tin quá. Cũng có thể các bạn ngại vì không biết bắt đầu từ đâu ? Nhưng sao các bạn không thử làm, chúng ta có dở thì chúng ta cũng phải làm mới có người hướng dẫn chúng ta được chứ. Các bạn chưa cần gì kiến thức cao siêu, nào là lập trình, viết bằng ngôn ngữ gì ? Nào là không có kinh nghiệm về vấn đề này...Tôi chỉ tiếc các bạn không hiểu được ý định thực hiện dự án này ra sao ? Các bạn chỉ cần diễn đạt thử xem yêu cầu của khách hàng muốn gì, xem các bạn có nắm bắt dược hết yêu cầu của khách hàng không ? Các bạn gửi bản diễn đạt ấy cho tôi và Hải. Khi tôi và Hải xác nhận chính thức rằng tôi đồng ý thì các bạn mới bước vào giai đoạn 2 là phân tích, thiết kế các yêu cầu của dự án, và phân công người thực hiện.
Xem như dự án này của tôi thất bại vì chẳng có ai có ý kiến gì thêm.
Nhưng các bạn có hiểu là rất nhiều vấn đề tương tự như thế xảy ra trong cuộc sống của chúng ta không ?
Bây giờ, chị mong Hải trực tiếp Post thử lên bản phác thảo dự án theo yêu cầu của khách hàng để mọi người tham khảo, và xem như em hãy hướng dẫn lời giải nhé

Trước khi tiếp tục nêu lên một dự án thứ hai, rất giống dự án đầu tiên, mặc dù cái tên có vẻ "khác", tôi muốn biết ý kiến của các bạn về vấn đề này một cách nghiêm túc : "Các bạn có thích học cách triển khai và thực hiện một dự án theo nhóm làm việc hay không ?"
Dự án kế tiếp, tôi dự định sẽ là : "Quản lý NVL xuất kho cho sản xuất các mặt hàng bao bì nhựa"
Với dự án này, chúng ta chỉ có 2 NVL là hạt nhựa và màng PVC để sản xuất các mặt hàng như bao bì đủ mọi kích thước, thanh nhựa, nút nhựa, áo mưa, móc nhựa...Và dĩ nhiên, chúng ta phải thiết lập các hệ số theo một chuẩn nào đó về NVL chính, công chính, phụ...
 
Mẫu ví dụ về Software Requirement Spec cho dự án Quản lý công nợ

Mất hơn 30 phút đề làm 1 mẫu ví dụ về Software Requirement Spec cho dự án Quản lý công nợ. Mọi người đọc để tham khảo. Dựa trên tài liệu đó cùng với những gì mà các bạn biết về nghiệp vụ sau khi đã tham khảo yêu cầu của chị Dung thì cứ thế điền vào. Ban đầu nếu mọi người làm thì mình chỉ định hướng dẫn cách làm đơn giản thôi (theo mẫu Simple hôm nọ mình gửi) nhưng dù đơn giản cũng ko thấy ai làm cả. Tuy nhiên, để mọi người được hình dung kiểu tài liệu này 1 đầy đủ hơn 1 chút thì mình đưa luôn ra 1 mẫu tạm thời được coi là "ổn ổn" 1 chút. Dĩ nhiên đây chỉ là mẫu tài liệu mà thôi (nghĩa là chỉ có da, chưa có thịt), để viết toàn bộ các thứ trong đó thì mỗi ngày bỏ ra 20 đến 30 phút là ổn (khoảng 3 đến 5 ngày thì coi như tài liệu có da có thịt)

Cheers!

PS: Sorry, mình ko thể gửi các bạn file doc được vì nếu làm thế thì các bạn sẽ ko tự làm và khi ko tự làm sẽ không nhớ gì cả.
 

File đính kèm

Lần chỉnh sửa cuối:
Chỉ còn 2 ngày nữa là hết 1 tháng khởi động cho dự án, nhưng xem chừng mọi việc đã kết thúc. Dù kết quả không được như ý muốn, chị cũng cảm ơn Hải thật nhiều, kế đến là cám ơn nhiệt tình của Đào Việt Cường, tsf...
Tuy vậy, chị rất mong chúng ta sẽ còn dịp họp lại để tiếp tục triển khai dự án này...Và rất mong các Admin còn lại như Duyệt, Tuân, Bình cố gắng hiệp sức tạo không khí sôi nổi nơi Box dự án giải pháp Excel, vì theo chị, đây sẽ là Box chính của diễn đàn trogn tương lai
 
handung107 đã viết:
Chỉ còn 2 ngày nữa là hết 1 tháng khởi động cho dự án, nhưng xem chừng mọi việc đã kết thúc. Dù kết quả không được như ý muốn, chị cũng cảm ơn Hải thật nhiều, kế đến là cám ơn nhiệt tình của Đào Việt Cường, tsf...
Tuy vậy, chị rất mong chúng ta sẽ còn dịp họp lại để tiếp tục triển khai dự án này...Và rất mong các Admin còn lại như Duyệt, Tuân, Bình cố gắng hiệp sức tạo không khí sôi nổi nơi Box dự án giải pháp Excel, vì theo chị, đây sẽ là Box chính của diễn đàn trogn tương lai

Anh Duyệt, cả mấy tuần nay, ảnh đi đâu mất rồi, không nghe anh nói gì hết vậy. Chắc bị ai nhốt rồi.+-+-+-+
 
tsf đã viết:
Anh Duyệt, cả mấy tuần nay, ảnh đi đâu mất rồi, không nghe anh nói gì hết vậy. Chắc bị ai nhốt rồi.+-+-+-+
Chị Dung ơi,
Hổm rày nhà em có nhiều việc nên không có lên tiếng được mong thông cảm.

Le Văn Duyệt
PS: tsf liên lạc với anh nha.
 
Bạn vui lòng cho biết password được không ?

Tôi không save được file này vì không biết được password ! bạn vui lòng cho biết password được không ?
 
conhi đã viết:
Tôi không save được file này vì không biết được password ! bạn vui lòng cho biết password được không ?

Bạn ơi, bạn nói file nào vậy? SG thấy ở đây hổng có file nào có pw hết. Nếu bạn muốn nói đến file SRS QLCongNo _Template.pdf của anh2hai thì bạn chỉ cần vào file/save as là được.
 
Cuối cùng, dự án này cũng có tác phẩm hoàn thành. Đó là cố gắng của nhóm thứ 3 : nhóm Những con chim trong bụi mận gai. Dĩ nhiên, sẽ còn nhiều thiếu sót, xong BGK rất hoan nghênh tinh thần của Bình OVerAC. Cùng vỗ tay nào các bạn ơi....
Các bạn tham khảo và thảo luận đóng góp ý kiến nhé
 

File đính kèm

Chúc mừng OverAC và "Những con chim trong bụi mận gai" đã có sản phẩm đầu tiên.
Đánh giá sơ qua tôi thấy SP này có triển vọng, nếu đầu tư hơn nữa ->v3.0 có thể chuyển thành thương phẩm được rồi.

OverAC và nhóm của mình xem lại một số vấn đề nhé:
1- Sơ đồ nghiệp chưa hợp lý lắm. Danh mục nên đặt ở trên, mua hàng - > Bán hàng
2- Trong các hóa đơn mua/bán nên có trường "Phương thức thanh toán".
3- Trong phiếu thanh toán không nên có hàng hóa, số lượng, đơn giá, vì những thông tin này nằm ở hóa đơn mua/bán.
4- (*) Trong một số hàm và thủ tục có sử dụng Application.EnableEvents = False thì nên khai báo On Error Goto/Next Resume và đặt Application.EnableEvents =True ở cuối.
 
Lần chỉnh sửa cuối:
Thực ra phiếu thanh toán và cách thiết kế các nhóm KH như vậy ko đúng lắm :). (Nên có Pricing Levels và Inventory Item's Pricing setup. Những vấn đề này nếu làm SRS thì phải viết ra.)

Thanh toán thì phải thanh toán cho chứng từ (hóa đơn) bán hàng nào chứ ko cần thể hiện từng mặt hàng trong hóa đơn đó. v.v...

Tham khảo màn hình nhập thanh toán cho nhà cung cấp:
DebtSupplier.JPG


Hoặc xem hẳn màn hình Customer Payment của Quickbook 2004 tại đây:
image004.jpg


Còn chuyện thiết kế nhóm KH và tỷ lệ trong hàng hóa là...ko được rội. Tuy nhiên để làm đúng thì lại phải biết 1 chút về nguyên tắc DB Design (1 phần của thiết kế) và phần làm tài liệu yêu cầu. (rất tiếc mấy món này mọi người lại ko làm)

Anyways, đây cũng là nhóm tích cực nhất (tuy nhiên ko có tài liệu yêu cầu như thế nào nên khó đóng góp quá)

Nói chung, rất tiếc là ko có tài liệu SRS nên ko guideline để mọi người làm từ đầu thì làm như thế nào.
 
Lần chỉnh sửa cuối:
Mọi người xem qua cái flash này sẽ thấy nếu làm phần mềm thì họ làm thế nào nhé: (Cái này giá mà để cho dân làm IT xem thì chắc thích hơn, thôi thì ai "thích" software engineering thì xem qua 1 chút để biết họ làm gì - và sẽ thấy họ ko coding luôn đâu)

http://69.57.142.74/websiteimages/images/vpsuite22.swf

Trên đấy mô tả 1 công cụ thiết kế ứng dụng sử dụng ngôn ngữ UML (ko phải là ngôn ngữ lập trình đâu nhé). Tại sao các phần mềm của các công ty be bé nho nhỏ của Vietnam ta thường làm ko có chất lượng là vì hầu hết họ nhỏ nên chưa đủ lực để làm 1 cách hiện đại, làm 1 cách đúng bài bản, đúng chất lượng và thậm chí có nhiều công ty làm PMKT ko biết đến từ UML là gì, 1 thứ mà hầu hết IT man làm ở các công ty lớn ở VN bắt buộc phải biết, phải đọc hiểu được thì mới làm việc được. Bây giờ, ở các trường đại học chuyên về IT chắc sẽ không chỉ dạy ngôn ngữ lập trình nhiều nữa. Thay vào đó, họ sẽ đưa vào các môn học mang tính chất thực sự quan trọng hơn như: Quản trị dự án, phân tích thiết kế với ngôn ngữ UML (cái này dân làm PM ko biết là ko được), kỹ năng làm việc nhóm, testing (hình như cái này ko thấy dạy ở đâu cả), v.v... Mấy cái đó đã thấy nhiều ở môi trường đào tạo Aptech rồi, hình như là 1 số trường dân lập đã đưa mấy món đó vào giảng dạy rồi.
 
Khởi động lại dự án

Dear all,
--------
Quả là đáng tiếc vì dự án Quản lý công nợ trên Excel gần như không có tiến triển trong thời gian dài - nếu không muốn nói là quá hạn so với thời gian dự kiến hoàn thành nó.
Đã đến lúc phải nhìn nhận lại vấn đề. Vì đây là dự án khởi động của www.Giaiphapexcel.com, không thể có một dự án nào thành công hơn nếu như ngay từ đầu dự án này không đi đến kết quả cuối cùng - đó là suy nghĩ của cá nhân tôi.
Nhìn lại, nguyên nhân dẫn đến sự chậm trễ này theo tôi có nhóm các yếu tố cơ bản sau:
1 - Mục tiêu của dự án:
Có thể dự án đã đưa ra những yêu cầu và chức năng xử lý quá cao, vượt quá khả năng của thành viên ở mức độ trung bình có thể tham gia vào dự án. Bên cạnh đó phải xét đến mức độ phù hợp với nhu cầu xây dựng ứng dụng của từng ngưởi vì nếu dự án không phục vụ trực tiếp cho công việc hàng ngày của họ thì hầu như các yêu cầu đó thường bị đặt ở phía sau. Dường như mục tiêu của dự án đã làm mất đi động lực của nó.
2 - Sự kết hợp của thành viên trong nhóm:
Một nhóm chỉ có khoảng 2-3 người, nhưng hạn chế lớn hơn là nhóm chưa có sự kết hợp chặt chẽ của thành viên. Tinh thần là chính. Vì thế nếu thiếu đi tinh thần đó thì mọi xử lý của một cá nhân dù tích cực đến đâu cũng chỉ là hời hợt và mang đậm "màu sắc cá nhân" - duy ý trí.
3 - Ban tổ chức:
Đây là yếu tố quan trọng quyết định vòng đời mỗi dự án. Bản thân Ban tổ chức không đánh giá đúng phạm vi, mục tiêu của dự án, không có những kích hoạt cần thiết thì cũng khó có kết quả tốt đẹp như mong đợi. Bên cạnh đó là các ý kiến động viên, cổ vũ, đóng góp - thậm trí cả tham ra để xây dựng và hoàn thiện ý tưởng.
Dự án quản lý công nợ là một trong những sản phẩm chính của www.Giaiphapexcel.com trong tương lai. Dự án dễ thực hiện, song dường như chúng ta đã làm cho nó thiếu đi tính hấp dẫn ban đầu vốn có của nó. Mặc dù đã có một số kết quả đạt được đáng ghi nhân, tuy nhiên theo tôi vẫn chưa đáp ứng được yêu cầu. Với mong muốn dự án hoàn thành dứt điểm, tôi rất mong muốn các thành viên tiếp tục tích cực tham gia hoàn thiện dự án này.
Một số kiến nghị như sau:
- Cắt giảm các yêu cầu quản lý không phổ biến. Yêu cầu quản lý ở mức đơn giản có thể chỉ là: tính được thời hạn thanh toán của từng lần phát sinh; trên cơ sở đó lập kế hoạch thanh toán với nhà cung cấp, kế hoạch thu tiền của khách hàng.
- Thời gian hoàn thành dự án của mỗi nhóm do mỗi nhóm đăng ký nhưng không vượt quá thời gian quy định trung bình do ban tổ chức xác định.
Nhân ngày "Đẹp Giời" kính chúc các thành viên sức khoẻ dồi dào để hoành thành dự án này!
 
Đào Việt Cường đã viết:
Dear all,
--------
Một số kiến nghị như sau:
- Cắt giảm các yêu cầu quản lý không phổ biến. Yêu cầu quản lý ở mức đơn giản có thể chỉ là: tính được thời hạn thanh toán của từng lần phát sinh; trên cơ sở đó lập kế hoạch thanh toán với nhà cung cấp, kế hoạch thu tiền của khách hàng.
- Thời gian hoàn thành dự án của mỗi nhóm do mỗi nhóm đăng ký nhưng không vượt quá thời gian quy định trung bình do ban tổ chức xác định.
Nhân ngày "Đẹp Giời" kính chúc các thành viên sức khoẻ dồi dào để hoành thành dự án này!

Thực ra mọi người nghĩ ra nhiều thành ra to tát đấy chứ. Bài toán này là 1 trong những bài .... dễ nhất về mọi thể loại:

- Ai cũng hiểu là mua hàng, bán hàng thì có điều khoản thanh toán: Thanh toán ngay, mua nợ, thanh toán từng phần (cái này ở ngoài hàng nước trà đã cũng có khái niệm)
- Nghiệp vụ thì cũng khá giản đơn: Cũng khách hàng, cũng nhà cung cấp, cũng hóa đơn mua/bán hàng, cũng phiếu thu, cũng phiếu chi (theo hóa đơn), tổng hợp công nợ, chi tiết công nợ,... toàn cái mà dân kế toán ngày nào cũng sờ đến.
- Về chức năng cũng khá đơn giản, chỉ gạch đầu dòng trên dưới chục dòng

Mục tiêu của dự án cũng khá dễ hiểu:
- Làm quen với cách tiếp cận thực hiện 1 bài toán, thậm chí tập cách viết tổng quát lại 1 bài toán (sumary lại những gì KH yêu cầu - kiểu như sau mỗi tiết học, hs về nhà summarized lại những gì mà thấy giáo nói trên lớp ấy). Có lẽ đây là mục tiêu chính của dự án.
- Viết 1 đoạn chương trình đơn giản về quản lý công nợ.
 
handung107 đã viết:
Công ty A phân loại khách hàng như sau :
- Doanh thu mua hàng hàng tháng đạt từ 10.000.000 trở lên : nhóm khách hàng 1
- Doanh thu mua hàng hàng tháng đạt từ 5.000.000 đến nhỏ hơn 10.000.000 : nhóm khách hàng 2
- Doanh thu mua hàng hàng tháng ít hơn 5.000.000 : nhóm khách hàng 3
Với từng nhóm khách hàng có các yêu cầu về công nợ sau đây:
1/ Nhóm 1 :
- Thanh toán 50% mỗi lần mua hàng
- Số tiền tồn nợ tối đa là 7.000.000đ
- Thời hạn thanh toán là 2 tháng cho mỗi lần mua hàng
2/ Nhóm 2 :
- Thanh toán 70% mỗi lần mua hàng
- Số tiền tồn nợ tối đa là 3.500.000đ
- Thời hạn thanh toán là 1 tháng cho mỗi lần mua hàng
3/ Nhóm 3 :
- Thanh toán 80% mỗi lần mua hàng
- Số tiền tồn nợ tối đa là 2.000.000đ
- Thời hạn thanh toán là 1 tuần cho mỗi lần mua hàng
Từ những yêu cầu trên, hàng ngày, sẽ có những phiếu báo công nợ cần thanh toán đến các khách hàng theo mẫu đính kèm
Các bạn lưu ý, đây sẽ là bài thực hành đầu tiên, và phương pháp làm việc của chúng ta sẽ là làm việc theo nhóm. Có thể chúng ta sẽ chia ra 3 nhóm làm việc, mỗi nhóm sẽ có trưởng nhóm, và mỗi nhóm sẽ có Box riêng để trao đổi thảo luận với nhau, chúng ta sẽ có thi đua giữa các nhóm làm việc, và tôi sẽ đề cử Mod Hai2Hai tổ chức thực hiện phương pháp thực hiện dự án đầu tiên của Giaiphapexcel

Thời gian thực hiện đề tài này là 1 tháng. Các bạn đăng ký tham gia làm việc theo các nhóm nhé
Dear all,
-------
Ý kiến của em thì không nên đưa ra yêu cầu cụ thể theo hướng trên đây vì các yêu cầu này chỉ là 1 trong các trường hợp của quản lý - sẽ không phù hợp trong các đơn vị mà thành viên tham gia, cũng có nghĩa là không tạo động lực cho họ nghiên cứu và phát triển ứng dụng của mình. Xét từ bản thân em, quy trình và các điều kiện thanh toán tại AUSTNAM BMC khác hơn nhiều so với các yêu cầu này. Do đó em không có điều kiện để tiếp cận ứng dụng trong khi công việc thì bộn bề.
Em thiết nghĩ nên để tự các nhóm đưa ra các mô tả các yêu cầu của nhóm mình từ đó trình bày cách thức xử lý và báo cáo. Ban tổ chức sẽ căn cứ vào các chỉ tiêu như: mức độ phức tạp, tính phổ biến (có thể ứng dụng rộng rãi); phương pháp xử lý và báo cáo... để đánh giá sản phẩm.
Như thực tế đã thấy, dự án được phát động khá lâu nhưng chưa có kết quả như mong muốn. Cũng có thể là do thời gian quy định đã hết nên mọi người không muốn tiếp tục. Em đồng ý thời gian hoàn thành cũng là một chỉ tiêu đánh giá nhưng với dự án này nên để các nhóm tự xác định thời gian hoàn thành dự án của nhóm mình và đăng ký với ban tổ chức (vì mỗi nhóm có yêu cầu và độ phức tạp khác nhau). Trên cơ sở đó ban tổ chức đưa ra thời hạn trung bình thống nhất.
Khó mà không làm thì còn có thể để động viên, dễ mà không làm thì lấy gì để động viên ạ!
 
Tôi chỉ mới biết sơ sơ về Excel nên khi thấy DA công nợ hay nên cũng tham gia (chủ yếu là cổ vũ, và nghe các bạn trình bày mà học hỏi thêm). Hy vọng sau này, tôi sẽ tham gia vào một DA khác, cũng hấp dẫn và sôi động như hiện tại.
 
Hi hai2hai,

Link này ko vào được nữa rồi.
http://69.57.142.74/websiteimages/images/vpsuite22.swf

Dự án này hay nhưng sao ko ai tiếp tục phát triển tiếp, hoặc đưa ra các dự án khác nhỉ.

Link này lâu lắm rồi, bạn tìm hiểu về phần mềm http://www.visual-paradigm.com nhé

Nhờ có bạn mà hai2hai tự nhiên nhớ lại những ngày nhiệt huyết. Tuy nhiên những bài này viết từ năm 2006 rồi và ko phát triển được tiếp vì một số hiểu nhầm về mục đích của "phong trào" này, tỉ như:

Ý kiến của em thì không nên đưa ra yêu cầu cụ thể theo hướng trên đây vì các yêu cầu này chỉ là 1 trong các trường hợp của quản lý - sẽ không phù hợp trong các đơn vị mà thành viên tham gia, cũng có nghĩa là không tạo động lực cho họ nghiên cứu và phát triển ứng dụng của mình. Xét từ bản thân em, quy trình và các điều kiện thanh toán tại AUSTNAM BMC khác hơn nhiều so với các yêu cầu này. Do đó em không có điều kiện để tiếp cận ứng dụng trong khi công việc thì bộn bề.

Đây không phải là việc viết về cái mình muốn, cái mình biết. Đây là 1 ví dụ để ta đóng vai trò là 1 "nhà cung cấp phần mềm" và thực hiện dự án "theo yêu cầu của KH". Ta viết cho ta thì nói làm gì nữa chứ :).

Chẳng biết AUSTNAM BMC khác thế nào chứ Augges đã triển khai cho AUSTNAM BMC và vẫn với cái mớ kiến thức quản lý công nợ kiểu kiểu như ở trên (dĩ nhiên nếu làm thật thì đầy đủ hơn). Nhưng mục tiêu ở đây ko phải là ta đi làm 1 bài toán lớn nào đó mà đây là 1 dự án "Ví dụ đầu tiên". Đã là ví dụ, là đầu tiên thì phải thật đơn giản và quan trọng nhất là: Hãy tập biến yêu cầu "bùng nhùng ko rõ ràng" của KH thành đặc tả yêu cầu phần mềm để có thể cho những ông coding chẳng cần hiểu nghiệp vụ cũng có thể làm được.

Mong muốn cuối cùng của dự án này ko phải là mấy cái file chạy chạy, cũng chả phải chúng ta viết cho chúng ta dùng,... mà là 1 file đặc tả tài liệu yêu cầu của KH thật rõ ràng (để bất cứ 1 dân coder nào đọc cũng hiểu). Chấm hết!

P/S: Còn về chuyện ko có thời gian. 1 tài liệu SRS đầy đủ cho ví dụ trên chỉ khoảng trên 10 trang, cần 1 tuần thực hiện (là quá nhiều) và mỗi ngày bỏ ra 30 phút buổi trưa là xong. Mặc dù rất đơn giản nhưng do là dự án online (mà ở VN thì làm Online rất kém) nên chỉ thành công với những ai MUỐN đạt mục tiêu nói trên mà thôi.
 
Lần chỉnh sửa cuối:
@VNUNI - toi k biet cac bac thiet ke phan mem gioi co nao chu may phan mem augess hay HR cua cac bac toi thay nhu the nay:

+ cong no k co kha nang quan ly theo Don hang; hoa don; Tuoi no
+ cong no k co kha nang len bang thanh toan thang; tuan; nam; theo su kien
+cong no lai cang k co kha nang phan nhom khach hang

+ Quan ly thiet bi thi cang so sai: k co kha nang theo doi theo vi tri cua tai san, cong cu dung cu
+ K co kha nang dua ra asset tracking log ( cai nay dac biet quan trong voi xây dung
Toi k hieu cac bac tu hao la nha thiet ke chuyen nghiep; nhin ai cung che nhung phan mem cac bac xu ly du lieu con kem hon ca nguoi khong chuyen ve tin xu ly tren excel
+ cac bac gioi lap trinh hay chi gioi chinh sua phan mem cua nguoi khac ?
Cac bac co gioi thi dua cac file the hien thuat tuan xu ly du lieu len moi nguoi cung kiem chung
 
....................................................................................................
 
Lần chỉnh sửa cuối:

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

Back
Top Bottom