离线考勤的处理方法及装置与流程

本申请涉及通讯技术领域，尤其涉及一种离线考勤的处理方法及装置。

背景技术：

团体管理人员需要通过了解团体成员的考勤状况，以了解团体的运营状态，从而通过采取相应的管理措施。因此，需要准确获得团体成员的考勤相关数据，并及时、有效地传递给团体管理人员，以确保团体的良性运作。

技术实现要素：

有鉴于此，本申请提供一种离线考勤的处理方法及装置，可以实现离线考勤，便于团队的考勤管理。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种离线考勤的处理方法，应用于客户端，该方法包括：

检测到在离线状态下发生于预设页面的考勤触发事件；

当预定义的数据传输条件未满足时，将所述考勤触发事件对应的考勤相关数据缓存于所述客户端；

当所述数据传输条件被满足后，将所述考勤相关数据传输至服务器。

根据本申请的第二方面，提出了一种离线考勤的处理方法，包括：

接收客户端上传的考勤相关数据；

当所述考勤相关数据非实时上传数据时，获取所述考勤相关数据对应的考勤触发事件的发生时刻；其中，所述考勤触发事件在离线状态下发生于所 述客户端的预设页面；

选取与所述发生时刻相匹配的考勤规则，并根据所述考勤相关数据和被选中的考勤规则得到相应的考勤状况信息。

根据本申请的第三方面，提出了一种考勤处理方法，包括：

检测到发生于即时通讯应用的预设考勤页面的考勤触发事件；

当未建立网络连接时，对所述考勤触发事件对应的考勤相关数据进行缓存；

当所述网络连接恢复后，将所述考勤相关数据传输至服务器。

根据本申请的第四方面，提出了一种离线考勤的处理装置，应用于客户端，该装置包括：

检测单元，检测到在离线状态下发生于预设页面的考勤触发事件；

缓存单元，当预定义的数据传输条件未满足时，将所述考勤触发事件对应的考勤相关数据缓存于所述客户端；

传输单元，当所述数据传输条件被满足后，将所述考勤相关数据传输至服务器。

根据本申请的第五方面，提出了一种离线考勤的处理装置，包括：

接收单元，接收客户端上传的考勤相关数据；

获取单元，当所述考勤相关数据非实时上传数据时，获取所述考勤相关数据对应的考勤触发事件的发生时刻；其中，所述考勤触发事件在离线状态下发生于所述客户端的预设页面；

处理单元，选取与所述发生时刻相匹配的考勤规则，并根据所述考勤相关数据和被选中的考勤规则得到相应的考勤状况信息。

根据本申请的第六方面，提出了一种考勤处理装置，包括：

检测单元，检测到发生于即时通讯应用的预设考勤页面的考勤触发事件；

缓存单元，当未建立网络连接时，对所述考勤触发事件对应的考勤相关数据进行缓存；

传输单元，当所述网络连接恢复后，将所述考勤相关数据传输至服务器。

由以上技术方案可见，本申请通过接收用户在离线状态下促成的考勤触发事件，并对数据传输条件的满足状况进行判断，可以在该数据传输条件未被满足的情况下，对考勤相关数据进行本地化的离线暂存，从而在数据传输条件被满足后，通过将考勤相关数据传输至服务器，可以及时将考勤相关数据传递至团队管理人员，以便于实现团队管理。

附图说明

图1a-1b是本申请一示例性实施例提供的基于客户端侧的一种离线考勤的处理方法的流程图。

图2是本申请一示例性实施例提供的一种实现离线考勤管理功能的系统架构图。

图3-4是本申请一示例性实施例提供的一种实现离线考勤管理功能的界面示意图。

图5是本申请一示例性实施例提供的基于客户端侧的另一种离线考勤的处理方法的流程图。

图6-9是本申请一示例性实施例提供的另一种实现离线考勤管理功能的界面示意图。

