CN111626702A - 基于条目式的记事记账计数计件项目管理方法 - Google Patents

基于条目式的记事记账计数计件项目管理方法 Download PDF

Info

Publication number
CN111626702A
CN111626702A CN202010445149.6A CN202010445149A CN111626702A CN 111626702 A CN111626702 A CN 111626702A CN 202010445149 A CN202010445149 A CN 202010445149A CN 111626702 A CN111626702 A CN 111626702A
Authority
CN
China
Prior art keywords
item
items
project
members
entry
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010445149.6A
Other languages
English (en)
Inventor
廖大超
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to CN202010445149.6A priority Critical patent/CN111626702A/zh
Publication of CN111626702A publication Critical patent/CN111626702A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • G06Q10/103Workflow collaboration or project management

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明提供一种基于条目式的记事记账计数计件项目管理方法,包括如下步骤:对项目、项目成员、项目标签进行定义;对具有独特属性的、可评论、可投票、具备日志的条目进行定义;对数据格式、整理方式、录入要素、呈现格式、记账计数方法、统计方法进行定义;结合所述数据格式、整理方式、录入要素、呈现格式、记账计数方法、统计方法进行计数、记账及计件的操作。该方法可以实现单人或多人,基于项目进行共同记事、记帐、计数,并能实现核对、检索、追溯、统计和互动,并可以完成管理审核、团队投票、财务报销、营销跟进、客户管理、客户服务等功能。

Description

