bruno63
commented
9 years ago Peter 6.8.15 Ich verstehe die Idee des RateType – bin aber nach wie vor nicht davon überzeugt. Erscheint mir bei der Eingabe der Rates eher komplex zum Erklären, was hier gewählt werden soll. Aber vor allem stört mich dies: Die Leute werden bei der Eingabe der Rates diese entsprechend benennen, also bspw. „Senior Rate Extern“ und „Senior Rate Intern“, und dann den Typ entsprechend setzen. So ist es dann doppelt gemoppelt, denn im Rate Title steht dann schon der Typ. Müsste es nicht so sein, dass man eine Rate als Text definiert, z.B „Senior Rate“. Und auf diesem Objekt gibt es dann verschiedene „Kategorien“, also STANDTARD_INT zu 100, STANDARD_EXT zu 150 etc. So würde es auf meiner Sicht dann Sinn machen – den dann wähle ich bei der Erfassung des Worc Records die Rate „Senior Rate“ und anschliessend den Typ aus. Sonst wähle ich ja schon „Senior Rate Extern“ – dann muss ich den Typ gar nicht mehr wählen. Aber das finde ich dann wieder zu komplex – für ein Feature das eigentlich schon durch die Benennung der Rates gelöst werden kann. Verstehst du, was ich meine?
Werner 7.8.15: RateModel.rateType dient zur Kategorisierung der Rates. Die "strenge" Kategorisierung wird wichtig sein für die Erstellung der Reports und für die Rechnungsstellung. Der eingecheckte Enum für RateType sieht momentan wie folgt aus:
STANDARD_INTERNAL, STANDARD_EXTERNAL_ON_SITE, STANDARD_EXTERNAL_OFF_SITE, OVERTIME_INTERNAL, OVERTIME_EXTERNAL_ON_SITE, OVERTIME_EXTERNAL_OFF_SITE;
Ich sehe da keine Redundanz zu einer RateType-Bezeichnung „Senior Rate Internal (Standard)“. Dieser hätte rateType=STANDARD_INTERNAL, rate=150 bzw. für „Senior Rate Internal (Overtime)“ rateType=OVERTIME_INTERNAL, rate=170.
Dies bedeutet, dass pro RateType mehrere Rates erfasst werden müssen und diese ihren 'Zusammenhalt' verlieren. Wie gesagt: rateType dient nur zur Kategorisierung von Rates, welche für die Erstellungen von Rechnungen und Reports wichtig sein werden.
Von mir aus können wir rateType aber auch gerne vorerst weglassen und dann wieder hinzufügen, wenn wir es für notwendig erachten. Das Middle-Tier API soll für das GUI optimiert sein. Im Backend werden rateType und noch viele weitere Attribute definitiv benötigt.