图10是本申请一示例性实施例提供的基于客户端侧的又一种离线考勤的处理方法的流程图。

图11是本申请一示例性实施例提供的基于客户端侧的又一种离线考勤的处理方法的流程图。

图12是本申请一示例性实施例提供的又一种实现离线考勤管理功能的界面示意图。

图13是本申请一示例性实施例提供的基于服务端侧的又一种离线考勤的处理方法的流程图。

图14是本申请一示例性实施例提供的另一种实现离线考勤管理功能的系统架构图。

图15是本申请一示例性实施例提供的基于客户端侧的一种电子设备的结构示意图。

图16是本申请一示例性实施例提供的基于客户端侧的一种离线考勤的处理装置的框图。

图17是本申请一示例性实施例提供的基于服务端侧的一种电子设备的结构示意图。

图18是本申请一示例性实施例提供的基于服务端侧的一种离线考勤的处理装置的框图。

图19是本申请一示例性实施例提供的基于客户端侧的一种电子设备的结构示意图。

图20是本申请一示例性实施例提供的基于客户端侧的一种离线考勤的处理装置的框图。

具体实施方式

为对本申请进行进一步说明，提供下列实施例：

图1a是本申请一示例性实施例提供的一种离线考勤的处理方法的流程图，如图1a所示，该方法应用于电子设备上的客户端中，可以包括以下步骤：

步骤102，检测到在离线状态下发生于预设页面的考勤触发事件。

在本实施例中，电子设备安装有具备考勤管理功能的应用程序的客户端，该应用程序运行后，可以向用户输出和展示诸如考勤页面等预设页面，并通过检测用户对该预设页面的考勤触发事件，从而完成用户考勤操作。尤其需要指出的是：在本申请的技术方案中，针对的是电子设备处于离线状态下的应用场景；换言之，即便电子设备处于离线状态下，用户仍然可以通过对预设页面的触发操作，使电子设备能够检测到相应的考勤触发事件，以确保在任意状况下均能够实现对用户的考勤管理。

在本实施例中，电子设备中安装的应用程序可以为即时通讯应用，该即 时通讯应用除了具备即时通讯功能之外，还具备考勤管理功能，从而可以实现对考勤触发事件的检测行为。举例而言，该即时通讯应用可以为企业即时通讯应用(eim，enterpriseinstantmessaging)，例如“钉钉(dingtalk)”等，当然本申请并不对此进行限制。

步骤104，当预定义的数据传输条件未满足时，将所述考勤触发事件对应的考勤相关数据缓存于所述客户端。

步骤106，当所述数据传输条件被满足后，将所述考勤相关数据传输至服务器。

在本实施例中，预定义的数据传输条件可以包括以下至少之一：已连接至预设网络、网络信号强度达到预设强度等；实际场景中，可以根据需要选取和调整该数据传输条件，本申请并不对此进行限制。

正如上文所述，本申请的技术方案可以应用于即时通讯应用，则图1b示出了相应的考勤处理方法的流程图，如图1b所示，该方法可以包括以下步骤：

步骤s102，检测到发生于即时通讯应用的预设考勤页面的考勤触发事件。

在本实施例中，考勤触发事件可以在离线状态下发生于预设考勤页面，从而实现与图1a所示实施例相似的离线考勤功能。

步骤s104，当未建立网络连接时，对所述考勤触发事件对应的考勤相关数据进行缓存。

步骤s106，当所述网络连接恢复后，将所述考勤相关数据传输至服务器。

在本实施例中，通过将考勤功能结合于即时通讯应用中，使得用户可以充分利用即时通讯应用的移动性和便捷性，方便执行考勤操作，且不需要购买和添加任何专门的考勤管理设备；同时，基于本申请的离线考勤功能，即便由于信号覆盖不足而导致无法建立网络连接，仍然可以实现考勤管理，不会造成对企业或其他团体的管理困难。

