会计信息管理系统毕设实战：从业务逻辑到Spring Boot源码实现

1. 会计信息管理系统作为毕设选题：为什么我建议你做这个

先说个真实场景。每年三四月份，我都能在技术群里看到一批被毕业设计折磨的学生：选题太偏没人做过，参考资料少得可怜；选题太泛做着做着发现根本没边界；还有一类更惨，选题做完了但自己的代码根本讲不清楚，到了答辩现场被老师连问三个问题就卡壳。

会计信息管理系统恰好是那种"看上去传统、实际含金量不低、参考资源和源码都比较充足"的毕设方向。它不是蹭区块链、人工智能这种热度，但它的业务逻辑非常明确：凭证录入、账簿登记、报表输出，这些是会计工作的核心链路，放到系统里就是清晰的模块边界。你不需要去编造需求，会计这门学科已经把规则定死了——有借必有贷，借贷必相等。这条准则本身就是天然的校验逻辑，能让你在设计系统时少走很多弯路。

选这个题做毕业设计，另一个隐形优势是面试有故事可讲。财务数字化、业财一体化在企业里是真实存在且持续投入的方向，哪怕你不是去面财务软件开发岗，你在介绍项目时提到"我设计了一个科目余额表的自动汇总逻辑，处理了跨期凭证的结转问题"，这种切切实实的业务落地能力，远比"我写了个增删改查"有说服力。

这篇文章我就把我自己带学生做这套系统时的一些思路、设计取舍、核心代码和踩坑经历完整拆开来讲。适合正在选毕设题目的同学，也适合那些已经选了类似系统、但不知道该怎么把"东西做出来"变成"逻辑讲清楚"的人。内容围绕源码实现来讲——所有代码思路、表结构、接口设计，都是能直接落到你自己的项目里的。

2. 需求不该靠猜：从会计业务规则反推系统模块

很多同学做管理系统容易犯一个毛病：先去画用例图、画ER图，但问起"这个字段为什么必须有""这个流程为什么这样走"，答不上来。这样写到论文里，评审老师一眼就看出来是拼凑的。正确的做法是先理解业务本身，再让技术服务于业务。

2.1 会计工作的核心流程决定了系统的主干

会计日常做的是这么几件事：根据原始凭证填制记账凭证，审核通过后登记总账和明细账，期末做结转，最后输出试算平衡表、资产负债表、利润表。这几件事映射成系统模块，就是：

• 基础数据管理：会计科目、辅助核算项（客户、供应商、部门）、期初余额
• 凭证管理：录入、审核、过账、作废、查询
• 账簿管理：总账、明细账、日记账的查询展示
• 期末处理：结转损益、结账
• 报表管理：科目余额表、试算平衡表、利润表

这么拆分完，系统的边界就非常清楚了。不会出现"我该不该做一个固定资产模块"这种纠结——核心链路之外的功能，毕设阶段一律先砍掉，除非你的题目明确包含。

2.2 借贷记账法是如何变成系统校验规则的

会计里最基础的原则：每一笔分录至少涉及两个科目，借方金额合计必须等于贷方金额合计。这个规则在系统里直接转化为保存凭证时的硬校验。换句话说，你的Service层根本不存在"只录入借没有贷"的可能性。

另外还有一个规则容易被忽略——科目余额方向。资产类科目余额在借方，负债类、权益类科目余额在贷方，损益类科目期末要结转清零。系统在做余额汇总时需要根据科目的余额方向决定是加还是减。如果表设计里没有余额方向这个字段，你后续算资产负债表的期末数时就会很难受，只能靠硬编码匹配科目编码前缀，那种写法后期维护起来想哭。

2.3 用例视角：三种角色就够用了，别贪多

毕业设计的系统权限没必要做成复杂的RBAC权限引擎，一般三种角色足够：

三种角色背后是两层的权限控制：菜单/按钮级别的功能权限（谁能看到什么页面、能点哪个按钮），以及数据范围的控制（比如会计只能看到自己录入的凭证，主管可以看到全部）。后者很多毕设会忽略，但答辩时如果老师问"你的系统怎么防止张三会计篡改李四会计做的账"，这就是一个很好的加分点。

2.4 功能清单阶段性规划

按一个学期的正常节奏，建议把开发分成三个阶段：第一阶段做基础数据和凭证，这是心脏；第二阶段做账簿和报表，这是发动机；第三阶段做系统管理和期末处理，这是配套。千万别一上来就想着把界面做得多花哨，会计系统最重要的是功能闭环——凭证录进去能查到账，账能汇总成表，表能对上数，这一条链子通了，项目就立住了。

