物联网与ICT有什么关系

1、国内研究现状：目前中科院信息口相关研究所几乎都在开展无线传感网的研究工作。中科院上海微系统与信息技术研究所、中科院声学所、中科院微电子所、中科院半导体所、中科院自动化所、中科院沈阳自动化所、中科院电子锁、中科院上海硅酸盐研究所、中科院软件所、中科院计算所等中科院单位均在从事物联网的研究。国内许多高校也掀起了无线传感网的研究热潮，清华大学、东南大学、中国科技大学、浙江大学、华中科技大学、天津大学、南开大学等高校纷纷开展了有关无线传感器网络方面的研究工作。国内物联网先头单位——中科院工作基础，中国科学院在传感器与微系统、传感网与宽带接入等领域已有长期的工作基础，并在知识创新工程中进行了更大的前瞻性战略布局：1999年，将“无线传感网及其应用”列入知识创新工程重点方向。2001年，成立“中国科学院上海微系统与信息技术研究所”。2001年，成立“中国科学院微系统中心”（非法人事业机构），作为顶层协调机构负责组织全院相应研究所开展微系统和传感网相关的创新工作。全院开展相关工作的研究所有：上海微系统所、声学所、电子所、微电子所、半导体所、计算所、长光所、沈阳自动化所、自动化所、物理所、上海技物所、中国科技大学等十几个单位。 中国科学院、江苏省、无锡市共建“中国物联网研究发展中心”总体目标：形成从研发、系统集成到典型应用示范的创新价值链，成为国家级“感知中国”创新基地。成为中国物联网产业培育中心、集成创新中心和行业应用示范中心，成为中国物联网产业大发展的核心技术引擎。针对“感知中国”战略产业发展过程中的应用瓶颈和技术难点，开展重大技术研究；汇集各方力量和现有成果进行集成创新，推进成果转化和产品孵化；开展应用示范，推动产业发展。 2、美国物联网发展现状：美国很多大学在无线传感器网络方面已开展了大量工作，如加州大学洛杉矶分校的嵌入式网络感知中心实验室、无线集成网络传感器实验室、网络嵌入系统实验室等。另，麻省理工学院从事着极低功耗的无线传感器网络方面的研究；奥本大学也从事了大量关于自组织传感器网络方面的研究，并完成了一些实验系统的研制；宾汉顿大学计算机系统研究实验室在移动自组织网络协议、传感器网络系统的应用层设计等方面做了很多研究工作；州立克利夫兰大学（俄亥俄州）的移动计算实验室在基于IP的移动网络和自组织网络方面结合无线传感器网络技术进行了研究。 除了高校和科研院所之外，国外的各大知名企业也都先后参与开展了无线传感器网络的研究。克尔斯博公司是国际上率先进行无线传感器网络研究的先驱之一，为全球超过2000所高校以及上千家大型公司提供无线传感器解决方案；Crossbow公司与软件巨头微软、传感器设备巨头霍尼韦尔、硬件设备制造商英特尔、网络设备制造巨头、著名高校加州大学伯克利分校等都建立了合作关系。IBM提出的“智慧地球”概念已上升至美国的国家战略。2009年，IBM与美国智库机构向奥巴马政府提出通过信息通信技术（ICT）投资可在短期内创造就业机会，美国政府只要新增300亿美元的ICT投资（包括智能电网、智能医疗、宽带网络三个领域），鼓励物联网技术发展政策主要体现在推动能源、宽带与医疗三大领域开展物联网技术应用。2009年美国振兴经济法案中与ICT相关计划整理见下表所示。②美国ICT相关发展计划1、 欧盟物联网发展现状：2009年，欧盟委员会向欧盟议会、理事会、欧洲经济和社会委员会及地区委员会递交了《欧盟物联网行动计划》，以确保欧洲在建构物联网的过程中起主导作用。行动计划共包括14项内容：管理、隐私及数据保护、“芯片沉默”的权利、潜在危险、关键资源、标准化、研究、公私合作、创新、管理机制、国际对话、环境问题、统计数据和进展监督等。该行动方案，描绘了物联网技术应用的前景，并提出要加强欧盟政府对物联网的管理，其行动方案提出的政策建议主要包括：（1）加强物联网管理。（2）完善隐私和个人数据保护。（3）提高物联网的可信度、接受度、安全性。2009年10月，欧盟委员会以政策文件的形式对外发布了物联网战略，提出要让欧洲在基于互联网的智能基础设施发展上领先全球，除了通过ICT研发计划投资4亿欧元，启动90多个研发项目提高网络智能化水平外，欧盟委员会还将于2011年～2013年间每年新增2亿欧元进一步加强研发力度，同时拿出3亿欧元专款，支持物联网相关公私合作短期项目建设。2、 日本物联网发展现状：自上世纪90年代中期以来，日本政府相继制定了e-Japan、u-Japan、i-Japan等多项国家信息技术发展战略，从大规模开展信息基础设施建设入手，稳步推进，不断拓展和深化信息技术的应用，以此带动本国社会、经济发展。其中，日本的u-Japan、i-Japan战略与当前提出的物联网概念有许多共同之处。2004年，日本信息通信产业的主管机关总务省提出2006至2010年间IT发展任务——u-Japan战略。该战略的理念是以人为本，实现所有人与人、物与物、人与物之间的连接（即4U，Ubiquitous、Universal、User-oriented、Unique），希望在2010年将日本建设成一个“实现随时、随地、任何物体、任何人均可连接的泛在网络社会”。2008年，日本总务省提出将u-Japan政策的重心从之前的单纯关注居民生活品质提升拓展到带动产业及地区发展，即通过各行业、地区与ICT的化融合，进而实现经济增长的目的。具体说就是通过ICT的有效应用，实现产业变革，推动新应用的发展；通过ICT以电子方式联系人与地区社会，促进地方经济发展；有效应用ICT达到生活方式变革，实现无所不在的网络社会环境。2009年7月，日本IT战略本部颁布了日本新一代的信息化战略——“i-Japan”战略，为了让数字信息技术融入每一个角落。首先，将政策目标聚焦在三大公共事业：电子化政府治理、医疗健康信息服务、教育与人才培育。提出到2015年，透过数位技术达到“新的行政改革”，使行政流程简化、效率化、标准化、透明化，同时推动电病历、远程医疗、远程教育等应用的发展。日本政府对企业的重视也毫不逊色。另外，日本企业为了能够在技术上取得突破，对研发同样倾注极大的心血。在日本爱知世博会的日本展厅，呈现的是一个凝聚了机器人、纳米技术、下一代家庭网络和高速列车等众多高科技和新产品的未来景象，支撑这些的是大笔的研发投入。3、 韩国物联网发展现状：韩国也经历了类似日本的发展过程。韩国是目前全球宽带普及率最高的国家，同时它的移动通信、信息家电、数字内容等也居世界前列。面对全球信息产业新一轮“u”化战略的政策动向，韩国制定了u-Korea略。在具体实施过程中，韩国信通部推出IT839战略以具体呼应u-Korea。韩国信通部发布的《数字时代的人本主义：IT839战略》报告指出，无所不在网络社会将是由智能网络、最先进的计算技术，以及其它领先的数字技术基础设施武装而成的技术社会形态。在无所不在的网络社会中，所有人可以在任何地点、任何时刻享受现代信息技术带来的便利。u-Korea意味着信息技术与信息服务的发展不仅要满足于产业和经济的增长，而且在国民生活中将为生活文化带来革命性的进步。由此可见，日、韩两国各自制定并实施的“u”计划都是建立在两国已夯实的信息产硬件基础上的，是完成“e”计划后启动的新一轮国家信息化战略。从“e”到“u”是信息化战略的转移，能够帮助人类实现许多“e”时代无法企及的梦想。继日本提出u-Japan战略后，韩国在2006年确立了u-Korea战略。u-Korea旨在建立无所不在的社会，也就是在民众的生活环境里，布建智能型网络、最新的技术应用等先进的信息基础建设，让民众可以随时随地享有科技智慧服务。其最终目的，除运用IT科技为民众创造食衣住行育乐各方面无所不在的便利生活服务，亦希望扶植IT产业发展新兴应用技术，强化产业优势与国家竞争力。为实现上述目标，u-Korea包括了四项关键基础环境建设以及五大应用领域的研究开发。四项关键基础环境建设是平衡全球领导地位、生态工业建设、现代化社会建设、透明化技术建设，五大应用领域是亲民政府、智慧科技园区、再生经济、安全社会环境、u生活定制化服务。u-Korea主要分为发展期与成熟期两个执行阶段。发展期（2006至2010年）的重点任务是基础环境的建设、技术的应用以及u社会制度的建立；成熟期（2011至2015年）的重点任务为推广u化服务。自1997年起，韩国政府出台了一系列推动国家信息化建设的产业政策。目前，韩国的RFID发展已经从先应用开始全面推广；而USN也进入实验性应用阶段。2009年，韩通信委员会通过了《物联网基础设施构建基本规划》，将物联网市场确定为新增长动力。该规划树立了到2012年“通过构建世界最先进的物联网基础实施，打造未来广播通信融合领域超一流ICT强国”的目标，为实现这一目标，确定了构建物联网基础设施、发展物联网服务、研发物联网技术、营造物联网扩散环境等4大领域、12项详细课题。在世界物联网领域，中国与德国、美国、韩国一起成为国际标准制定的主导国之一。2009年9月，经国家标准化管理委员会批准，全国信息技术标准化技术委员会组建了传感器网络标准工作。标准工作组聚集了科学院、等中国传感网主要的技术研究和应用单位，将积极开展传感网标准制订工作，深度参与国际标准化活动，旨在通过标准化为产业发展奠定坚实技术基础。目前，我国传感网标准体系已形成初步框架，向国际标准化组织提交的多项标准提案被采纳，物联网标准化工作已经取得积极进展

