Dự án quản lý công nợ

Liên hệ QC
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

  • Theogioibanhang.rar
    66 KB · Đọc: 1,284
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:
Web KT
Back
Top Bottom