3. 技术选型的取舍：不用最潮的，用最稳的

技术栈直接决定你写代码的效率和论文里可以吹的内容。我的建议是：业务系统类的毕设，不要玩花活。

3.1 后端：Spring Boot + MyBatis Plus 是稳妥组合

现在市面上能看到的会计信息管理系统毕设源码，绝大多数基于Spring Boot，这本身就是一种市场筛选。Spring Boot的好处不用多说，自动配置、内嵌Tomcat、生态成熟，遇到问题搜一下几乎都有答案。

ORM层面的选择，有人用JPA，有人用MyBatis，我的建议是MyBatis Plus。理由很实际：会计系统的查询条件特别多，凭证按日期范围、按科目、按摘要模糊查询、按金额区间组合筛选，用MyBatis Plus的LambdaQueryWrapper可以非常流畅地拼条件，不用写大量的XML映射文件。而且它对分页的支持也省事，打印凭证列表这种场景一行代码搞定。

如果你在参考源码时看到基于Spring MVC+JSP的老项目，不是不能用，但有三个现实问题：第一，前端页面和Java代码耦合在一起，改UI就要重启项目；第二，答辩演示时老项目的界面观感差一截；第三，面试时候问"你用过前后端分离吗"，你只能摇头。所以尽量选前后端分离的方案，哪怕Vue你只学了基础，做个登录页加列表页撑住主界面，问题也不大。

3.2 前端：Vue 2还是Vue 3，以及那些UI库

Vue 3确实已经是主流，但Vue 2 + Element UI的存量项目和参考源码更多。如果你是零基础或半吊子水平，我建议直接Vue 3 + Element Plus，别犹豫。原因就一条：现在新写的教程、遇到bug搜到的解决方案，Vue 3的占比已经碾压Vue 2。

页面不用多，六到八个核心页面就够：登录页、系统首页（放点统计卡片）、科目管理页、凭证录入页、凭证列表页（带审核操作）、账簿查询页、报表页、用户管理页。这些页面用Element Plus的表格、表单、日期选择器、对话框组件基本上就能拼出来，不用自己造轮子。

3.3 数据库：MySQL 8.x，表结构和索引要注意

MySQL 8.x相比5.7在窗口函数、通用表达式CTE上做了增强，这对做财务报表类的汇总查询很有帮助（后面讲到报表SQL时会再说）。表结构设计我按五个核心表来拆：科目表、凭证表、凭证明细表、用户表、角色表。它们之间的关系是：一个凭证包含多条明细，每条明细对应一个科目，一个用户拥有一种角色。

期初余额的处理很多人会搞错。我建议单独建一张科目期初余额表，字段包括科目ID、年份、期间、借方期初、贷方期初。这样期末结账的时候，每个期间的期初数是从上一期的期末结转过来的，逻辑会非常清楚。

3.4 为什么不用那些"看起来更高级"的技术

我在某些毕设源码网站上见过给会计系统上微服务、上Redis缓存、上RabbitMQ消息队列的方案，我强烈建议你别学。原因不是这些技术不好，而是你的业务规模撑不起这套架构：一个学校的毕设系统，并发量可能还没你朋友圈点赞量大，引入分布式组件只会增加部署复杂度和你答辩时讲不清的风险。用个Spring Cache或者干脆不加缓存，项目一样跑得飞起。记住一句话：架构是为业务服务的，不是用来凑字数的。

4. 数据库设计：五个核心表加一个关联表，足够了

数据库设计是整个系统的地基。我见过太多毕设源码的数据库表设计得很漂亮，但做出来的系统根本没法用——不是字段缺了，就是冗余得一塌糊涂。下面是我推荐的建表方案，直接可以拿来改。

4.1 科目表和凭证表：核心中的核心

科目表的设计逻辑是这样的：