前言

用户系统是很多产品最基础的构成之一，但是越是基础越是开源设计想要完善也更难。在设计用户系统的时候，首先想到的关键词是注册和登录。但并不是有这两者就足够了，更加完善用户系统本身还需要考虑：多平台账号打通，同平台账号之间绑定与解绑，账号安全等及需要怎样的前端设计才是满足这个产品本身定位和用户 *** 作的设计。
用户系统的实现简单来说有两种方式：1、自己构建用户系统；2、用第三方授权。第三方授权获得的用户信息有限且受制于人，而自己构建用户系统研发及用户使用成本均不如第三方授权。所以更多的是两者并存，相互补充。

在定义服务端字段或需求若有不完善和不专业的地方，希望大家多提意见，共同完善。

一、总结需求

1用户系统基本注册／登录功能及前端页面设计

2多平台账号打通，即在单一app注册的用户，能够使用此账号登陆系统内所有app

3用户相对独立，对于单一app来说用户身份唯一

二、前端设计

登陆注册主流设计有三种（原型如下）
1 账号密码优先
账号密码优先是最常见的一种登录注册设计，适用于普遍场景，鼓励用户用注册方式登录，有利于产品引导用户完善更多的资料，留存自己的用户信息。例如知乎是以账号密码登录为最优先，且会隐藏第三方授权登录。现在的账号密码登录都会以用户注册方式代替系统生成的userid作为账号。纯账号密码登录是较为早期的设计，例如早期qq和飞信。

