I have a question

[azhar2006]

Hello all
I have a question
I have the first two being in the process of calculation is not certain and the second conducted by this process
At the same time the customer takes categories
Do you work tables for groups
For more information,
Two types of silver


Silver European operations conducted by the ounce
Silver and the second Asian to Atjra by these processes
Will enclose draft
Please Help

[Dal Jeanis]

Azhar - I think it might help if you first wrote out your question in your own language, assuming that you were going to have to explain it to a six- or eight-year old child so that he understood exactly the situation. Then read the question to someone else, and find out all the specific questions they have about your question. Once you have included all the details in your description in your language, THEN translate the question into English.

Looking at your database, and reading your words, I have no idea what the issue is. All the queries seem to work (although I can't read Arabic, so I don't know what the column headings are).

I suspect that your problem has to do with the fact that you have two different types of silver, and they are stored in different tables, and you would prefer to have a single query or form to do all the work.

The way to do that is to put both kinds of silver transactions in the same table, and have a field that marks which kind of silver is being bought or sold. Such a design would allow the same database to track many transactions in gold, silver, platinum and so on, without having to add extra tables for each new precious metal.

You might have three fields - metal type, measurement type, and amount.

Hope this helps.

[azhar2006]

Hello Dal
Yes you what I said is true
Sorry for my poorly worded
But it was the words correctly
Do I need tables to many tables
Queries in the database you are correct

is to put both kinds of silver transactions in the same table, and have a field that marks which kind of silver is being bought or sold. Such a design would allow the same database to track many transactions in silver

[Dal Jeanis]

Yes, apparently the nuances of the words don't translate very well. Please try to write many sentences and long explanations. The more words I read, the better my ability to guess how they relate to each other. Here are some of my questions.

1) What is the purpose of the database? I understand that you are tracking sales and purchases of silver. Please describe all the different ways the database will be used to track and report these occurrences.

2) What is the purpose of the tblGroups table? It seems to have information about particular purchases. Does it have any other function?

3) Does the database need to keep track of how many unsold units are in a warehouse or safe somewhere?

[azhar2006]

Thank you very much Dal

1 . True buying and selling silver only
2 . Table tblGroups
We sell two types of silver
European silver
Silver Asian
European silver sell a manner ounce
Asian silver We define their We priced
In other words, do not follow the accounts ounce
3 . For example, when buying silver on 01/01/2013
And buying silver in 11/30/2013
We want to be sold 11/30/2013 Silver first and then be in 0
Go back to the old silver or the rest of the silver in the history 01/01/2013
In other words, sales will be inversely
The new first and then the old

[Dal Jeanis]

Okay, so your accounting method is "first in, last out".

You are tracking an inventory of silver of various types, purchases and sales.

You are not using the database to track shipping.

Your database needs to calculate how many bars have been sold from each purchase.

Will this LastIn-FirstOut method be used to determine which physical bars are sent to the buyer, or are the bars physically indistinguishable?

Will this LastIn-FirstOut method be used solely to determine the cost of the bars that were sent, and the profit?

Is the profit to be reported by day, by month, by transaction, or what?

If two or three sales happen in the same day, does it matter which one of them received the "older" bars?

[azhar2006]

Profit will be an annual
Profit is not money but silver
For example
At the beginning of the year I had 10 kg silver
At the end of the year how he became 11 kg So I won
9 kg So if I'm a loser
Does not exist in the database for tracking shipping
Selling price is calculated ounce for the day only, not for hours
This being the only Silver Europe
I am selling two types of goods
Silver
The balance of silver

[Dal Jeanis]

Will this LastIn-FirstOut method be used to determine which physical bars are sent to the buyer, or are the bars physically indistinguishable?

If, at the end of the year the only important thing is how much silver you have, and if tracking profit or cost of silver bars is not an important function of the database, then what is the significance of making sure that the first silver sold each day is the last silver bar received?

[azhar2006]

bars physically indistinguishable ///// Yes
the only important thing is how much silver you have ///// Yes

the significance of making sure that the first silver sold each day is the last silver bar received? ///
Because we buy silver at a particular price
Silver, for example, purchased a month ago at a price of $ 10
And today has become the price of $ 13
It is not possible to sell to the customer of silver bearing ancient history which is priced at $ 10 to $ 13
Silver is selling the customer bear the earliest date for the price of $ 13

[Dal Jeanis]

I do not understand this statement:

"It is not possible to sell to the customer of silver bearing ancient history which is priced at $10 to $13".

If the bars are indistinguishable, then the price you sell for today has NOTHING to do with what price you bought the bar for. You sell for today's price.

For Tax Accounting, you might have to track the costs of the remaining bars that are in stock. However, if you do not have to track the particular bars, and if you do not have to track the cost of sales, only the number of bars you have at the end of the year, and then it is unnecessary to determine which bars were sold.

[Dal Jeanis]

Okay, what you need to do first is determine your entity relationships.

Go to this page http://www.rogersaccesslibrary.com/forum/topic238.html.

First, read the five Topics. Understand them as well as you can. If possible, get one or two other people to read them with you, so you can discuss them.

Second, do entity relationship diagrams for at least two of the Examples on that page. I would suggest that you do "Class Information Database", and then after that do "Consolidated Widgets". Widgets is closer to your own application, but I want you to do it second, so that you will learn more.

After you have done Widgets, then do an entity relationship diagram for your own application. Apply what you have learned to identify the entities that you need to represent in your silver database.

Some of your entities are (1) clients, (2) silver bars, (3) Sellers, (4) purchase transactions, and (5) sales transactions. There may be other entities that you need to represent, I do not know. You need to tell me that.

For instance, are your silver bars all kept in the same location (safe, vault, garage, closet) or are there multiple locations that you need to track? If you need it, then add location as an entity.

For instance, might there be a second person (perhaps a relative) who owns some silver that you might sell - a situation that in the US we call a "Consignment" of inventory, and therefore you need to track whose silver is actually being shipped? If you need it, then add an entity for consignments or consignors.

Once you have designed your application, post your proposed design on a new thread in the Database Design forum, and we'll review it with you.