由以上技术方案可见，本申请通过接收用户在离线状态下促成的考勤触发事件，并对数据传输条件的满足状况进行判断，可以在该数据传输条件未 被满足的情况下，对考勤相关数据进行本地化的离线暂存，从而在数据传输条件被满足后，通过将考勤相关数据传输至服务器，可以及时将考勤相关数据传递至团队管理人员，以便于实现团队管理。

图2是本申请一示例性实施例提供的一种实现离线考勤管理功能的系统架构图，如图2所示，该系统架构可以包括服务端、客户端和前端三个部分，其中服务端可以由服务器进行承载，而客户端和前端则表现为用户的电子设备中安装的应用程序(比如上述的企业即时通讯应用“钉钉”等)。需要指出的是：在一种情况下，用户在安装应用程序时，可以同时完成对客户端和前端的安装，那么当用户启动应用程序并在图3所示的“微应用”页面选中“考勤”图标后，只需利用安装时配置于电子设备的本地数据，即可呈现出图4所示的前端考勤页面，以及该前端考勤页面中包含的打卡选项(比如图4中间的圆形“打卡”按钮)；在另一种情况下，用户在安装应用程序时，可以仅安装客户端，那么当用户启动应用程序并在图3所示的“微应用”页面选中“考勤”图标后，可以下载相关的页面数据并呈现图4所示的前端考勤页面以及打卡选项，比如该前端考勤页面及其打卡选项可以通过html5技术来实现。当然，不论采用何种方式，前端与客户端之间均可以通过必要的数据交互，实现本申请的技术方案，本申请并不对此进行限制。在图2中，前端中的“前端考勤页面”表示用于实现前端考勤页面的数据和功能，以及“打卡选项”表示用于实现该前端考勤页面中的打卡选项的数据和功能；类似地，客户端中的“存储”表示用于实现存储功能，以及“考勤规则”表示用于实现考勤规则的功能和该考勤规则的数据本身、“打卡数据”表示用于处理打卡数据的功能和该打卡数据本身等，此处不再一一描述。

为了便于理解，下面结合图5及相关附图，针对图2所示的系统架构和本申请的离线考勤处理方案进行详细说明；其中，图5是本申请一示例性实施例提供的另一种离线考勤的处理方法的流程图，如图5所示，该方法可以包括以下步骤：

步骤502，检测到考勤触发事件。其中，当预定义的数据传输条件未满 足时，转入步骤504a；当该数据传输条件被满足时，转入步骤504b。

在本实施例中，当检测到用户在预设页面(比如上述的前端考勤页面)的预设操作时，可以判定为检测到考勤触发事件；比如图4所示，该预设操作可以包括用户对圆形“打卡”按钮的点击操作。其中，考勤触发事件可以是在电子设备处于离线状态时检测到；换言之，即便电子设备处于离线状态下，仍然可以示出诸如图4所示的前端考勤页面，使得用户可以通过对该前端考勤页面的触发操作，使电子设备能够检测到相应的考勤触发事件，以确保在任意状况下均能够实现对用户的考勤管理。

在本实施例中，数据传输条件可以为任意预定义条件，客户端可以根据实际状况对该数据传输条件的满足情况，确定采取的处理方案；举例而言，数据传输条件可以包括以下至少之一：已连接至预设网络、网络信号强度达到预设强度。

1)已连接至预设网络。一种情况下，该预设网络为任意可与服务端产生数据交互的网络，比如电子设备的3g、4g等无线移动通讯网络或者wifi局域网络等，那么相应的数据传输条件可以理解为：通过连接到该预设网络，使得客户端可以与服务端进行数据连接和交互，从而将诸如考勤相关数据上传至服务端。另一种情况下，该预设网络为预定义的特定网络，比如公司内部的wifi局域网络等，那么相应的数据传输条件可以理解为：只有连接至该特定网络时，才判定为满足数据传输条件；而即便已连接的其他网络可与服务端产生数据交互，但出于信息安全等方面的因素，仍然判定为未满足数据传输条件。