基于条目式的记事记账计数计件项目管理方法
技术领域
本发明具体涉及一种基于条目式的记事记账计数计件项目管理方法。
背景技术
人们日常生活工作中经常会需要对生活事件、工作事件进行管理记录,但使用专业系统显得过于繁琐,同时系统布置、人员学习均有较高的门槛;如使用很随性的纸笔碎片、大脑记忆或使用社交软件、电话等工具辅助记忆,又会错漏频出,在发生问题时纠纷较多,可见现有的方式全都显得力不从心。综上所述,本发明提出一种基于条目式的记事记账计数计件项目管理方法,可以系统化进行记事、记账、计数等日常生活及工作中常用的记录问题及管理问题,同时本方法在实现完整功能的前提下删繁就简,在使用功能完全满足需求的同时降低了使用门槛及学习成本。
发明内容
本发明的目的在于针对现有技术的不足,提供一种基于条目式的记事记账计数计件项目管理方法,该基于条目式的记事记账计数计件项目管理方法可以很好地解决上述问题。
为达到上述要求,本发明采取的技术方案是:提供一种基于条目式的记事记账计数计件项目管理方法,该基于条目式的记事记账计数计件项目管理方法包括如下步骤:
对项目、项目成员、项目标签进行定义;
对具有独特属性的、可评论、可投票、具备日志的条目进行定义;
对数据格式、整理方式、录入要素、呈现格式、记账计数方法、统计方法进行定义;
结合所述数据格式、整理方式、录入要素、呈现格式、记账计数方法、统计方法进行计数、记账及计件的操作。
该基于条目式的记事记账计数计件项目管理方法具有的优点如下:
(1)团队使用价值:对于工作团队而言可以用此软件,简易且高效率的完成:1、团队需要的账务录入、核对、统计;2、团队管理所需要的信息分发、共享、审核;3、团队营销所需要的客户跟进、信息共享、和客户服务工作;4、团队生产中的工人计件录入和统计。而且本方法不限团队组织形式,可以是公司、单位、个体户和雇员、也可以是一个家庭、几个好友、旅游团、协会、销售与客户,一支球队等。
(2)个人使用价值:对于个人用户而言从用户的角度看,除了可以用本软件完成个人记事记帐计数以外,该用户还可以加入更多项目,通过在不同项目中的活动,可以通过一个软件,同时完成在生活层面、家庭层面、工作层面、业余爱好层面等多种场景下信息管理和交互:如与他人协同记事、记账、计数和核对、统计、投票、客户和供应商管理、客户服务等工作。
(3)成本和效率价值:本方案定义的逻辑和方法,在数据的一致性、及时性、可追溯性、可统计性、安全性方面也有较高程度的实现。记账方法和数据展现,更接近没有接受过专业财务和管理培训的普通百姓的日常思维方式,可大幅降低团体团队在记账、记事、计数、计件、项目管理、客户服务方面的时间成本、学习成本,以及管理成本。可以为社会活动中的多人合作、合伙项目提供显著效益。
(4)减少纠纷和内耗的价值:数据具有很好的的一致性,及时性、及可追溯性,可大幅减少人员合作纠纷。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,在这些附图中使用相同的参考标号来表示相同或相似的部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1示意性地示出了根据本申请一个实施例的基于条目式的记事记账计数计件项目管理方法的流程示意图。
图2示意性地示出了根据本申请一个实施例的基于条目式的记事记账计数计件项目管理方法的条目必备的基础属性的示意图。
图3示意性地示出了根据本申请一个实施例的基于条目式的记事记账计数计件项目管理方法的统计结果模板的示意图。
图4示意性地示出了根据本申请一个实施例的基于条目式的记事记账计数计件项目管理方法的统计结果模板的示意图。
图5示意性地示出了根据本申请一个实施例的基于条目式的记事记账计数计件项目管理方法的统计结果模板的示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,以下结合附图及具体实施例,对本申请作进一步地详细说明。
在以下描述中,对“一个实施例”、“实施例”、“一个示例”、“示例”等等的引用表明如此描述的实施例或示例可以包括特定特征、结构、特性、性质、元素或限度,但并非每个实施例或示例都必然包括特定特征、结构、特性、性质、元素或限度。另外,重复使用短语“根据本申请的一个实施例”虽然有可能是指代相同实施例,但并非必然指代相同的实施例。
为简单起见,以下描述中省略了本领域技术人员公知的某些技术特征。
根据本申请的一个实施例,提供一种基于条目式的记事记账计数计件项目管理方法,包括对项目、项目成员、项目标签进行定义;
对具有独特属性的、可评论、可投票、具备日志的条目进行定义;
对数据格式、整理方式、录入要素、呈现格式、记账计数方法、统计方法进行定义;
结合所述数据格式、整理方式、录入要素、呈现格式、记账计数方法、统计方法进行计数、记账及计件的操作。
根据本申请的一个实施例,下面对该基于条目式的记事记账计数计件项目管理方法的具体实现方式及各名词定义进行系统化介绍说明:
一、项目:
1. 项目内部结构:方法规定:项目下有以下属性或数据,分别见后续描述:1、项目成员;2、项目条目;3、项目标签;4、子项目(内部结构与父项目一致,从而实现多级项目嵌套);5、项目单位;6、成员权限配置;7、可有其他常规属性,并可适当扩展,非方法核心内容:项目简介、项目权限等。
2. 项目建立:用户可以新建项目,并自定义项目名称,并自动成为该项目首个管理员。也可以加入别人的项目,并成为别的项目的成员。
3. 加入项目:管理员可以向项目中添加其他成员。一个用户可以同时加入多个项目。
4. 项目可以销毁:所有的项目管理员,一致同意销毁项目后,项目的所有数据被清空。成员解散。
5. 项目可以停用:停用后的项目,只能查看,不能添加数据。
6. 子项目:项目下可以建立子项目。
(1)父子项目的管理员强制一致:任命为父项目的管理员,也自动成为所有子项目的管理员。卸任父项目管理员,也自动卸任所有子项目管理员。
(2)父子项目的成员是可以不一致的:如果只是父项目成员,而不是子项目的成员,则看不到子项目的内容。反之,只是子项目的成员,也看不到父项目的内容。
(3)父项目的标签,可以被子项目使用。但子项目的标签,不能被父项目使用。
二、项目成员:
1、一个项目下,可有一至多个项目成员(简称成员)。
2、按成员与项目关系,可分为内成员、外成员:
(1)内成员:项目内部人员、合伙人、员工、以及项目的科目、账户、仓库等,应被加为内成员。
(2)外成员:项目客户、供应商、临时人员、以及其他外部业务往来方、或业务逻辑上属于外部户头、账户等,应被加为外成员。
(3)按成员是否关联真实注册用户划分,可分为真实用户成员、虚拟成员:
(4)真实用户成员:也就是该成员与系统某一注册用户关联。
(5)虚拟成员:该成员不与系统真实注册用户关联。甚至可以仅是有一个名字。这样,项目的成员将允许添加银行帐户、未在本系统注册的、不知名的收支方、以及任何虚拟的记帐计数科目、户头、仓库等,都允许被添加为项目虚拟成员。
方法规定:若项目成员填写了联系方式,则系统会扫描用户数据库,若与某注册用户的联系方式一致,则该成员会自动被标记为真实成员。反之,该项目成员没有联系方式,或联系方式不与任何已注册用户一致,则该成员是虚拟成员。
方法规定:位于不同项目的成员,依据联系电话,按以下规则判定此两成员,在现实生活中的是否指同一人(或同一对象等):
(1)如果联系电话一致,本方法则判定该两成员是同一个人:例如:A项目某成员联系电话为888,B项目某成员联系电话也为888,不论他们在各项目中的名称是否一致,系统都会认为此两成员在现实生活中是同一个人。
(2)如果联系电话都未填写,即使其成员名完全相同,则认为这两个虚拟成员是不同的人:例如父项目有成员“张三”,其联系电话为空,子项目也有成员“张三”,其联系电话也为空,则系统认为父项目的“张三”和子项目的“张三”并不是同一人。
(3)成员的联系电话可填可不填,若填写,同一项目下(子项目也视为不同项目),不允许任两个成员的电话完全相同,若添加相同电话的成员,会提示该成员电话在此项目已经存在。
(4)这些判定规则会在某些筛选或统计中体现出来。在父子项目体系中这一点尤为重要。例如:父项目有一成员叫“公司账户”,子项目也有一成员叫“公司账户”,如果要让系统判定父项目的“公司账户”和子项目的“公司账户”是同一帐户,则唯一的办法,都指定一个相同的电话号码,比如都随意指定一个但二者必须相同的电话为“222”。
3、按成员是否可以参与该项目活动划分,可分为互动成员、非互动成员。
(1)互动成员:项目只可以与真实用户成员建立互动状态。互动后,该成员关联的用户,登录后可以看到此项目中他有权限查看的内容,也可以在权限范围内,参与该项目的记事记账等各项活动。
(2)非互动成员:与互动成员相对应,没有建立互动的成员为非互动状态。所有虚拟成员只能是非互动成员。没建立互动状态的真实用户成员,也是非互动成员。非互动成员,只是作为该项目记账、计数可供选择的甲乙丙方(收支方)、统计中发生往来业务的角色而存在。非互动成员若是真实成员,他所关联的用户,不能感知项目中的任何内容,甚至连项目名也看不到。一切都是项目方单方面的。
4、按成员的权限分:成员分为管理员、普通成员:
(1)管理员:管理员有权对项目进行管理。只有同时是内成员、互动成员,才有可能成员管理员。
(2)普通成员:与管理员对应,其他不是管理员的成员,即为普通成员。
管理员的任命和卸任:
(1)用户新建项目,自动成为该项目的首任管理员。
(2)本方法规定:项目可有多个管理员,现任管理员可以将其他互动的、真实的、内成员提升为管理员。这也是除新建项目自动产生首任管理员外,成为管理员的唯一办法。
(3)解除管理员的唯一办法是由管理员自己点击卸任功能,卸任后转为普通互动内成员。在实际生产生活中,应是其他管理员与该管理员协商同意后,由该管理员自行卸任。如果该管理员是项目唯一管理员,则禁止卸任。
(4)项目多个管理员的权限是平等的。一些合伙项目,可共同担任管理员,以确保数据不被一方左右。项目内的重大事务,多个管理员可实行表决制,全部同意则通过。有任一方不同意则维持现状。如项目销毁,条目删除。
(5)方法规定:父项目的管理员的任命或卸任,同时也自动成为或卸任子项目管理员,即子项目和管理员与父项目的管理员是强一致的,且是自动的。
5、按成员时效状态:分为正常成员、历史成员:
有权限的成员,可以删除项目中别的普通成员。删除成员时,只能转为历史成员。历史成员的存在的意义是让项目之前涉及到该成员的条目不会受到影响。也让项目客户资料不会受到实质丢失。但新增条目将不能再涉及该历史成员。有权限的成员,也可以将历史成员恢复为正常成员。新录入条目时,历史成员将不能再被选择。
6、成员属性:最重要最基础的属性就是所属项目、项目内名称、联系电话。
(1)所属项目:标记该成员属于哪个项目。该项不能空缺。
(2)项目内名称:可以与用户昵称一致。也可以不一致。该项不能空缺。
(3)联系电话:建立互动时,系统依据电话搜索注册用户登记的联系电话。在不同项目中的成员,如果其联系电话相同,则系统判定这两个成员在现实生活中的同一个人(或账户等)。电话不同,就一定不是现实生活中的同一个人或账户。电话留空则认定此成员与所有项目的所有成员都不是现实生活中的同一个人(即使项目内名称相同也不算),统计或筛选时,会体现上述依据电话而产生的判定规则。
(4)还有其他一些必要的属性:如成员介绍,成员标签,成员加入时间等,也可以扩展更多属性。
7、各类成员的权限:
管理员的权限:管理员具有普通互动内成员的所有权限。另还具有项目的管理权限如下:(1)改项目名、改项目简介、增删改项目内标签、增删成员,修改成员类型和属性,让项目与成员建立或断开互动、停用项目、发起销毁项目或参与销毁项目表决、修改项目内所有条目内容或属性、发起删除条目或参与条目删除表决、作废或取消作废项目内所有条目、管理项目计数单位、统计项目、导出项目到其他格式文件备份。(2)对子项目有上述同样的项目管理权。(3)扩展的项目可管理功能,管理员都有权使用。(4)管理员还可以任命新管理员,可以为其他成员分配单项项目管理权限:如管理计数单位权限、统计权限、导出备份权限等。(5)如果管理员不是项目唯一的管理员,则管理员可以卸任管理员。卸任后自动转为互动内成员。(6)管理员不能直接退出项目,只有先卸任管理员,然后再以互动内成员身份退出项目。
非互动成员没有该项目的一切权限。
普通互动内成员权限:(1)默认可以查看项目内所有条目。但条目发布者在发布时,单独屏蔽了该成员则除外。(2)可以查看该项目的设置、标签、成员、权限分配等。但如果不是具体的子项目互动内成员,则看不到该子项目。(3)可以在该项目下发布条目,自己发布的条目限定时间内(如10分钟)可撤回。自己发布的条目如果没被任何管理员修改过,自己有权修改。如果被管理员修改过,自己则失去修改权。(4)对自己发布或最后修改的条目,有权发起删除权和参加删除表决权。如果管理员发起的删除表决,如果该条目是自己发布的或最后修改的,则也必须要自己同意删除后方能删除。自己不同意则删除也终止。(5)可以作废自己发布或最后修改的条目,作废后,也有权取消作废。该条目被管理员作废或取消作废后,则失去作废(或取消作废)权。(6)可以在有权看到的条目内评论、回复、投票。可以查看该条目送达情况。(7)如果被管理员分配了某些管理权限,可以行使该单项管理权。(8)互动内成员可以选择退出项目,退出后,此成员将由互动内成员转为非互动内成员。该成员将不能再看到项目的一切。但项目方涉及到该成员的数据不会受影响。
普通互动外成员权限:(1)默认不能查看该项目的所有内容:包括条目、设置、标签、成员等。但可以看到一些指定的条目,即:条目在发布时,就特别指定了该条目允许该互动外成员查看,此条目则可以被该互动外成员看到。(2)可以看到项目名,以及自己在项目内的名称和身份。(3)可在被允许看到的条目内评论、回复、投票、查看该条目送达情况。(4)互动外成员可以选择退出项目,退出后,由互动外成员转为非互动外成员。该成员将不能再看到项目的一切。但项目方涉及到该成员的数据不会受影响。
8、项目成员的添加、删除与修改:
(1)项目管理员可以添、删、改项目的成员(含内成员和外成员)。
(2)项目互动内成员默认可以添、删、改项目外成员(被管理员特别禁止的除外)。
(3)添加成员:添加时直接输入成员在项目内的名称即可。可选填联系电话和其他资料(如成员标签,成员备注等)。
(4)添加成员后默认是非互动状态。
(5)建立互动:有权限的成员,可以为项目的非互动成员建立互动关系,申请互动时,寻找电话一致注册用户,找不到则提示该电话还未注册,无法互动。找到则需要经该成员的同意后,方能建立互动。
(6)断开互动:成员可以自己点击退出项目,从而断开与项目的互动。项目中有权限的成员,也可以断开其他成员的互动状态。断开后成为非互动成员。
(7)删除成员:有权限的成员,可以删除成员,删除后成为历史成员。
(8)恢复历史成员:有权限的成员,可以将历史成员恢复为正常成员。
(9)联系电话:有权限的成员,可以修改项目成员的联系电话,但互动成员因与的联系电话不能被修改,确要修改必须先断开互动。
三、项目分类标签:
1、项目下可以建立多个分类标签,下简称标签。
2、标签有以下类型:
1) 内成员标签:可被关联在内部成员上,以对内成员分组,方便检索和查看。
2) 外成员标签:可被关联在外部成员上,以对外成员分组,方便检索和查看。
3) 记事标签:可被关联在记事类型条目上,方便检索和查看记事条目。
4) 账数标签:可被关联在账数类型条目上,方便检索和查看账数条目。
5) 印戳标签:可被关联在所有类型条目上,可用于显示标记所有条目,且方便检索和查看条目。印戳最大的特点是所有条目都可以用。而记事标签和账数标签则仅限记事条目或账数条目可以用。
3、标签添\改\停用\恢复:
2) 系统可定义一些公用标签,在所有项目中都会出现,并可直接被使用。
3) 有权限成员可为项目添加标签,这些标签,仅限在该项目内使用。
4) 项目中,同一类型标签,同一名称的,只允许建立一次。也不能与系统公用标签同名。
5) 有权限的成员,可以修改标签名。
6) 标签不能被删除,只能被停用。有权限的成员可以停用或恢复标签。标签停用后,之前用到该标签的条目不会受到影响,但新录入条目将不能再使用该标签。
四、条目
1、条目:是本方法存储或检索数据的基本数据单元。方法的核心规则和功能都是基于条目实现的。
2、每个用户记录的记事,账数内容,被整理为统一格式的条目,首先保存在服务端。客户端按使用者所属项目及在项目内的读写权限,通过网络从服务器获取该用户有权查看的条目。也可以通过客户端,向其所属项目添加条目。
3、条目基础属性:本方法规定条目必须具备的基础属性如图2所示。依据条目类型不同,这些属性有的必须具备,有的必须空缺、有的可选。最后形成统一格式的条目,这样不同类型的条目就可以存储在一起、并可利用这些属性进行筛选、索引、统计、排序等。实际使用中,还可以在这些属性的基础上,扩展更多属性,条目格式可以参考但不限于图1格式,须充分而清晰展示其各项属性:
(1)发生时间(必备):用于标记条目所指记事/记账/计数这个现实生活中的事件发生的时间。可以与记录时间一致,也可以指定一个时间。在客户端显示时,若记录时间与指定的时间差距较大,可以显著标示该条目为“补记”,或“xx天后补记”字样。以考核记录的及时性。
(2)条目类型(必备):用于标记条目类型,每个条目只能有一种的类型。可能的类型值至少包括以下:
(1)基本类型:
A. 记事条目
B. 账数条目
(2)扩展类型:可在基础类型的基础上,扩展一些属性,以具备更丰富的功能,本方法定义了两个扩展类型:
A. 项目日志条目:是记事条目的扩展,在项目内发生的设置、修改类较重大事件时,自动生成,以实现项目内容的可追溯性。
B. 统计报告条目:也是记事条目的扩展,内附了一份统计报告的链接,可以由此保存一份统计报告,供后续查阅。
C. 实际系统中,可扩展一些更多类型:如系统通知、日程、审批、带文件条目、带照片条目等等
2) 所属项目(必备):用于标记条目所属于的项目。
3) 所属标签(可选):条目可附加一系列标签,以标记条目的类别,性质。
4) 内成员可见性(必备):默认对项目内成员都可见,但也可以单独指定条目只给哪些内成员看,或不给哪些内成员看。
5) 外成员可见性(必备):默认外成员都不可见,但条目也可以单独指定哪些外成员可见。
6) 账数组(账数条目必备,记事条目空缺):账数条目内须有一到多个账数组。每一个账数组,描述一笔具体的记账、计数或计件业务。记事类条目此项空缺。每个账数组,由8)-14)条定义的这些属性灵活组成:
7) 账数甲方(账数组必备): 该属性的值必须是条目所在项目的成员之一,系统会自动提供一个“外部其他”可选成员,以代表不知名的外部收支方。所有账数组中,此项不可缺。
8) 账数动作一(账数组必备):该属性定义了记账或计数的第一动作。所有账数组中,此项不可缺。方法定义了以下七个可选值(或相同含义):(1)非借还付给 (2)非借还收到 (3)归还类付给(4)应付(或欠、或借入)(5)计数增加 (6)计数减少 (7)代(代收或代付类),其中1-6为基本动作,7为复合动作。实际实现系统中,允许扩展更多的可选值。
9) 账数乙方(视该账数动作一而定,或必备,或空缺):当“记账动作一”的值为“计数增加”或“计数减少”时,此项空缺,为其他值时,该属性不可缺。该属性的值必须是所在项目的成员之一,系统会自动提供一个“外部其他”可选成员,以代表不知名的外部收支方。
10)账数动作二(视该账数组动作一而定,或必备,或空缺):该属性定义了记账或计数的第二动作。当“记账动作一”的值为“代(代收或代付类)”时,此项不可缺。为其他值时,此项空缺。此项必须是以下两个值(或相同含义)之一:(1)非借还支付 (2)非借还收到。
11)账数丙方(若该账数组有动作二,则必备,否则空缺):该属性定义了记账或计数的第二动作的对象。当“记账动作一”的值为“代(代收或代付类)”时,此项不可缺。为其他值时,此项空缺。该属性的值必须是所在项目的成员之一,系统会自动提供一个“外部其他”可选成员,以代表不知名的外部收支方。
12)账数数额(账数组必备):此项目不可缺,必须大于零,可以带小数。
13)账数单位(账数组必备):默认单位为“元”,也可以输入任何自定义的单位。但如果单位为“元”等货币单位时,则此账数组为一笔记账。如果是其他单位,则此账数为一笔计数或计件。
14)印戳(可选):有权限的成员可以为条目加上一个印戳标签。印戳标签应醒目的标记,以便于一眼识别此条目的某方面性质或类别。一条目同一时间只能有一个印戳。可空缺。
15)内容或备注(必备):账数条目,此属性为账数备注;如果是记事条目,此属性为记事内容。
16)初次记录信息(必备):保存一些初记信息,包括条目真实记录时刻,记录人等。该项在条目初次记录时自动生成,且不可再被修改。该属性不可缺少。
17)修改信息(修改过则必备):用于标记条目的修改信息。条目若没被修改过则空缺。如有,则保存最后的修改时间及最后修改人信息、累计修改次数。此项在条目被修改时自动生成。
18)送达情况(必备):有权查看条目的成员,可以据此查看本条目对其他成员的送达情况。
19)条目表态结果(有表态则自动产生):每个条目都允许成员对条目至少表达支持、反对、质疑这三种态度,详见条目表态功能描述。
20)条目日志(因成员操作而自动生成):用于记录条目的互动、记录、修改等操作中,产生的一些必要的信息。条目日志内的信息,对本方法的目的实现有着举足轻重的作用。对条目日志有以下定义:
(1)条目日志分为:表态日志、修改日志、评论日志、删除表决日志。允许扩展更多类型的条目日志。各类日志的产生及内容,分别见条目的各项功能的描述:条目修改、条目表态、条目评论、条目删除。
(2)条目日志不可以被修改。只能由系统根据本方法定义自动生成。仅条目被表决删除时,会一并删除。
(3)有权查看条目的成员,都有权查看其条目日志。
(4)条目内容展示时,应按时间顺序,展示此条目的所有条目日志。
21)在以上基础属性的基础上,具体实施中,条目允许被扩展一些属性:如附件(文件、图片、录音等)、提醒闹钟、录入者位置、链接等。
3. 条目存储:
所有条目应首先在服务端存储,采用数据库存储是首选方法。服务器收到客户端请求时,将该客户端当前登录用户有权看到的条目同步分发给用户。客户端若具备技术条件,应保存一个该用户有权查看的条目副本在移动端本地(本地缓存),以提升体验,减轻服务器压力。通过推送、触发或定时同步,向服务器获取最新的条目及条目附加信息。该缓存与服务器数据强制一致。如不一致,则以服务器数据为准。
5. 条目输入:
用户使用可联网客户端设备,通过满足本方法定义的手机程序或电脑程序,将条目各属性的录入,并通过网络,利用布置在服务器实现的本方法的服务端程序,将条目数据存储在服务器。服务器同时将该条目分发给其他有权看到此条目的客户端用户。
6. 条目检索:
1) 用户可以按条目的任一属性或多种属性检索条目。如:可以只查看指定项目、指定类型、指定标签、指定成员、指定时间、或搜索指定内容的条目,等等。
2) 如果客户端设备有缓存本地条目,条目检索应优先在本地缓存中进行。这样设备离线时,可以不影响阅读内容。
7. 条目修改:
1) 条目是可以被修改的。但本方法规定,不允许修改条目所属的项目。以防止条目记录后,记录人可以通过修改所属项目,以隐匿曾经录入过的条目,使得条目内容失去可追溯性。
2) 项目的所有管理员,条目记录人、条目最后修改人(如有)都有修改权限。项目管理员修改过条目后,此条目的记录人、之前的最后修改人(如有),则失去修改权。
3) 条目修改时,系统自动在此条目的日志中保存一份条目修改日志。
4) 条目修改日志:条目修改日志应保存修改前的内容快照,修改人、修改时间、以及在哪些地方做了修改。并在查看此修改日志时,应可以还原修改前的条目完整内容。以保证条目修改的可追溯性和可核对性。
8. 条目表态:
1) 有权查看本条目的成员,都可以对条目进行表态。表态值至少有三个值:赞成(或同意、支持等),反对(或不同意等),质疑(或不明白、不懂等)。表态时还可以输入表态备注。
2) 有权查看本条目的成员,都可以查看其他成员对本条目的表态情况、表态时间、表态备注、表态日志。
3) 同一成员可以反复表态,后续表态意见代替之前表态意见,但每次表态会自动生成表态日志。
4) 表态日志:应包括表态意见、表态人、表态时间、表态备注。表态日志能清晰的反应该成员反复表态的历程和变化。让成员的表态可追溯和可核对。
5) 查看条目时,应展示最后表态情况。各种表态值的清单,以及各种表态人数的百分数。
6) 条目被修改后,条目表态结果被清空。但条目日志中的表态日志应保留。
9. 条目评论:
1) 有权查看本条目的成员,都可以对条目进行评论,也可以回复别人对此条目的评论。
2) 所有评论以评论日志的形式保存在条目日志中。
3) 评论日志:应包括评论人、评论时间、评论内容、是针对谁的回复(如有)。
10.条目作废、或取消作废:
1) 条目发布后,任何时间都可以被作废,或对已作废条目取消作废。作废本质是对条目修改。修改了条目的有效性这一属性。
2) 有权修改条目的成员都可以作废一个条目。
3) 作废应生成一个修改日志。但可以不保存修改快照,而用文字描述,例如:某人于某时间,作废或取消作废了此条目。
4) 作废后的条目,原来的内容仍可以查看。但应显著标记此条目已作废(如对条目内容加上删除线)。
5) 被作废后的条目,后续的统计中将会排除此条目。
11.条目撤回:
1) 条目可在发布后限定的时间内撤回。(为确保数据的可追溯性,建议10分钟内。作为发布人误操作,误发敏感信息后的挽救措施。)
2) 撤回只能由发布人自己撤回。
3) 撤回后,所有成员将不能再看到撤回前的内容。条目内容由“本条目已被撤回”(或相同含义)代替。
4) 被撤回条目将不能再修改、表态、评论,也不会被统计。撤回条目不必生成条目日志。
12.条目删除:
1) 条目允许在表决通过后被删除。
2) 方法默认规定:条目记录人、最后修改人(如有),项目所有管理员一致同意的情况下,条目才会被删除。任一人反对,则删除表决终止,维持原状。如果只有一人的项目,将不可避免的同时满足上述条目,也意味着只有一人的项目,可以随意删除条目。实际中,允许项目管理员依据生产生活实际情况,在项目设置中,增加额外需要同意的成员。
3) 删除的发起:有权参与删除表决的成员,都可以发起对某条目的删除表决。
4) 删除通过后,此条目的实质内容和所有条目日志均被删除。且不提供恢复功能。
13.条目录入:
1) 录入时,应尽可能提供条目录入的属性的准确性、便捷性和数据一致性。例如:应遵循多选择,少输入的原则。
2) 项目互动内成员和管理员,可以向该项目录入条目。
3) 条目类型、条目所属项目、所属标签、账数组甲乙丙方、账数组动作、之前用到过的账数单位、印戳、成员可见性清单,均应通过选择方式录入。以确保无误和快捷。、
4) 项目日志条目、条目修改日志、条目日志等性,应由客户端或服务器自动生成并保存。条目的一些非输入性属性,应自动依据本方法规则填写或空缺。
5) 选择成员或标签时,应支持快速搜索功能,这样在可选项过多时,可以通过成员名、或成员标签名、或成员电话等,快速查找。
14.条目显示:
1) 在客户端,应可以检索和阅读当前登录用户可以看到的条目。并应提供便捷的按各种属性的查找、检索、归类、排序、搜索功能。
2) 条目默认应优先按发生顺序显示。
3) 应提供“补记”这一概念,记录时间严重滞后于条目发生时间,标补记字样,以提升项目管理中,记录的及时性。并为项目管理人员提供考核便利性。
4) 条目显示可以直接按照文字排版方式。但要清晰、有条理,应尽可能将定义的条目要素显示完整。不产生歧义或空缺的属性可以简化或省略。
五、记账计数方法:
1、本方法在前述条目、项目、成员的基础上,设立了较完整的记账计数方法。能够较完整的模拟生活生产中常见的记账、计数、计件、借还、出货、进货等活动,思路较贴近百姓日常生活思维,不需要专业的会计知识,也可以轻易处理账务,同时支持导出数据,作为原始数据进行下一步分析处理。
2、首先,本方法认为账数有三种性质:计数增减性质,非借还收支性质,借还性质:
(1)计数增减性质:由账数动作“计数增加”和“计数减少”记录的条目,都是此类性质。这类性质用于模拟生产生活中直接出现,或者直接消失的情况:如跑步里程增加,积分增减,产品被生产出来,或者报废、丢失等;
(2)非借还收支性质:由账数动作“非借还付给”和“非借还收到”记录的条目,都是此类性质。这类性质用于模拟生产生活中,款或物由一方转移到另一方,但不考虑收回的情况:如销售产生收入,就不考虑货款要归还对方;购买货物,则不考虑购买款需要收回来,捐赠也是一样。
(3)借还性质:由账数动作“归还类付给”和“应付(或欠、或借入)”记录的条目,都是此类性质。这类性质用于模拟生产生活中,款或物由一方转移到另一方,且属于归还或要收回的情况:借与还是两个相反方向的款物转移,可以相抵,且相抵之后,净借净还为0是借还业务所追求的状态。
(4)本方法用这三类账数性质定义,将生活生产常见的账数业务,划分为三个完全独立类型。这三种性质的数据,即使单位一样,也应分别予以独立统计。且相互之间不能累加,本方法认为相互累加是毫无意义的。这些规则也是本方法较为核心的部分。实际生产生活中的账务往来,人们往往关注的也是这三类性质的数字:如有多少产品被生产出来(计数增减性质),产生多少销售,花了多少成本(非借还收支性质),我欠别人多少,别人欠我多少(借还性质)。这三类数据分别汇总,但彼此之间不再累加。
3、账数组概念:如前条目属性中所描述,一个账数条目,可有一到多个账数组。同一次活动或业务,可以分解为多条账数组,来归纳和记录记账计数收支往来行为。所谓账数组,是由甲乙丙方、动作一、动作二、数额、单位这几个要素灵活的组合而成的一个可理解的语句。来表达相应的记账计数收支往来。而这些组合的属性,在存储时是分别存储的,以方便分析和检索。
4、账数组基本组合语句:本方法定义了以下几种基本的账数组合语句:
(1)甲方 + (非借还)付给+ 乙方 + 数量 + 单位:此组合用于记录生活生产中的购买付款、货物交付、捐赠等不需要对方归还的活动,单位为货币表示甲方支付乙方款项,单位为货物或其他单位则表示甲方交付乙方货物等。
(2)甲方 + (非借还)收到 + 乙方 + 数量 + 单位:此组合用于记录销售收款、购买后收到货物、收到捐赠等不需要归还对方的活动。单位为货币表示甲方收到乙方款项,单位为货物或其他单位则表示甲方收到乙方货物等。
(3)甲方 + (归还)付给 + 乙方 + 数量 + 单位:此组合用于记录归还欠款欠物行为。单位为货币表示甲方归还乙方款项,单位为货物或其他单位表示甲方归还乙方货物等。
(4)甲方 + 应付(或欠) + 乙方 + 数量 + 单位:此组合用于记录借欠款物的行为。单位为货币表示甲方应付乙方款项、或乙方借给甲方款项;单位为货物或其他单位表示甲方应付乙方货物、或乙方借给甲方货物。(应注意:甲方应付乙方、甲方欠乙方、乙方借给甲方,表达其实是相同含义。)
(5)甲方 + 计数增加 + 数量 +单位:此组合用于记录计数、计件类的直接增加的情况。如跑步里程的增加、工人生产数量的增加等。
(6)甲方 + 计数减少 + 数量 +单位:此组合用于记录计数、计件类的直接减少的情况。如体重的减少、产品的丢失损坏等、剩余任务的减少等。
5、账数组复合组合语句:所谓复合语句,就是他的业务逻辑可以拆分为多条基础语句。但复合语句更方便和直观,且易于理解。本方法定义了可以直接使用的两个复合组合语句,分别如下,实现本方法的系统中,可以扩展一些可以更多的复合语句。
(1)甲方 + 代 + 乙方 +(非借还)付给 + 丙方 + 数量 + 单位:此组合用于记录甲方代乙方支付丙方款或物的行为。这个复合语句与:“甲方+(非借还)付给+丙方+数量+单位” ,同时“乙方+应付(或欠)+甲方+数量+单位” 两条基本组合的叠加等价。例如可用此组合记录员工支出的需报销的费用:如 某员工代公司付给的士司机100元打的费。其拆分含义是:该员工付给的士司机100元,同时公司应付该员工100元。
(2)甲方 + 代 + 乙方 +(非借还)收到 + 丙方 + 数量 + 单位:此组合用于记录甲方代乙方收到丙方款或物的行为。这个复合语句与:“甲方+(非借还)收到+丙方+数量+单位” ,同时“甲方+应付(或欠)+乙方+数量+单位” 两条基本组合的叠加等价。例如可用此组合记录员工代收货款的行为:如某员工代公司收到某客户10000元货款。其拆分含义是:该员工收到某客户10000元,同时该员工应付公司10000元。
6、多个账数组:在一个账数条目内,可使用多个账数组描述更复杂情况,下面直接列出几个举例来示范:
例1、甲购买乙产品,需支付款项90元,甲支付了100元,乙方应找补10元,但乙没有零钱,于是商定先记下账,以后结算。可以在一个条目内,用两条账数组来描述:
[1] 甲(非借还)付给乙100元
[2] 乙应付(或欠)甲10元
并在备注中说明具体事由和情况。
例2:甲销售给乙4吨水泥,并收到他货款1200元。这一交货并收款的交易行为,如果需要同时记录货物和款项,可以在一个账数条目内,用下面两条账数组来描述,并直接使用了自定义单位“吨水泥”:
[1] 甲(非借还)付给乙4吨水泥
[2]甲(非借还)收到乙1200元
并在备注中说明具体事由和情况。
例3:甲乙丙丁共同投资了一商铺,各25%股份,本月租金10000万,理应每人各分2500元,但为方便,此租金由甲代收,然而甲乙丙丁之间的往来频繁,远不止这一笔,所以他们采用的是定期核对账务并结算的方式,所以甲收到租金时,此笔账务应该先记下,可用下面几条基本组合来描述这笔业务:
[1] 甲(非借还)收到外部其他10000元
[2]甲应付(或欠)乙2500元
[3]甲应付(或欠)丙2500元
[4]甲应付(或欠)丁2500元
并在备注中说明具体事由和情况,注意这里用到“外部其他”,不需记名的其他收支方,系统会提供“外部其他”这一公共可选项。
例4:甲欠乙10000元,乙因为资金需要催甲归还,而甲目前无钱归还,于是向丙借,丙同意后,为方便由丙直接转款10000元给乙方,此后甲欠丙10000元。这是一种丙代甲归还乙10000元的逻辑,可记录如下:
[1] 甲(归还)付给乙10000元
[2] 甲应付(或欠)丙10000元
并在备注中说明具体事由和情况。
7、账数单位:
(1)本方法通过单位的灵活性,将记录范围从记账扩展到记所有物或者数。
(2)本方法认为,不同单位之间的账数数额,没有任何相关性,统计中不能互相累加,完全独立。
(3)方法默认使用常用货币单位,如“元”作为默认单位,但可以选择和输入任意其他单位:如“吨”,“千米”,“工天”等,为方便说明物料,可以将物料名带在单位后面,有着更好的可阅读性:如直接将“吨水泥”作为单位的效果:“甲乙(非借还)付给乙方xx吨水泥。”
(4)使用了货币单位,意味着此账数组是记账。使用了非货币单位,意味着此账数组是记物、计数或记件。
(5)实现本方法的系统应自动记录该项目用到过的自定义单位,并在下一次该项目的账数记录中可选。以后管理员修改项目用到过的单位时,之前涉及该单位的条目应不受影响。
六、账数统计方法:
1. 实现本方法的系统应该具备统计功能。可以对指定的条目集合,按以下方法进行统计和展示。
2. 统计结果:本方法定义了要统计出的结果数据,并定义了文字版的统计结果参考格式,该格式也可是表格化、图表化的。但要表达的数据应一样。也允许对该结果进行扩展。如图3至5所示,下方左边是参考格式,右边是带有编号的注释,解释了各项的逻辑和定义:
3. 统计过程:
(1)首先,应指定要统计的条目范围。且统计应限于某一项目内(可以包括其子项目),然后可以依据指定的条件筛选或搜索,将其筛选出的条目集合作为统计样本。
(2)其次,逐一分析涉及的条目的所有账数组,复合组合语句要折分为多条基本组合语句,再进行分析。并依据本方法寻找(没有则生成)对应的“单位部分”、各类“二级项(总体项、成员项、标签项)”、“三级项(成员项下的一对一成员项,标签项下的该类别下成员项)”。每一项中,有一到多个“统计汇总项”。并依据此条目的分析结果,对这些“统计汇总项”的各项数据进行累计加减或刷新,最后得到累加数字。统计工作最好在客户端完成,以节省服务器运算资源。在分析条目时,如果栏目项或汇总项还不存在,则立即创建一个。
(3)按参考格式或其他格式,将统计结果展示出来。
(4)条目分析和统计方法:在统计时,复合账数组合语句都应被拆分为基本组合语句,再参与分析,下面是基本组合语句的分析和统计方法,为方便描述,直接引用前面统计格式右侧的注释编号表示要更新的项,语句中的xx表示账数组数额。
1) “甲方(非借还)付给乙方xx单位”:
A. 首先,操作仅限在相应的单位部分下。其他单位部分不做任何操作。
B. 累加总体项下注释7“总体对外成员非借还收支汇总”:
a) 甲乙都是内成员或都是外成员,则不累加此项。
b) 甲是内成员,乙是外成员,则注释7的A增加xx,并依据A,B的差值刷新C。
c) 甲是外成员,乙是内成员,则注释7的B增加xx,并依据A,B的差值刷新C。
C. 再累加此单位部分下成员『甲』项内的一系列汇总项:
a) 应累加注释11“该成员对外成员非借还收支汇总”,注释12“该成员对内成员非借还收支汇总”,注释13“该成员对内外成员非借还收支汇总”。
b) 若乙是内成员,则注释12和13的A增加xx。并依据A,B的差值刷新C。
c) 若乙是外成员,则注释11和13的A增加xx。并依据A,B的差值刷新C。
d) 累加成员『甲』下的成员『甲』与『乙』一对一分项:注释18中的A增加xx,并依据A,B差值刷新C。
D. 再累加此单位部分下成员『乙』项内的一系列汇总项:
a) 应累加注释11“该成员对外成员非借还收支汇总”,注释12“该成员对内成员非借还收支汇总”,注释13“该成员对内外成员非借还收支汇总”。
b) 若甲是内成员,则注释12和13的B增加xx。并依据A,B的差值刷新C。
c) 若甲是外成员,则注释11和13的B增加xx。并依据A,B的差值刷新C。
d) 累加成员『乙』下成员『乙』与成员『甲』分项:注释18中的B增加xx,并依据A,B差值刷新C。
E. 如果本条目有标签:再累加此单位部分下,相应标签项内的一系列汇总项:
a) 标签项下,注释24:“该标签下非借还收支汇总”,按本节B条逻辑累加。
b) 标签下成员『甲』分项下,应累加注释28“该成员此类对外成员非借还收支汇总”,注释29“该成员此类对内成员非借还收支汇总”,注释30“该成员此类对内外成员非借还收支汇总”。按本节C条逻辑累加。
c) 标签下成员『乙』分项下,应累加注释28“该成员此类对外成员非借还收支汇总”,注释29“该成员此类对内成员非借还收支汇总”,注释30“该成员此类对内外成员非借还收支汇总”。按本节D条逻辑累加。
2) “甲方(非借还)收到乙方xx单位”:
将其变换为“乙方(非借还)支付甲方xx单位”后,按前一条规则分析统计。
3) “甲方(归还)支付乙方xx单位”:
A. 首先,操作仅限在相应的单位部分下。其他单位部分不做任何操作。
B. 累加总体项下注释8“总体对外成员借还汇总”:
a) 甲乙都是内成员或都是外成员,则不累加此项。
b) 甲是内成员,乙是外成员,则注释8的C增加xx,并依据ABCD的值刷新E。
c) 甲是外成员,乙是内成员,则注释8的D增加xx,并依据ABCD的值刷新E。
C. 再累加成员『甲』项内的一系列汇总项:
a) 应累加注释14“该成员对外成员借还汇总”,注释15“该成员对内成员借还汇总”,注释16“该成员对内外成员借还汇总”。
b) 若乙是内成员,则注释15和16的C增加xx。并依据ABCD的值刷新E。
c) 若乙是外成员,则注释14和16的C增加xx。并依据ABCD的值刷新E。
d) 累加成员『甲』下的成员『甲』与『乙』一对一分项:注释19中的C增加xx,并依据ABCD的值刷新E。
D. 再累加成员『乙』项内的一系列汇总项:
a) 应累加注释14“该成员对外成员借还汇总”,注释15“该成员对内成员借还汇总”,注释16“该成员对内外成员借还汇总”。
b) 若甲是内成员,则注释15和16的D增加xx。并依据ABCD的值刷新E。
c) 若甲是外成员,则注释14和16的D增加xx。并依据ABCD的值刷新E。
d) 累加成员『乙』下成员『乙』与成员『甲』一对一分项:注释19中的D增加xx,并依据ABCD的值刷新E。
E. 如果本条目有标签:再累加每个相应标签项内的一系列汇总项:
a) 标签项下,注释25:“该标签下借还汇总”,按本节B条逻辑累加。
b) 标签下成员『甲』分项下,应累加注释31“该成员此类对外成员借还汇总”,注释32“该成员此类对内成员借还汇总”,注释33“该成员此类对内外成员借还汇总”。按本节C条逻辑累加。
c) 标签下成员『乙』分项下,应累加注释31“该成员此类对外成员借还汇总”,注释32“该成员此类对内成员借还汇总”,注释33“该成员此类对内外成员借还汇总”。按本节D条逻辑累加。
4) “甲方应付(或欠)乙方xx单位”:
A. 首先,操作仅限在相应的单位部分下。其他单位部分不做任何操作。
B. 累加总体项下注释8“总体对外成员借还汇总”:
a) 甲乙都是内成员或都是外成员,则不累加此项。
b) 甲是内成员,乙是外成员,则注释8的B增加xx,并依据ABCD的值刷新E。
c) 甲是外成员,乙是内成员,则注释8的A增加xx,并依据ABCD的值刷新E。
C. 再累加此成员『甲』项内的一系列汇总项:
a) 应累加注释14“该成员对外成员借还汇总”,注释15“该成员对内成员借还汇总”,注释16“该成员对内外成员借还汇总”。
b) 若乙是内成员,则注释15和16的B增加xx。并依据ABCD的值刷新E。
c) 若乙是外成员,则注释14和16的B增加xx。并依据ABCD的值刷新E。
d) 累加成员『甲』下的成员『甲』与『乙』一对一分项:注释19中的B增加xx,并依据ABCD的值刷新E。
D. 再累加成员『乙』项内的一系列汇总项:
a) 应累加注释14“该成员对外成员借还汇总”,注释15“该成员对内成员借还汇总”,注释16“该成员对内外成员借还汇总”。
b) 若甲是内成员,则注释15和16的A增加xx。并依据ABCD的值刷新E。
c) 若甲是外成员,则注释15和16的A增加xx。并依据ABCD的值刷新E。
d) 累加成员『乙』下成员『乙』与成员『甲』分项:注释19中的A增加xx,并依据ABCD的值刷新E。
E. 如果本条目有标签:再累加每个相应标签项内的一系列汇总项:
a) 标签项下,注释25:“该标签下借还汇总”,按本节B条逻辑累加。
b) 标签下成员『甲』分项下,应累加注释31“该成员此类对外成员借还汇总”,注释32“该成员此类对内成员借还汇总”,注释33“该成员此类对内外成员借还汇总”。按本节C条逻辑累加。
c) 标签下成员『乙』分项下,应累加注释31“该成员此类对外成员借还汇总”,注释32“该成员此类对内成员借还汇总”,注释33“该成员此类对内外成员借还汇总”。按本节D条逻辑累加。
5) “甲方计数增加xx单位”和“甲方计数减少xx单位”
A. 首先,操作仅限在相应的单位部分下。其他单位部分不做任何操作。
B. 累加总体项下注释6“总体计数增减汇总”:
a) 若是计数增加,则注释6的A增加xx,并依据AB的值刷新C。
b) 若是计数减少,则注释6的B增加xx,并依据AB的值刷新C。
C. 再累加此成员『甲』项内注释10“该成员计数增减汇总”:
a) 若是计数增加,则注释10的A增加xx,并依据AB的值刷新C。
b) 若是计数减少,则注释10的B增加xx,并依据AB的值刷新C。
D. 如果本条目有标签:再累加每个相应标签项内的一系列汇总项:
a) 标签项下,注释23:“该标签下计数增减汇总”,按本节B条逻辑累加。
b) 标签下成员『甲』分项下,应累加注释27“该成员此类计数增减汇总”,按本节C条逻辑累加。
6) 复合组合语句:应折解为基本语句后,再逐一用上述方法进行分析统计。
7) 涉及子项目时的内外成员定义规则:从本节第5)条可以看出,很多时候,要判断甲乙方是该项目的外成员还是内成员。一般情况下,直接依据该成员在该项目中的身份即可。但统计时,如果统计的是父项目,是可以包括子项目一起统计的。这时内外成员的身份有一些特殊规则:
A. 若子项目的成员,不同时是父项目的成员(电话一致则认为是同一人),则一律视为外成员。
B.若子项目的成员,同时也是父项目的成员(电话一致则认为是同一人),则一律按其在父项目的身份为准。举例说明:如父项目有外成员“张三”,电话222,子项目有内成员“张三丰”,电话也是222,则系统依据电话相同,判定父项目的“张三”和子项目“张三丰”在现实生活中是同一角色,如果统计父项目,且包含子项目时,在父项目中发生在“张三”身上的数据,和在子项目中发生在“张三丰”身上的数据会被累加在一起,而且以在父项目中外成员身份为准。认为这一累加后的数字是属于外成员性质的。
4、统计结果的保存:
(1)按上述统计方法统计完成后,即得到统计结果。对结果可以保存,也可以不保存。不保存则在退出结果页面后,结果即消失。本方法着重定义了以下两种保存方式:
(2) 一种方式是导出:统计结果页面,提供导出按钮,可以按原样格式,输出txt文件或其他可阅读格式文件。如excel文件。
(3)另一种方式是保存为统计报告条目:在统计结果页面中提供在线保存功能,可以将本结果以统计报告条目的形式保存在本系统中。如前条目类型中所描述,统计报告条目是记事条目的扩展。内部附加了一个统计结果的链接。打开此链接,可以原样直接显示该统计结果页面,这样实现统计结果可追溯。在统计之后,若对其中的条目进行了修改,不会影响此统计报告。而且方法要求,在显示历史统计结果中的条目快照时,应与当前条目的最新状态对比,并提示哪些条目在后来产生了修改。以实现更清晰的可追溯性。
七、进行项目管理等更多功能的方法:
(1)利用本方法,进行项目管理,需以利用本方法的实现的系统为工具,后简称系统。因为本方法的特点,实现项目管理等功能时,其使用特点与传统方式有一些不一样。总体而言,较灵活且简单,有些控制则需要团队协调配合。
(2)与专业财务对接:首先,可以利用本系统获取团队成员的一手账务材料。其次,可以利用本系统导出文件,如Excel文件,作为专业财务作账的一手材料。
(3)申请与审批,成员的同意:本方法认为,在这种可互动式的系统下,以记事的方式(可自建一“申请”标签),记录一条记事,领导看到后,直接评论回复“同意”,或表态“支持”,或加一“同意”字样的印戳,就完成审批。因为是领导本人操作,且由此产生的条目日志是不会被删除的,所以具备审批效力。甚至在条目显示送达对方后,对方没有提出反对意见,也可以视为同意。这种简易的方式,大大降低了系统的复杂度,同时也完全能满足生产生活需要。
(4)财务报销:员工可以通过本系统,记录代公司支出的费用。作为项目成员的财务看到后,以多种方式回复同意,可自建印戳“同意报销”,由此产生的条目日志,认为此报销审核通过。实际报销后,财务可以录入归还性质条目,完成报销。
(5)工作汇报:可以自建“工作日志”或“工作周报”等类似标签,并线下要求员工每天或每周,定时在项目中发布相应标签的记事条目。根据“补记”属性确定哪些员工没有及时上报工作汇报。
(6)营销跟进:可以为一个大的营销项目、分店、内部小组建立子项目,并拉入所需人员。也可以在一个条目中,以评论回复的形式,讨论和跟进此营销项目的进度和保存各种反馈。有多个门店的销售系统,也可以通过本系统,每天上报销量、库存等情况。
(7)客户和供应商管理:将所有的客户添加为项目的外成员,并贴上“客户”这类自定义外成员标签,同时可以在外成员资料中记录电话、简介。与之产生的往来账务和事务,均可以通过条目的方式,保存在本系统中。也可以在筛选中指定该外成员,统计与之产生的销售额、进货额、借欠情况等。
(8)客户服务:可以将客户添加为外成员,并建立互动。一些与他有关的记事或账数,可以在记录时允许他看到,这样他就可以在本条目内一起讨论回复。客户的同意或否决意见,也可作为项目服务的证据。客户也可以看到自己的积分增减、项目进度记录等。
(9)投票表决:项目要决定的某一事项,可以通过记录一条记事,然后要求相关成员在下方表态。表态区内会显示投票率、支持率或反对率。且每一次成员的表态,都会按时间留下条目日志。这样的表决,既方便快捷,也免去了口头表决反悔无证据,签字表决又太麻烦的弊端。
(10)承诺守约:项目中,领导或员工一些日常承诺的事项,比如领导承诺的奖金,如果全部通过签字书面化,既显得不方便,又显得过于“重”,通过本系统发记事条目,另一方回复确认。是一份抹不掉的电子契约。即使修改,也可在条目修改日志中看到修改演变过程,无可抵赖。
(11)计件生产:生产中,若遇到计件生产时,可以通过计数增减的方式,在此系统中互动式记录,管理方与工人可以即时用评论的方式确认是否有误。这样方便明了且不会出现纠纷。
(12)员工绩效考核:如果是通过销售业绩考核,可以直接为每个员工建立一个标签,录入公司对外收入时,贴上该业务所属的员工标签,统计时查看相应标签项的数据即可。若是将考核的指标转为积分,直接以计数增减的方式,记录员工积分增减即可。
(13)岗位交接:平时就应该要求员工在此系统中记下有关工作的一切资料,比如客户的电话、客户方找谁审批,与谁接洽,施工进度,结算进度,需要注意的事项,当老员工辞职,新员工上岗的时候,可以直接将老员工断开项目互动,新员工建立互动,然后让新员工查看项目中之前的内容,就可以直接开始新的工作。防止人走客户失的现象出现。
(14)合伙投资监督:当作为合伙人参与项目时,可以要求成员项目的管理员,这样合作股东之间,可以有相互监督、相互制衡的效果。股东可以对项目的一切运作有知情权。股东退出时,在协商到一致的情况下,股东才会卸任管理员。防止实际操作人单方面操作。对重大事项,也可以在条目中利用表态投票表决。需要删除条目、销毁项目时,也需要所有管理员一致同意方能进行。本方法认为,管理员的自愿卸任、同意删除,应是股东之间线下相互协调的结果,股东不能协商一致,就维持现状。
(15)仓库管理:将某仓库建为一个内成员。出库、入库都以此内成员为甲乙丙方,配合自定义单位。实现仓库的进出货管理。
(16)订单与合同管理:专门建立一个自定义标签,叫“订单”或“合同”,在此标签下添加记事,并在每一个记事下通过评论或回复,汇报或更新此订单或合同的进度。并辅以印戳标记,如添加“合同已签订”,“订单进行中”,“已收款”,“订单已完成”等印戳,然后标记在相应的记事上。
(17)欠款与项目现金流管理:通过借欠统计,可以查看客户或供应商、员工等与本项目之间的借欠,资金积压情况。
(18)部门管理:用子项目模拟每一个下级部门,将部门成员拉入子项目成员。公司管理员自动担任部门子项目的管理员。并赋予部门经理在子项目中的一些管理权限。实现在该部门的管理。
八、数据备份与导出
所有数据应可以导出通用格式的可阅读文件:如txt文件,Excel格式文件,以供使用者做下一步处理或数据备份。
九、应重视数据安全:
所有数据应加密存储,并重视传输、使用过程中的安全性。
十、允许扩展:
本方法只是定义了这一套体系中,最核心基础的逻辑和方法。具体实现中,可以依据实际生产和生活情况,在本方法的基础上进行扩展,以实现更丰富的功能,更强的社会效益。
以上所述实施例仅表示本发明的几种实施方式,其描述较为具体和详细,但并不能理解为对本发明范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进,这些都属于本发明保护范围。因此本发明的保护范围应该以所述权利要求为准。