2 手机号快捷登陆优先

手机号快捷登陆，也叫免密登录／短信验证码登录，适用于用户不登录能够完成大部分行为，只有在某种场景下必须获得用户身份时才需要用户登录，且此时用户的想要完成的行为是被要求登录 *** 作打断的。常见的如团购类产品，用户在应用内进行了商品的浏览、筛选、添加到购物车，当要进行最后一步付款 *** 作时，发现未登录。这时繁琐的注册或者登录都有可能导致这笔订单甚至这个用户的流失。所以这时获取用户身份的方式一定要尽可能便捷。

3 第三方授权登陆优先

第三方授权登陆，适用于对用户资料和权限要求不高快速解约开发成本的产品。建议在应用构建用户系统的前期可以首先接入第三方，快速的实现登录功能。但是若想建设自身关系链还是需要完善自己的用户系统。

用户资料实际也属于用户系统等设计的内容。是否要增加此项的判断原则是根据这个产品对用户资料的需求程度决定用户注册时是否要增加资料填写页，资料填写页是强制阻断性的还是可跳过的，必填的资料项有哪些，希望填的有哪些。例如是需要关系链的那么注册的时候就应该强制用户去填写资料设置必要的昵称和头像，这样的用户对于此类应用来说才属于有效用户，不然在app内用户点进资料页，全是系统自动生成的垃圾信息，对于建设关系链和留存伤害较大。

交互细节上又可以延伸用户进行注册或登录需要几个步骤？这些步骤是在一个页面上承载还是一步一个页面以多页面去承载？单一页面承载的优势是用户能够有很清楚的预期，他完成注册需要进行哪些 *** 作，但是劣势是一个页面承载过多信息显得杂乱， *** 作的次序也会不明确；多页面承载的劣势是用户对完成注册的具体行为没有完整预期，更容易跳出，优势是页面整洁并且路径单一，能引导用户完全按照通畅的预设路径进行。我个人更推荐后者，因为用户预期可以用页码／步骤管理用户预期。

下面是我根据我们产品的定位和需求设计的用户登录／注册系统原型：如上所说，我设计的用户系统是需要承载多产品的，所以我设计融合账号密码登录和手机号快捷登录两种方式，以用户出发需要登录的场景去切换展现在用户面前的是哪一种。

补充一些贴心的小点：
1申请读取本机号码权限，并帮用户填写

2申请读写短信权限，获取到验证码后自动填写并点击下一步

3应该前置到提醒：上次登录方式，合法的手机号，正确的图形验证码等等

三、服务端设计

很多产品，特别是没有技术背景的产品不会去接触和设计服务端需求，实际上我自己日常工作中接触服务端需求也并不多，并不是说产品要负责设计一个完善的用户系统服务端，而是要学会以服务端同事能懂的方式表达清楚自己的诉求，两边对功能的实现不会有太多的偏差，这是产品设计服务端目的所在。
简单的用户系统服务端的基本功能需求为：判断账号身份（注册/未注册），账号身份生成（新用户分配id），账号密码验证；这里要设计的并不满足于注册登录，需要考虑多平台账号打通的用户系统并且要和在打通情况下单一平台或多个平台之间，用户的多个账号之间绑定于解绑。现在先说一下多平台账号打通需要考虑哪些问题：

1用户系统身份的创建，因为我们是多平台的系统，所以用户身份只能纳入手机号注册的用户，若第三方授权注册的也算用户系统用户，在账号绑定的那一关则会出现混乱；
2实现多平台账号打通，要实现多平台账号打通，即所有接入多平台都能够查询到此用户身份；

