I am currently learning how to design accounting databases for payment systems like PayPal or PayTim etc. In one of my project I just can't figure how and where to apply double-entry patterns as I learned it is very important in accounting.
So my project is intended to work like PayPal for learning purposes. I created some tables such as:
payments_table - Which store every payment the user pays for service or sending to somebody (Stores money that circulates within the system).
transfers_in_table - Stores every transaction from Visa/MasterCard (Records money that is coming in the system)
withdrawals_table - This stores every money that user withdrawals. (Stores money which going out of the system)
transfers_out_table - Stores money that has been successfully withdrawn by the user.
So when the user1 pays somebody or for service(lets say user2) the flow will be like
User1->Visa->My Project -> User2->Some Fees->Bank.
How do I implement double entry for the situation like this, not to forget I need to store withdrawing fees in database too so that every calculation will balance?
I was thinking of having another table ledger but I dont think if is good solution.
Tables summary
payments_table - id,amount, and userId(FK)
transfers_in_table - id,amount and paymentId(FK)
withdrawals_table - id,amount and userId(FK)
transfers_out_table - id,amount and withdrawalId(FK)
Related
I'm a bit of a newbie with databases and database design, but I'm hoping someone can point me in the right direction. I currently have 14 monthly loan extracts, each of which contain all accounts, their status, balance and customer contact info as-of month end. Not knowing what to do, I imported each of the monthly files into Access with each table acting more like a tab from an Excel workbook. Laugh away - I now know that's not how it's supposed to work.
I've done my homework and I understand how to split up part of my data into Customer and Account tables, but what do I do with the account balances? My thought is to create a Balances table, create a relationship to the Accounts table and create columns for each month. This seems logical, but is it the best way?
99% of my analysis involves trend reporting and other ad hoc tasks - tracking the total balances by product type over time given other criteria, such as credit score or age. My intended use is to create queries to select the data I need and connect to it via Get & Transform in Excel for final manipulation and report writing.
This also begs the question "how normalized should my new database be?" Each monthly extract is cumulative, so a good 75% of my data is redundant contact info already, but how normalized should I go?
Sorry for ranting,but if anyone has any experience in setting up their own historical database or could point me in a direction that will get me on track, I would appreciate it.
Best practice for transactional systems is close to what you expect:
1. Create a Customer table
2. Create an Account table
3. Create an Account Balance table
4. Create relationships from the Account to Customer, and from the Account Balance to the Account table.
You can create a column for each month, provided you have Year as part of the key of the Account Balance table. Even better would be to have the key for the Account Balance be Account ID and Date.
However, since you are performing analytics over the data, a de-normalized approach is not only acceptable -- it is preferable. So yes, you can (and perhaps should, based upon your use cases) put all the data into one big flat table and then compile your analytics.
I'm trying to draw a database design of an ecommerce, and fulfilment of order platform. The company currently has a distribution centre for fulfilling the orders. But they want to extend this to use its stores for a part of the fulfilment process. I have designed a database of "internet sales" and "store sales", but I am stuck on the fulfilment of the internet order, and I wonder if any of you can help me with this.
Scenario : When the customer places in an order, and the distribution centre doesn't have a stock of an item to ship to the customers, the item needs to be taken from one of the stores. This item is then sent to the customer.
But the problem is that I can't just take an item from a store, and then send it to the customers, because the item hasn't been sold in the store, its (store) stock database isn't going to be updated. If I put the item through the cash machine, the item is removed from the stock table, but there are two transactions for the same item - one transaction from the internet, and the other from the store.
I guess my question is, how do I go about processing internet orders, and avoid having two transactions on the same item?
Any helpful pointers on this issue is greatly appreciated.
Update : Here's what I have done so far after advice from Jo Douglass,
Database Design Here
Sorry, I can't post images, because I don't have enough points. And please note that the above database design isn't complete
It sounds like you have a Transaction entity, and you have or are planning on having some logic which ensures that when one of these is created for an Item, your system knows to deplete the stock level for the relevant location (either a store of the distribution centre).
You could use an entity which shows an Item being transferred from one location (a store) to another (a distribution centre), and then create some logic which works very similarly to your existing logic - depleting the stock level in the starting location, and increasing the stock level in your destination location. Then when you carry out the last part of the process (sending the item to the customer), you'll have a Transaction showing that and depleting the distribution centre's stock level. Depending on the rest of your model, you might carry this out via a change to the Transaction entity, or by creating a new entity altogether.
Alternatively, if that doesn't really model what's happening in the business very well, then maybe you just need to modify your logic (and possibly your model - hard to tell without seeing your existing model). Rather than only being able to create store transactions via use of the cash register, perhaps you simply need to be able to create a store transaction that's been kicked off via the Internet.
One idea is to go ahead and treat the item as sold from the store (through an online transaction) and credit the store's account with the sale price. The distributor has probably already received the wholesale price from the store so it's happy, the store gets credit for the sale (with at least some part of the shipping charges) so it's happy, and you don't have to create new transaction codes or any other modification to the existing database.
We are developing a platform for NGOs (N) to get their work done via Individual Volunteers (V) or Volunteers via a Company (C)
NGO
An NGO can come signup for an account and create a profile.
It creates Activities (jobs it needs help from volunteers) to which Individual Volunteers or a Company (Sub set of their Employees who are registered as Volunteers in the system) can apply.
An NGO can check the Applicants Profile and previous Work History
and accept the application. On Acceptance they become members of an
Activity.
Here While they work after regular intervals say 2weeks they need to
enter the amount of hours they have contributed towards that
particular activity.
NGO has to validate this time so that it can reflect in a Volunteers profile as credit
Company
A Company signup for a profile.
It uploads the list of all its employees in a particular formatted CSV file to add Volunteers against itself or send an invite link to to ask their employees to signup. If an Employees already exists in the system we send an email asking him to validate the company's claims
Company can search for a particular Task and apply to it by selecting all its employes or a subset of it.
While Validating time for the work done it can be done it two ways. 1 Company can centrally say V1 V2 V3 have completed 2hrs 3hrs and 2hrs and submit for validation from the NGO or allow each of its Employees handle this manually and allow them to submit it.
Where i need help?
I have created the NGO and single Volunteer relationships. I am confused as to how use the same tables but allow a new entity like Company come in between the NGO and Volunteer and manage the time validation and activity management.
The Time Validated is very important as it will be used to be shown that in the Social Equity Balance of the NGO, Company as well as Volunteers (Individual Work and also Worked for a cause through a company)
I have created the ER diagram below for the NGO and Volunteer and need to create the Company part of it.
Link: http://i.stack.imgur.com/OMY21.png
I'm not sure you need to change your schema much, or even at all. Your schema requires an application to go with it to make it do anything - you can't implement all the logic here - some/most of it will be in your application.
As I understand it, your spec says that all actual volunteer work is performed by individuals, some of whom may be associated with a Company and some aren't. Your schema captures this already.
That's pretty much all you need, I think. When you say:
While Validating time for the work done it can be done it two ways. 1 Company can centrally say V1 V2 V3 have completed 2hrs 3hrs and 2hrs and submit for validation from the NGO or allow each of its Employees handle this manually and allow them to submit it.
This is already covered - either each individual inputs their own work records or the application allows the company to do it for them - and then the NGO validates these records in the same way, regardless of who entered them.
I have created the NGO and single Volunteer relationships. I am confused as to how use the same tables but allow a new entity like Company come in between the NGO and Volunteer and manage the time validation and activity management.
Lets go through a worked example to illustrate both use cases, to make sure we've got everything covered:
Worked Examples
Individual, no company
An individual signs up, creating a row in the volunteers table. They sign-up for an activity, creating a row in the ngo_activity_applications table.
The NGO approves them, creating a row in the ngo_activity_members table - and either removing the row in the ngo_activity_applications table, or changing it's status - the spec. is unclear.
The individual does some work and logs the time in the app, creating rows in the ngo_activity_time_validations table.
The NGO validates the work done somehow, then tells the app this. This presumably changes the status of the rows in the ngo_activity_time_validations table and creates either one summary row or matching rows in the volunteer_validated_times table. Spec unclear where cost_per_hour comes from?
Company
A company signs up and uploads a CSV file with 3 volunteers in. This creates a row in the companies table, plus three rows in the volunteers table, and 3 rows in the company_volunteers linking table.
Company Volunteer 1 signs up to an activity individually and everything proceeds as above.
The Company signs up for a different activity and volunteers all 3 of it's people to work on it. This creates 3 rows in the ngo_activity_applications table.
The NGO approves all three, creating three new rows in the ngo_activity_members table - and either removing the rows in the ngo_activity_applications table, or changing their status - the spec. is unclear.
The volunteers do some work and the company logs time in the app on behalf of Company Volunteers 1 and 2 - and Company Volunteer 3 logs her own time:
Company Volunteers 1 and 2
The company uses the application to log the time on their behalf - creating 2 rows in the ngo_activity_time_validations table.
Company Volunteer 3
Company Volunteer 3 uses the application to log their own time - creating a row in the ngo_activity_time_validations table.
The NGO validates the work done somehow, then tells the app this. This presumably changes the status of the rows in the ngo_activity_time_validations table and creates either one summary row or matching rows in the volunteer_validated_times table. Spec unclear where cost_per_hour comes from?
Summary
You can see how much validated time any individual has logged by querying the volunteer_validated_times table JOINed to the volunteers table. You can also see how much validated time any Company has logged, by doing the same query but also joining on the company_volunteers table.
Possible changes & Questions:
You might want to add a company_entered flag to the ngp_activity_time_validations table, so that you can distinguish between records entered by individuals and ones entered by the company on an individuals behalf. You might also want to add the ID of the person who makes the entry in this table, if logging that is relevant to your application.
Might want to add an hourly_rate column to the volunteers table, to use as a default cost_per_hour when creating rows in the volunteer_validated_times table.
Good Day,
I'm currently designing database structure for a website of mine. I need community assistance in one aspect only as I never did something similar.
Website will include three types of the payments:
Internal payments (Escrow kind payments). User can send payment to another user.
Deposits. Users add fund to their accounts.
Withdrawal. User can request a withdrawal. Money will be sent to their bank/PayPal account.
Basically, I need some tips to get the best design possible.
Here's what I'm thinking about:
deposits - this table will store info about deposits
deposits_data - this table will store info about deposit transaction (ex. data returned by PayPal IPN)
payments - table to store internal payments
withdrawals - table to store info about withdrawal request
transactions - table to store info about ALL transactions (with ENUM() field called type with following values possible: internal, deposit, withdrawal)
Please note that I have already a table logs to store every user action.
Unfortunately, I feel that my design approch is not the best possible in this aspect. Can you share some ideas/tips?
PS. Can I use a name "escrow" for internal payments or should I choose different name?
Edit
DEPOSITS, PAYMENTS and WITHDRAWALS tables store specific transaction details. TRANSACTIONS table stores only limited info - it's a kind of logs table - with a details field (which contains a text to display in user log section, ex: "User 1 sent you a payment for something")/
Of course I have users tables, etc.
Can I use a name "escrow" for internal
payments or should I choose different
name?
Escrow has a specfic financial/legal meaning, which is different from how you seem to mean it: "a written agreement (or property or money) delivered to a third party or put in trust by one party to a contract to be returned after fulfillment of some condition" (source)
So choosing a different name seems like a good idea.
As for design, what data will DEPOSITS, PAYMENTS and WITHDRAWALS store which TRANSACTIONS won't? Also, you need an ACCOUNTS table. Or are you planning to just use your existing USERS table (I presume you have such a thing)? You probably ought to have something for external parties, even if you only intend to support PayPal for the time being.
I'm planning a database for an enterprise cloud service. The service will be two web applications, one Warehouse management system and one for Invoices.
Companies can signup and become a "user" of the service, then they can have their Inventory and Invoice system online.
Should I keep all users/companies in the same table or should I have one table/application per user? It would be much easier to maintain if all users/companies use the same database table, but I think it would be easier to implement the serial number on invoices if I use one table per user/company.
The Inventory/Warehouse will contain up to 5,000 items per user/company.
Each Invoice are required to have a serial number, starting from 1 for the first invoice. So an Auto-Increment-column would be a good idea, if I have one table per user/company. Or how should I solve it if I put all companies in the same table and use a company_id-column?
How should I design the database for such an application? I will use MySQL as DBMS.
starting from 1 for the first invoice: that's probably not a good idea. Potential customers probably had a life before they join your service.
how should I solve it if I put all companies in the same table: just calculate the MAX of InvoiceId FOR THAT CUSTOMER, then increment it.