การออกแบบฐานข้อมูลการบันทึกรายการสองครั้ง

ฉันกำลังสร้างซอฟต์แวร์บัญชี ฉันต้องบังคับใช้การบันทึกบัญชีสองครั้ง ฉันมีปัญหาคลาสสิกของหนึ่งแถวต่อการทำธุรกรรมเทียบกับสองแถว

ลองมาเป็นตัวอย่างและดูว่าจะมีการนำไปใช้อย่างไรในทั้งสองสถานการณ์

พิจารณาบัญชีและบัญชีCash Rentเมื่อฉันจ่ายค่าเช่ารายเดือนฉันจะโอน $ 100 จากCashบัญชีของฉันไปยังRentบัญชีของฉัน

หนึ่งแถวต่อธุรกรรม

ในระบบแถวเดียวธุรกรรมดังกล่าวจะถูกจัดเก็บเป็น:

การทำธุรกรรม

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

 id | tx_id | credit_account | debit_account | amount
 1  | 1     | Cash           | Rent          | 100.00

สองแถวต่อธุรกรรม

ในระบบสองแถวฉันจะต้องทำรายการบันทึกเดียวกันเพื่อสร้างระเบียนตรงกันข้ามที่เมื่อฉันสรุปผลรวมทั้งสองฉันจะได้ยอดเงินเป็นศูนย์

การทำธุรกรรม

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

id  | tx_id | type   | account | amount
1   | 1     | credit | Cash    | 100.00
2   | 1     | debit  | Rent    | 100.00

ปัญหา

ก่อนอื่นฉันต้องการทราบ: เหตุผลที่ฉันมีทั้งสองtransactionsและtransaction_recordsตาราง (แทนที่จะเป็นหนึ่งตาราง) คือเพื่อให้สามารถจัดการธุรกรรมแยก (กรณีที่ฉันโอนเงิน $ 100 จากCashบัญชีไปยังบัญชีสองบัญชีหรือมากกว่า)

ตอนแรกฉันพยายามที่จะใช้สิ่งนี้กับหนึ่งแถวต่อการทำธุรกรรม แต่มันเจ็บปวดในการคำนวณยอดเงินในบัญชีและการดึงข้อมูลจริง

ฉันเอนตัวไปยังสถานการณ์ที่สอง อย่างไรก็ตามมีปัญหาบางประการเช่น:

• ฉันจะอัปเดตระเบียนเดียวได้อย่างไร สมมติว่าฉันทำผิดและแทนที่จะบันทึก 100 ดอลลาร์สำหรับค่าเช่าของฉันฉันได้บันทึก $ 10 ตอนนี้ฉันมี 2 transaction_records- หนึ่งสำหรับเครดิตและอีกหนึ่งสำหรับเดบิตทั้งสองมีจำนวน $ 10
• ตอนนี้ฉันจะคืนดีและฉันต้องการแก้ไขพิมพ์ผิดนี้ ฉันจะแก้ไขปัญหานี้ในฐานข้อมูลได้อย่างไร ฉันไม่ทราบการเชื่อมต่อระหว่างบันทึกและในกรณีที่มีการแยกธุรกรรมหนึ่งรายการอาจมีมากกว่า 2 รายการ ทางออกเดียวที่ฉันมาด้วยคือการเพิ่มบางref_idสำหรับแต่ละคู่ระเบียนที่ไม่ซ้ำกันจะระบุระเบียนเหล่านั้นเป็น "ด้านตรงข้ามของกันและกัน" tx_idในบริบทของการที่เฉพาะเจาะจงได้

วิธีใดดีกว่า / ง่ายกว่า?

หากต้องการทำให้คำถามของฉันง่ายขึ้น: ฉันต้องการแสดงการเคลื่อนไหวของเงินทุนจากบัญชี A ไปยังบัญชี B สถานการณ์สมมติทั้งสองที่ฉันได้รับนั้นเป็นทั้งการออกแบบที่ถูกต้องในการจัดเก็บธุรกรรมดังกล่าว ขณะที่ฉันยังชี้ให้เห็นว่าพวกเขาทั้งสองมีข้อเสีย & ข้อดี (อันแรก: ง่ายกว่าที่จะบันทึกและยากที่จะเรียกคืน; อันที่สองตรงกันข้าม)

