全部栏目

首页 热点资讯 义务教育 高等教育 出国留学 考研考公

有没有一款记录借还款的账本？

发布网友 发布时间：2022-04-22 19:47

我来回答

共5个回答

热心网友 时间：2023-10-26 18:24

经常会忘记向或被朋友借了多少钱？次数太多，金额零散真的记不起来啊！用晨曦记账本不仅可以记录开销和收入，还可以记录借还款呢！请看如下步骤分析。

工具/原料

热心网友 时间：2023-10-26 18:24

借钱次数太多，金额零散真的记不起来，那么通过晨曦记账本，它不仅能记录收支，还可记录借还款

热心网友 时间：2023-10-26 18:25

应该有的，！！！！！！

热心网友 时间：2023-10-26 18:25

个人做一个账单还款记账的产品好实现吗？我们可以尝试一下。每个人都可以当一次产品经理，借此实战，和大家分享一下产品实现的一些方*。
1. 前言
现在我们基本上大多数人每个月都有各种需要还款的账单，要么是房贷，要么是信用卡。对于我自己，信用卡也比较多，每个月要还房贷，还信用卡，为了防止漏还，还专门做了一个Excel进行记录。之前和几个朋友吃饭聊天，发现有朋友也在用Excel记录每个月的还款。
像我这样的用Excel记录每月还款，应该也有不少。使用Excel记录，在PC上操作比较方便，显示屏幕大，信息显示直观，操作比较方便。不过在移动端上操作，就不是很便捷。心里就想，要不要自己也做一个在移动端使用的账单还款助手。可以方便大家在移动端记录每个月账单的还款，防止漏还款逾期造成的逾期风险。市面上有这种功能的产品有很多，都是好几个团队协作完成的。
个人做一个账单还款记账的产品好实现吗？我们可以尝试一下。每个人都可以当一次产品经理，借此实战，和大家分享一下产品实现的一些方*。
2. BRD之竞品分析
我们都知道，产品经理涉及的三大产品文档，分别是BRD（Business Requirement Document，商业需求文档）、MRD（Market Requirement Document，市场需求文档）和PRD（Proct Requirement Document，产品需求文档）。
一般而言，BRD是基于商业目标或价值所描述的产品需求内容文档。类似于我们软件工程中所提到的可行性分析。你计划设计的产品在投入研发之前，为企业高层提供决策评估的依据。如果大家要做创业计划书，BRD也是很重要的一个部分，一般会涉及市场分析，销售策略，盈利预测。BRD通常是供决策层们讨论的演示文档，一般比较短小精炼，没有太多的产品细节。说的直白一点，就是这款产品值不值的做。
产品经理在进行产品设计前，最重要的就是进行竞品分析。通过竞品分析，你可以更清晰的理解自己产品的价值主张，对方的产品优势与劣势有哪些，自己将要做的产品同竞品的差异点有哪些？自己产品的定位与卖点。用户或是消费者，使用我们的产品而不使用竞品的理由是什么？
如果我们分析完成，自己都说服不了自己，那产品也就没有再继续设计下去的必要。俗语说，知己知彼，百战不殆。如果产品经理没有去做产品调研，竞品分析，投入了很多时间和金钱，结果产品投向了市场才发现没用户，那就为时已晚。
我们选取市面上比较主流产品的账单还款产品。分别是银联云闪付中的信用卡功能、支付宝中的信用卡功能和业界主打信用卡账单管理的“51信用卡管家”。
2.1 银联云闪付-信用卡还款
银联云闪付中的“信用卡还款”是银联云闪付中比较重要的一个功能。依托银联本身的优势，银行也为银联提供了各种数据API，银联可以把绑定的各家银行信用卡的账单日、最后还款日、账单金额、最小还款金额，实时为用户展示。这是银联信用卡还款产品的一大特点。
还信用卡免手续费，用户在还款时不会有额外支付其他费用的顾虑，由于是实时到账，给用户的还款体验不错。添加信用卡的功能也比较方便，提供了OCR（Optical Character Recognition，光学字符识别）支持，免去了用户添加信用卡输入卡号的繁琐。
另外，还提供了在线申卡的功能，可以很方便申请各家银行的信用卡，为各家银行导流。银行为银联提供API（Application Programming Interface，应用程序接口），银联帮助银行获客，也算是互惠互利，合作共赢。银联信用卡还款产品定位明确，信用卡账单显示与还款整个流程非常流畅，但缺少对非信用卡还款的支持，比如消费贷款、房贷、交房租等账单的记账还款功能。
2.2 支付宝-信用卡还款
支付宝也为用户提供了信用卡还款产品。可以将用户绑定在支付宝的信用卡在信用卡还款列表中进行展示。但部分银行不提供账单应还金额的实时查询功能，在信用卡实时查询的范围上，不如银联云闪付所覆盖的银行全面。
对于信用卡的还款，需要自行设置还款时间。而且还信用卡需要支付一定的费用，也没有标明实时到账，只是提示“预计今天到账”，和银联相比在到账时效上，缺少些自信。不知道对于信用卡还款有多少用户愿意为此付费。
支付宝信用卡还款产品提供了“添加还款类型”功能，不仅可以添加信用卡，也可以添加房贷、车贷、房租的还款信息，这点比较人性化。为用户提供了更多的记账类别，便于用户查看自己不同的还款项目，这个很不错。
2.3 51信用卡管家
51信用卡算是在互联网行业主打以信用卡还款产品为核心的企业了。支持用户添加信用卡账单和生活账单，统计比较全面。账单汇总功能，可以查看名下各账单的还款情况，并为用户提供了信用卡消费分析。为客户提供了除账单管理的额外增值服务。对于51信用卡而言，其Slogan是“让有信用的人过得更好”，可见信用卡账单管理对用户来说功能是免费的，不是51信用卡营收的直接来源，但通过引流，最终通过发放贷款进行赚钱。
不过，对于用户而言，核心诉求还是想记账，其他功能，例如提供还款功能，是加分项。用户还款，也不是实时到账，产品提示是“预计1h到账，次日入账”，对于还款手续费，当月只有6000元的还款额度，超出额度，要额外支付0.2%的手续费。对于经常还大额的用户来说，可能更倾向于选择免手续费的还款方式。
由于51信用卡缺少同银行API对接，无法为用户提供实时的账单信息查询，只能通过用户提供自己接收账单的邮件账号，51信用卡通过读取用户邮箱中的银行账单，提取信用卡账单还款数据。也算是一种折衷的办法。但对于我自己而言，我是不希望把自己邮件的用户名和密码提供给第三方机构，让其读取我邮件中的内容。感觉有一些安全上的顾虑。
2.4 小结
结合以上分析，我整理了一个功能表格，如下所示。
可以看出，虽然仅是账单还款这么一个小功能，各家产品也有各家产品的基因。不同用户可以根据自己需要选择产品。而像我这一类的客户，不愿意提供邮件账号密码给第三方，又希望支持其他账单有还款记录，也不在意对方提供不提供实时还款的功能，就是希望有一个单纯的记账和查看功能。
产品更加轻量简洁一些，只想要记账这个核心功能，相当于要给这些产品做减法。目前上有这样单纯的产品吗？还没有，都是流量入口，大家都希望提供更多的功能来增强用户粘性。而有像我这样就想单纯的记账用户吗？应该也有。
3. MRD之产品设计
MRD可以通俗地理解为准备做某一款产品，市场层面打算想做成什么样的说明，其作用是承上启下。
一方面，对BRD中领导层的的意见和公司战略方向进行整合，提炼核心功能与核心价值，另一下面，对即将编写的PRD，为其明确产品范围、功能定义，防止产品设计与最初的目标不一致的情况出现，可以理解为MRD是一个指导性的框架说明文档。
有些公司前中后台产品经理分工比较细，也可以理解为是我们常遇到的一句话需求。比如业务产品经理直接和技术产品经理说，我要实现一个业绩查看的功能，可以查看、导出某个时间范围内的团队业绩。接下来技术产品经理会根据业务产品的这句话，编写PRD。说的直白一点，就是这款产品打算怎么做。
3.1 产品定位
如果我也想做一款像银联、支付宝、51信用卡功能这么齐全的账单管理产品，即便是技术可行性和经济可行性，都具备，还不具备时间可行性。账单管理产品，在这几家公司都是几个团队配合，至少投入十几个人的人力和资源才开发出来的。
而由于其用户群体的广泛性，需要围绕账单还款这个核心功能扩展出很多衍生功能。而现实中，即便是使用了这些功能的用户，仍然也在使用Excel记录自己的账单还款情况。而我的还款产品的定位，就是希望能为使用Excel记账的用户，提供移动便捷的记账功能。
3.2 产品框架设计
将产品功能做减法后，仅保留几个必要功能。
用户相关模块，用户注册和登录是必不可少的。由于产品设计的初衷是尽量不收集用户信息，因此用户注册中，仅需要输入用户名和密码即可，对于自愿的用户，可以提供电子邮箱地址，认证通过后的用户，可以用来使用密码找回功能。
账单还理模块，用户可以自行新建账单月份，在月份中录入还款项名称，账单日，最后还款日，账单金额 和已还金额，系统会自动计算剩余应还金额。月份列表，会汇总当月所有还款项的账单总金额，已还总金额和剩余应还总金额，方便用户直观查看自己的还款情况。
考虑到用户新增月份后，每个月都要新增还款项比较繁琐，为用户提供了还款项智能模版功能，用户新增月份后，不需要再录入还款项，会自动将上个月的已经录入完成了还款项名称带入，用户只需要填写本月的账单金额即可。
还款趋势分析是一个额外的附加功能，便于用户直观查看每个月总的账单情况和还款情况。
3.3 产品流程设计
既然我们的产品是定位一款极简的还款记账产品，我们就要先明确核心流程。对于产品流程设计，我们可以采用自底向上或是自顶向下的设计方法。自底向上，就是我们先明确最基础的功能流程，将一个个基础功能流程整合起来，形成最终总流程，向顶向下的设计方法，则是先明确总流程，然后再将总流程中涉及的每个子流程进行细化。
我们这款产品采用自顶向下的流程设计方法，经过分析，我们这款产品流程设计如下所示。
用户注册登录、用户信息管理、密码修改、邮箱管理这些产品的基础功能太基础了，就不在这里特别介绍了。接下来主要介绍还款记账的核心功能。在准备做这款产品前，我自己觉得非常简单，但在实现的过程中却发现有很多值得考虑的细节。在这里分享给大家。
4. PRD之产品功能设计
PRD就是将产品理念进行落地的文档，主要面向团队开发人员，设计（UI、UE）、测试、运营等，需要更加详细的去阐述所有功能。就产品流程而言，其实PRD也不是产品的最终文档，还可以继续分拆为需求说明书、设计说明书、测试说明说、运营说明书等。PRD中主要会描述详细的功能说明和业务流程。说的直白一点，就是这款产品如何落地推向市场面向用户。
4.1 产品主页面
产品功能设计采用产品MVP（Minimum Viable Proct，最小可行性产品）理念，先满足核心功能。用户希望有一辆车解决出行痛点，我们就先造一辆车让用户先开起来，至于里面有没有空调，座椅是不是真皮，暂时不重要。
本次的产品功能设计也是如此，为了方便用户直观体验产品功能，用户不需要注册，就可以先体验。因为好的产品不应该绑架用户。有些产品设计，用户不注册，就不让用户体验产品是不对的。
主页中，突出了“开始记账”的按钮，方便用户可以第一时间找到记账入口。如果用户还没有登录，则会先为用户展示登录页面。用户登录完成，进入到每月的还款汇总列表页面。
4.2 还款月汇总页面
还款项都是以每个月份进行承载，所以我们的视图设计，也是基本还款记账月份列表进行展示。用户查看自己的还款账单，一般都是看这个月份总共需要还多少钱，已经还了多少钱，还剩下多少钱未还。
按照流程设计，用户从列表页面可以查看月还款项细节，不过首次使用的用户，在新增完成记账月份之后，不能第一时间知道从哪开始新增还款项。因此细节上，在每个月还款的卡片上，将”查看”，改为记账。
4.3 还款项新增与编辑
用户选择记账年和记账月份，点击 “新增记账月份”会为用户新增一条记账月份卡片。
用户点击月份卡片中的“查看”，会为用户显示月份下的还款项明细信息，用户也可以进行还款项的新增、编辑、删除操作。
新增完成记账项后，会实时显示新增的还款项卡片。为了用户方便了解还款项数量，在每个还款项名称前进行自动编号。同时，为了便于用户关注自己的还款情况，将剩余还款金大于0的金额标红。考虑到删除是个相对比较谨慎，因此功能放置在编辑的下一级，而没有同编辑平级。
4.4 安全设计
而每次我们修改每一还款项的还款金额时，当月的总还款情况都需要同步更新，这就需要在产品设计的内部，定义一个触发器，以确保各数据都可以实时更新。以确保数据准确。
防注入设计，因为我们在使用ID录入还款项时，要对传入的ID进行认证，对于不合法的ID要进行过滤。否则会有注入风险。后续如果为了保证数据传输安全，还可以通过配置权威机构认证的数字证书，采用https的方式进行数据传输。
5. 总结
最后，我们通过KANO 模型进行我们产品的功能分析，看看我们是否遗漏优先级比较高的功能。KANO 模型原本是用于对用户需求进行分类和优先排序的工具，通过分析用户需求对用户满意的影响，从而了解产品性能和用户满意之间的关系。
很明显，优先级比较高的几个核心功能，都已经实现了。接下来就是我们要考虑如何能给用户提供能令用户“尖叫”的功能了。因为我们这款产品为用户提供的还款记账基础功能，只是解决了用户还款记账的痛点，如果想要用户体验更好，我们还要做一些锦上添花的功能，满足用户的爽点，同时借助于口碑，进一步为其他用户群体提供痒点。但不论怎样，我们都要围绕我们产品的定位，一款极简的还款记账工具。
这样一个基本的账单记账小助手的产品就完成了。当然产品细节还有需要打磨的空间，比如一些操作过程中的异常处理和提示。整个流程是不是还有进一步提升用户体验的空间。既然是谈到实战， 就要看实际的效果。
其实使用MVP理念，可以先用最小成本将产品投入市场，根据用户和市场反应，不断升级迭代。这样用户的学习成本也相对较低。这次的产品采用H5和PC自适应技术，用户通过手机浏览或是PC浏览，会自行适配。接下来，可以进一步开发账单记账小助手的小程序版本和APP版本。
有温度的产品源于有温度的员工和企业文化。做为产品经理，我们首先站在用户的角度去看待问题，规划产品。希望我们彼此，都能做有温度的人，设计有温度的产品。
作者：王佳亮，中国计算机学会（CCF）会员。
本文原创@王佳亮 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议

