Tracciamento del tempo e architettura di registrazione dei pagamenti

1

Тitle potrebbe essere un po 'errato. :) Comunque, sto costruendo un software in cui i dipendenti inseriscono il tempo che hanno lavorato al giorno (orario di lavoro) e il datore di lavoro "paga" per questo periodo. Il "pagamento" viene effettuato al di fuori di questo sistema, quindi il datore di lavoro si limita a "confermare" (casella di controllo o qualcosa del genere) quali ore di lavoro sono pagate.

Quindi la domanda è: qual è il modo migliore (sia per l'interfaccia utente che per l'archiviazione dei dati) per implementarlo? Al momento ho questa idea:

  • Il dipendente seleziona la settimana e manualmente (con alcuni helper JavaScript, come "riempire lo stesso orario per tutti i giorni") immette le ore di lavoro in tutti i giorni della settimana. Il datore di lavoro conferma il pagamento allo stesso modo dei dati di input dei dipendenti (seleziona la settimana, conferma ogni giorno). I dati vengono salvati nel DB come timestamp unix (un giorno per riga della tabella).

    Il problema è di 14 input (7 giorni * ("ore da" + "ore a" input), tuttavia questo approccio sembra un po 'facile da implementare.

Forse sto trascurando qualcosa e questo può essere fatto in modo diverso e migliore? Forse qualcuno ha qualche esempio di software già funzionante?

    
posta egis 05.10.2012 - 19:03
fonte

1 risposta

1

Hai detto yet this approach seems kinda easy to implement , che mi porta a chiedere: Perché complicare le cose? Codice per i requisiti aziendali della tua applicazione.

Il modo in cui trattate i dati nel database dovrebbe essere indipendente dalla vista di input per i dipendenti.

Crea un oggetto comune tra l'interfaccia utente e l'interfaccia DB. Quando i requisiti di archiviazione dei dati cambiano, è possibile aggiornare il database di conseguenza senza dover modificare la visualizzazione poiché l'interfaccia utente e l'interfaccia DB continuano a parlare nello stesso oggetto comune. Allo stesso modo per l'interfaccia utente, ora può essere indipendente dal DB.

La tua struttura DB iniziale probabilmente rispecchierà l'oggetto comune, che è ok.

Non conoscerai la soluzione "migliore" per il tuo scenario finché non inizi a costruirlo e farlo funzionare. Sembra che tu abbia qualche idea per la codifica. Se le tue idee sembrano soddisfare i tuoi requisiti, inizia da quello e aggiusta il progetto secondo necessità.

    
risposta data 05.10.2012 - 19:34
fonte

Leggi altre domande sui tag