พวกเขาอาจมีข้อดี / ข้อเสียอื่น ๆ ที่ฉันไม่ได้เห็นในตอนนี้ดังนั้นฉันจึงขอความเห็นจากคนที่มีประสบการณ์มากกว่า

อันที่จริงแถวบัญชีเค้าร่างเดียวที่เสนอนั้นอนุญาตให้ทำบัญชีสองรายการที่เหมาะสม (เพื่อระบุบัญชีที่เดบิตและเครดิตเสมอ) โดยไม่ต้องแนะนำการซ้ำซ้อนของข้อมูล "จำนวน"

Schema แถวเดียวให้คุณสามารถนำรายการสองรายการที่มียอดคงเหลือมาใช้ในการก่อสร้างดังนั้นจึงเป็นไปไม่ได้ที่จะไม่มี "ยอดคงเหลือหลวม" เครื่องอาจคำนวณบัญชีแยกประเภทได้ทันที

คุณต้องเลือก 2 อย่างแทนที่จะเลือกหนึ่งตัวเพื่อดึงบัญชีแยกประเภท

หมายเหตุนอกเหนือจากการแบ่งธุรกรรมมีธุรกรรมอื่น ๆ เช่นการแลกเปลี่ยนเงินตราต่างประเทศอาจจบลงด้วย 2 ระเบียนแทน 4 มันทั้งหมดขึ้นอยู่กับว่าคุณจะทำให้เป็นปกติเล็กน้อยเพียงแค่ป้อน 4 การทำธุรกรรมที่มีคำอธิบายที่คล้ายกัน

คุณอาจป้องกันไม่ให้รายการหรือดัดแปลงของธุรกรรมใด ๆ เพื่อรักษาหลักฐานการตรวจสอบนี้เป็นสิ่งจำเป็นหากคุณต้องการที่จะสามารถตรวจสอบบันทึกการทำธุรกรรม

ปรากฏว่าในหัวข้อด้านบนสำหรับ CPA นั้น "ปกติอย่างสมบูรณ์" ดูเหมือนจะหมายถึงกฎที่นักบัญชีทุกคนรู้จักแต่ทว่าโปรแกรมเมอร์มีความหมายที่แตกต่างกันว่าไม่มีการจัดเก็บข้อมูลที่ซ้ำซ้อนหรือซ้ำซ้อน

ทั้งหมดที่มีในข้อมูลการบัญชีคือชุดของธุรกรรมที่ให้จำนวนเงินและบัญชีที่มีการไหลของข้อมูลพร้อมกับวันที่คำอธิบายบางอย่าง (และเอกสารแนบอื่น ๆ ) บัญชีแยกประเภทและยอดคงเหลือเป็นมุมมองง่ายๆที่ได้จากข้อมูลธุรกรรมโดยทำผลรวม

วารสารเป็นรายชื่อตามลำดับของการทำธุรกรรมทุกประเภทที่ระบุไว้สำหรับระบบบัญชี นี่คือการนำเสนอแบบคลาสสิกบนกระดาษบัญชีแยกประเภทของวารสารการขาย (ในบัญชี) แบบง่าย:

โปรดทราบว่าทุกบรรทัดเป็นธุรกรรมเดียวที่มียอดรวมเดบิต = ยอดรวมเครดิต; และทุกการทำธุรกรรมจะมีบัญชีเดียวกันสามบัญชี ขายรายวันเงินสดจะมีลักษณะคล้ายกัน แต่แทนที่คอลัมน์บัญชีลูกหนี้เดบิตกับคนที่มีป้ายกำกับเดบิต เงินสดเบิกเงินวารสารจะมีคอลัมน์แรกที่มีป้ายกำกับเครดิตเงินสดและคอลัมน์เพิ่มเติมเช่นบัญชีเจ้าหนี้เดบิตและค่าใช้จ่ายพนักงานเดบิต

