CN107563763A - 一种防止餐费余额负数方法、*** - Google Patents
一种防止餐费余额负数方法、*** Download PDFInfo
- Publication number
- CN107563763A CN107563763A CN201710791002.0A CN201710791002A CN107563763A CN 107563763 A CN107563763 A CN 107563763A CN 201710791002 A CN201710791002 A CN 201710791002A CN 107563763 A CN107563763 A CN 107563763A
- Authority
- CN
- China
- Prior art keywords
- meal
- time
- current
- card
- user
- 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
Links
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
本发明公开了一种防止餐费余额负数方法、***,包括了客户端和后端服务器,客户端和后端服务器通过网络进行连接,包括了防止餐费余额出现负数的过程:步骤A:用户通过客户端进行预报用餐登记,用户使用餐卡在刷卡机上刷卡,将***传输到后端服务器;步骤B:后端服务器根据***获取用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;步骤C:后端服务器根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;步骤D:后端服务器根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,再用需扣除的餐费与卡上余额进行对比。以防止餐费余额出现负数并且可以避免用户在余额不足时无饭可吃。
Description
技术领域
本发明涉及餐饮管理领域,尤其涉及一种防止餐费余额负数方法、***。
背景技术
在一些大型企事业单位中,单位员工均在食堂统一就餐,一般采用刷卡取餐模式,在用餐时间内,如果用户卡上余额不足则无法取餐,这将导致用餐人没饭吃,所以为了更显得人性化,将设置卡上余额不足餐费时,也可取餐;当时如果用户刷卡取餐且余额小于当前餐次餐费时,可以取餐吃饭,但必定会导致余额出现负数,如此情况出现较多的话,可能会造成经营亏损。所以,需要经过双重处理,才能减少用户余额出现负数但在余额不足时也有饭吃。
发明内容
本发明的目的在于提出一种防止餐费余额出现负数并且避免用户在余额不足时无饭可吃的防止餐费余额负数的方法、***。
为达此目的,本发明采用以下技术方案:
一种防止餐费余额负数方法,包括客户端和后端服务器,所述客户端和所述后端服务器通过网络进行连接,包括了防止餐费余额出现负数的过程:
步骤A::用户通过所述客户端进行预报用餐登记,用户使用餐卡在刷卡机上刷卡,刷卡机获取餐卡***,再将***传输到所述后端服务器;
步骤B:所述后端服务器收到***,根据***获取用户所设置的取餐时间范围,所述后端服务器根据用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;
若在当前取餐时间范围内,则获取取餐时间范围内的当前餐次;
若不在当前取餐时间范围内,则提示现在非取餐时间;
步骤C:所述后端服务器再根据***获取当前用户的余额和卡类型的信息,根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;
若当前餐次为预报餐次,则按照有报有取的餐费进行结算;
若当前餐次不是预报餐次,则按照没报有取的餐费进行结算;
步骤D:所述后端服务器根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,再用需扣除的餐费与卡上余额进行对比;
若需扣除的餐费大于卡上余额,则当前餐次可取并扣费,同时提示充值和欠费金额并删除后面未扣费的预报用餐登记记录;
若需扣除的餐费小于卡上余额,则当前餐次可取并扣费。
优选的,包括了预报用餐的登记过程:
步骤A1:用户通过所述客户端进入预报用餐页面,提交某餐次的订餐操作,然后所述后端服务器接收报餐数据并根据用户信息获取当前余额和所属卡类型的信息;
步骤A2:所述后端服务器再获取当前用户未扣除费用的预报餐记录,并按照早午晚三类进行分组,统计出各餐次总数量,用各餐次总数量分别乘以对应餐次的费用并将各结果相加,得出已报餐但未扣除费用的总金额;
再根据当前用户卡类型获取早午晚三类餐次的有报有取的费用列表,得出有报有取的已扣费的总金额;
步骤A3:将已报餐但未扣除费用的总金额和有报有取的已扣费的总金额相加,得出预扣总金额;
用预扣总金额与当前用户余额对比,若预扣总金额大于当前用户余额,则提示不可报餐;若预扣总金额小于当前用户余额,则提示报餐成功。
优选的,使用一种防止餐费余额负数方法的***,包括了客户端和后端服务器,所述客户端和所述后端服务器通过网络进行连接,包括了防止餐费余额负数模块;
用户通过所述客户端进行预报用餐登记,用户使用餐卡在刷卡机上刷卡,刷卡机获取餐卡***,再将***传输到所述后端服务器;
所述后端服务器根据***获取用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;
所述后端服务器再根据***获取当前用户的余额和卡类型的信息,根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;
所述后端服务器根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,利用餐卡余额进行扣费。
优选的,所述后端服务器包括了取餐时间判断模块,用于判断当前时间是否可以取餐;
所述后端服务器收到***,根据***获取用户所设置的取餐时间范围,所述后端服务器根据用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;
若在当前取餐时间范围内,则获取取餐时间范围内的当前餐次;
若不在当前取餐时间范围内,则提示现在非取餐时间。
优选的,所述后端服务器包括了预报餐次判断模块,用于判断当前餐次是否为预报餐次,根据餐次类型进行餐费结算;
所述后端服务器根据***获取当前用户的卡类型的信息,根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;
若当前餐次为预报餐次,则按照有报有取的餐费进行结算;
若当前餐次不是预报餐次,则按照没报有取的餐费进行结算;
优选的,所述后端服务器还包括了:餐费扣除模块,用于判断余额是否足够扣除餐费;
所述后端服务器根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,再用需扣除的餐费与卡上余额进行对比;
若需扣除的餐费大于卡上余额,则当前餐次可取并扣费,同时提示充值和欠费金额并删除后面未扣费的预报用餐登记记录;
若需扣除的餐费小于卡上余额,则当前餐次可取并扣费。
优选的,所述客户端和所述后端服务器还包括了报餐模块,用于用户提前报餐并方便取餐时的扣费;
用户通过所述客户端进入预报用餐页面,提交某餐次的订餐操作,然后所述后端服务器接收报餐数据根据用户信息获取当前余额和所属卡类型的信息;
所述后端服务器再获取当前用户未扣除费用的预报餐记录,并按照早午晚三类进行分组,统计出各餐次总数量,用各餐次总数量分别乘以对应餐次的费用并将各结果相加,得出已报餐但未扣除费用的总金额;
再根据当前用户卡类型获取早午晚三类餐次的有报有取的费用列表,得出有报有取的已扣费的总金额;将已报餐但未扣除费用的总金额和有报有取的已扣费的总金额相加,得出预扣总金额;
用预扣总金额与当前用户余额对比,若预扣总金额大于当前用户余额,则提示不可报餐;若预扣总金额小于当前用户余额,则提示报餐成功。
附图说明
图1是本发明的防止餐费余额负数的过程流程图;
图2是本发明的预报用餐登记过程流程图。
其中:客户端1、后端服务器2。
具体实施方式
下面结合附图并通过具体实施方式来进一步说明本发明的技术方案。
本实施例的一种防止餐费余额负数方法,如图1所示,包括客户端1和后端服务器2,所述客户端1和所述后端服务器2通过网络进行连接,包括了防止餐费余额出现负数的过程:
步骤A::用户通过所述客户端1进行预报用餐登记,用户使用餐卡在刷卡机上刷卡,刷卡机获取餐卡***,再将***传输到所述后端服务器2;
步骤B:所述后端服务器2收到***,根据***获取用户所设置的取餐时间范围,所述后端服务器2根据用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;
若在当前取餐时间范围内,则获取取餐时间范围内的当前餐次;
若不在当前取餐时间范围内,则提示现在非取餐时间;
步骤C:所述后端服务器2再根据***获取当前用户的余额和卡类型的信息,根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;
若当前餐次为预报餐次,则按照有报有取的餐费进行结算;
若当前餐次不是预报餐次,则按照没报有取的餐费进行结算;
步骤D:所述后端服务器2根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,再用需扣除的餐费与卡上余额进行对比;
若需扣除的餐费大于卡上余额,则当前餐次可取并扣费,同时提示充值和欠费金额并删除后面未扣费的预报用餐登记记录;
若需扣除的餐费小于卡上余额,则当前餐次可取并扣费。
优选的,如图2所示,包括了预报用餐的登记过程:
步骤A1:用户通过所述客户端1进入预报用餐页面,提交某餐次的订餐操作,然后所述后端服务器2接收报餐数据并根据用户信息获取当前余额和所属卡类型的信息;
步骤A2:所述后端服务器2再获取当前用户未扣除费用的预报餐记录,并按照早午晚三类进行分组,统计出各餐次总数量,用各餐次总数量分别乘以对应餐次的费用并将各结果相加,得出已报餐但未扣除费用的总金额;
再根据当前用户卡类型获取早午晚三类餐次的有报有取的费用列表,得出有报有取的已扣费的总金额;
步骤A3:将已报餐但未扣除费用的总金额和有报有取的已扣费的总金额相加,得出预扣总金额;
用预扣总金额与当前用户余额对比,若预扣总金额大于当前用户余额,则提示不可报餐;若预扣总金额小于当前用户余额,则提示报餐成功。
优选的,使用一种防止餐费余额负数方法的***,包括了客户端1和后端服务器2,所述客户端1和所述后端服务器2通过网络进行连接,包括了防止餐费余额负数模块;
用户通过所述客户端1进行预报用餐登记,用户使用餐卡在刷卡机上刷卡,刷卡机获取餐卡***,再将***传输到所述后端服务器2;
所述后端服务器2根据***获取用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;
所述后端服务器2再根据***获取当前用户的余额和卡类型的信息,根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;
所述后端服务器2根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,利用餐卡余额进行扣费。
优选的,所述后端服务器2包括了取餐时间判断模块,用于判断当前时间是否可以取餐;
所述后端服务器2收到***,根据***获取用户所设置的取餐时间范围,所述后端服务器2根据用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;
若在当前取餐时间范围内,则获取取餐时间范围内的当前餐次;
若不在当前取餐时间范围内,则提示现在非取餐时间。
优选的,所述后端服务器2包括了预报餐次判断模块,用于判断当前餐次是否为预报餐次,根据餐次类型进行餐费结算;
所述后端服务器2根据***获取当前用户的卡类型的信息,根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;
若当前餐次为预报餐次,则按照有报有取的餐费进行结算;
若当前餐次不是预报餐次,则按照没报有取的餐费进行结算;
优选的,所述后端服务器2还包括了:餐费扣除模块,用于判断余额是否足够扣除餐费;
所述后端服务器2根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,再用需扣除的餐费与卡上余额进行对比;
若需扣除的餐费大于卡上余额,则当前餐次可取并扣费,同时提示充值和欠费金额并删除后面未扣费的预报用餐登记记录;
若需扣除的餐费小于卡上余额,则当前餐次可取并扣费。
以上结合具体实施例描述了本发明的技术原理。这些描述只是为了解释本发明的原理,而不能以任何方式解释为对本发明保护范围的限制。基于此处的解释,本领域的技术人员不需要付出创造性的劳动即可联想到本发明的其它具体实施方式,这些方式都将落入本发明的保护范围之内。
Claims (7)
1.一种防止餐费余额负数方法,包括客户端和后端服务器,所述客户端和所述后端服务器通过网络进行连接,其特征在于:包括了防止餐费余额出现负数的过程:
步骤A::用户通过所述客户端进行预报用餐登记,用户使用餐卡在刷卡机上刷卡,刷卡机获取餐卡***,再将***传输到所述后端服务器;
步骤B:所述后端服务器收到***,根据***获取用户所设置的取餐时间范围,所述后端服务器根据用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;
若在当前取餐时间范围内,则获取取餐时间范围内的当前餐次;
若不在当前取餐时间范围内,则提示现在非取餐时间;
步骤C:所述后端服务器再根据***获取当前用户的余额和卡类型的信息,根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;
若当前餐次为预报餐次,则按照有报有取的餐费进行结算;
若当前餐次不是预报餐次,则按照没报有取的餐费进行结算;
步骤D:所述后端服务器根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,再用需扣除的餐费与卡上余额进行对比;
若需扣除的餐费大于卡上余额,则当前餐次可取并扣费,同时提示充值和欠费金额并删除后面未扣费的预报用餐登记记录;
若需扣除的餐费小于卡上余额,则当前餐次可取并扣费。
2.根据权利要求1所述一种防止餐费余额负数方法,其特征在于:包括了预报用餐的登记过程:
步骤A1:用户通过所述客户端进入预报用餐页面,提交某餐次的订餐操作,然后所述后端服务器接收报餐数据并根据用户信息获取当前余额和所属卡类型 的信息;
步骤A2:所述后端服务器再获取当前用户未扣除费用的预报餐记录,并按照早午晚三类进行分组,统计出各餐次总数量,用各餐次总数量分别乘以对应餐次的费用并将各结果相加,得出已报餐但未扣除费用的总金额;
再根据当前用户卡类型获取早午晚三类餐次的有报有取的费用列表,得出有报有取的已扣费的总金额;
步骤A3:将已报餐但未扣除费用的总金额和有报有取的已扣费的总金额相加,得出预扣总金额;
用预扣总金额与当前用户余额对比,若预扣总金额大于当前用户余额,则提示不可报餐;若预扣总金额小于当前用户余额,则提示报餐成功。
3.使用一种防止餐费余额负数方法的***,包括了客户端和后端服务器,所述客户端和所述后端服务器通过网络进行连接,其特征在于:包括了防止餐费余额负数模块;
用户通过所述客户端进行预报用餐登记,用户使用餐卡在刷卡机上刷卡,刷卡机获取餐卡***,再将***传输到所述后端服务器;
所述后端服务器根据***获取用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;
所述后端服务器再根据***获取当前用户的余额和卡类型的信息,根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;
所述后端服务器根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,利用餐卡余额进行扣费。
4.根据权利要求3所述一种防止餐费余额负数方法的***,其特征在于:
所述后端服务器包括了取餐时间判断模块,用于判断当前时间是否可以取 餐;
所述后端服务器收到***,根据***获取用户所设置的取餐时间范围,所述后端服务器根据用户所设置的取餐时间范围,判断当前时间是否在取餐时间范围内;
若在当前取餐时间范围内,则获取取餐时间范围内的当前餐次;
若不在当前取餐时间范围内,则提示现在非取餐时间。
5.根据权利要求3所述一种防止餐费余额负数方法的***,其特征在于:所述后端服务器包括了预报餐次判断模块,用于判断当前餐次是否为预报餐次,根据餐次类型进行餐费结算;
所述后端服务器根据***获取当前用户的卡类型的信息,根据当前用户卡类型获取当前餐次费用列表并判断当前餐次是否为预报餐次;
若当前餐次为预报餐次,则按照有报有取的餐费进行结算;
若当前餐次不是预报餐次,则按照没报有取的餐费进行结算。
6.根据权利要求3所述一种防止餐费余额负数方法的***,其特征在于:所述后端服务器还包括了:餐费扣除模块,用于判断余额是否足够扣除餐费;
所述后端服务器根据当前餐次是否为有报餐次和餐次费用列表结算需扣除的餐费,再用需扣除的餐费与卡上余额进行对比;
若需扣除的餐费大于卡上余额,则当前餐次可取并扣费,同时提示充值和欠费金额并删除后面未扣费的预报用餐登记记录;
若需扣除的餐费小于卡上余额,则当前餐次可取并扣费。
7.根据权利要求所述一种防止餐费余额负数方法的***,其特征在于:所述客户端和所述后端服务器还包括了报餐模块,用于用户提前报餐并方便取餐时的扣费;
用户通过所述客户端进入预报用餐页面,提交某餐次的订餐操作,然后所述后端服务器接收报餐数据根据用户信息获取当前余额和所属卡类型的信息;
所述后端服务器再获取当前用户未扣除费用的预报餐记录,并按照早午晚三类进行分组,统计出各餐次总数量,用各餐次总数量分别乘以对应餐次的费用并将各结果相加,得出已报餐但未扣除费用的总金额;
再根据当前用户卡类型获取早午晚三类餐次的有报有取的费用列表,得出有报有取的已扣费的总金额;将已报餐但未扣除费用的总金额和有报有取的已扣费的总金额相加,得出预扣总金额;
用预扣总金额与当前用户余额对比,若预扣总金额大于当前用户余额,则提示不可报餐;若预扣总金额小于当前用户余额,则提示报餐成功。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710791002.0A CN107563763A (zh) | 2017-09-05 | 2017-09-05 | 一种防止餐费余额负数方法、*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710791002.0A CN107563763A (zh) | 2017-09-05 | 2017-09-05 | 一种防止餐费余额负数方法、*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN107563763A true CN107563763A (zh) | 2018-01-09 |
Family
ID=60979270
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710791002.0A Pending CN107563763A (zh) | 2017-09-05 | 2017-09-05 | 一种防止餐费余额负数方法、*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107563763A (zh) |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20080034707A (ko) * | 2006-10-17 | 2008-04-22 | 김덕겸 | 알에프-아이디를 이용한 급식관리 시스템 및 관리 방법 |
CN102214372A (zh) * | 2010-04-06 | 2011-10-12 | 朱振明 | 食堂自助预约售饭*** |
CN102789596A (zh) * | 2011-05-17 | 2012-11-21 | 徐建军 | 一种订餐处理流程 |
CN104157130A (zh) * | 2013-05-14 | 2014-11-19 | 成都国腾电子集团有限公司 | 一种基于移动互联网的停车管理***及车位预定方法 |
CN104915718A (zh) * | 2014-03-11 | 2015-09-16 | 遵义市亿易通科技网络有限责任公司 | 企业食堂订餐*** |
CN105303238A (zh) * | 2014-07-18 | 2016-02-03 | 上海市闵行第二中学 | 网络订餐方法及其订餐*** |
CN105976276A (zh) * | 2016-05-17 | 2016-09-28 | 中国计量学院 | 一种食堂订餐传菜装置及其控制方法 |
-
2017
- 2017-09-05 CN CN201710791002.0A patent/CN107563763A/zh active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20080034707A (ko) * | 2006-10-17 | 2008-04-22 | 김덕겸 | 알에프-아이디를 이용한 급식관리 시스템 및 관리 방법 |
CN102214372A (zh) * | 2010-04-06 | 2011-10-12 | 朱振明 | 食堂自助预约售饭*** |
CN102789596A (zh) * | 2011-05-17 | 2012-11-21 | 徐建军 | 一种订餐处理流程 |
CN104157130A (zh) * | 2013-05-14 | 2014-11-19 | 成都国腾电子集团有限公司 | 一种基于移动互联网的停车管理***及车位预定方法 |
CN104915718A (zh) * | 2014-03-11 | 2015-09-16 | 遵义市亿易通科技网络有限责任公司 | 企业食堂订餐*** |
CN105303238A (zh) * | 2014-07-18 | 2016-02-03 | 上海市闵行第二中学 | 网络订餐方法及其订餐*** |
CN105976276A (zh) * | 2016-05-17 | 2016-09-28 | 中国计量学院 | 一种食堂订餐传菜装置及其控制方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107833341B (zh) | 一种智能排队方法、设备及计算机可读存储介质 | |
CN102521909B (zh) | 排队服务处理方法及*** | |
CN105989653A (zh) | 一种医疗信息处理方法、装置、就诊***及自助终端 | |
CN105632004B (zh) | 一种多功能排队叫号*** | |
CN109242726A (zh) | 一种基于快递柜的酒店业务自助办理的方法及快递柜 | |
CN204537307U (zh) | 基于指纹识别的自助缴费终端 | |
CN106355784B (zh) | 一种用于atm设备的清机对账方法及*** | |
CN104103113A (zh) | 排队服务器以及排队方法 | |
KR20190070218A (ko) | 가상 화폐 투자 및 분배를 위한 시스템 및 방법 | |
CN107657325A (zh) | 一种政务业务的预约方法及*** | |
CN111160884A (zh) | 聚合支付方法、***、服务器及存储介质 | |
CN205507960U (zh) | 一种基于自助挂号机的快速挂号*** | |
CN102982492A (zh) | 一种分时段预约挂号平台 | |
CN109191104A (zh) | 一种信息处理方法及其设备 | |
CN108665273A (zh) | 停车优惠管理方法、服务器及可读存储介质 | |
CN106651368A (zh) | 防刷单的支付方式的控制方法及控制*** | |
CN110705980A (zh) | 基于数据分析处理交易支付操作的方法、装置及存储介质 | |
CN109410027A (zh) | 一种基于特征识别的金融信息处理方法、智能终端及介质 | |
CN106408100A (zh) | 一种智能预约挂号***及方法 | |
CN109325664A (zh) | 一种数据可视化处理方法、装置、服务器及介质 | |
CN113011863A (zh) | 账单管理方法及装置 | |
CN107688994A (zh) | 账单记录方法、装置、存储介质及终端 | |
CN204537335U (zh) | 基于挂号号码的自助缴费终端 | |
CN101452586A (zh) | 银行用自动按服务种类分配柜台的智能排队机***和方法 | |
CN107563763A (zh) | 一种防止餐费余额负数方法、*** |
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 | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180109 |