Plugin Procedure Use Case
Zhuq!
ชื่อ object ที่เป็น ack_XXXX_XXX คือ tables ต่างๆ ของ System Core
ที่แต่ละ modules จะต้องกระทำกับมัน
เพื่อที่จะทำการเชื่อมตัวแปรทั้งหมดเข้าเป็นส่วนหนึ่งส่วนเดียวกัน
รายละเอียดของ fields ต่างๆ ใน tables ที่ปรับปรุงแก้ไข
ผมกำลังไล่ทำต่อให้จบเป็นส่วนๆ ไป แต่ตอนนี้อยากให้ช่วยกันดูว่า use case
ที่คุยกันคือเขียนเป็นรูปร่างอย่างนี้รึเปล่า? :P
Dreamer
ระบบ IVM, ARM, APM, PRM, และ FRM เวลา plug เข้ามาจะเขียนไฟล์
init.conf, ตาราง ack_module_list และสร้าง table ใหม่ บน db เดียวกับ
core table เหรอครับ แล้วก็จะเขียนงานบนนั้น ส่วน user
จะเขียนงานเข้าไปที่ ack_accmap_conf, ack_doccat_id, ack_trustee_conf
ซึ่งทั้ง 3 ตัวนี้จะอ่าน core ขึ้นมา และอ่าน ack_module_list
ขึ้นมาเช็คด้วย ใช่ไหมครับ
On Dec 21, 1:01 am, "Zhuq!" <viruzh...@gmail.com> wrote:
> ทดลองเขียน use case ของ plugin procedure ให้ดูครับ :)
>
> ชื่อ object ที่เป็น ack_XXXX_XXX คือ tables ต่างๆ ของ System Core
> ที่แต่ละ modules จะต้องกระทำกับมัน
> เพื่อที่จะทำการเชื่อมตัวแปรทั้งหมดเข้าเป็นส่วนหนึ่งส่วนเดียวกัน
>
> รายละเอียดของ fields ต่างๆ ใน tables ที่ปรับปรุงแก้ไข
> ผมกำลังไล่ทำต่อให้จบเป็นส่วนๆ ไป แต่ตอนนี้อยากให้ช่วยกันดูว่า use case
> ที่คุยกันคือเขียนเป็นรูปร่างอย่างนี้รึเปล่า? :P
>
> http://ackernel.googlegroups.com/web/PluginProcedures.png?gda=Rq5buEc...
Dreamer
Zhuq!
1 . system core แทบจะไม่มีอะไรของมันเองเลย เป็นแค่ระบบการบริหารจัดการ
กับระบบบัญชีแยกประเภทซึ่ง function จะน้อยมาก
เพราะเป็นข้อมูลปลายสุดของการบันทึกทั้งหมดในระบบ ดังนั้น parameter และ
table อีกหลายๆ อย่างจึงกำหนดไว้ให้เฉพาะตัวเองใช้
เช่นจะมีแต่รหัสผังบัญชี, รหัสแผนก, รหัสพนักงาน, แต่ไม่มีรหัสสินค้า
หรือรหัสลูกหนี้-เจ้าหนี้เลย เพราะนั่นเป็นเรื่องของ modules อื่นๆ
2. IVM, ARM, APM, FAM, PRM เป็น modules ที่เอามาเพิ่มลงไป
จะต้องมีหน้าที่สร้างตารางรหัสที่ตัวเองต้องการเพิ่มลงไปในระบบด้วย
แล้วก็ต้องสร้าง parameter ที่จำเป็นของตัวเองต่างหากจาก ackinit.conf
ของ system core เช่นอาจจะเป็น ivminit.conf, arminit.conf, ...
ไล่ไปเรื่อย
3. จากนั้นก็ประกาศตัวให้ system core รู้จัก ด้วยการเติม records
เข้าไปใน ack_MODULE_LIST เพื่อบอกว่า modules ของตนนั้นมีชื่อย่อว่าอะไร
(ivm, arm, arpm, ...) แล้ว interface ต่างๆ มีชื่อว่าอะไรบ้าง ...
ตรงนี้ system core ก็จะเอาไปใช้ประโยชน์ในการสร้างรายการใน
ack_ACCMAP_CONF (ดย users) ซึ่งจะเป็นการโยง field ต่างๆ ของแต่ละ UI
ของ modules เพื่อกำหนดเป็น pattern การบันทึกบัญชีรายวัน เช่นรายวันซื้อ
รายวันขาย รายวันชำระเงิน ... ซึ่งเกือบ 100% จะมี pattern
แบบเดียวกันหมด การกำหนดตรงนี้ ก็เพื่อให้ modules
ที่เกี่ยวข้องมาอ่านค่าไป แล้วทำหน้าที่สร้างข้อมูลบัญชีตามที่กำหนดไว้
เราก็จะได้สมุดบัญชีรายวันกลุ่มหนึ่งที่เกิดขึ้นพร้อมกับการบันทึกข้อมูลส่วนอื่นๆ
ทั้งหมดที่เล่าตรงนี้ ยังไม่มีเรื่องของข้อมูลทางบัญชีเลยครับ
เป็นการเชื่อมโยงตารางรหัสต่างๆ เข้าด้วยกัน
เพื่อจะประกอบกันเป็นระบบบัญชีทั้งก้อนขึ้นมา ตรง ack_MODULE_LIST
จะคล้ายๆ กับเป็น control panel ที่จะสามารถเลือกปลด modules
บางอย่างออกไปได้ มันก็จะไปไล่ถอด DB ของ modules นั้นๆ ออกไป ... IVM,
ARM, APM เหล่านี้ก็อาจจะมี third party ที่ทำได้น่าสนใจกว่า
หรือเราเองปรับปรุงให้ดีขึ้น ก็เอาไปเสียบลงแทนที่ของเดิม โดยที่ table
ทั้งหมดจะไม่ตีกัน :)
นี่ก็คือ concept ของส่วนที่จะทำหน้าที่เป็น system core ใน AcKernel
ครับ
Dreamer
software ใดๆ ใช้ เพื่อไม่ให้ถูกครอบงำด้วยแนวความคิดของ software ใดๆ
(ไม่เอา process การ config software เพราะจะทำให้หลงทาง)
http://groups.google.com/group/ackernel/web/AcKernelWorkProcess.png
อธิบายรูป: ระบบ plug in ต่างๆ จะมีข้อมูลส่วนหนึ่งที่เหมือนกับบน
journal การอ่านเขียนข้อมูลบน journal ก็จะได้เฉพาะข้อมูลบน journal
เท่านั้นโดยไม่เกี่ยวกับ plug in แต่ระบบ plug in จะมีข้อมูลต่างๆ ตามที่
journal มี สามารถเขียนอ่านได้เช่นเดียวกับที่ journal ทำได้
แต่จะมีความสามารถเพิ่มเติมตามแต่ละ plug in ต้องการ
การจะเข้าถึงข้อมูลเฉพาะใน plug in จะต้องเข้าถึงผ่าน plug in
นั้นโดยตรงเท่านั้น ไม่ทราบว่าผมเข้าใจถูกหรือไม่?
Zhuq!
process แบบง่ายๆ มาให้ดู
http://ackernel.googlegroups.com/web/BusinessProcess1.png?gsc=qhMosAsAAAC3JtxdVfvnvJ2c-TOqP0W_
ที่เห็นนั่นคือ process พื้นฐานปรกติ
โดยยังไม่เติมรายละเอียดเรื่องการรับคืนสินค้า, การส่งคืนสินค้า,
หรือการควบคุม serial no เพื่อการทะเบียนการรับประกันสินค้า
หรือการปรับปรุงเพื่อเปลี่ยนแปลงหน่วยนับสินค้า
การเบิกจ่ายสินค้าเพื่อประกอบ หรือการถอดชิ้นส่วนเพื่อแปลงสภาพของสินค้า
ฯลฯ เพราะไม่อย่างนั้นมันจะเปรอะจนไม่เห็น process ที่เกี่ยวไขว้กัน
'ระหว่าง' สิ่งที่ผมแยกเรียกว่า modules ต่างๆ
requirement หลายๆ อย่างเป็นสิ่งที่จะเกิดขึ้นเฉพาะในแต่ละ modules
เท่านั้น เพื่ออำนวยความสะดวกในการทำงาน แต่มักจะไม่ค่อยคาบเกี่ยวระหว่าง
modules เช่นทำตารางราคาสินค้า, การแปลงใบสั่งสินค้าให้เป็นใบจอง
หรือบิลขาย, ทำใบแจ้งหนี้อัตโนมัติ, ฯลฯ ...
ในขณะที่ส่วนที่จะเกี่ยวข้องกับระบบบัญชีแยกประเภท
ก็จะต้องมีสมุดรายวันของเรื่องนั้นๆ มารองรับเสมอ
หรือแม้แต่สมุดรายวันทั่วๆ ไปที่ไม่ได้เกี่ยวข้องกับสินค้า ลูกหนี้
เจ้าหนี้ ก็ยังมักจะแยกย่อยออกเป็นหลายๆ เล่ม เพื่อให้หลายๆ
ส่วนงานสามารถปฏิบัติได้พร้อมๆ กัน และเป็นการจำแนกหมวดหมู่ของงาน
เพื่อให้สะดวกกับการตรวจสอบดูแลด้วย
สำหรับ process ในระบบบบัญชีแยกประเภท หากไม่มีคอมพิวเตอร์ใช้
เขาก็จะต้องมีสมุดบัญชีแยกประเภท กระจายออกไปเป็นหลายๆ เล่ม
แล้วก็ลอกรายการจากสมุดบัญชีรายวันเฉพาะรายการที่เกี่ยวกับบัญชีแยกประเภทเล่มนั้นๆ
ลงไป ทีละรายการๆ ไปเรื่อยๆ จนกว่าจะครบทุกรายการ ...
พอจะปิดงวดบัญชีก็ไล่บวกจากทีละเล่มๆ กลับเข้ามา
เพื่อบันทึกยอดสรุปของบัญชีแยกประเภทแต่ละเล่มมาแสดงเป็นงบการเงินอีกทอดหนึ่ง
วิธีที่คล้ายๆ กันนี้ ก็จะปฏิบัติแบบเดียวกับ stock card
คือต้องเอารายการสินค้าแต่ละบรรทัดในบิลซื้อขาย ไปลอกใส่ใน stock card
แต่ละหน้าๆ ที่หมายถึงสินค้าตัวใดตัวหนึ่งอย่างเจาะจง
พอสิ้นปีก็สรุปตัวเลขสินค้าคงเหลือแต่ละตัวมาทำเป็นรายงานสรุป
ต้นทุนสินค้าก็ไล่คำนวณไปทีละบรรทัดๆ เรื่อยๆ
เพื่อเอาไปคำนวณหากำไรขั้นต้นที่ยังไม่หักค่าใช้จ่าย ... งาน labor ดีๆ
นี่เองครับ :D
ความเกี่ยวข้องกันของข้อมูลทางบัญชีแต่ละส่วนั้นถือว่ามีน้อยมาก
เพราะเป็นการเอาตัวเลขที่สรุปแบ้วจากที่หนึ่ง
โยนไปเขียนลงในสมุดอีกเล่มหนึ่ง (โดยไม่เอารายละเอียดมาด้วย)
ซึ่งก็วนกันอยู่อย่างนี้ตลอดอายุขัยของพนักงานบัญชีแหละครับ อย่างเช่น
บิลขายหนึ่งบิลจะเกี่ยวกับบัญชีลูกหนี้ก็เฉพาะแค่ยอดรวมตรงท้ายบิล
รายละเอียดของสินค้าที่ขาย บัญชีลูกหนี้ก็ไม่สนใจ
เพราะต้องการแค่ตัวเลขที่สรุปแล้วจากการขายนั้นๆ อย่างนี้เป็นต้น
Zhuq!
ระบบ plug in ต่างๆ จะมีข้อมูลส่วนหนึ่งที่เหมือนกับบน
journal การอ่านเขียนข้อมูลบน journal ก็จะได้เฉพาะข้อมูลบน journal
เท่านั้นโดยไม่เกี่ยวกับ plug in แต่ระบบ plug in จะมีข้อมูลต่างๆ ตามที่
journal มี สามารถเขียนอ่านได้เช่นเดียวกับที่ journal ทำได้
แต่จะมีความสามารถเพิ่มเติมตามแต่ละ plug in ต้องการ
การจะเข้าถึงข้อมูลเฉพาะใน plug in จะต้องเข้าถึงผ่าน plug in
นั้นโดยตรงเท่านั้น ไม่ทราบว่าผมเข้าใจถูกหรือไม่?
ผมจะตอบว่า :
1. บน journal จะมีเฉพาะตัวเลขขั้นสุดท้ายของ plug-in
นั่นคือความหมายว่ามันมี 'แค่บางส่วน'
เช่นบิลหนึ่งใบจะมีรายการสินค้ากี่ใบไม่เกี่ยวกับ journal
แต่จะมีเฉพาะยอมรวมของแต่ละเรื่องเท่านั้นที่เกี่ยว คือยอมรวมซื้อ
ยอดรวมภาษี ยอดรวมหนี้
2. การ 'ล้วงลูก' บันทึกแก้ไขข้อมูลปลายทาง (ในสมุดรายวัน)
จะไม่มีผลกระทบมาถึงข้อมูลต้นทาง แต่จะมีผลให้ integrity
ของข้อมูลผิดเพี้ยนทันที เหมือนเราไปแก้ไขผลลัพธ์ของสมการ
แทนที่จะแก้ไขที่ตัวสมการ ประมาณนั้นครับ
3. ข้อ 2 คือสิ่งที่ต้องป้องกัน แต่ห้ามปิดกั้น
เพราะในบางกรณีก็มีความจำเป็นต้องทำงานอย่างนั้นเหมือนกัน
โดยผู้รับผิดชอบที่เข้าใจวิธีการทางบัญชี ถ้าเป็นสมุดบัญชีปรกติ
เขาจะใช้วิธีแยกสมุดรายวันปรับปรุงขึ้นมาต่างหาก
แล้วแก้ไขด้วยประบวนการทางเอกสาร ซึ่งยุ่งยากมาก
4. journal จะสามารถเข้าถึงข้อมูลทุกอย่างเฉพาะที่ plug-in
ส่งมาให้แล้วเท่านั้น แต่การเข้าถึงรายละเอียดอื่นๆ จะต้องทำงานด้วย
interface ของแต่ละ plug-in เท่านั้น เนื่องจากส่วนของ journal จะมีเฉพาะ
interface สำหรับจัดการกับข้อมูลของตัวเอง
(รวมทั้งข้อมูลเฉพาะที่ถูกส่งมาให้แล้ว) เท่านั้น
On Dec 22, 6:47 am, Dreamer <asuwanna...@gmail.com> wrote:
mangmo
อยู่นะครับ
แต่ยังคิดไม่ออกว่าจะเข้าไปสอดแทรกเข้าตรงไหน
เดี๋ยวจะลองลอกไดอะแกรมของพี่ฉึก
ไปแก้แล้ววางให้ดูใหม่ก็แล้วกัน ส่วนที่ผมบอกว่าขาด
ก็คือส่วนที่จะต้องเกี่ยวข้องกับกระบวนการผลิต
เห็นในไดอะแกรม พูดถึงการบวนการซื้อขาย โฟลไปถึงระบบสินค้าคงคลัง
เพราะฉะนั้นจึงต้องมีกระบวนการผลิตสินค้าเข้ามาเกี่ยวข้อง
กับระบบบัญชีอย่างหลีกเลี่ยงไม่ได้ ถ้าเราตัดออกไป
ระบบบัญชีนี้ก็จะดูไม่สมบูรณ์ หรือว่ามีแล้วแต่ผมมองไม่ออก
หรือความเห็นอื่นไหมครับ
On Dec 22, 2:04 pm, "Zhuq!" <viruzh...@gmail.com> wrote:
> เดี๋ยวค่อยทำความเข้าใจรูปที่คุณ Dreamer แปะไว้ครับ อันนี้เอา business
> process แบบง่ายๆ มาให้ดู
>
> http://ackernel.googlegroups.com/web/BusinessProcess1.png?gsc=qhMosAs...
> ...
>
> read more >>
Zhuq!
เนื่องจากผมเลือกตัดเอาเฉพาะส่วนที่วุ่นวายที่สุดออกมาให้ดูเท่านั้นเอง
ซึ่งจริงๆ มันยังมีเรื่องของการส่งคืนสินค้า และรับคืนสินค้าด้วย
เพียงแต่ process มันคล้ายๆ กันก็เลยเว้นไว้ก่อน
ส่วนเรื่องการผลิตมันจะแยกออกไปอีกส่วนหนึ่ง
ซึ่งเป็นเรื่องที่วนอยู่ในเฉพาะ module ของสินค้าคงคลัง โดยเกี่ยวข้อกับ
modules อื่นๆ น้อยมาก
เว้นแต่ไปกระทบโดนมูลค่าของสินค้าที่เปลี่ยนแปลงไปเนื่องจากการผลิต
มันจึงต้องมีสมุดบัญชีรายวันต่างหากของมันขึ้นมา ก็เลยเว้นเอาไว้ก่อน
และคงจะตัดแยกออกเป็น process ย่อยของมันเองครับ
เพื่อไม่ให้เส้นระโยงระยางพวกนั้นมันตีกันมั่ว
พอไปถึงเรื่องการผลิต เรื่องระบบเงินเดือนมันก็จะเป็น requirement ถัดมา
เพราะองค์กรแบบนั้นมักจะมีพนักงานหลายสิบถึงหลายร้อยคน
ความสะดวกในการทำรายการเงินเดือนด้วยคอมพิวเตอร์จึงเป็นสิ่งที่จะต้องถูกเรียกร้องให้ต้องมีครับ
จากนั้นมันก็จะเลยต่อไปเรื่องของทะเบียนสินทรัพย์
เพราะทรัพยากรประเภทเครื่องจักรจะไม่สามารถบันทึกรายการเป็นค่าใช้จ่าย
และจะต้องมีการคำนวณค่าเสื่อมราคา อันนั้นก็จะต้องเพิ่มเข้าไปเป็นอีก
module หนึ่งต่างหากออกไป
> ...
>
> read more >>
mangmo
พอดีช่วงนี้ผมยุ่งๆ อีกแล้ว ไม่ได้เข้ามาหลายวัน
คงช่วยไม่ได้เต็มไม้เต็มมือซักที
แต่เท่าที่ดูแผนงานยังไม่มีอะไรเพิ่มเติมมาก
ใช่ไหมครับ ระหว่างนี้ผมก็คงคอยอ่านไปเรื่อยๆ ก่อนนะครับ
ยังไม่มีอะไรจะมาสอดแทรก ว่าแต่ว่าช่วงวันหยุดปีใหม่ทีมงานเรา
แยกย้ายกันไปไหนบ้างล่ะครับนี่ พักผ่อนกันบ้างก็ดีนะครับ
กลับมาจะได้มีแรงทำงานกันต่อ (และมาช่วยกันพัฒนางานในกลุ่มกันต่อ)
> ...
>
> read more >>
Dreamer
ก่อนเข้าไปในรายละเอียด อ้อ
ไม่ทราบว่าระบบอื่นมีความเกี่ยวพันกันเองอีกบ้างหรือไม่ครับ
พรุ่งนี้จะแวะเข้าไปคุยใน irc นะครับ
http://ackernel.googlegroups.com/web/SystemUseCase.png?gda=cXHNxUQAAACk4RHY04KYMvxyjV1uku2ol5r8CK6TXGqKmQ5qy8DzOQn9OHIde_O-Vxz_yMsriHRV6u9SiETdg0Q2ffAyHU-dzc4BZkLnSFWX59nr5BxGqA&gsc=_YFSyRYAAABnl1gxD83DsskyfL2_Yg4DQBByzFxxjldLK3mjhZ6UWw
หยุดปีใหม่ อาจจะต้องพาครอบครัวไปลพบุรีครับ
ยังไงก็ขอให้มีความสุขปีใหม่ทุกๆ คนนะครับ
> ...
>
> read more >>