热心网友 时间：2023-10-26 18:26

跨年*也能报销！但必须这样处理！否则后果由会计自己承担！
一、借贷记账法概述
1、复式记账法，是指对于每一笔经济业务，都必须用相等的金额在两个或两个以上相互联系的账户中进行登记，全面、系统地反应会计要素增减变化的一种记账方法。
2、复式记账法分为借贷记账法、增减记账法、收付记账法等。
3、我国会计准则规定，企业、行政单位和事业单位会计核算采用借贷记账法记账。
4、借贷记账法，是以“借”和“贷”作为记账符号的一种复式记账法。
5、通常情况下，资产类、成本类和费用类账户的增加用“借”表示，减少用“贷”表示;负债类、所有者权益类和收入类账户的增加用“贷”表示，减少用“借”表示。
二、借贷记账法的记账规则
1、记账规则是指采用某种记账方法登记具体经济业务时应当遵循的规律。
2、借贷记账法的记账规则是“有借必有贷，借贷必相等”
三、借贷记账法的会计科目结构
1、资产类会计科目的结构资产类科目的结构为:科目的借方记录资产的增加额，贷方记录资产的减少额。资产类科目期末如有余额，一般应该在借方。
资产类会计科目期末余额=期初余额+本期借方发生额-本期贷方发生额
特殊资产类科目:贷增借减，如:累计折旧、存货跌价准备、累计摊销等。
2、负债及所有者权益类会计科目的结构“资产=负债+所有者权益”这个会计等式，决定了负债及所有者权益类科目的结构与资产类科目的结构正好相反，其贷方登记负债及所有者权益的增加额，借方登记负债及所有者权益的减少额。同样，负债及所有者权益的余额，一般应为贷方余额。
负债及所有者权益类会计科目期末余额=期初余额+本期贷方发生额-本期借方发生额
3、成本类会计科目的结构成本类会计科目的结构与资产类会计科目的结构一致，其内部关系也相同。即成本类会计科目的借方登记成本的增加额，贷方登记成本的减少额，期末若有余额，应在借方。
4、损益类会计科目的结构
(1)收入类会计科目的结构
借方
贷方
本期减少发生额或转销额
本期增加发生额
借方
贷方
本期减少发生额或转销额
本期增加发生额
本期借方发生额合计
本期贷方发生额合计
(2)费用类会计科目的结构
借方
借方
本期增加发生额
本期减少发生额或转销额
本期借方发生额合计
本期贷方发生额合计
年末损益类科目期末应结转到“本年利润”科目，期末没有余额。
四、借贷记账法下的账户对应关系与会计分录
账户对应关系，是指采用借贷记账法对每笔交易或事项进行记录时，相关账户之间形成的应借、应贷的相互关系。存在对应关系的账户称为对应账户。
会计分录，简称分录，是对每项经济业务列示应借、应贷的账户名称(科目)及其金额的一种记录。会计分录由应借应贷方向、相互对应的科目及其金额三个要素构成。会计分录分为简单会计分录和复合会计分录。
(1)简单会计分录指只涉及一个账户借方和另一个账户贷方的会计分录，即一借一贷的会计分录。
(2)复合会计分录指由两个以上(不含两个)对应账户组成的会计分录，即一借多贷、多借一贷或多借多贷的会计分录。
五、借贷记账法的试算平衡
1、试算平衡的含义
试算平衡是以会计恒等式和借贷记账规则为理论基础，根据资产与权益之间的平衡关系，按照记账规则的要求，通过对所有会计科目记录的汇总和计算，来检查各类会计科目的记录是否正确的一种方法。
平衡关系主要包括三个方面:
(1)全部会计科目的借方期初余额合计数=全部会计科目的贷方期初余额合计数;
(2)全部会计科目的本期借方发生额合计数=全部会计科目的本期贷方发生额合计数;
(3)全部会计科目的借方期末余额合计数=全部会计科目的贷方期末余额合计数。
2、试算平衡的分类
试算平衡分为发生额试算平衡法与余额试算平衡法。
(1)发生额试算平衡法。全部会计科目本期借方发生额合计=全部会计科目本期贷方发生额合计。
(2)余额试算平衡法。根据余额时间的不同，余额试算平衡又分为期初余额平衡和期末余额平衡两类。
公式分别为:全部会计科目的借方期初余额合计=全部会计科目的贷方期初余额合计全部会计科目的借方期末余额合计=全部会计科目的贷方期末余额合计实务中，余额试算平衡是通过编制试算平衡表来完成的。

声明声明：本网页内容为用户发布，旨在传播知识，不代表本网认同其观点，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。E-MAIL:11247931@qq.com