2)网络信号强度达到预设强度。通过对网络信号强度的获取和比较，实际上是确定相应的预设网络是否足够稳定；其中，当网络信号强度达到预设强度时，认为该预设网络能够将考勤相关数据上传至服务端，从而判定为满足数据传输条件。

步骤504a，读取本地存储的考勤规则。

在本实施例中，如图2所示，可以由前端考勤页面向客户端发起规则请 求后，由客户端将存储的考勤规则返回前端考勤页面，并在前端考勤页面中呈现为如图4所示的“上班时间09:00”、“下班时间18:00”等信息，且这些时刻可以作为相应考勤触发事件的判断标准，即用于判断用户是否正常打卡、迟到、早退等。类似的，考勤规则还可以包括考勤地点信息，比如“xx省xx市xx区xx大厦”等，同样可以用于对考勤状况进行判断，此处不再一一列举和赘述。

步骤506a，获得第一考勤状况信息。

在本实施例中，如图2所示，前端根据用户对打卡选项执行的操作，将相应的打卡信息返回客户端，并由客户端由此得到作为“打卡数据”的第一考勤状况信息；其中，该打卡信息实际上是对用户的考勤触发事件的描述信息，比如打卡时刻、地理位置等，客户端通过将考勤触发事件的描述信息与本地存储的考勤规则进行匹配，即可得到第一考勤状况信息，以作为图2所示的“打卡数据”；举例而言，考勤触发事件的描述信息可以为该考勤触发事件的发生时刻，假定该发生时刻为图4所示的“08:58”，而考勤规则对应的标准为“09:00”，则通过比较可知：用户属于正常打卡，并未存在迟到现象，即第一考勤状况信息可以为“正常打卡”。

在本实施例中，根据对数据传输条件的满足情况，可以在前端考勤页面中的考勤触发区域或区域附近，示出对应于满足情况的第一提醒信息；其中，该考勤触发区域用于触发考勤触发事件，比如图4所示的圆形“打卡”按钮的显示区域。那么，当数据传输条件被满足时，如图4所示，该第一提醒信息可以为考勤触发区域内的文字“打卡”等；以及，当数据传输条件未满足时，如图6所示，第一提醒信息可以为考勤触发区域内示出的预设图标等，以区分于上述的文字“打卡”等。

在本实施例中，客户端在接收到来自前端的打卡信息，或者根据该打卡信息获得打卡数据后，可以向前端返回打卡结果，则前端可以示出如图7所示的“打卡成功”以及打卡时刻“08:58”等，从而对用户起到提示作用，协助其执行后续操作。

步骤508a，将考勤相关数据缓存于本地离线队列。

在本实施例中，考勤相关数据可以包括任意与考勤触发事件相关的考勤数据，比如上述的第一考勤状况信息，以及考勤触发事件的描述信息等。

在本实施例中，通过将考勤相关数据缓存于本地离线队列，使得即便当前不满足数据传输条件、无法实时完成考勤，但仍然可以通过对考勤相关数据的离线缓存和异步上传，使得服务端最终得知该考勤相关数据，从而实现对用户的考勤管理。

步骤510，当数据传输条件被满足时，转入步骤512，否则继续等待。

步骤512，对客户端的本地离线队列进行上传操作，从而将本地离线队列中的数据上传至服务端。

在本实施例中，本地离线队列中包括上述的考勤相关数据，通过将该考勤相关数据上传至服务端，使得即便暂时无法满足数据传输条件，服务端仍然可以通过上述方式异步获得用户的离线的考勤相关数据，从而实现对相应用户的考勤管理。

