ordine/fattura/Pagamento database di modellazione

Question

Io sono la progettazione di un sito e-commerce che ha il seguente scenario:

1. Un cliente può acquistare oggetti e creare un ordine.
2. L'ordine può avere una tariffa sconosciuta che verrà aggiunta dopo che il cliente paga l'importo totale degli articoli. Cioè, il cliente paga prima il numero . L'ordine aggiunge una commissione e modifica il totale. E il cliente paga ancora per la differenza. Ma i due (o altri ) pagamenti sono associati allo stesso ordine.
3. (Opzionale) Il cliente può inviare un unico pagamento per più ordini .

Attualmente, ho un tavolo Order ed ogni ordine può essere costituito da più OrderLineItem s (schema semplificato):

Order 
===== 
customer 
line_items 
total 
status 

OrderLineItem 
============= 
price 
quantity 
order 
product 

Un pagamento è associata ad un ordine (schema semplificato):

Payment 
======= 
order 
payment_account 
total 
result 

Sembra essere molto difficile supportare i pagamenti multipli per uno scenario a singolo ordine nell'attuale implementazione. Suppongo di dover introdurre fatture immutabili nel sistema e che il pagamento debba essere associato a una fattura anziché a un ordine. Tuttavia, avrei bisogno di aiuto con il modello di ordine/fattura/pagamento per lo scenario sopra descritto. Alcune domande specifiche che ho:

1. un ordine e una fattura molto simili a me (per esempio entrambi hanno articoli e totali). Qual è la principale differenza nei tipici sistemi di e-commerce ?
2. Come devo modellare le fatture per il mio scenario? Dovrei avere OrderLineItem s per un Order E InvoiceLineItem s per un Invoice?
3. Alcune considerazioni preliminari: avrò più fatture associate con un certo ordine. Ogni volta che l'ordine cambia il totale, ho per calcolare in qualche modo la differenza e inviare una nuova/immutabile fattura al cliente. Quindi, il cliente può pagare e il pagamento sarà associato alla fattura.

Mi piacerebbe sentire qualche consiglio. Molto apprezzato. Grazie!

Answer 1

Ci sono un sacco di domande qui, cercherò di rivolgermi a quante più persone posso. Molti dei problemi sono il modello di business piuttosto che il modello di dati.

In primo luogo, hai ragione che hai bisogno di una fattura immutabile. Una volta creata una fattura non è possibile modificarla, il modo standard di gestire una modifica della fattura è di emettere una nota di credito e una nuova fattura.

pensare alle relazioni tra le tabelle: il Order non ha bisogno di tenere le lineItem s in quanto questi si fa riferimento nella direzione opposta, vale a dire

Order 
===== 
orderId 
customerId 
status 

OrderLineItem 
============= 
orderLineItemId 
orderId 
product 
price 
quantity 

Quindi, per visualizzare l'ordine si uniscono le tabelle a orderId.Non è inoltre necessario memorizzare total come calcolato dal join.

Prova a non duplicare i dati: la fattura farà riferimento allo orderLineItem s, ma non necessariamente gli stessi nell'ordine. Ad esempio, il cliente ordina un A e un B, ma B è esaurito. Spedite A e creare una fattura che fa riferimento a orderLineItemId per A. Quindi, le tabelle delle fatture potrebbe essere simile:

invoice 
======= 
invoiceId 
status 

invoiceLineItem 
=============== 
invoiceId 
orderLineItemId 
quantity 

In altre parole non c'è bisogno di avere i dettagli dell'elemento. Ci si potrebbe chiedere perché non si aggiunga un ID fattura alla tabella orderLineItem - il motivo è che il cliente può ordinare 10 articoli A, ma ne spedisci solo 8, gli altri due vanno in una fattura successiva.

I pagamenti non sono effettuati a fronte di ordini, sono contro fatture. Quindi la tabella dei pagamenti dovrebbe fare riferimento alla fatturaId.

Quindi si tocca la riconciliazione. Se tutto fosse perfetto, il cliente effettuerebbe un pagamento contro una determinata fattura, anche se un pagamento parziale. In realtà questo sarà il tuo più grande mal di testa. Supponiamo che il cliente abbia diverse fatture in sospeso per gli importi x, yez. Se effettuano un pagamento di p, a chi lo assegni? Forse in ordine di data, in modo che se p> x il resto è assegnato a y. Cosa succede se p = z? Forse il cliente ha intenzione di pagare z ora ma sta contendendo y e ha smarrito x? Il modo in cui gestisci questo tipo di cose dipende da te, ma posso dire che la maggior parte dei sistemi di fatturazione lo fa davvero molto male.