งานนำเสนอนี้เป็นมาตรฐานสำหรับหลายร้อยปีจนกระทั่งคอมพิวเตอร์ส่วนบุคคลมีราคาไม่แพงเมื่อสองสามทศวรรษที่ผ่านมา มีข้อได้เปรียบที่สำคัญในการตรวจสอบได้อย่างง่ายดายว่าทุกธุรกรรมมีความสมดุลโดยเพียงตรวจสอบแต่ละแถว ในทำนองเดียวกันก่อนที่จะโพสต์หน้าของการทำธุรกรรมดังกล่าวไปยังบัญชีแยกประเภทรวมหน้าสามารถตรวจสอบในทำนองเดียวกัน นั่นคือรูปแบบการประมวลผลแบบแบทช์ที่ใช้ในระบบบัญชีหลายระบบ

มันง่ายที่จะเห็นว่าแบบจำลองกระดาษนี้มีข้อเสียอย่างมีนัยสำคัญเมื่อคัดลอกไปที่ระบบอัตโนมัติ:

1. โครงสร้างข้อมูลเป็นสิ่งสำคัญในขณะที่ประสบการณ์ได้แสดงให้เห็นว่ามันง่ายกว่ามาก (เช่นมีความทนทานและตรวจสอบได้ง่ายกว่า) เพื่อตั้งโปรแกรมกับโครงสร้างข้อมูลแบบพับ และ
2. เนื่องจากสมุดรายวันเฉพาะทุกชุดมีบัญชีแตกต่างกันวารสารแต่ละฉบับจะต้องได้รับการออกแบบและตั้งโปรแกรมแยกต่างหากกิจกรรมที่สิ้นเปลืองและผิดพลาดได้ง่าย

ด้วยเหตุผลเหล่านี้จึงแนะนำให้ใช้การออกแบบSpecialized Journalsเป็นส่วนต่อประสานกับระบบบัญชี แต่เพื่อออกแบบโครงสร้างข้อมูลที่สามารถเป็นที่เก็บตัวเลขสำหรับวารสารหลายเล่ม ใน RDBMS ที่ทันสมัยนี้มีข้อได้เปรียบที่เป็นไปได้ที่บัญชีแยกประเภททั่วไปและแม้กระทั่งบัญชีแยกประเภทย่อยพิเศษสามารถกลายเป็นมุมมองที่จัดทำดัชนีในวารสารขจัดความต้องการในการรหัสกระบวนการโพสต์ (ขั้นตอนที่ธุรกรรมในวารสารถูกล็อค ยอดรวมที่คัดลอกไปยังบัญชีแยกประเภทต่างๆ)

ไม่ว่าคุณจะออกแบบข้อมูลด้วยอะไรก็ตามที่สำคัญคือการมีการผ่านรายการเดียวสำหรับแต่ละประเภทธุรกรรม (เช่นวารสารเฉพาะแต่ละฉบับในระบบกระดาษเทียบเท่า) ที่มีการตรวจสอบยอดคงเหลือ

ประเด็นของฉันคือทั้งสองแนวทางที่คุณเสนอนั้นเป็นกลไกที่ไม่ปลอดภัยสำหรับการทำบัญชีสองทาง จุดแรก: วารสารเป็นตารางการเขียนครั้งเดียวด้วยเหตุผลที่ดีมาก บางครั้งตารางเสมือนทั้งสองรายการที่รอดำเนินการและรายการที่โพสต์จะถูกจัดวางในโครงสร้างข้อมูลเดียว แต่บิตIsPostedเป็นแบบเขียนอย่างเดียวเสมอและระบบต้องมั่นใจว่ามีการเก็บรักษาลักษณะการอ่านอย่างเดียวของบันทึกรายการที่ลงรายการแล้ว

นักบัญชีวิธีที่ได้โพสต์คอมเมนต์วารสารสำหรับที่ผ่านมา 800 ปีเป็นปกติอย่างเต็มที่ ข้อแตกต่างเพียงอย่างเดียวระหว่างการนำเสนอกระดาษและงานนำเสนอทางอิเล็กทรอนิกส์คือโครงสร้างของโต๊ะพับนั้นสะดวกกว่าในกรณีหลังขณะที่โครงสร้างตารางหมุนได้ในอดีตซึ่งในอดีตมีความสำคัญมากที่สุดเมื่อต้องการประมวลผลแบบขนานสูง - เช่นพนักงานหลายคน การบำรุงรักษาวารสารเฉพาะทางจำนวนหนึ่งหรือน้อย เฉพาะผู้ควบคุมในอดีตเท่านั้นที่มีสิทธิ์สำหรับวารสารทั่วไป