在本实施例中，根据对考勤相关数据的上传情况，还可以在前端考勤页面中的考勤相关数据展示区域或区域附近，示出对应于该上传情况的第二提醒信息。举例而言，当数据传输条件未满足且考勤相关数据的上传情况为尚未上传时，第二提醒信息可以为图8中位于地理位置信息“xx省xx市xx区xx大厦”右侧的第一图标，该第一图标与图6所示的第一提醒信息相似，以表达出一脉相承的设计原理，并通过图8所示的“↑”箭头表现出“尚未完成上传”的状态；进一步地，当数据传输条件被满足且考勤相关数据的上传情况为已上传，则第二提醒信息可以为图9中位于地理位置信息“xx省xx市xx区xx大厦”右侧的第二图标，该第二图标与第一图标类似，但通过图9所示的“√”对勾表现出“已完成上传”的状态。

在本实施例中，除了对考勤相关数据的异步、离线上传，客户端还可以在数据传输条件未满足时，将与本地存储的考勤规则相关的更新请求加入本地离线队列，从而在数据传输条件被满足后，通过对本地离线队列的上传操 作，与服务端之间实现数据交互，从而更新本地存储的考勤规则，比如对考勤时间、考勤地点等的变化等；上述过程对应于图2所示架构图中由客户端的“考勤规则”→“离线队列”至服务端的“考勤规则”，以及由服务端的“考勤规则”返回客户端的“考勤规则”的数据传输路径。

步骤504b，在数据传输条件被满足的情况下，客户端可以更新考勤规则。

步骤506b，获得实时考勤状况信息。

步骤508b，将实时考勤状况信息上传至服务器。

在本实施例中，处理过程可以参考相关技术，此处不再赘述。其中，客户端除了可以在检测到考勤触发事件后更新考勤规则，还可以按照预设时长进行周期性地更新考勤规则，均可以确保对用户考勤的准确管理，本申请并不对此进行限制。

在图5所示的上述实施例中，由客户端直接对用户的考勤状况进行检测和判断，得到第一考勤状况信息，无需服务端进行判断；当然，考虑到客户端本地存储的考勤规则可能并非最近规则，比如原来的上班时间为“09:00”而更新后的上班时间为“08:30”，那么当打卡时刻为“08:58”时对于原来的考勤规则属于“正常打卡”、按照更新后的考勤规则属于“迟到”，所有可以在上传至服务器的考勤相关数据中包含考勤触发事件的描述信息，从而据此实现日后追溯。

图10是本申请一示例性实施例提供的另一种离线考勤的处理方法的流程图，如图10所示，该方法可以包括以下步骤：

步骤1002，检测到考勤触发事件。其中，当预定义的数据传输条件未满足时，转入步骤1004a；当该数据传输条件被满足时，转入步骤1004b。

步骤1004a，客户端缓存考勤相关数据。

在本实施例中，客户端可以将考勤相关数据添加至本地离线队列中；其中，考勤相关数据可以包括考勤触发事件的描述信息等。

步骤1006a，当数据传输条件被满足时，转入步骤1008a，否则继续等待。

步骤1008a，当考勤规则与考勤触发事件的发生时刻不匹配时，转入步骤1010，否则转入步骤1012。

步骤1010，客户端对本地存储的考勤规则进行更新。

步骤1012，客户端获得第二考勤状况信息。

在本实施例中，当确定本地存储的考勤规则与考勤触发事件的发生时刻不匹配时，可以从服务器处获取匹配于该发生时刻的考勤规则；从而通过将该考勤触发事件的描述信息与获得的考勤规则进行匹配，得到第二考勤状况信息；其中，上述的考勤相关数据中包含该第二考勤状况信息。

举例而言，假定当前时刻为“2016-02-2009:30”，考勤触发事件的发生时刻为“2016-02-1708:58”，那么：

如果客户端本地存储的考勤规则的最近更新时刻为“2016-02-1002:30”，且考勤规则在“2016-02-1602:30”发生过更新，那么考勤触发事件发生于考勤规则更新之后，若直接采用客户端本地存储的考勤规则进行判断，可能会导致相应的判断错误，即考勤规则与考勤触发事件的发生时刻不匹配。例如，客户端本地存储的考勤规则规定的上班时间为“09:00”，而考勤规则在