CREATE TABLE `account_subject` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `subject_code` VARCHAR(20) NOT NULL COMMENT '科目编码，如1001库存现金', `subject_name` VARCHAR(50) NOT NULL COMMENT '科目名称', `parent_id` BIGINT DEFAULT NULL COMMENT '父级科目ID，实现层级', `subject_type` TINYINT NOT NULL COMMENT '1资产 2负债 3权益 4成本 5损益', `balance_direction` TINYINT NOT NULL COMMENT '余额方向 1借方 2贷方', `is_deleted` TINYINT DEFAULT 0, `create_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_subject_code` (`subject_code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会计科目表';

科目编码的设计要遵循会计制度习惯：1001开头的是一级科目，100101是二级科目。很多系统不考虑层级关系，把科目名称做成一个扁平的字符串，等你做上级科目汇总下级科目余额的功能时就会非常痛苦。

凭证主表和明细表是典型的一对多，必须分开建。

CREATE TABLE `voucher` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `voucher_no` VARCHAR(20) NOT NULL COMMENT '凭证号，如记-0001', `voucher_date` DATE NOT NULL COMMENT '凭证日期', `attachment_num` INT DEFAULT 0 COMMENT '附件张数', `status` TINYINT DEFAULT 0 COMMENT '状态 0草稿 1已审核 2已过账 3已作废', `create_by` BIGINT DEFAULT NULL COMMENT '制单人', `create_time` DATETIME DEFAULT NULL, `audit_by` BIGINT DEFAULT NULL COMMENT '审核人', `audit_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_voucher_no` (`voucher_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='记账凭证主表'; CREATE TABLE `voucher_entry` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `voucher_id` BIGINT NOT NULL COMMENT '凭证主表ID', `entry_index` TINYINT NOT NULL COMMENT '分录序号', `subject_id` BIGINT NOT NULL COMMENT '科目ID', `direction` TINYINT NOT NULL COMMENT '方向 1借 2贷', `amount` DECIMAL(15,2) NOT NULL COMMENT '金额', `summary` VARCHAR(200) DEFAULT NULL COMMENT '摘要', PRIMARY KEY (`id`), KEY `idx_voucher_id` (`voucher_id`), KEY `idx_subject_id` (`subject_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='凭证明细表';

这里关键一点：金额字段必须用DECIMAL(15,2)，绝对不能用float或double。这是会计系统的红线，等我在第五章展开讲为什么。

4.2 总账表：用来加速查询的存在

理论上，有了凭证表就能通过SQL实时汇总出任何科目的发生额和余额。但当数据量大了以后——比如一个模拟公司的账套有几千条凭证——实时汇总的查询会越来越慢。所以正规一点的会计软件会有一个总账表，定期从凭证表汇总数据到总账表。

CREATE TABLE `general_ledger` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `subject_id` BIGINT NOT NULL, `period` VARCHAR(7) NOT NULL COMMENT '会计期间，如2025-05', `debit_total` DECIMAL(15,2) DEFAULT 0 COMMENT '本期借方发生额', `credit_total` DECIMAL(15,2) DEFAULT 0 COMMENT '本期贷方发生额', `opening_balance` DECIMAL(15,2) DEFAULT 0 COMMENT '期初余额', `closing_balance` DECIMAL(15,2) DEFAULT 0 COMMENT '期末余额', PRIMARY KEY (`id`), UNIQUE KEY `uk_subject_period` (`subject_id`, `period`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='总账汇总表';

期末结账的时候，程序按期间把所有未过账的凭证汇总进总账表，同时把上期的期末余额转到这期的期初余额。这样做的好处是查询账簿变成纯查表的操作，速度极快。

4.3 用户、角色及一个容易忽略的辅助核算表

用户表和角色表属于常规设计，这里不展开。我要提醒的是一个在答辩时特别加分的点——辅助核算。

现实中企业记账，除了要知道记在哪个科目上，还经常要知道这笔账对应哪个客户、哪个供应商、哪个部门。比如"应收账款——甲公司"和"应收账款——乙公司"，在系统里如果作为两个科目来建，科目表会爆炸。正确的做法是科目表里只有"应收账款"科目，再通过一张辅助核算表记录是哪个客户的：

CREATE TABLE `auxiliary_item` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `entry_id` BIGINT NOT NULL COMMENT '凭证明细ID', `item_type` VARCHAR(20) NOT NULL COMMENT '客商/部门/项目', `item_name` VARCHAR(100) NOT NULL COMMENT '具体名称' );

加了这张表，你可以做一个"应收账款按客户维度汇总"的统计页面，这在答辩演示时是一个很出彩的功能点，而且工作量并不大。

5. 核心功能实现：凭证、过账、报表的代码思路

这一部分直接上可落地的实现思路和代码骨架。每一个环节我都尽量解释这样写的业务理由。

5.1 凭证保存时，事务和校验缺一不可

凭证保存是整个系统里最需要细心处理的接口。我在设计这个Service时，代码的核心逻辑分四步走：

第一，校验明细的借贷平衡；第二，校验每个明细科目ID是否有效；第三，生成凭证单号；第四，主表和明细表一起落库，整个过程必须在一个事务里。

代码如下：

@Service public class VoucherServiceImpl extends ServiceImpl<VoucherMapper, Voucher> { @Autowired private VoucherEntryMapper voucherEntryMapper; @Override @Transactional(rollbackFor = Exception.class) public boolean saveVoucher(VoucherDTO dto) { // 1. 校验借贷平衡 BigDecimal debitSum = dto.getEntries().stream() .filter(e -> e.getDirection() == 1) .map(VoucherEntryDTO::getAmount) .reduce(BigDecimal.ZERO, BigDecimal::add); BigDecimal creditSum = dto.getEntries().stream() .filter(e -> e.getDirection() == 2) .map(VoucherEntryDTO::getAmount) .reduce(BigDecimal.ZERO, BigDecimal::add); if (debitSum.compareTo(creditSum) != 0) { throw new BizException("借方金额与贷方金额不相等"); } // 2. 生成凭证号：日期 + 当日序号 String voucherNo = generateVoucherNo(dto.getVoucherDate()); // 3. 保存主表 Voucher voucher = new Voucher(); BeanUtils.copyProperties(dto, voucher); voucher.setVoucherNo(voucherNo); voucher.setStatus(0); this.save(voucher); // 4. 保存明细表 List<VoucherEntry> entryList = dto.getEntries().stream().map(item -> { VoucherEntry entry = new VoucherEntry(); BeanUtils.copyProperties(item, entry); entry.setVoucherId(voucher.getId()); return entry; }).collect(Collectors.toList()); voucherEntryMapper.insertBatch(entryList); return true; } }

这里要注意@Transactional注解必须加上，而且rollbackFor要指定成Exception.class。Spring默认只在遇到RuntimeException时回滚，如果你在Service里抛了一个自定义的BizException而它没有继承RuntimeException，就会导致凭证主表插入成功、明细表插入失败，数据就脏了。

5.2 凭证编号并发问题：加锁还是用数据库唯一约束

凭证号有一个业务规矩：一个月内凭证号从1开始连续编号，不能跳号、不能重复。实现时有简单的做法和稳妥的做法。

简单的做法是查一下表里当月凭证号最大的那条，然后+1。但这在并发场景下会发生两个请求同时查到同一个"最大号"，生成同一张凭证号。毕设答辩一般不会真的拿并发去压测你，但是老师可能会问"你怎么处理并发"。

我的方案是双保险：程序里用synchronized加JVM锁保证单实例下生成凭证号不冲突，数据库里对voucher_no字段建唯一索引兜底。即使程序锁失效，数据库也会抛出DuplicateKeyException，不会真的插入重复数据。

private synchronized String generateVoucherNo(Date date) { String prefix = new SimpleDateFormat("yyyyMMdd").format(date); // 查询当天最大凭证号 Voucher latest = voucherMapper.selectMaxNoByDate(prefix); int next = latest == null ? 1 : Integer.parseInt(latest.getVoucherNo().substring(9)) + 1; return prefix + "-" + String.format("%04d", next); }

我在实际写源码的时候，很多毕设项目的做法是直接用UUID或者当前时间戳当凭证号，这样确实不用操心并发，但业务上完全说不过去——凭证号是会计凭证的关键标识，无规则乱码编号会让审账的人抓狂。这一点你写到论文里也能体现你真的懂业务。

5.3 过账逻辑：从凭证到总账的汇总算法

过账（也叫记账）是整个系统中最有"会计感"的操作。它把已审核的凭证分录，按科目汇总到general_ledger表对应的期间行里。

实现思路是这样的：

@Transactional(rollbackFor = Exception.class) public void postVouchers(List<Long> voucherIds) { // 1. 锁定凭证，置状态为过账 List<Voucher> vouchers = voucherMapper.selectBatchIds(voucherIds); vouchers.forEach(voucher -> { if (voucher.getStatus() != 1) { throw new BizException("存在非已审核状态的凭证，无法过账"); } // 2. 查询所有明细 List<VoucherEntry> entries = voucherEntryMapper.selectByVoucherId(voucher.getId()); for (VoucherEntry entry : entries) { // 3. 按科目和期间拿到或创建总账行 GeneralLedger gl = generalLedgerMapper.selectBySubjectIdPeriod( entry.getSubjectId(), periodOf(voucher.getVoucherDate())); // 4. 借方发生额累加或贷方发生额累加 if (entry.getDirection() == 1) { gl.setDebitTotal(gl.getDebitTotal().add(entry.getAmount())); } else { gl.setCreditTotal(gl.getCreditTotal().add(entry.getAmount())); } generalLedgerMapper.updateById(gl); } voucher.setStatus(2); voucherMapper.updateById(voucher); }); }

这一步的难点不在代码量，而在"期间"的处理：一张凭证日期是5月28日，那么它应该影响5月的总账，而不能影响4月已经结账的数据。所以过账前需要判断凭证所属期间是否已经结账，如果已结账必须禁止过账。这个判断逻辑要在过账方法的最前面做。

5.4 报表查询：科目余额表与利润表

科目余额表是最能体现SQL功力的地方。它要把所有科目在某个期间内的期初余额、本期发生额、期末余额都查出来。

我用MySQL的窗口函数+CTE来实现，MySQL 8.0以下做不到这么优雅：

WITH period_data AS ( SELECT subject_id, SUM(CASE WHEN direction = 1 THEN amount ELSE 0 END) AS debit_total, SUM(CASE WHEN direction = 2 THEN amount ELSE 0 END) AS credit_total FROM voucher_entry ve JOIN voucher v ON ve.voucher_id = v.id WHERE DATE_FORMAT(v.voucher_date, '%Y-%m') = #{period} AND v.status IN (1, 2) GROUP BY subject_id ) SELECT s.subject_code, s.subject_name, s.balance_direction, COALESCE(gl.opening_balance, 0) AS opening_balance, COALESCE(pd.debit_total, 0) AS debit_total, COALESCE(pd.credit_total, 0) AS credit_total, CASE WHEN s.balance_direction = 1 THEN COALESCE(gl.opening_balance, 0) + COALESCE(pd.debit_total, 0) - COALESCE(pd.credit_total, 0) ELSE COALESCE(gl.opening_balance, 0) + COALESCE(pd.credit_total, 0) - COALESCE(pd.debit_total, 0) END AS closing_balance FROM account_subject s LEFT JOIN general_ledger gl ON s.id = gl.subject_id AND gl.period = #{period} LEFT JOIN period_data pd ON s.id = pd.subject_id ORDER BY s.subject_code;

这段SQL的精华在CASE WHEN s.balance_direction = 1那段——它根据科目的余额方向，自动判断期末余额是借方加发生额还是贷方加发生额。如果不用这个字段，你只能在前端写死判断科目编码前缀，代码会很丑而且不灵活。

利润表的逻辑其实就更简单了：把损益类科目里收入相关的科目余额放在营业收入行，成本费用类科目余额放在成本费用行，最后用"收入减成本费用"得到净利润。难点在于不同行业的报表结构不同，你在毕设里只需要做一个通用的、只包含一级损益科目的利润表即可，不用纠结多级明细科目的归并。

6. 毕设开发中最容易翻车的细节：我踩过的坑，你别再踩

这一章专门聊聊我在实际参考和指导开发过程中见过的各种坑。每一个都真实存在，每一个都可能导致你的毕设演示当场社死。

6.1 金额用浮点型，算着算着多出一分钱

这是会计系统里最经典的低级错误。Java里float和double是二进制浮点数，用它们做加减运算会产生精度丢失。经典案例：

double a = 0.1; double b = 0.2; System.out.println(a + b); // 0.30000000000000004

在凭证分录里有好几条金额，每条金额还有多位小数，用double累加后最终对账差个0.01，排查起来痛不欲生。在会计行业，一分钱对不上都是大事。所以所有金额字段一律使用BigDecimal，数据库层面用DECIMAL(15,2)，Java层面用BigDecimal。你可以在MyBatis Plus的实体类里给每个金额字段都加上类型处理器，确保从数据库读出到Java对象都是BigDecimal。

另外注意，BigDecimal做加法时要用add方法并接收返回值，不能直接改原对象的值。这个细节我在评审同学的代码时经常看到，属于典型的"看似会写其实没真正用过"。

6.2 期初余额不平衡，报表就废了

很多同学做系统时，把期初数据通过SQL直接灌到数据库里，根本不校验借贷平衡。等做到试算平衡表和资产负债表的查询输出时，发现表怎么都对不上，然后开始怀疑自己的SQL写错了。其实问题根源在期初数据就是不平的。

解决方法是建一个期初余额导入/录入页面，录入界面实时显示借方合计和贷方合计的差额。当差额不为零时禁止保存。这是一个很简单的功能，但在答辩时很能体现你对会计业务的理解。

6.3 后端校验形同虚设，只靠前端

我在一些毕设源码里看到过这样的现象：Vue前端做了表单校验（比如必填项检查、金额不能为负），后端Controller完全信任前端传过来的参数直接保存。这样做在开发时确实"顺滑"，但是一旦演示时有人直接调接口，绕过前端传一个负数金额进来，系统就乱了。

正确的做法是后端必须做二次校验，而且不能只校验非空，还要校验业务规则。比如：凭证明细至少要有两条；每条分录必须有科目；金额必须大于0，等等。你的Service层应该第一步就是校验参数，第二步才是业务逻辑，这个顺序不要反。

6.4 凭证改不了、删不掉，历史数据乱成一团

会计系统里凭证不允许"物理删除"，只能"作废"。原因是审计要求留痕——凭证一旦被彻底删除，财务数据的可追溯性就没了。所以在设计凭证模块时，删除操作做的应该是逻辑删除（把状态置为作废），并且在凭证列表里依然能看到作废的凭证，只是画面上有标识。

这个设计在开发初期会让人感觉"增加了不少麻烦"（删除变成改状态，查列表要过滤状态），但这是真实业务的要求。你如果做的是"物理删除，点一下直接没了"，答辩时老师大概率会追问："你这样做符合会计规范吗？"答不上来就尴尬了。

7. 源码之外：论文写作和答辩演示的加分技巧

最后这部分，很多技术攻略不会写，但对毕设来说非常实用——代码写得好不好是基础，能讲清楚才是拿到高分的关键。

7.1 论文的主体结构怎么排

一般计算机毕设论文框架是：绪论 / 相关技术 / 需求分析 / 系统设计 / 系统实现 / 系统测试 / 总结展望。会计信息管理系统的论文，在系统设计一章里建议加入数据库逻辑结构设计，把关键表的字段含义、表间关系讲清楚。在系统实现一章里，不要流水账式地截图，而是按照"功能描述→核心代码→运行效果截图"来组织，每个模块挑一到两个真正有逻辑含量的代码片段来讲，剩下的放在附录里就好。

测试环节不要只写功能测试。"凭证借贷平衡校验""跨月过账限制""权限越权访问拦截"这三类测试用例要单独列出，因为它们是针对系统特点设计的，会让老师觉得你真的考虑了全面性。

7.2 答辩演示的脚本化设计

答辩现场最怕的是临场现找数据、现录凭证。正确的做法是提前准备好一套完整的演示数据，把操作顺序写成脚本，反复演练至少三遍。我推荐的演示顺序是：

1. 登录系统，先展示科目树和期初数据
2. 录一张简单的现金费用凭证，展示借贷自动平衡的校验
3. 录一张包含辅助核算的销售凭证，展示往来明细
4. 审核凭证，过账
5. 查询总账和明细账，展示凭证到账簿的数据流转
6. 生成科目余额表和利润表
7. 演示权限控制：用会计账号登录，看不到"用户管理"菜单

整个流程控制在8到10分钟。关键的是第2步和第6步——前者展示你对业务规则的理解，后者展示你的汇总查询能力。

7.3 演示数据必须是"干净"且"有说服力"的

不要在演示时用张三、李四、测试数据这种名字，也不要录一堆金额相同的凭证。准备一套模拟的真实场景数据：某公司5月份发生了销售、采购、费用报销、差旅借款、工资计提等业务，每个业务都包含完整的分录，合计金额能对上有寓意的数字。当老师问你"这个利润表里的数字怎么来的"，你能指着一路从凭证说到总账再说报表，整条链路无懈可击，这个项目的可信度一下子就上来了。

我个人在带学生的过程中体会到，会计信息管理系统类毕业设计最关键的其实不是代码量有多大、界面有多炫，而是业务逻辑是不是真的闭环了。你让一个没用过会计软件的人做这种系统，会做出单纯的增删改查；你让一个理解"有借必有贷"的人做，做出来的就是有业务灵魂的工具。希望这篇文章能帮你把项目做成后者，在毕业答辩和面试中都能挺直腰板讲出自己的设计。