บางคำถามที่ได้รับจาก twitter :)
Zhuq!
เลยเอามาตอบในนี้ทั้งหมดดีกว่า จะได้เห็นพร้อมๆ กันหลายคน
1. ใน table ที่ชื่อว่า ack_BOOK_LIST มี field หนึ่งที่ชื่อว่า
`serialctrl` เอาไว้ทำอะไร?
2. การเลือก voucher เพื่อนำไปคำนวนตาม account id ทำอย่างไร
ช่วยแจกแจงรายละเอียดหน่อยครับ?
สองข้อนี้เกี่ยวข้องกับ ack_BOOK_LIST โดยเฉพาะครับ
1. serialctrl เป็นส่วนที่เอาไว้ให้ user กำหนดหมายเลขตั้งต้นสำหรับ
running number ของ voucher ต่างๆ ในสมุดบัญชีรายวันแต่ละเล่ม
หรือแต่ละรหัส โดยกำหนดว่าถ้า serialctrl=0 จะเป็นการ disable
การให้เลขลำดับแบบอัตโนมัติ และ user จะเป็นผู้กำหนดหมายเลขเอกสารของ
voucher ด้วยตนเองทุกๆ ครั้งที่จะบันทึกรายการ
เพราะหมายเลข voucher อาจจะไม่จำเป็นต้องเริ่มต้นจาก 1 เสมอไป โดย user
อาจจะต้องการให้มีตัวเลขนำหน้าเพื่อแยกแผนก, ปี, เดือน, หรืออื่นๆ
ได้ตามต้องการ เช่นอาจจะเริ่มต้นที่ 162010010001
เพื่อประโยชน์ในการอ้างอิงภายในกระบวนการทำงานของ user เอง
2. การเลือก voucher เพื่อนำไปคำนวณตาม account id ทำยังไง?
โดยปรกติแล้วทุก voucher จะต้องถูกนำไปคำนวณทั้งหมดอยู่แล้ว
เพราะถือเป็นข้อมูลทางบัญชี
อย่างไรก็ตามเราสามารถแยกรายการที่บันทึกไว้เพื่อการเปรียบเทียบในรูปของสมุดบัญชีรายวันงบประมาณ
หรืออาจจะมีสมุดบัญชีรายวันสำรองจ่าย ซึ่งทั้งหมดเหมือนกับเป็น 'สมุดทด'
ที่ใช้งานภายในกระบวนการทางเอกสารเท่านั้น
แต่ยังไม่เกิดผลลัพธ์เป็นธุรกรรมใดๆ
ซึ่งในกรณีที่ว่านี้ วิธีที่สะดวกที่สุดก็คือ
การแยกรายการเหล่านั้นให้ไปอยู่ในสมุดบัญชีรายวันต่างหากจากเล่มอื่นๆ
(คือแยก bookid ออกไปเลย) แล้วกำหนดค่าในฟิลด์ posted ของ bookid
นั้นเป็น N เพื่อบอกให้ระบบรับรู้ว่า เวลาปิดงวดบัญชีไม่ต้องเอารายการใน
bookid ดังกล่าวไปร่วมคำนวณ
3. สิ่งที่ user ทำกับ voucher มีอะไรบ้าง?
สิ่งที่ user ต้องทำงานกับสมุดบัญชีรายวันก็จะมีเพียง 5 อย่างเท่านั้นคือ
Browse, Print, Create, Edit, Delete ครับ โดย table
ที่จำเป็นจะต้องเกี่ยวข้องก็จะมีเพียง ack_SECTION_ID กับ ack_ACCOUNT_ID
เท่านั้น
สำหรับสมุดบัญชีแยกประเภทในระบบบัญชีคอมพิวเตอร์นั้น
ส่วนใหญ่จะเป็นสิ่งที่เกิดจากระบบรายงาน ซึ่งดึงข้อมูลจาดสมุดบัญชีรายวัน
แล้วจัดเรียงตาม account id เท่านั้น ไม่ค่อยมีความจำเป็นที่จะต้องมี
physical data อย่างจริงๆ จังๆ
Dreamer
ดูข้อมูลอะไรบ้าง print มี print ข้อมูลอะไรบ้าง
5 serial control ต้องการจะให้เปลี่ยนแปลงค่าในทีหลังได้หรือไม่ เช่น
เดิมกำหนดไว้ เริ่มต้นที่ 1000 ใช้ไปๆ แล้วเปลี่ยนไปใช้แบบวันที่เป็นต้น
6 แล้ว 2 การแยกออกไปคำนวนจะต้องแยกออกไปคิดตาม account id หรือ book id
ละครับ (ยังไม่ได้คำตอบ) และแยกออกไปคิดนั้นมีกระบวนการเอาไปคิดอย่างไร
เช่น จับกลุ่มคิดตามกลุ่ม account id ใช่หรือไม่?
(ต้องการรายละเอียดเชิงลึกครับ)
Zhuq!
การ browse ที่ว่านี้ ควรจะเหมือนการจำลอง 'การพลิกหน้ากระดาษ'
ของแฟ้มเอกสารจริงๆ คือสามารถ page up / page down ดูรายเอกสารทีละใบๆ
(เรียงตามลำดับหมายเลขเอกสารไปเรื่อยๆ) และควรจะต้องสามารถ search
เพื่อหาหมายเลขเอกสารที่ต้องการได้โดยสะดวก
ซึ่งปรกติแล้วก็คือหน้าจอเดียวกับการทำงานปรกติ เพียงแต่ไม่ได้อยู่ใน
mode ของการบันทึกข้อมูลเท่านั้น
5. serial control ต้องสามารถเปลี่ยนแปลงได้โดย user ที่ดูแลระบบ
ซึ่งโดยปรกติแล้วก็จะต้องมีการเปลี่ยนให้เริ่มต้นใหม่เป็นระยะๆ
อาจจะเป็นรายเดือน หรือรายปีก็ได้ ...
ตรงนี้หากเปรียบเทียบกับเอกสารจริงๆ ลำดับตรงนี้จะคล้ายกับ 'เล่มที่' /
'เลขที่' ซึ่งบางแห่งเริ่มนับ 1 ใหม่เมื่อมีเปลี่ยน 'เล่มที่'
แต่บางแห่งก็ใช้วิธีนับต่อเนื่องไปเรื่อยๆ โดยมี 'เล่มที่'
กำกับไว้ข้างหน้าเฉยๆ ...
ระบบปัจจุบันที่ผมใช้งานอยู่จะใช้วิธีเข้าไปแก้ไขให้เริ่มนับหนึ่งใหม่ทุกๆ
เดือน เวลาที่อ้างอิงหมายเลขเอกสารก็จะสะดวกในการหาเอกสารจริง
เพราะจะจัดเก็บเอกกสารเป็นเดือนๆ เหมือนกัน
6. ข้อมูลที่อยู่ในสมุดบัญชีรายวันจะถือเป็น 'ข้อมูลดิบ' หรือ
'ข้อมูลตั้งต้น' เท่านั้นครับ
การคำนวณเพื่อปิดงวดบัญชีจะต้องลำดับข้อมูลโดยใช้
accountid + date + docno ซึ่ง bookid จะเหลือบทบาทแค่เป็น reference
เพื่อให้รู้ว่ารายการบัญชีนั้นถูกบันทึกไว้จริงที่สมุดบัญชีรายวันเล่มไหนเท่านั้นเอง
ตรงนี้เปรียบเทียบกับการทำงานกับกระดาษจริงๆ อย่างนี้ครับ
(i) เมื่อพนักงานบัญชีทำการบันทึกรายการในสมุดบัญชีรายวัน
- 1 - ระบุวันที่ที่บันทึกรายการ โดยไม่ต้องสนใจวันที่ในเอกสารจริง
ให้ถือวันที่บันทึกรายการเป็นสำคัญเท่านั้น
- 2 - บันทึกคำอธิบายรายการบัญชีว่าเป็นรายการอะไร เช่นซื้อเครื่องเขียน,
จ่ายค่าเช่า, หรือเป็นเรื่องไหนก็ว่าไป
- 3 - บันทึกรายการ 'คู่บัญชี' ที่ต้องการ
ซึ่งส่วนใหญ่ในโลกของกระดาษก็จะใช้ 'รหัสสมุดบัญชีแยกประเภท'
เป็นตัวกำกับรายการ ซึ่งก็คือ 'รหัสผังบัญชี'
ในระบบบัญชีคอมพิวเตอร์นั่นเอง ...
แล้วก็บันทึกมูลค่าเงินตามเอกสารในช่อง debit / credit ที่แยกออกเป็นคนละ
column อยู่แล้ว
- 4 - รวมผลลัพธ์ของฝั่ง debit / credit ที่แยกอยู่คนละ column นั่นแหละ
แล้วบันทึกยอดรวมเอาไว้เพื่อตรวจสอบว่า debit = credit แล้วหรือไม่
- 5 - ขีดเส้นขั้นรายการไว้ถือว่าจบ 1 voucher เวลาบันทึก voucher
อื่นก็เขียนต่อท้ายลงไปเรื่อยๆ
จนกว่าจะเต็มหน้ากระดาษแล้วค่อยขึ้นหน้าใหม่ ...
แล้วก็ตอกเบอร์ลงไปบนเอกสารว่า
ได้ทำการบันทึกรายการไว้ในสมุดบัญชีรายวันเล่มไหน ลำดับรายการที่เท่าไหร่
เพื่อเตรียมไว้เก็บเข้าแฟ้ม
สมุดบัญชีรายวันที่ใช้งานนี้เรียกว่า 'สมุดบัญชี 2 ช่อง' คือแยกช่อง
debit / credit เป็นคนละ column อย่างชัดเจน
(ii) เมื่อนำตัวเลขไปบันทึกในสมุดบัญชีแยกประเภท
- 6 - เอาตัวเลขที่บันทึกไว้แล้วในสมุดบัญชีรายวันนั้นไปแยกบันทึกใน
'สมุดบัญชีแยกประเภท' หรือ 'สมุดบัญชี 3 ช่อง'
โดยเด็ดเอาไปทีละบรรทัดเพื่อไปบันทึกลงในสมุดที่มีรหัสตรงกับที่ระบุเอาไว้ ...
ถ้า voucher นั้นมี 5 รายการที่อ้างถึง 'รหัสสมุด' 5 รหัส ก็แปลว่ามันมี
5 ประเภท ... ก็จะต้องบันทึกแยกกันเป็น 5 เล่ม ... โดย debit ก็ไว้ช่อง
debit ส่วน credit ก็เอาไว้ช่องเครดิต ... แล้วก็ บวก/ลบ
หาค่าสะสมของมันไว้ช่องสุดท้ายทีละบรรทัดไปเรื่อยๆ
อันนี้ลองนึกถึงสมุดบัญชีเงินฝากที่เราเห็นทั่วๆ ไปน่ะครับ มียอดเข้าก็
debit, มียอดออกก็ credit ... แล้วก็แสดงตัวเลขสะสมไว้ช่องท้ายสุด
จะได้ไม่ต้องบวกลบด้วยตัวเลขแนวตั้งยาวๆ
เวลาที่จะดูยอดรวมในสมุดบัญชีแยกประเภทนั้นๆ
ตรงหัวบรรทัดของแต่ละรายการก็จะระบุรหัสสมุดบัญชีรายวันเอาไว้
เพื่อให้รู้ว่ารายการนี้มีที่มาจากสมุดบัญชีรายวันเล่มไหน
เวลาที่จะตรวจทานเอกสารจึงจะค้นได้สะดวก
- 7 - พอบันทึกรายการในสมุดบัญชีแยกประเภทเสร็จแล้ว
ก็จะต้องย้อนกลับไปทำเครื่องหมายในสมุดบัญชีรายวันให้รู้ว่า voucher
ไหนได้รับการ post บัญชีไปแล้ว จะได้ไม่ต้องทำซ้ำซ้อน
เป็นอันเสร็จพิธีกรรมต่อหนึ่ง voucher ครับ พอมีเอกสารฉบับใหม่เข้ามา
ก็วนตั้งแต่เริ่มนั่นใหม่อีกครั้งครับ ... สมมุติว่ามีการบันทึกผิด ...
ทำไง?? สมุดบัญชีเขาห้ามมีรอบขูดขีดใดๆ เลยนะครับ สมัยก่อนๆ นี้แม้แต่
liquid ก็ไม่ได้
ต้องบันทึกสิ่งที่จะแก้ไขลงไปในสมุดบัญชีรายวันทั่วไปอีกเล่มหนึ่ง
แล้ววนไปไล่ post ลงในสมุดบัญชีแยกประเภททีละเล่มๆ
เพื่อจัดการกับสิ่งที่จะแก้ไขนั้นให้ถูกต้อง
ส่วนในระบบการบันทึกแบบคอมพิวเตอร์เขาทำอย่างนี้ครับ
- 1 - เลือก bookid ที่ต้องการขึ้นมา
- 2 - เปิดฉากมาก็ให้เบอร์ voucher ไปก่อนเลย
- 3 - บันทึกคำอธิบายรายการลงไปในพื้นที่ที่กำหนด
- 4 - บันทึก 'รหัสผังบัญชี' แทนการใช้ 'รหัสสมุดแยกประเภท'
แล้วเอาตัวเลขกรอกในช่อง debit / credit เหมือนการทำด้วยสมุด
- 5 - ออกจากโหมดการบันทึกข้อมูล ถือว่าเสร็จพิธีกรรมแล้ว
- 6 - สั่งพิมพ์ voucher นั้นๆ
ออกมาเพื่อเป็นใบปะหน้าสำหรับหนีบเข้าเป็นชุดกับเอกสาร แล้วเก็บเข้าแฟ้ม
ถ้า debit ไม่เท่ากับ credit ในข้อ 4
ระบบจะต้องปฏิเสธไม่ยอมให้ออกจากโหมดของการบันทึก
เพื่อให้แก้ไขตัวเลขให้ถูกต้องตรงกัน
- การสร้างสมุดรายวันออกมาเป็นกระดาษ เพื่อใช้แทนสมุดรายวันแบบเดิม
จะใช้วิธี print ผ่านระบบรายงาน ซึ่งจะเอา voucher ต่างๆ
มาเรียงต่อกันเป็น block เหมือนสมุดบัญชีรายวันที่นักบัญชีเขาใช้งานกัน
- การสร้างสมุดบัญชีแยกประเภท ก็สั่งผ่านระบบรายงานเหมือนกัน
ซึ่งโปรแกรมจะเป็นผู้ไปไล่กวาดจากสมุดบัญชีรายวันทุกๆ เล่ม เพื่อหา
'รหัสผลังบัญชี' ที่ระบุนั้นออกมา แล้วก็พิมพ์ออกมาให้หน้าตาเหมือนกับ
'สมุดบัญชี 3 ช่อง' ทุกประการ โดยไม่มีการบันทึกข้อมูลซ้ำซ้อนใดๆ อีก
แต่ให้ระบบหยิบจากข้อมูลดิบไปสร้างโดยตรงเลย
ทีนี้ถ้ามีการบันทึกผิด ทำไง? ...
ในระบบคอมพิวเตอร์ก็ edit เข้าไปที่สมุดบัญชีรายวันได้เลย เพราะจริงๆ
แล้วข้อมูลมันยังไม่ได้วิ่งไปไหนทั้งนั้น ส่วนที่ว่า post
แล้วห้ามแก้ไขโดยปราศจากร่องรอยอย่างที่กฎหมายกำหนด
มันก็จะกลายเป็นเงื่อนไขของสถานะของ voucher เท่านั้นว่า user
จะกำหนดให้มันกลายเป็น post แล้วเมื่อไหร่ครับ :)
Dreamer
เพื่อนำไปคำนวนทำอย่างนี้ใช่ไหมครับ
1 ใส่ค่า book id และวันที่ ลงไป ก็จะได้ voucher 2 ชุดนี้มา
2 ใส่ account id ลงไป ก็จะได้ itemorder พร้อมทั้งข้อมูลอื่นๆ ใน
itemorder นั้นที่มี account id ที่ตรงกับ account id ที่ป้อนลงไป
3 ส่วน itemorder อื่นๆ ที่ไม่เกี่ยวข้องใน voucher 2 ชุดนี้
ก็จะไม่ถูกเลือกขี้นมา
สรุปอย่างนี้ถูกต้องไหมครับ
Zhuq!
แต่ตามที่เข้าใจนั่นก็ถูกต้องแล้วครับ
ความสัมพันธ์ของส่วนต่างๆ ที่ประกอบกันขึ้นมาเป็น 'สมุดบัญชีรายวัน'
แต่ละ bookid คืออย่างนี้ ตาม table ที่ร่างเอาไว้จะประกอบด้วย 3 ส่วน
1. ack_{{BookID}}_HEAD : ตรงนี้เพื่อเก็บหมายเลข voucher, วันที่,
และคำอธิบายรายการ
2. ack_{{BookID}}_BODY :
สำหรับเก็บรายละเอียดของใบกำกับภาษีเพื่อใช้ในการออกรายงานภาษีมูลค่าเพิ่มเท่านั้น
3. ack_{{BookID}}_TAIL : ส่วนนี้เก็บรายการ 'คู่บัญชี' ของ voucher
นั้นๆ ซึ่งจะนำไปสร้างเป็น 'บัญชีแยกประเภท' ต่อไป
ตัวที่เกี่ยวข้องกับการคำนวณจริงๆ จะมีแค่ 1 กับ 3 เท่านั้น ... ในขณะที่
2
ตามที่ออกแบบไว้จะเกี่ยวกับการสร้างรายงานภาษีมูลค่าเพิ่มเพียงจุดประสงค์เดียว
HEADER -> BODY เป็น one-to-many โดยใช้ DocNo เป็น key เพื่อให้ voucher
เดียวสามารถรองรับการมีใบกำกับภาษีหลายๆ ใบได้ ซึ่งการ bundle
เอกสารเข้าเป็นเรื่องเดียวกันอาจจะเกิดกรณีอย่างนี้ได้เสมอ ...
HEAD -> TAIL นี่ก็เป็น one-to-many โดยใช้ DocNo เป็น key เหมือนกัน
เพราะใน voucher 1 ใบจะต้องมี 'คู่บัญชี' 2 items ขึ้นไปเสมอ
สำหรับ itemorder นั้น จริงๆ แล้วมีจุดประสงค์แค่ให้ลำดับของ records
ต่างๆ ในแต่ละ voucher ต้องไม่เพี้ยนไปจากเดิม
คือจะต้องมีลำดับคงที่เสมอไม่ว่าจะเรียกข้อมูลอีกกี่ครั้งก็ตาม
และในขณะเดียวกัน itemorder ก็น่าจะใช้เป็น primary key ของส่วน TAIL ใน
BookID แต่ละรหัสได้ด้วย ตอนที่เขียน table จึงกำหนดไว้อย่างนั้นครับ
> ...
>
> read more >>