“2016-02-1602:30”更新后的考勤规则规定的上班时间为“08:30”，则考勤触发事件的发生时刻“2016-02-1708:58”对于客户端本地存储的考勤规则而言是“正常打卡”、对于更新后的考勤规则而言是“迟到”。其中，该实施例适用于步骤1008a→步骤1010→步骤1012的处理过程，可以确保客户端对考勤规则的及时更新，以保障第二考勤状况信息的正确性。

如果客户端本地存储的考勤规则的最近更新时刻为“2016-02-1002:30”，且考勤规则在“2016-02-1802:30”发生过更新，那么考勤触发事件发生于考勤规则更新之前，不应当采用更新后的考勤规则进行判断，而应当采用客户端本地存储的考勤规则进行判断，且不会导致相应的判断错误，即考勤规则与考勤触发事件的发生时刻相匹配。例如，客户端本地存储的考勤规则规定的上班时间为“09:00”，而考勤规则在“2016-02-1802:30”更新后的考勤规则规定的上班时间为“08:30”，则考勤触发事件的发生时刻“2016-02-17 08:58”应当采用客户端本地存储的考勤规则且打卡结果为“正常打卡”。其中，该实施例适用于步骤1008a→步骤1012的处理过程，使考勤规则匹配于考勤触发事件，以保障第二考勤状况信息的正确性。

然后，客户端可以将第二考勤状况信息添加至本地离线队列中的考勤相关数据中；其中，考勤相关数据中还可以包括考勤触发事件的发生时间、发生地理位置等描述信息。

步骤1014，对客户端的本地离线队列进行上传操作，从而将本地离线队列中的数据上传至服务端。

在本实施例中，对于本地离线队列的数据上传操作，可以参考图5所示实施例的步骤512，此处不再赘述。

步骤1004b，在数据传输条件被满足的情况下，客户端可以更新考勤规则。

步骤1006b，获得实时考勤状况信息。

步骤1008b，将实时考勤状况信息上传至服务器。

在本实施例中，对于本地离线队列的数据上传操作，可以参考图5所示实施例的步骤504b-508b，此处不再赘述。

除了通过诸如图5或图10所示的实施例，即由客户端直接获得用户的考勤状况，比如正常打卡、迟到、早退等，并上传至服务端之外，本申请的技术方案还提出了由服务端自行确定用户的考勤状况的处理过程，下面结合图11进行说明。如图11所示，该过程可以包括以下步骤：

步骤1102，检测到考勤触发事件。其中，当预定义的数据传输条件未满足时，转入步骤1104a；当该数据传输条件被满足时，转入步骤1104b。

步骤1104a，客户端缓存考勤相关数据。

在本实施例中，客户端可以将考勤相关数据添加至本地离线队列中；其中，考勤相关数据可以包括考勤触发事件的描述信息等。

步骤1106a，当数据传输条件被满足时，转入步骤1108a，否则继续等待。

步骤1108a，对客户端的本地离线队列进行上传操作，从而将本地离线队列中的数据上传至服务端。

在本实施例中，考勤相关数据中包含考勤触发事件的描述信息，比如打卡时刻(即考勤触发事件的发生时刻)、地理位置信息等，并由服务器根据该描述信息以及预定义的考勤规则得到第三考勤状况信息；其中，由于服务端存储有各个版本的考勤规则，因而服务端可以从中选取配合于当前的考勤触发事件的考勤规则，并据此得到第三考勤状况信息。

步骤1104b，在数据传输条件被满足的情况下，客户端可以更新考勤规则。

步骤1106b，获得实时考勤状况信息。

步骤1108b，将实时考勤状况信息上传至服务器。

