索赔管理系统的数据库设计？ [英] Database design of claim management system?

问题描述

我遇到了一个复杂的场景，我必须为公司的内部项目设计一个数据库。该项目是索赔管理系统，员工可以在这里提交他们不同的索赔ig医疗，旅行等等。但是，这些索赔还必须得到特定管理人员的批准才能获得公认。在这里，审批经理可以根据员工的指定和索赔的类型进行不同的审核。如果员工指定为高级软件，则假设有医疗索赔



工程师然后他们的索赔首先由Team Lead批准，然后由经理批准。对于旅行津贴的相同指定，申请将由主任直接批准。如果



指定经理然后为他的医疗索赔，他将直接得到主任的批准。到目前为止，我遇到过以下表格，



ClaimTypes（ClaimId，Claim）



EmployeeDesignation（ Id，指定，经理（parentId））



ClaimApprovalLevel（Id，ClaimId，namesId，Approvallevel，approvalAuthority）



但在这里我很困惑，如果同一名称的同一名员工需要两位不同经理的批准怎么办？如果将来需要进一步增加管理人员，我的解决方案是否可行？

I have come across a complex scenario where I have to design a database for a in-house project of my company. The project is claim management system where employee can

submit their different claims i.g medical, traveling etc. But this claims will also have to get approval from specific managers before they are accepted. Here the heirarchy of

the approval managers can b different based on the designation of the employee and type of the claim. Lets suppose for a medical claim if employee designation is Senior Software

Engineer then their claim gets first approved by Team Lead then from Manager. For the same designation for a traveling allowance claim will directly approved by Director. If

designation is manager then for his medical claim, he will get directly approval from Director. So far, I have come across following tables,

ClaimTypes(ClaimId, Claim)

EmployeeDesignation(Id, Designation, Manager(parentId))

ClaimApprovalLevel(Id, ClaimId, designationId, Approvallevel, approvalAuthority)

But here I am confused that what if a same employee of same designation need approval from two different managers ? Is my solution viable if there has to be added further heirarchies of managers in future ?

推荐答案

我们在这里使用这样的系统（分层审批链）进行休假审批，软件和硬件请求，购买等等：JavaScript / PHP / SQL。



它也很好用，因为没有人能在桌面上丢失纸张。此外，它还具有内置的烦恼功能，因此电子邮件会定期发送给下一个在线审批人，直到他们完成工作为止。在购买的情况下，它甚至根据

We use such a system here (hierarchical approval chain) for Leave Approval, Software and Hardware requests, purchases, &etc: JavaScript/PHP/SQL.

It works rather well, too, as no one can ever lose a paper on their desktop. Also, it has a built in annoyance feature so that emails are periodically dispatched to the next-in-line approver until they do their job. It even branches, in the case of purchases, to different chains based upon the

金额分支到不同的链。



你想要的链条应该发出订单并在达到该特定链的最大值时终止 - 这应该动态获取，这样您就可以为各种目的实现多个这样的层次结构。



详细信息不幸的是，除非他们另有说明，否则他们是公司财产。然而，具有多层的多个链的概念实际上是这种问题的一般情况。

amount.

The chains you want should give an order and terminate when the max value for that particular chain is reached - this should be gotten dynamically so you can implement multiple such hierarchies for various purposes.

The details, unfortunately, are company property unless they say otherwise. The concept, however, of multiple chains with multiple tiers is really the general case for such problems.

这篇关于索赔管理系统的数据库设计？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！