3平台间用户身份独立，要实现平台间用户身份独立，则需要在用户系统用户身份的基础上创建一个平台的用户身份；
(一) 用户系统多平台打通

名词解释
1)Appid：接入用户系统时首先分配，用于区别接入的各个app；

2)Unionid：用户手机注册时，由用户系统根据手机号创建，在用户系统作为用户唯一身份标识；

3)Appuserid：用户注册时，由app服务端根据union或者第三方授权的openid创建，在app内作为用户唯一的身份标识；

基本原则

1)手机号作为用户系统账号的注册的唯一途径，根据手机号在用户系统服务端创建并保存unionid；app服务端根据unionid创建并保存appuserid，且将unionid对应保存；

2)用户系统同一unionid可对应不同的appuserid

3)使用第三方openid授权的注册用户不计入用户系统仅存在app服务端作为单app用户，即unioid为空只生成appuserid；第三方授权包括微博微信，QQ，Facebook，Twitter

1 主线流程图
手机号注册主流程为：

用户注册时，用户系统服务端需要验证手机号＋验证码是否为真，此手机号是否已有对应unionid；若有提示已注册，请登录；若无创建对应unionid，app服务端根据unionid创建appuserid。至此成功生成了用户系统身份及当前app用户身份。

手机号登陆主流程为：

用户登录时，用户系统服务的验证手机号＋密码是否为真，此手机号是否有对应unionid，若有，则说明此用户有用户系统身份。

还需要app服务端需要查询是否有对应的appuserid，若有说明此用户有此app身份，直接用其appuserid登录；若无则说明是用户系统内其他联合app注册用户根据unionid创建此app的用户身份，至此登录成功。

用户系统是大多数app都会有多构成，单一的用户系统也并不那么复杂，但是若要构建产品矩阵进行多平台间的用户打通，加上帐号绑定与解绑，并不是一时半会能够想清楚的需求，若大家感兴趣为会继续补充帐号绑定和账号安全产品应该关心和设计的事情。谢谢：）

你好，
据我所知目前有两个方式：
1微信OAuth网页授权。服务号（订阅号不行）可以在公众号后台开通微信OAuth网页授权，用户在网页中进行授权 *** 作时你会得到用户的openid
2接入服务器。微信允许接入服务器进行开发，配置好接入服务器（参考微信的开发文档）后，用户发给公众号的消息全部会以一个xml表单的形式被转发到你的服务器上。
作者：掰漫
链接：>

通常来讲的话，这个App想修改成已经注册过的手机号是没有任何办法的，因为这个注册的手机号，相当于已经有了一个账号了，是不可能再注册另外一个的。

手机号又称移动电话号msisdn，由11位数字组成，是共同构成移动通信终端设备。无论是GSM系统还是CDMA系统，数字移动电话机用户在“入网”时会得到一张手机卡(SIM卡SubscriberIdentityModule或UIM卡UserIdentity Module)。

手机号段：

中国通信运营商有：移动、联通、电信

中国移动：134(0-8)、135、136、137、138、139、1440（物联网）、147（上网卡）、148（物联网）、150、151、152、157、158、159、165（虚拟运营商）、170(3,5,6)（虚拟运营商）、172、178、182、183、184、187、188、195、197、198。

中国联通：130、131、132、1400（物联网）、145（上网卡）、146（物联网）、155、156、166、167（虚拟运营商）、170(4,7,8,9)（虚拟运营商）、171（虚拟运营商）、175、176、185、186、196。

聚商汇WMS--开源仓库管理系统

项目介绍：

完全开源仓储管理软件，遵循Apache License 20协议，前后端分离，且完全开源，API使用restful协议，方便二次开发，前端代码使用quasar进行构建，后端使用Python Django31，利用API，可以支持多仓，波次发货，合并拣货，Milk-Run等业务模型。

软件著作权编号：2018SR517685

GitHub地址：

GitHubgithubcom/Singosgu/GreaterWMS

Demo地址：

GreaterWMS--Open Source Warehouse Management System>

商务联系：mail@56yhzcom

技术交流：GreaterWMS-01（加微信进群）

项目初衷：

我在供应链行业工作了15年，发现在我们这个专业的领域，没有一款高自由度、高自定义化的软件，来深度支持我们企业的业务。大多数软件都是闭源的，而且很难去做二次开发，即使开发，周期也是非常长，开发失败的案例也是比比皆是。由于企业选择了一款软件后，其二次开发也会被开发公司绑定，至于二次开发费用，只能说呵呵。所以，我设计了这个聚商汇WMS，为的是做到一款高自由度，高自定义开发的仓库管理软件，来深度支持企业的业务。

愿景：如果你从事着非IT行业的工作，而你又热爱你的行业，那就用科技去改变他。

生命周期

V 100 -- 2019年7月 ~ 2020年12月（由于100版本的二次开发设计较为复杂，故20重新编写）

V 200 -- 2020年12月 ~ 2021年3月（重新编写业务逻辑，原生自带API开发文档，加入实时通信，方便企业用户互相沟通）