在本实施例中，对于本地离线队列的数据上传操作，可以参考图5所示实施例的步骤504b-508b，此处不再赘述。

步骤1110，接收服务器推送的考勤状况通知消息。

步骤1112，展示出考勤状况通知消息中包含的第三考勤状况信息。

在本实施例中，步骤1104a～步骤1108a对应于图2所示架构图中虚线描绘的从客户端中“打卡数据”→“离线队列”至服务端中“打卡数据”的数据传输路径，表明考勤相关数据通过异步、离线方式上传至服务端，并实现相应的离线打卡功能；而步骤1104b～步骤1108b对应于图2所示架构图中实线描绘的从客户端中“打卡数据”至服务端中“打卡数据”的数据传输路径，表明考勤相关数据实时上传至服务端，以实现在线打卡功能。

在本实施例中，通过将第三考勤状况信息的生成过程移至服务端，使得客户端只需要对考勤相关数据进行暂时的离线缓存即可，无需考虑本地存储的考勤规则是否配合于考勤触发事件的描述信息，避免判断错误和反复更改。

在本实施例中，当服务端接收到客户端上传的考勤相关数据，并生成了相应的第三考勤状况信息后，可以通过向客户端推送如图12所示的考勤状态通知消息，以便用户查看到该第三考勤状况信息的具体内容，了解自身的考 勤情况。其中，图12所示的考勤状态通知消息中可以包含第三考勤状况信息的概略内容，比如“2016-02-1708:58正常打卡”、“2016-02-2008:58迟到”等；以及，当用户点击该考勤状态通知消息的“查看详情”后，可以查看相应的第三考勤状况信息的详情内容，此处不再赘述。

对应于图11所示的实施例，图13是本申请一示例性实施例提供的服务端侧的一种离线考勤的处理方法的流程图，如图13所示，该方法应用于服务器，可以包括以下步骤：

步骤1302，接收客户端上传的考勤相关数据。

步骤1304，当所述考勤相关数据非实时上传数据时，获取所述考勤相关数据对应的考勤触发事件的发生时刻；其中，所述考勤触发事件在离线状态下发生于所述客户端的预设页面；。

步骤1306，选取与所述发生时刻相匹配的考勤规则，并根据所述考勤相关数据和被选中的考勤规则得到相应的考勤状况信息。

在本实施例中，由于考勤相关数据是用户上传的非实时上传数据，导致该考勤相关数据并不一定匹配于服务端的最新考勤规则；因此，通过对考勤规则的配合选择，使得即便考勤规则发生变化和更新，服务器仍然能够选取最匹配于考勤相关数据的考勤规则，而避免直接使用最新考勤规则容易导致的判断错误，有助于确保考勤状况信息的正确性和准确性。

在本申请的技术方案中，还可以对图2所示的系统架构图进行改进，以得到图14所示的架构图；如图14所示，在图2所示实施例的基础上，该架构在客户端添加了“后台任务”、在前端添加了“前台任务”。举例而言，“前台任务”可以表现为考勤管理页面中的“更新”按键(图中未示出)，使得用户可以通过该按键来手动触发对诸如考勤规则的更新操作；类似地，可以在考勤管理页面中添加“上传”按键，使得用户可以通过该按键手动触发对考勤相关数据的离线上传操作。通过对上述“任务”的设定和配置，可以给用户带来更多的操作选择，以适应于不同使用场景，有助于提升用户体验。

图15示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图15，在硬件层面，该电子设备包括处理器1502、内部总线1504、网络接口1506、内存1508以及非易失性存储器1510，当然还可能包括其他业务所需要的硬件。处理器1502从非易失性存储器1510中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成离线考勤的处理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图16，在软件实施方式中，该离线考勤的处理装置应用于客户端，可以包括检测单元、缓存单元和传输单元。其中：

检测单元，检测到在离线状态下发生于预设页面的考勤触发事件；

