I have a problem on accouting, I need to control the cash flow.
Actually my schemma is somehing like this:
**invoice_payable** control all my payable invoices
**invoices_receivale** control all my receivale invoices
Also I have other to entities to receive only the payment. They Are :
**invpay_paid** and **invrec_paid**
It receive only the payment coming from the first two tables.
Now I need to generate the daily balance, it is no problem, cause it is done already, but on the fly. I need to save the daily balance in a new table that I have called balance_history .
Now I will try to give more details about my tables.
My invpay_paid looks like this
id | invoiceid | amount_recvs | recv_data | cashier | company
the balance_history looks like this
id | balance | balance_date | cashier | company
The invrec_paid is a little different. but folow the same logic.
The problem is, I need to down the bill by company and cashier, I really need to do like this 'cause is more then one company and cashier that have registered payment everyday.
I'm really confused about this. How to control all the payment in the same place but for different companies and cashier (banks).
Here follow my data model: http://deepcell.org/app/AccountingDataModel.png sample.
Thanks for everyone, I have edited this topic, I hope to be clearer now.
I'm just answering my own question to give this topic as closed.
The question was solved using the follow data model.
Here follow my data: Model Sample.
Also I have an script workng to me every night (cronjob) generating my daily balance.
Related
So I am working on a booking system where I am posting small avaiable jobs for the kids in the community. I am not looking for a direct booking system in the sense that the user can just press the "booking button" and directly have the job. The approach i want to take is that you can SUBMIT INTEREST and then the poster of the job can accept one of the applicants.
So i have a few tables going on but the essential for the questions are these two.
|users|
|id | name | age |......
|jobs|
|id | date | salary |
What i am looking for explained in it's most simplest form is that i want multiple user id´s to be stored in a column so that i can later display/controll the users connected to the job in matter.
Would very much appreciate a sultion or just as much a tip on how i would go about solving the problem.
(I am using mySQL database if that adds any value to the question)
Best regards.
That is an n:m relation. A user can be interested in multiple jobs and a job can be interesting to multiple users. You should have a third table user_jobs for this where you store one record per user interested in a job.
Something like
user_jobs
userid
jobid
date
status
I have a bit of question. I'm currently being tasked to create a budget tracking database for the IT department using Microsoft Access. So below is the data about the IT department's budget in 2017. There are 14 IT departments in the company and they are categorized as KSIT, OPDR, PIIT and etc. The budget they spend on every year is listed on the left-hand side, which are perkakasan, perisian, projek baru and so on.
EXCEL spreadsheet
So now, my boss would like it if the interface would be something like each department may input the amount they've spent on each category; either perkakasan (hardware), perisian (software), projek baru (new project) and etc. There will be a login page too so there will be an admin ID, password, and the department they're from.
So now, the problem lies in the tables I have to construct. In my mind, I had come up with something like this: there would be 4 tables; table_dept, table_type, table_budget, and table_admin. Now for table_admin, I have no problem constructing them and assigning the PK. The problem is with the other tables. Is it possible that there will be only one entity in table_dept, which is dept_type or something like that. And the values from the dept_type will be the 14 departments, so it will be like a drop-down menu to ease the user inputting the data.
This sounds like a very basic question and I am a noob, I know. Your help will be very much appreciated!
Hi I've got a small internal project I am working on. Currently it only serves my company, but I'd like to scale it so that it could serve multiple companies. The tables I have at the moment are USERS and PROJECTS. I want to start storing company specific information and relate it to the USERS table. For each user, I will have a new column that is the company they belong to.
Now I also need to store that companies templates in the database. The templates are stored as strings like this:
"divider","events","freeform" etc.
Initially I was thinking each word should go in as a separate row, but as I write this I'm thinking perhaps I should store all templates in one entry separated by commas (as written above).
Bottom line, I'm new to database design and I have no idea how to best set this up. How many tables, what columns etc. For right now, my table structure looks like this:
PROJECTS
Project Number | Title | exacttarget_id | Author | Body | Date
USERS
Name | Email | Date Created | Password
Thanks in advance for any insights you can offer.
What I would do is create 2 tables:
I would create one table for the different companies, lets call it COMPANY:
Company_id | Title | Logo | (Whatever other data you want)
I would also create one table for the settings listed above, lets call it COMPANY_SETTINGS:
Company_id | Key | Value
This gives you the flexibility in the future to add additional settings without compromising your existing code. A simple query gets all the settings, regardless of how many your current version uses.
SELECT Key, Value FROM COMPANY_SETTINGS WHERE Company_id = :companyId
Te results can then be put into an associative array for easy use throughout the project.
I'd like to do some Php graphs with MySQL datas, but first I have to think about the best design for my database, I prefer ask you some advice because I'm a newbie and I think there is a better way that the one I'm thinking.
I have a main table called "companies", with an autoincrement id column and a region column, more companies and more column could be added later.
On the Php graphs, I'd like to choose the graphs by companies regions and maybe others filters later, this is why my table "companies" is the the central table.
I'd like to fetch new datas (stocks, commands, roi, etc..) for every companies one time per day and use those datas on graph. The old datas won't be overwritten but keep for the graphs history, more data I'll have more the graph will show the behavior of the company.
So, every day there will be one more row per companie (more than 200 companies in total), and this point is my issue.
I was thinking to create one table per companie and add a new row everyday on each on those tables, but I feel it's dirty and there is a better and cleaner way to do that, is anybody can show me the best way ?
Thanks for reading, I hope you'll can help me.
From what I understand, you have at least those entities in your domain:
Companies
Company indicators (stock, ROI, commands, ...)
Indicator types (stock, ROI, commands, ...)
Regions
So you should probably have something similar to the schema below:
,---------.
,-------. |Indicator|
|Company| |---------|
|-------| |date |
|name |*---|value |
|-------| |---------|
`-------' `---------'
o o
| |
,------. ,-------------.
|Region| |IndicatorType|
|------| |-------------|
|name | |-------------|
|------| `-------------'
`------'
This is my first project outside of school so I'm rusty and lacking practice.
I want to create a database but I'm not sure if I'm doing ok so far. I need a little help with the reports table.
The situation:
The food bank has multiple agencies who hand out food
Each agency has to submit a report with how many families/people served from a long list of zip codes.
I thought of putting a fk on Report to Zips table. But will that make selecting multiple zips impossible?
Maybe I'm way off base. Does someone have a suggestion for me?
A better name for this table might be FoodService or something. I imagine the kind of reports you really want to end up are not just a single row in this table, so naming it Report is a bit confusing.
In any case, each Report is the unique combination of {Agency ID, ZIP code, Date} and of course Agency ID is a foreign key. The other columns in this table would be number of families and people served, as you've indicated. This means you'll have rows for each agency-ZIP-date combination like this:
Agency | ZIP | Date | FamiliesServed | PeopleServed
Agency A | 12345 | Jan-12 | 100 | 245
Agency A | 12340 | Jan-12 | 20 | 31
Agency B | 12345 | Jan-12 | 80 | 178
Agency B | 12340 | Jan-12 | 0 | 0
Are these totals also broken down by "program"? If so, program needs to be part of the primary key for this table. Otherwise, program doesn't belong here.
Finally, unless you're going to start storing data about the ZIP codes themselves, you don't need a table for ZIP codes.
Usually having orphan tables like "Food" is a sign something's missing. If there's that much data involved, you'd think it would link in to the order model in some capacity, or at the very least you'd have some kind of indication as to which agency stocks which kind of food.
What's curiously absent is how data like "families-served" is computed from this schema. There doesn't seem to be a source for this information, not even a "family served" record, or a spot for daily or weekly summaries to be put in and totalled.
A "Zips" table is only relevant if there is additional data that might be linked in by zip code. If you have a lat/long database or demographic data this would make sense. Having an actual foreign key is somewhat heavy handed, though. What if you don't know the zip? What if, for whatever reason, the zip is outside of the USA? How will you handle five and nine digit zip codes?
Since zips are not created by the user, the zips table is mostly auxiliary information that may or may not be referenced. This is a good candidate for an isolated "reference" table.
Remember that the structure of a diagram like this is largely influenced by the front-end of the application. If users are adding orders for food items, that translates into relationships between all three things. If agencies are producing reports based on daily activity logs, then once again you need relationships between those three entities.
The front end is usually based on use-cases, so be sure you're accommodating all of those that are relevant.