V 210 -- 2021年3月 ~ 2021年6月（加入了客户与企业之间的实时互动，增进企业与客户之间的业务联系，实现VMI）

V 220 -- 2020年6月 ~ 2021年9月（加入了供应商与企业之间的实时互动，增进企业与供应商之间的业务联系，实现Milk-Run和看板拉动）

V 230 -- 2021年9月 ~ 2021年12月（库存管理雏形，初步加入神经网络，深度学习库存变化）

V 300 -- 2021年12月 ~ 2022年3月（完全植入神经网络，让上下游企业可以以最低的成本运营整体的业务）

V 310 -- 2022年3月 ~ 2022年6月（区域仓库业务布局，通过深度学习，实现多仓运营，成本最低化）

开发环境：

Python 版本为 V 380 +

Django 版本为 V 310 +(该版本Django才原生支持异步实时通信)

Django-rest-framework 版本为 V 3122 + (更高版本的Django-rest-Framework对Django3的兼容比较好)

Django-silk 版本为 V 410 (如果是部署上线，请关闭silk，silk仅为调试API接口速度用，有可能会泄露用户信息)

Quasar 版本为 V172 + (可以查看Quasar官网，来编辑GreaterWMS前端代码：Quasar官网)

Vue 版本为 V 260 +（尽量不要使用Vue3，因为开发环境没有使用Vue3，不知道会出现什么问题）

API，遵循 RESTful 架构

构建命令：

下载代码：

git clone

安装Python库：

pip install -r requirementstxt

注意：安装需要Twisted库，这个库有时候会安装不上，需要下载下来本地安装

下载地址：TWISTED

pip install Twisted{你下载下来的版本名称}

注意：本地安装需要注意路径

初始化数据库：

python managepy makemigrations

迁移数据库：

python managepy migrate

创建数据库，Django默认使用sqlite3作为数据库，如果需要mysql数据库，请在greaterwms/settingspy里面配置DATABASE

开发服务器运行：

开发运行：

daphne -p 8008 greaterwmsasgi:application

生产服务器运行：

supervisor守护进程：

pip install supervisor

使用supervisor来守护Django进程，再使用Nginx做反向代理，至于superevisor的教程有很多，这里不做讲解

Nginx支持：

推荐使用Nginx进行部署，部署的时候需要指定WebSocket链接，如果不指定，实时通信功能将报错

另需要修改axios_requestjs里的ws_url

## 示例更改前
const baseurl = '/'
const wsurl = 'ws://127001:8008/'
## 示例更改后
const baseurl = '://你的域名/'
const wsurl = 'wss://你的域名/websocket/'

如果服务器启用了SSL，请使用>

修改后需要重新build前端代码

开发扩展：

因为使用的前后端分离的设计，所以可以通过API，开发更多的软件应用

物流智能AGV

AGV的项目也已经开源，由于场地受限，仅实现智能发货，定点回库，使用的循迹感应器，超声波避障感应器，红外避障感应器，所有的指令通过网络传输，AGV绑定MAC地址和IP地址，保证了安全性，前提是，你需要有一个树莓派。

进销存

可以直接当一个进销存系统使用，简化仓库库位设置等 *** 作即可。

APP和小程序

Quasar原生可以直接打包成IOS APP和Android APP

小程序的开发可以通过API开做二次开发，但小程序不支持put请求，所以需要自己再写一个请求接口。

API的组合可以达到100万种，这样我们可以根据查询请求，来获得实时报表和数据监控

供应链管理系统

产品的数量，创建时间，最后使用时间是各方面统计的，所以可以方便采购计划和调拨计划进行库存的分析

V 230及其以后的版本，将自带深度学习分析，所以可以直接使用分析结果作为供应链管理系统工具使用

多仓管理

OPENID为用户的数据唯一标识，数据组统一标识为APPID，所以很方便可以实现多仓管理

波次拣货，发货

可以设置固定时间向服务器发出请求，从而达到波次拣货的功能

也可以直接使用任务工作，通过API查询分析结果来实现，推荐使用APScheduler

~~~python pip install apscheduler ~~~

Milk-Run

V 220及其以上版本，将原生支持此功能

如果现在就需要这个业务，可以根据API调用库存消耗，来实现此功能

VMI

V 210及其以上版本，将原生支持此功能

如果现在就需要这个业务，可以根据API调用库存消耗，来实现此功能

拣货路线优化

现在的拣货路线是按照库位排序

V 230以后版本将原生支持此功能

如果现在需要这个业务，可以根据每天的拣货明细，调用API来实现此功能

开发指南：

baseurl

是发起请求的基本网址，如果是本地调试，则默认为>

修改方式为，修改axios_requestjs，注意websocket的修改之前已经提到了

Django-silk

django-silk为开发时的调试工具，可以统计每个接口的响应速度，如果需要部署到生产环境，请删除Django-silk相关配置，因为会有泄露用户信息的风险，或者直接修改Django-silk库，让用户只能看到自己的请求数据

数据库存储

数据库设计时考虑到数据迁移等问题，所以只有users里面的user_id和Django自带的user_id做了外键，其余所有字段全部没有使用外键，方便数据备份和数据库迁移