缓存单元，当预定义的数据传输条件未满足时，将所述考勤触发事件对应的考勤相关数据缓存于所述客户端；

传输单元，当所述数据传输条件被满足后，将所述考勤相关数据传输至服务器。

可选的，所述数据传输条件包括以下至少之一：已连接至预设网络、网络信号强度达到预设强度。

可选的，还包括：

读取单元，读取所述客户端中存储的考勤规则；

第一匹配单元，将所述考勤触发事件的描述信息与所述考勤规则进行匹配，得到第一考勤状况信息；其中，所述考勤相关数据中包含所述第一考勤状况信息。

可选的，还包括：

更新单元，当所述数据传输条件未满足时，生成与所述客户端中存储的考勤规则相关的更新请求，并在所述数据传输条件被满足后，通过向服务器发起所述更新请求，更新所述客户端中存储的考勤规则。

可选的，还包括：

交互单元，当所述数据传输条件被满足时，与服务器执行数据交互；

获取单元，当确定所述客户端中存储的考勤规则与所述考勤触发事件的发生时刻不匹配时，从所述服务器处获取匹配于所述发生时刻的考勤规则；

第二匹配单元，将所述考勤触发事件的描述信息与获得的考勤规则进行匹配，得到第二考勤状况信息；其中，所述考勤相关数据中包含所述第二考勤状况信息。

可选的，所述考勤相关数据中包含所述考勤触发事件的描述信息，以由服务器根据所述描述信息以及预定义的考勤规则得到第三考勤状况信息。

可选的，还包括：

接收单元，接收服务器推送的考勤状况通知消息；

展示单元，展示出所述考勤状况通知消息中包含所述第三考勤状况信息。

可选的，还包括：

第一提醒单元，根据对所述数据传输条件的满足情况，在所述预设页面中的考勤触发区域或区域附近，示出对应于所述满足情况的第一提醒信息；其中，所述考勤触发区域用于触发所述考勤触发事件。

可选的，还包括：

第二提醒单元，根据对所述考勤相关数据的传输情况，在所述预设页面中的考勤相关数据展示区域或区域附近，示出对应于所述传输情况的第二提醒信息。

图17示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图17，在硬件层面，该电子设备包括处理器1702、内部总线1704、网络接口1706、内存1708以及非易失性存储器1710，当然还可能包括其他业务所需要的硬件。处理器1702从非易失性存储器1710中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成离线考勤的处理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图18，在软件实施方式中，该离线考勤的处理装置可以包括接收单元、获取单元和处理单元。其中：

接收单元，接收客户端上传的考勤相关数据；

获取单元，当所述考勤相关数据非实时上传数据时，获取所述考勤相关数据对应的考勤触发事件的发生时刻；其中，所述考勤触发事件在离线状态下发生于所述客户端的预设页面；

处理单元，选取与所述发生时刻相匹配的考勤规则，并根据所述考勤相关数据和被选中的考勤规则得到相应的考勤状况信息。

图19示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图19，在硬件层面，该电子设备包括处理器1902、内部总线1904、网络接口1906、内存1908以及非易失性存储器1910，当然还可能包括其他业务所需要的硬件。处理器1902从非易失性存储器1910中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成考勤处理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图20，在软件实施方式中，该考勤处理装置可以包括检测单元、缓存单元和传输单元。其中：

检测单元，检测到发生于即时通讯应用的预设考勤页面的考勤触发事件；

缓存单元，当未建立网络连接时，对所述考勤触发事件对应的考勤相关数据进行缓存；

传输单元，当所述网络连接恢复后，将所述考勤相关数据传输至服务器。

可选的，还包括：

读取单元，读取所述即时通讯应用中存储的考勤规则；

匹配单元，将所述考勤触发事件的描述信息与所述考勤规则进行匹配，得到考勤状况信息；其中，所述考勤相关数据中包含所述考勤状况信息。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/ 输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述” 和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。