实现传统农业企业的信息管理系统， 也就是产销存系统 具体文档， 当结束后补充。
python==3.6
linux==Ubuntu16.04LTS
package==requirment.txt
mysql >= 5.7
假设你已经创建好python3的虚拟环境， 或者使用pycharm创建了虚拟环境， 或者你头铁使用default的环境
source ./venv/bin/activate # 如果使用了虚拟环境， 先切换
pip install -r requirements.txt
python manage.py runserver runserver 127.0.0.1:8000 # 或者sudo sh ./start.sh体验地址 账户:guest 密码:qwerasdf
本次为时两周的实验。小组根据要求开发了一个农业企业的产销存系统。
需求大体上分为两点
- 快捷财务
- 节约物资
- 管理公司事务
- 财务
- 物资出入库
- 基本信息管理
- 统计报表
- 批发中心
- 管理顾客
- 蔬菜的销售管理
- 蔬菜的库存管理（出入库）
- 生产基地
- 组织生产， 指导种植， 物资管理
- 需要有生产基地的品种、 产量等信息
- 提供报表来指导生产，决策支持系统
- 组织生产， 指导种植， 物资管理
很明显， 这个企业想通过信息化， 将传统的农产品生产、物资的发放、 财务使用信息系统来管理和维护， 达到节约成本、提高效率、优化决策的目的。
- 产销存
思考一下这个公司的需求， 虽然整个公司分为了， 公司、生产基地 、 代购点、批发中心、 四个子系统， 但实际上由于整个公司各个系统的业务都包括了产销存三个方面， 所以其实按照业务来设计系统（而不是机构）更加地简洁方便。减少冗余。
- 机构隔离
然后在权限设计的时候， 把各个机构点隔离开来。
- 统计报表
针对销售和收购生成统计报表， 在整个系统的业务流程完成后， 再针对销售和收购两个业务加上统计报表的模块
- 导入导出和备份。
设置导入导出模块 和 全局备份
-
查询筛选模块
还好xadmin有自带的queryset模型以及一系列的查询筛选组件， 不然为每一张表加上一个专属的原生sql语句真的会死人的。
根据业务来设计系统， 就设计到我这个系统的四个模块
-
公司基本信息
包括各种单位， 公司维护的顾客、 农户、 产品、 物资、 机构， 等静态信息
-
生产
生产指的是生产计划， 从需求来看， 一直从公司->生产基地->代购点->农户->具体生产计划
是一个树状结构 ，跟公司组织的结构类似， 需要一级一级地将任务细分
-
物资库存发放
-
产品库存销售
上面两个模块是一致的， 只不过业务的终点前者是发放到农户， 后者是销售给顾客，
所以再设计的时候， 可以直接编写共同的模块。
以上、 生产是一个树状结构， 也是一种一对多的关系。
然后公司的基本信息里的实体， 也都是其他模块的外键，
最后到物资库存和产品库存， 产品库存和物资库存都是， 产品\物资 和 机构之间的多对多联系。
， 然后出入库、 盘存 都是与库存的一个多对一联系。
数据库表设计
根据E-R图， 来编写django的model即可。注意好E-R图里的外键关系即可。
其实就是界面设计啊。 因为我用了xadmin， 所以不用考虑这个问题了。
其实就是编码的设计， 竟然叫代码设计， 真的很无语啊。
编码就很简单， 有要求的按照要求来， 没要求的根据中文缩写加上有前导0的流水号
('%05d' % self.id)来自动生成编码。
其实这个系统没有做上面流程设计，(因为现在已经实现的功能在后台管理系统的整个流程上非常简单) 主要是在查询库存以及填写出入库单， 销售单。开始还准备添加采购单、 以及订单的模块， 来丰富流程， 但是由于时间原因没有继续完善。
业务逻辑完成、 报表模块完成
导入导出excel、 数据库备份
系统布置在自己再阿里云上使用学生身份 购买的优惠服务器，
首先把项目所依赖的包导出到requirement.txt， 然后编写简单的运行服务脚本， 再使用git部署到github的远程仓库中。
然后登录阿里云服务器，clone github上的项目， 安装python3 mysql 以及相应的依赖包。
最后运行start.sh脚本就完成了服务器配置， 当然生产环境中最好使用nginx 以及 uswig 配合来作为web服务器。
开始设计公司信息表格。 白天的任务， 完成公司表格的设计（包括简单的用户管理设置）
表格需求
上午
基本信息
- 产品
- 物资
- 农户
- 顾客
部门信息
- 机构
- 生产基地
- 代购点
- 批发中心
产销存业务
- 生产计划
- 产品库存管理
- 物资库存管理
系统信息
- 用户管理
- 权限管理
下午
阅读django的字段文档。
上午
一直再思考如何用django 的 model 来实现实时库存的查询。
2种实现
- 基于数据库的触发器处理， 维护实时库存
- 基于前台的逻辑处理， 不维护库存， 而是实时计算查询库存
第一种触发器说实话不会
第二种的话写起来很方便，只要重载model或者modeladmin 里的save函数即可
想了很久， 最后完成了构思。
首先建立一个库存（仓库）模型。 库存跟入库单、出库单、 盘存单是一个一对多的关系。
一个仓库维护属于他的入库单、 出库单、盘存单（销售)。
然后仓库显示的字段是一个计算库存的函数就行了。同时还能支持一个时期内的库存变化查询
下午
完成了盘存的编写， 参考了一个开源项目Django-ERP的业务设计， 同时看到了刘江的django实践项目，学会了
- 关联对象的访问， 实现库存的查询
- save_model的重写。 实现一些默认字段的添加， 比如操作人员， 操作时间等日志。
晚上
刘江的教程非常不错啊， 比复杂的官方文档简洁明了多了。
发现自己不知道python的装饰器是干嘛的。 所以去补习了一下， 简单来说就是给一个函数， 或者一个类， 套一个马甲， 马甲上可以写一些诸如验证、 日志的操作， 非常的方便， 适用于函数的复用。
上午
睡觉了
下午
-
完成产品库存
-
添加采购单和物资入库单之间的一对一联系。
-
添加生产计划和入库单之间的一对一联系。
-
一对一联系， 实现填写出库单，联系的生产计划状态变为运输中， 填写入库单， 联系的生产计划变为完成。
-
完成销售和顾客之间的联系
-
其他人， 完成代码的注释， 和代码设计的编写。
晚上
重构了一下公司的机构， 像把他分成独立的部门， 不过后来放弃了， 因为重构后虽然能独立的管理、方便实现逻辑， 但是其他代码写起来就更加冗余了，
接着完成了下午的任务， 使用了时间筛选插件， 修改了后台样式
玩了一天的雪
睡觉、和地下室的朋友们在外面玩了一晚上
主要还是休息和
转入学习xadmin。
全天
- 将所有admin后台代码迁移到xadmin上，xadmin是中间发现的一个开源的后台框架， 使用了bootstrap3的ui， 重写了admin的template。 更加得符合我们开发的需求
- 编写筛选器和权限、思考如何写统计报表功能，
- 初步自己测试系统， 修改bug， 和重构系统的运行流程和整理文件结构。
上午
- 完成基于机构的， 职员权限的编写， 配合django自带的权限控制。
- 完善筛选报表的任务
下午
- 组织组员完成了大部分功能的测试
- 修改代码的bug
- 修改系统逻辑上的bug
晚上
- 查看所有TODO， 删除已经完成的， 保留可以改进的。
- 编写服务器配置以及布置方案，并将项目开源到github上， 然后从服务器上clone项目， 并且使用命令行部署。
上午
- 再测试了一些bug
- 添加了一些测试数据用以展示报表图
下午
-
瞎写了两个小的按钮， 使用mysqldump完成数据库简单备份和还原
-
验收
-
虽然整个系统不会允许删除用户， 只允许标记员工为解雇状态， 因为删除用户后， 会级联删除所有的操作。 但是再点击删除用户表的时候， 会抛出保护异常并且没有做异常处理。
-
没有做系统的使用文档， 系统的很多功能被安全控制了， 但是并没有很好地限制用户进行某些非安全操作，（比如出入库单的一对一选择， 如果一个出入库单意境完成配对， 那么员工就不应该能够查询到这些完成了的记录） 虽然这种操作在底层被限制了。 所以如果用户不熟悉系统， 很容易产生一些无法完成正常操作的情况。
-
没有进一步完成财务流程的设计
财务流的报表由于自己无法单独完成需求的分析和设计， 所以也无法开发出来
-
没有产品的追溯设计， 我思考过如果要完成产品的追溯， 那么就需要添加一个产品实例表， 即一个产品对象类，需要有产品实例， 这样一个仓库的库存不再是维护一个产品的数量了， 而是该产品库存的所有的对象实例。
这样库存的转移， 就要变成， 产品实例之间的转移， 而不仅仅是数量的转移。
这样就跟我系统中的生产计划设计模式（详细的看apps/product/models.py)很像， 写报告的事后思考了一下， 确实可以这样联系起来，当时开发的时候没有这样想（这确实也是没有做好需求设计的坏处） 希望能有学弟学妹们完成吧。
作为一个兼职开发人员
也想过自己造轮子， 甚至再第二次实验小作业的时候也造了一些导入导出、备份还原、浏览、筛选、增删改的轮子。 但是真的时间有限， 并且只有我一个人造轮子，造出来的残次品的概率很高，再所以还是放弃了， 乖乖地使用xadmin的后台框架， clone一下， 看源码写一些插件。完成需求就好了。
阅读xadmin源码的过程中发现，设计者在用设计的时候留了挺多基于后端的插件接口， 很多插件plugin也是通过后端来添加的。
但是现在web的流行趋势是前后端分离，xadmin的原作者也抛弃了django的这种模板系统， 不再更新xadmin的纯后端版本了。
所以初步了解了一下前后端分离， 真的是一个很好的模式， 不仅逻辑清楚， 还易于开发人员分工和专精。 后端提供数据获取的api， 前端去提取就行了。 实际使用应该还涉及网络信息的验证和加密吧。 总之这种设计模式很清晰啊。
就算是一个人包揽前后端的开发， 这种设计模式也能很舒服的开发， 相比与传统的开发方式。
还有一个重要的问题就是如何处理并发， 和高并发的时候服务器的负载均衡（真是书到用时方恨少）
要开始认真复习， 把基础补牢固了先 。 这种面向搜索引擎的开发真得很折磨人。效率低下、收获也少得可怜。(复制粘贴快捷键都要按坏了)
以MVP思维，解析最小可行的进销存产品 | 人人都是产品经理
xadmin
vue.js
nginx
django
github