数据库是4段式设计

验证数据用户归属

验证数据安全性

验证数据是否可以存入数据库

存入数据库，并返回Response

关于数据传输

需要在所有的请求头headers里面加入token值，这个值就是用户的数据唯一标识OPENID

所有的数据传输需要设定content-type为application/json

OPENID

OPENID是注册用户数据的唯一标识，当管理员直接注册时，会有developer=1这个管理员标识。

你可以根据developer标识来做自定义二次开发

APPID

APPID是用户数据组唯一标识

如果需要多公司运营，或者多仓运营，可以通过APPID做统一链接，来实现多公司，多仓 *** 作

用户权限

未对用户权限做过多限制，请根据自身的业务需要，做二次开发限制

业务流程：

管理员

点击注册，可以注册成为管理员账号，从而实现初始化程序设置

注册后会得到2个ID和1个开发者标识，OPENID是用户数据组唯一标识，通过OPENID绑定此OPENID下所有的数据，APPID是用户组数据唯一标识，通过APPID来实现多公司，多仓库功能，Developer标识是个布尔值，True代表这是个管理员账号

用户登入分2种：

使用OPENID和员工名称直接登入

管理员使用账号和密码登入

登入后前端会存储登入信息

可以通过查看我的OPENID来查看用户数据组的OPENID

如果需要多公司，多仓库 *** 作，注意需要更改OPENID

更多管理员权限，请自行开发

员工管理

注册管理员后，新建一个员工

员工有2个字段，Staff_name（用于员工登入），Staff_type（员工类型来控制员工的权限）

系统没有对员工权限做任何限制，如果需要员工权限，请根据企业业务模型，自行修改Templates

点击Edit，可以修改员工信息

点击Delete，可以删除员工信息，系统后台会将Is_delete调成True

点击Contact：

可以直接和员工实时聊天，但是不可以和自己聊天

可以新建一个备忘录员工，这样做其实是当成备忘录使用

在个人中心，可以查看最近的联系人

Message标识会提醒你现在有多少未读消息

司机管理

司机管理只会在发货流程中用到

你需要知道货物是哪个司机提货取走的

仓库设置

Warehouse

仓库的创建只可以创建一个仓库，现在可以创建多个，但是只有第一个会起作用

如果需要多仓处理，可以通过APPID进行二次开发，也可以直接重新创建一个管理员账号

仓库的城市一定要填写，这是用来计算运费的

Bin_Property

库位属性决定了仓库中货物属于什么属性的货物

4种属性：破损（Damage)，锁定（Holding），质检（Inspection），正常（Normal）

Beta版中，属性可以修改和删除，正式版将无法删除和修改

所有的发货，都只会匹配Normal库位的货物

收货上架和移库，都会根据库位属性，直接修改库存数量，仓库的库存数量不会出现负数

Bin_Size

库位的尺寸是帮助 *** 作人员查看货物是否可以放入库位

现行的版本没有对上架和移库尺寸做检查，将来会加入自动检查

Bin_Set

库位设置是必须的，通常库位设置是横纵横纵，比如A010101，即A横01纵01横01纵

库位的设置需要设置库位属性和尺寸，属性很重要，他决定了此库位的货物是否为正常货物

基础设置

Company

公司基本信息的创建只可以创建一个公司，现在可以创建多个，但是只有第一个会起作用

如果需要多公司处理，可以通过APPID进行二次开发，也可以直接重新创建一个管理员账号

公司的城市一定要填写，这是用来显示在收发货单上的

Supplier

供应商的基础信息

供应商的城市一定要填写，这是用来显示在收货单上的，并且也是要自动计算运费的

Customer

客户的基础信息

客户的城市一定要填写，这是用来显示在发货单上的，并且也是要自动计算运费的

商品管理

Unit

商品的单位，系统会初始化创建一些，但可以自己添加和修改

Class

商品的类型，可以自己添加和修改

Color

商品的颜色，系统会初始化创建一些，但可以自己添加和修改

Brand

商品的品牌，可以自己添加和修改

Shape

商品的形状，系统会初始化创建一些，但可以自己添加和修改

Specs

商品的规格，可以自己添加和修改

Origin

商品的产地，可以自己添加和修改

Goods List

商品的列表

固定资产

Capital

固定资产创建，没有做过多拓展，只是记录使用

可以统计托盘账目等

库存管理

Stock List

在库的货物总的库存数据量

Onhand_stock现有的库存数量

Can Order，可以用于下单发货的库存数量，因为有些货物已经被下了订单，虽然有现有库存，但是不可以再被订货

Ordered Stock，已经被下单的货物数量

ASN Stock，已经下了到货通知书，但还没有确认到货通知书的货物数量

DN Stock，已被下单，但是还没有确认订单数量

Pre Load，预计到货货物数量

Pre Sort，已经到货，卸货完成，等待分拣的货物数量

Sorted Stock，货物分拣完成，等待上架的货物数量