Claims (10)

1.一种基于条目式的记事记账计数计件项目管理方法,其特征在于,包括如下步骤:
对项目、项目成员、项目标签进行定义;
对具有独特属性的、可评论、可投票、具备日志的条目进行定义;
对数据格式、整理方式、录入要素、呈现格式、记账计数方法、统计方法进行定义;
结合所述数据格式、整理方式、录入要素、呈现格式、记账计数方法、统计方法进行计数、记账及计件的操作。
2.根据权利要求1所述的基于条目式的记事记账计数计件项目管理方法,其特征在于:所述项目成员按成员与项目关系,可分为内成员、外成员;
按项目成员是否关联真实注册用户划分,可分为真实用户成员、虚拟成员;
按项目成员是否可以参与该项目活动划分,可分为互动成员、非互动成员;
按项目成员的权限划分,可分为管理员、普通成员;
按项目成员时效状态划分,可分为正常成员、历史成员。
3.根据权利要求2所述的基于条目式的记事记账计数计件项目管理方法,其特征在于:
所述管理员具有普通互动内成员的所有权限的同时还具有项目的如下管理权限:修改项目名称、修改项目简介、增删改项目内标签、增删成员、修改成员类型和属性、让项目与成员建立或断开互动、停用项目、发起销毁项目或参与销毁项目表决、修改项目内所有条目内容或属性、发起删除条目或参与条目删除表决、作废或取消作废项目内所有条目、管理项目计数单位、统计项目、导出项目到其他格式文件备份;扩展项目的管理权限;任命新管理员,为其他成员分配单项项目的管理计数单位权限、统计权限、导出备份权限;若管理员非项目唯一的管理员,管理员具有卸任管理员功能,卸任后自动转为互动内成员;
所述普通互动内成员权限:查看条目发布者在发布时单独屏蔽了该成员以外的项目内条目;查看该项目的设置、标签、成员、权限分配;在该项目下发布条目,自己发布的条目限定时间内能撤回;并对管理员未修改的自己发布的条目有权修改;对自己发布和最后修改的条目,有权发起删除和参加删除表决;作废自己发布或最后修改且未被管理员作废的条目,作废后有权取消未被管理员作废条目的作废操作;在有权看到的条目内评论、回复、投票并查看该条目送达情况;在被管理员分配了管理权限后可以行使该单项管理权;选择退出项目,退出后此成员将由互动内成员转为非互动内成员,该成员将不能再看到项目的一切,但项目方涉及到该成员的数据不会受影响;
普通互动外成员权限:查看条目在发布时,特别指定了该条目允许该互动外成员查看的条目;查看项目名,以及自己在项目内的名称和身份;查看被允许能看到的条目内评论、回复、投票及该条目送达情况;选择退出项目,退出后,由互动外成员转为非互动外成员,该成员将不能再看到项目的一切;但项目方涉及到该成员的数据不会受影响。
4.根据权利要求1所述的基于条目式的记事记账计数计件项目管理方法,其特征在于,所述项目能够建立如下标签:
内成员标签:被关联在内部成员上,以对内成员分组,方便检索和查看;
外成员标签:被关联在外部成员上,以对外成员分组,方便检索和查看;
记事标签:被关联在记事类型条目上,方便检索和查看记事条目;
账数标签:被关联在账数类型条目上,方便检索和查看账数条目;
印戳标签:被关联在所有类型条目上,可用于显著标记所有条目,且方便检索和查看条目;
所述标签具有添加、修改、停用、恢复的功能。
5.根据权利要求1所述的基于条目式的记事记账计数计件项目管理方法,其特征在于:用户记录的内容,整理为统一格式的条目,保存在服务端;客户端按使用者所属项目及在项目内的读写权限,通过网络从服务器获取该用户有权查看的条目并通过客户端,向其所属项目添加条目。
6.根据权利要求1所述的基于条目式的记事记账计数计件项目管理方法,其特征在于:所述账数分为计数增减性质账数、非借还收支性质账数及借还性质账数;
所述计数增减性质账数,由账数动作“计数增加”和“计数减少”记录的条目,用于模拟生产生活中直接出现或者直接消失的情况;
所述非借还收支性质账数,由账数动作“非借还付给”和“非借还收到”记录的条目,用于模拟生产生活中,款或物由一方转移到另一方,但不考虑收回的情况;
所述借还性质账数,由账数动作“归还类付给”和“应付、或欠、或借入、”记录的条目,用于模拟生产生活中,款或物由一方转移到另一方,且属于归还或需要收回的情况。
7.根据权利要求1所述的基于条目式的记事记账计数计件项目管理方法,其特征在于:账数统计的具体方法如下:
指定要统计的条目范围,且统计限于包括其子项目的某一项目内,依据指定的条件筛选或搜索,将其筛选出的条目集合作为统计样本,
将涉及的条目的账数组逐一进行分析,复合组合语句要折分为多条基本组合语句,再进行分析;并寻找或生成对应的单位部分、各类包括总体项、成员项、标签项的二级项、包括成员项下的一对一成员项及标签项下的该类别下成员项的三级项;每一项中,有一到多个统计汇总项,依据此条目的分析结果,此这些统计汇总项的各项数据进行累计加减或刷新,最后得到累加数字;
复合帐数组合语句均被拆分为基本组合语句后参与分析。
8.根据权利要求1所述的基于条目式的记事记账计数计件项目管理方法,其特征在于:若子项目的成员,不同时是父项目的成员,则一律视为外成员;若子项目的成员,同时也是父项目的成员,则一律按其在父项目的身份为准。
9.根据权利要求1所述的基于条目式的记事记账计数计件项目管理方法,其特征在于:统计结果可以保存或不保存;不保存则在退出结果页面后,结果即消失;
所述统计结果保存的方法包括:
所述导出,统计结果页面,提供导出按钮,按原格式输出为可阅读格式文件;
保存为统计报告条目:统计结果页面,提供在线保存功能,将本结果以统计报告条目的形式保存在本系统中,如前条目类型中所描述,统计报告条目是记事条目的扩展,内附加了一个统计结果的链接,打开此链接,可以原样直接显示该统计结果页面,这样实现统计结果可追溯,在统计之后,若对其中的条目进行了修改,不会影响此统计报告,同时要求在显示历史统计结果中的条目快照时,应与当前条目的最新状态对比,并提示产生了修改的条目,以实现更清晰的可追溯性。
10.根据权利要求1所述的基于条目式的记事记账计数计件项目管理方法,其特征在于,还包括如下步骤:
使用者通过客户端在服务器进行注册,并绑定至少一种的可验证的联系方式,并通过自定义密码登录。
CN202010445149.6A 2020-05-23 2020-05-23 基于条目式的记事记账计数计件项目管理方法 Pending CN111626702A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010445149.6A CN111626702A (zh) 2020-05-23 2020-05-23 基于条目式的记事记账计数计件项目管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010445149.6A CN111626702A (zh) 2020-05-23 2020-05-23 基于条目式的记事记账计数计件项目管理方法

