Here's how I would set it up:

Tables: Description:
Positions Holds new positions
PositionTypes Look up for position types
Transactions Holds transactions on positions
TransactionTypes Look up for transaction types

Here's the fields in each table:
Positions:
pkPositionID (Primary key, autonumber)
fldPositionType
positionDescription

PositionTypes:
pkPositionTypeID (Primary key, autonumber)
fldPositionType

Transactions:
pkTransactionID (Primary key, autonumber)
fkPositionID (Foreign key to Positions table)
fldDate
fldTransactionType
fldQuantity
fldPricePerUnit

TransactionTypes:
pkTransactionTypeID (Primary key, autonumber)
fldTransactionType

Relationships:
One Position has many Transactions

I actually set this database up, so email me and I'll send it to.
The basic idea is to divide the data up into its logic relationships (e.g. 1
position has 10 transactions so have separate tables for positions and
transactions.) This avoids repeating everything about a position when you
buy it and when you sell it (this is what you would have to do if you kept all
the information in a spreadsheet.)

Add as many fields as you can think of now or add fields later as you need
them. Remember, you can query/sort/sum etc. on those fields later with ease.
Everything in you post is possible, though, with the above table structure.

Later,
Johnny