Pick Stock，发货单生成了拣货单，等待拣货的货物数量

Picked Stock，已经拣货完成，等待和司机交接的货物数量

Back Order Stock，欠货订单数量

Bin Stock

Total Stock，这个库位该产品的所有库存数量

Pick Stock，这个库位需要拣货的数量

Picked Stock，这个库位拣货完成的数量

Move To Bin， 移库，移库后，会根据库位属性，直接更新库存数量，如果库位全部移空，则该库位会更新为空库位

Empty Bin

空库位明细

Occupied Bin

非空库位明细

收货管理

ASN到货通知书状态

ASN Status = 1, ASN到货通知书创建完成，状态1是唯一可以删除和修改ASN信息的状态，他会显示在Pre Delivery中，即有了到货通知书，但是还没有到货，点击Confirm Delivery，即确认货物已经到达，ASN Status更新到2，此时已经无法再修改ASN信息

ASN Status = 2, 拓展开发为司机到货排队，如果我们有很多司机到货，这可以做成一个排队系统，同时也可以让采购和销售看到到货信息，减少不必要的邮件和电话沟通，点击Finish Loading，即确认货物已经卸货完成，ASN Status更新到3,货物信息会出现在Sorting，此时的ASN状态表示，货物已卸到仓库，等待分拣

ASN Status = 3, 货物分拣是必须的一个流程，没有货物分拣，货物是无法上架的，上架的原则就是货物整理好，摆放到相对应的库位上，点击Confirm Sorted，ASN Status更新到4，即确认分拣完成，等待上架

此时移动Sorted页面，会出现需要上架的货物明细，点击Move To Bin，上架完成，当然，系统会根据上架后的库位属性，自动更新商品库存数量信息

发货管理

DN发货单状态

DN Status = 1, DN发货单创建完成，此时订单还是可以修改状态，且系统中的库存数量不会发生任何改变，点击Confirm Order，DN Status更新到2，即订单已经被确认，且无法更改，同时系统中的货物库存数量会自动更新，比如Can Order数量和Ordered数量

DN Status = 2, 这是订单被确认等待生成拣货单的过程，你可以点击单条订单Order Release来生成一个订单的拣货单，你也可以点击Release All Order，来将所有订单生成拣货单，如果是所有订单Release，那么会根据时间的先后进行库存匹配，库存不足时，会生成Back Order，即欠货订单，在这个过程中，DN单号是会发生改变的，如一家客户的多张订单，会被统一到一张订单中进行拣货，如客户订单无法满足，会将未满足部分生成欠货订单，欠货订单如果仍未得到匹配库存满足，将不再生成新的订单，DN Status会更新到3，即等待拣货的过程，已确认的订单和欠货订单都时Status为2的状态

DN Status = 3, 直接拣货，此功能会出现在Beta5更新中，暂时未更新

DN Status = 4, 发货交接，此功能会出现在Beta6更新中，暂时未更新

DN Status = 5, 客户签收，此功能会出现在Beta7更新中，暂时未更新

DN Status = 6, 对账结束，订单关闭，此功能会出现在Beta7更新中，暂时未更新

退货管理

RO退货订单 此功能将会出现在正式版中

运费管理

Transportation Fee API已经完成，前端暂未更新入口，如果想要使用，可以直接调用Payment下的Transportation Fee API进行使用，运费自动计算模块已经做进收发货流程中

楼上的是机器翻译的，只是分了一下段
IMPACT ON THE INTERNET OF THINGS
关于物联网的冲击
The Internet of Things describes a world where humans are surrounded by machines that communicate with each other and can allow people to interact with the digital world
物联网描述了一个人类被很多机器所包围的世界，通过这些机器，人能够彼此交流或者人与数字世界进行交流
To succeed in this vision, it is not only the people who need an understanding of this multi-device environment, but also the network needs a representation of “who” the user is
为了能够完成这个目标，人们不仅需要理解“多设备环境”，而且还需要明白对于网络来说谁是终端用户
SWIFT provides a solution to this problem by considering the virtual identity as the endpoint of communication,independent of the device
通过把虚拟标识当作独立的设备和通信终端，SWIFT提供了一个解决方案
The direct impact of this concept is that, in a world where humans are
surrounded by machines, it is the user’s virtual identity and digital shadow that is understood as consistent endpoint information;
这个方案最直接的影响就是，在世上人被机器所环绕，用户的虚拟标识和数码影像被理解成一个不变的终端信息
allowing users to interact with several devices, seamlessly, under one name
并允许用户在同一个用户名之下无缝地与各种设备互动，
Users project their virtual identity onto devices in the Internet of Things by an authentication process, a temporary feeble association or a long term relation
在物联网上，通过一个认证进程，用户把虚拟标识投射成临时的或者是长期的设备
The authentication process will allow a user to employ the services any device, public or not, as if it were its own
认证进程可以允许用户使用任意设备提供的服务，不管该设备是公有的还是私有的，不管它是不是自己的。
A temporary volatile type of association is also required for usability purposes
一个临时性的 *** 作也要求有可用性的目的
It is often not possible to perform a strong authentication because of the nature of the device or the context in which it is being used
而且要经常使用一个很强的认证方式是不太可能的，因为使用了自然设备或者明文信息
This type of association, while not as secure and strong as the first, will still allow the user to perform some non-critical operations on that device
这种类型的结构，虽然没有另外一种安全和强健，但是仍然能允许用户在设备上使用不太严格的 *** 作
We also envision a long term kind of association
我们也可以预见长时期类型的结构
This type of relation should be used when the user is the owner of the device and the device is of everyday use
这种关系类型应该在用户是设备的拥有者，并且设备每天都需要使用时才使用
We can think of a watch or phone, which, while not requiring constant authentication, is recognized by other devices as part of the user’s digital shadow
我们可以把它看作成是一个手表或者是一个电话，因为这些设备不需要经常认证，而是被看作为用户的数码影像的设备的一部份