โปรดทราบว่าในข้างต้นฉันระบุว่ารายการวารสารได้รับการทำให้เป็นมาตรฐาน รายการบันทึกรายวันเป็นบันทึกตามลำดับเวลาของการทำธุรกรรมทั้งหมดจัดกลุ่มในวารสารเฉพาะสำหรับแต่ละประเภทธุรกรรม การโพสต์ของรายการบันทึกไปยังบัญชีแยกประเภทเป็นความพยายามที่แยกต่างหากและในขณะที่ปกติอย่างเต็มที่ในตัวของมันเองเป็นสำเนาซ้ำซ้อนของรายการวารสารที่การทำธุรกรรมทั้งหมดจะสรุป (บัญชีแยกประเภททั่วไป) หรือรายละเอียด (Sub บัญชีแยกประเภท) โดยบัญชี ทั้งวารสารและบัญชีแยกประเภทจ้างทำบัญชีสองครั้งอย่างอิสระ

@Codism ใดระบบบัญชี, DEB หรือ SEB ให้คุณ Generalized รายงานสำหรับบัญชีทั้งหมดที่บันทึกไว้ โปรดทราบว่าภายในบัญชีแยกประเภทย่อยคือโดยการกำหนดบันทึกการทำบัญชีรายการเดียว; อีกด้านหนึ่งเป็นบัญชีควบคุมที่เกี่ยวข้องในงบดุล DEB เพื่อให้แน่ใจว่าทุกดอลลาร์สินทรัพย์ที่มีการบันทึกที่ถูกต้องของการเรียกร้องทางธุรกิจของสินทรัพย์คือส่วนได้เสียในสินทรัพย์ไม่ว่าจะเป็นส่วนของหนี้ (aka รับผิด) หรือส่วนของเจ้าของและความสำคัญของการเรียกร้องเหล่านั้นถ้าที่ องค์กรกลายเป็นหนี้สินล้นพ้นตัว

ฉันขอแนะนำให้คุณดูขุมสมบัติของซอฟต์แวร์โอเพ่นซอร์สที่มีอยู่ในพื้นที่นี้หรือไม่?

Google ของ " ซอฟต์แวร์บัญชีโอเพ่นซอร์สสองรายการ " มอบโอกาสในการตรวจสอบที่หลากหลาย

คุณสามารถดูแพ็คเกจการบัญชีของ GNU ได้ที่นี่ไซต์ตรวจสอบสองชุด ( 1 & 2 ) และสุดท้ายคือวิกิซอฟต์แวร์บัญชีที่มีหัวข้อเกี่ยวกับซอฟต์แวร์เสรี

ฉันแน่ใจว่าโดยการตรวจสอบซอร์สโค้ดและสกีมา F / LOSS บางส่วนคุณอาจได้รับคำแนะนำและข้อบ่งชี้ที่ดีเกี่ยวกับวิธีการเขียนสกีมาและ / หรือซอฟต์แวร์ที่เหมาะสมกับความต้องการเฉพาะของคุณ

ฉันมีระบบที่ทำสองบรรทัดและความท้าทายมากกว่าการมีบัญชีแบบบรรทัดเดียว ครั้งแรกที่ฉันพบอินสแตนซ์ของบรรทัดเดียวเท่านั้นที่ถูกผลักเหมือนกับด้านเดบิตส่งผลให้บัญชีไม่สมดุล แม้ว่าฉันจะไม่ได้ทำการควบคุมการยอมรับและการย้อนกลับอย่างเหมาะสม แต่สิ่งนี้จะไม่เกิดขึ้นในบัญชีบรรทัดเดียว สุดท้ายฐานข้อมูลของคุณจะเพิ่มขึ้นเป็นสองเท่าอัตราการส่งบรรทัดที่สองของคุณจะมีข้อมูลที่ซ้ำกันมากมายความแตกต่างเพียงอย่างเดียวคือบัญชีที่สอง จะแนะนำให้รักษาบัญชีบรรทัดเดียวกำลังจะไปเส้นทางที่ ..