Publications (1)

Publication Number Publication Date
CN111626702A true CN111626702A (zh) 2020-09-04

Family

ID=72271064

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010445149.6A Pending CN111626702A (zh) 2020-05-23 2020-05-23 基于条目式的记事记账计数计件项目管理方法

Country Status (1)

Country Link
CN (1) CN111626702A (zh)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107220331A (zh) * 2017-05-24 2017-09-29 成都明途科技有限公司 一种多维式的数据管理方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107220331A (zh) * 2017-05-24 2017-09-29 成都明途科技有限公司 一种多维式的数据管理方法

Similar Documents

Publication Publication Date Title
CN112950162B (zh) 信息系统工程监理工作派发管理信息系统
CN111815168B (zh) 信息系统工程监理项目质量管理系统
CN108090823B (zh) 基于SaaS的账务数据管理系统
CN108133299A (zh) 一种智能项目管理系统
CN110751361B (zh) 一种银行需求条目级管理方法及系统
US20080201157A1 (en) Methods, systems, and computer software utilizing xbrl to electronically link the accounting records of multi-period contracts and multi-period loans and grants for management
CN103903081A (zh) 利用erp系统中的涉税单据数据生成涉税凭证的方法和系统
CN109214892A (zh) 一种电子商务平台管理系统
CN112581283A (zh) 商业银行员工交易行为分析及告警的方法及装置
CN115170090A (zh) 一种项目管理方法、装置、电子设备及可读存储介质
US20210272113A1 (en) Transaction audit system
Accorsi et al. A practitioner’s view on process mining adoption, event log engineering and data challenges
TWM582187U (zh) Supply chain financial service system combining big data information in blockchain technology
CN109508947A (zh) 一种基于信用体系的电子合同运营方法及系统
CN111626703A (zh) 基于条目式的记事记账计数计件项目管理系统
CN107924534A (zh) 用于结构性融资的信贷管理的银行系统、方法以及程序
JP2003296554A (ja) 取引先要項システム
CN111626702A (zh) 基于条目式的记事记账计数计件项目管理方法
Chiantera Data quality and data governance in insurance corporations
Singh A conceptual model for proactive detection of potential fraud enterprise systems: exploiting SAP audit trails to detect asset misappropriation
Xiong et al. Financial Risk Control and Audit of Supply Chain under the Information Technology Environment
Alamaki et al. The Effectiveness of Regulatory Reporting by Banking Institutions
Pierce Extending IP-MAPS: Incorporating the Event-Driven Process Chain Methodology.
Li et al. Application study of a classification and encoding system in meticulous management of Zhengzhou Metro enterprises
TR2022011307A1 (tr) Sözleşme di̇ji̇tali̇zasyonu, ki̇ra süreç yöneti̇mi̇ ve taraflar ri̇sk skorlama si̇stemi̇

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20200904

WD01 Invention patent application deemed withdrawn after publication