用户识别，通过记录用户自身各类数据，将用户利益关联在其账号下，提供可持续的服务

通过沉淀的用户数据，提供个性化服务，更高效的满足用户需求，提升用户体验

通过沉淀的用户数据，实现精细化运营推广，更低成本获取更多的价值

这类产品/功能需要在建立了账号体系后，才能为用户提供服务。

注重的是账号体系的核心价值。

如：社交类产品，核心是建立人与人之间的连接，且要维持这种连接；连接的建立和维持都是要建立在可以识别用户并记录对应个人数据的前提下。

在这类产品中，构建一个优秀的账号体系是十分关键的。

这类产品/功能在无账号体系的时候也是可以为用户提供服务的。

注重的是账号体系的扩展价值和商业价值。

如：搜索功能，为用户提供的服务的前提是：搜索词、收录的网站数据。并不会因为没有账号体系而影响对用户需求的满足。但如果有了账号体系，我们可以在搜索识别、搜索结果排序、广告推送策略等方面进行优化。

对于大部分的工具类产品来说，账号体系都是一个弱需求。一般会在考虑公司战略、产品发展到一定阶段后逐渐变得越来越重要。

1、移动端具有强烈的个人属性，绝大多数的情况下，一部手机对应着一个用户

2、移动端提供了更多的个人信息，如：位置、手机型号等等

1、在未建立账号体系/用户未登录时，可以通过设备号来区分用户，收集用户数据，以提供个性化服务，来满足企业的商业需求

2、更多的用户信息，可以帮助更好的建立用户画像

随着用户价值得到越来越多的重视，账号体系逐渐成为了一个必备的基础服务，流程也逐渐固化；但我们仍要考虑到需求强弱、设备以及其他因素的影响，进行针对性设计，选择最适合的方案
一、用户身份（UID）

    2、组成：一般为按序生成的数字编码

    3、特点：唯一性、不可更改

    4、作用：是用户的身份标识，类似现实生活中的身份z号码

二、用户名（userName）
    2、组成：系统分配一般由英文字母、数字或2者组合而成

    3、特点：唯一性，一般设置一次后不可更改

    4、作用：账号密码登录时的用户唯一识别标识；

三、用户昵称（nickName）
    2、组成：数字、字母、中文均可；系统生成时可考虑产品定位

    3、特点：可自由设置和改动

    4、应用：用户自定义的昵称可反映其特质，可作为用户对外展示的一个标签

四、用户账号（userAccount）
    2、组成：用户名、手机号、邮箱三种形式

    3、特点：一个集合概念，具有唯一性，并与UID进行唯一性映射

    4、应用：用户的外部标识

五、账号密码（password）
    2、组成：一般为字母、数字组合，此外要考虑特殊字符的限制

    3、特点：目前交易最充分的一种身份标识方式

    4、应用：登录时的安全校验

六、第三方账号（openId）
    2、特点：唯一性，并与UID进行唯一性映射

    3、应用：实现一键注册与一键登录

为用户创建账号，建立用户与系统的联系

1、区分用户，保护用户的私密数据仅自己可见

2、用户登录是将数据与账号进行关联，用户得以 *** 作持续性功能的前提条件

1、出于安全性的考虑，会对用户设置的密码进行一定复杂度的要求，不便于用户记忆

2、随着越来越多应用的出现，用户使用密码的情况越来越多，可能会出现记错、记混的情况

所以出于账号的持续可用的考虑，需要提供忘记密码的功能

由于用户账号中会绑定用户的所有在平台上保留的信息，甚至会有一些资产信息；一旦账号被攻破，会

1、造成用用户信息泄露，甚至会给用户带来资产的损失

2、对企业的形象造成极大不利影响、无法挽回的用户流失

所以一个完整的账号体系，是必须包含风控流程的。

随着用户价值得到越来越多的重视，账号体系逐渐成为了一个必备的基础服务。账号体系成为了产品经理的一个必须掌握的知识点。

接下来，我会从账号体系4个核心流程的角度来进行分析，来逐步加深对账号体系的理解。

由于自身能力有限，难免会有疏漏与不足，欢迎大家给予指正，谢谢~

参考资料：

>