Hello I need help with this modeling
a transaction can have one or two participants, and one or more statements can have that transaction.
But I need to somehow know who owns the transaction and who receives the transaction
An example :
the participant who owns the transaction sends 100 dollars, I need to somehow show that he is losing 100 dollars and the other participant of the transaction receiving 100 dollars
but I’m not able to imagine how I can do that, identify in the transaction who is the origin and the destination and the value
In my opinion, transaction_participants.from_id is the "owner" (payer) and transaction_participants.to_id is the receiver. Multiple records in transaction_participants for single transaction could mean some kind of multi-payment for several receivers.
Concerning how to get the amount of payments, for example amount of payments sent from certain account: you start with rows from transaction_participants where from_id is the account ID, and via transactions_has_transaction_participants you get to transactions.amount, where the total amount of transaction is stored.
Related
I am trying to make small POS system, using FDMem table to fill items for the customer.
In case the customer forget his money or go to change a product .. and the customers in the line move and new customer shows up asking to start sale process, how can I save or freeze the current state of the FDMem table holding the products of the previous customer and start a new order and finish the sale. Then, when the first customer comes back, how can I resume the previous sales process and reactivate the previous FDMem table with it's items?
Add one more column in the FDMem table. That column could take 3 values: 'Finalized', 'Opened' and 'Paused' depending how the "status" of the sales is going. You can then navigate between the records.
So if I understand you correctly you want to be able to handle multiple customers or orders at the same time.
One solution one would guess would be to assign each customer unique number and them add that number as additional field to each record in your database. Now assigning unique values to online customers isn't particularly difficult. In fact you already have such information in form of session ID. But doing something like this for customers in a physical store is not feasible.
But there is another similar solution. Most Tax authorities require any shops to issue a receipt for any purchase made. And each of those receipts needs to have a unique number. So you could reserve a new receipt number when customer gets to your POS for the first time and you start adding its items to the system. Then you might want to have another table with all reserved receipt numbers and their current status, so you can know which receipt has been finished which one is still pending completion or which one was cancelled.
I'm planning the following table:
While I know this is technically feasible (I just tried it), I wanted to see if it seemed unnecessarily complicated... Basically I'm keeping track of revenues vs. costs.
Tab1 contains revenue data for both Tab2 & Tab3. Tab2 contains its own cost data, so that's easy. But the complication is that Tab3 costs are further allocated across Tab2 units. That's why there's a secondary joinsB table there.
I realize this isn't a concrete question, but I know there are so many more experienced folks who, based on that experience, will have a gut "wow this is too complicated" sense or not about what I'm doing. That's what I'd like input/ feedback on as a gut check before I build this.
EDIT for more clarity
Tab1 = Charges
Tab2 = Reservations
Tab3 = Logistics
joinsA = TypeCharges
joinsB = TypeLogistics
A user pays for a reservation of something, but may also pay to have that something shipped logistically. The two payments are wrapped up in one charge. The complication is that one logistics shipment may contain more than 1 reservation under separate users (i.e., separate charges).
This data structure is designed to help me do two things:
easily track exactly which charge is associated with a given reservation or logistics so that for example I can issue a refund, but for a specific amount (for example, a user may keep the reservation but want to cancel the logistics shipment and pay for it him/herself using another vendor)
easily understand how the cost of a logistics breaks down into allocatable costs by reservation
The latter is why Tab3 and Tab2 are joined, and the through table contains more information on the nature of the type of logistics. The through table also contains the charge amount that the user paid to have a reservation shipped logistically. Tab3 contains the cost of the logistics which is then allocated based on how many reservations there are. Then you can compare that allocated cost against the charge for the specific reservation in the joins table.
It seems that you need to track your charges at reservation + logistics level. If I were to model this I would do it as shown in the below diagram where the Reservations is an entity/table and so is Logistics. These have a many-to-many relation with each other, this is many-to-many relation is materialized using the Charges entity/table. So if you need charges for a reservation, you add up all the charges for a reservation, if you need charges for a logistic you add up all the charges for a logistic/shipment. The base data in the Charges table will contain the lowest level of granularity of the charges and can be rolled up by reservation and/or logistic/shipment.
Hope this helps
Image of different fees that relate to a transaction
I have a Transactional Fact table showing transactions done by a particular client. I want to relate this fact table to a Dimension Containing Different transaction Fees that might occur on a transaction. Each transaction will be linked to a range of between 1-5 different Transaction Fees which are all listed in different rows within the Transaction Fees Dimension. What is the best way to implement this ? Should I implement something such as Role Play Dimension and have multiple Keys for each type of Transaction Fee ?
Regards,
K
I would create a fact table with an atomicity of transaction + transaction fee.
If you know the fees at the time that the transaction is created then you can perform the join between the transaction and its fees during the data load process.
I have to track the status of my business process for analysis purpose. I have seen a post where it is mentioned that we can keep the status in Transaction Fact Table against time/transaction type/service center and we can use the Accumulated fact table to study the process lag, I am wondering if few transactions have multiple status in a single day should I store all the status in Transaction Fact Table? Here I am assuming that my ETL is done at end of the business day.
Secondly should i keep all my key dimensions keys into Transaction Fact Table. Keys in this case are Transaction Type, Department id, Service_type, Service_id, Submission Channel or should I divide them in multiple fact tables?
Third if I need to report which department is meeting its SLA what would be the best approach, Calculate and keep track of Within SLA and Not Within SLA in Transaction Fact Table or I should compute this value at run time?
Thanks in advance for your help and assistance.
For status tracking you should have:
A transaction table where ony events show up (but does not provide event tracing)
An accumulating snapshot table where each process's status are tracked/updated as they happen.
As for the keys, you should keep as much detail as possible. No need to delete keys if they may hold valuable information in the future.
I have a scenario where I have a few products that are sold during an event. These products are configured once and can be used at any event. I currently have the following nodes/relationships:
event-[:HAS_CURRENT_INVENTORY]->inventory-[:OF_PRODUCT]->product
The inventory here is for a single product, so I have a number of these for each event. When a transaction occurs, I want to maintain a snapshot of inventory across all products that I sell at the event. I am currently thinking of doing it this way:
Create a new transaction node
Create new "inventory" nodes for all of the inventory items included in this transaction with new inventory count
Link the new transaction node to all the "current" inventory nodes (not just the ones in the transaction, but all of them)
Replace the "HAS_CURRENT_INVENTORY" relationship to the inventory nodes affected, and give them an "archived" relationship. Simultaneously, create "HAS_CURRENT_INVENTORY" links to the new inventory nodes.
Is there a more optimal way to implement this? It is important to have a snapshot of inventory levels across the event when a single transaction occurred, or at an arbitrary point in time. However, I am creating a tonne of stuff for each transaction at the event. Is there a better way to query the info?