Tracking purchase prices on past transactions

This forum contains all archives from the SD Mailing list (go to http://www.systemdynamics.org/forum/ for more information). This is here as a read-only resource, please post any SD related questions to the SD Discussion forum.
Locked
Ulli.Koenig@energie.rwe.de
Junior Member
Posts: 2
Joined: Fri Mar 29, 2002 3:39 am

Tracking purchase prices on past transactions

Post by Ulli.Koenig@energie.rwe.de »

Bill,
just have a look at Chapter 12 of John Stermans great new book "Business
Dynamics". This chapter deals with coflows and aging chains - it deals with
the problem you are confornted with.
Faithfully

Ulli König
RWE Energie Aktiengesellschaft
Kruppstraße 5, 45128 Essen, Germany
Unternehmensentwicklung - Strategische Planung/Projekte
Corporate Development - Strategic Planning/Projects
Telefon: +49-(0)-201-12-29724
Telefax: +49-(0)-2 01-12-22975
mailto: Ulli.Koenig@energie.rwe.de
Ulli.Koenig@energie.rwe.de
Junior Member
Posts: 2
Joined: Fri Mar 29, 2002 3:39 am

Tracking purchase prices on past transactions

Post by Ulli.Koenig@energie.rwe.de »

Hi Bill and fellow SD-People,
as I have no Web-Space available, I send this model to the list (perhaps Bob
can put it somewhere on his web-pages).
I tried to model the flow-problem Bill mentioned. To keep it simple I
presumed, that none of the stocks is allowed to be stored more than 2 years
(104 weeks). The stock that one buyes in the present time-step is pushed
into the "StockChain" Level with the subscript "1to2" and moves forward
every full time-step ("2to3", "3to4"). The same thing happens to the
individual prices of the stocks (PriceChain Level). I use the Subrange
"Older1Year" to determine the stock with an subscribt higher than "52to53" -
so I hope Bill can use this to define a policy rate.
If you have any comments do not hesitate to contact me.
Cheers,

[Hosts Note: A reminder that if you want to send a model you need to send it in
a separate message directly to me (bob@vensim.com). Attachments with postings
get corrupted and cant be read.

I can put up Ullis model at http://www.vensim.com/sdmail/models/
with the same name as this message number.]

Ulli König
RWE Energie Aktiengesellschaft
Kruppstraße 5, 45128 Essen, Germany
Unternehmensentwicklung - Strategische Planung/Projekte
Corporate Development - Strategic Planning/Project
Telefon: +49-(0)-201-12-29724
Telefax: +49-(0)-201-12-22975
mailto: Ulli.Koenig@energie.rwe.de
Bill Harris
Senior Member
Posts: 75
Joined: Fri Mar 29, 2002 3:39 am

Tracking purchase prices on past transactions

Post by Bill Harris »

Okay, I know this should be simple, but Im having a mental block.

If I want to model my behavior in buying and selling stocks, for
example, Ill have personal policies that make buy and sell decisions.
I can model the current price of a stock as a level that rises or falls
by some mechanism (exogenous, random, exponential growth, you name it).
I can model the number of shares I own with a level (duh), with the
inflows and outflows controlled by my personal policies.

The personal policies controlling selling may be based on current paper
gain or loss, as well as the tax implications of the sale. (IOW, its
not likely Id use a FIFO scheme.) To calculate paper gains or losses,
I need to know the basis of a block of stock.

If I only bought one block of stock, I could sample the sale price and
store it in a level. For a fixed number of blocks, I guess I could
kludge something with arrays, having an array of levels, with dimensions
for purchase date and purchase price. Without trying it, Im guessing
the calculations would get pretty messy (for example, in iThink).

Does anyone have any clever ideas, preferably in a straight SD
paradigm? In all the cases I can think of Ive done in the past, I
remember being able to model the growth in net value directly or Ive
been able to calculate net value from other current or delayed (by a
constant) levels.

This one looks made for colored Petri nets, but Im frustrated I cant
think of a nice SD solution.

Thanks for any tips (including that of removing my blinders),

Bill
From: Bill Harris <
bill_harris@facilitatedsystems.com>
--
Bill Harris 3217 102nd Place SE
Facilitated Systems Everett, WA 98208 USA
http://facilitatedsystems.com/ phone: +1 425 337-5541
Bill Harris
Senior Member
Posts: 75
Joined: Fri Mar 29, 2002 3:39 am

Tracking purchase prices on past transactions

Post by Bill Harris »

Ulli,

Thanks, but thats not quite what I want, I think. Im waiting to get
a copy of the book, but, while I wait, I downloaded the models and
looked at chapter 12. There are several aging chains, but they all
have the attribute that you appear to put stuff in the front end of
the aging chain and remove it from the end. In capitalv.itm, for
example, the coflows track an attribute of capital through the aging
chain sequentially.

In my stock example, Id like to model this scenario:

I buy a block A of stock at $100 a share in week 1.

I buy a block B of the same stock at $130 a share in week 5.

I buy a block C of the same stock at $95 a share in week 25.

I buy a block D of the same stock at $140 a share in week 40.

In week 62, Id like some money. I have some options (and thus need
a policy--a rate equation):

I can sell block D and minimize my gain and thus maybe my taxes.
However, in the US, that gain would be taxed at normal income
rates, not at the lower capital gains rate, so it might be a bad
decision. (It does happen to be the flow modeled in the standard
aging chain/coflow model, though.)

I can sell block A and take advantage of the capital gains tax
rate. Ill have to do some figuring to see if thats a better
deal, as my net gain is $4000 more (1 block=100 shares).

I can sell block C, but that maximizes my taxable gain _and_ taxes
it at normal income rates. Thats not likely to be a good idea.

Block B would seem to be the best choice. Its basis is almost as
large as block D, thus minimizing the gain, and Ive held it over
52 weeks, thus qualifying for capital gains tax rates. So Id
sell that and add the gain to my annual gain so that I could
calculate taxes at years end. (I might sell more stock by
year-end, so I need to keep track.)

(I guess theres yet another option: move to a country where their
tax laws favor FIFO. :-)

(This isnt quite the problem I started with, but it explains the
essence of the problem, I think.)

It seems easy to do in colored Petri nets: I assign a value (or color)
to each token (block of stock) that includes its basis and its date of
acquisition. Then I can write arc expressions and transition guards
that pick the block to sell (at least it seems easy; I havent
implemented it yet).

My first thought was that you cant do this in SD, as SD doesnt allow
you to associate an attribute with a "thing" moving through a flow.
That is, I cant associated a basis and an acquisition date with a
entity; without the discrete extensions provided by tool vendors, I
can hardly keep those entities apart in normal stocks and flows.

My second thought is that it might be possible, but the number of
cohorts in parallel chains could get to be big (either one per period
I care about--say days, weeks or no coarser than months--or one per
block of stock in the system at any one time), and the auxiliary and
rate equations required to calculate the best block to sell and to
deal with moving both the stock and its basis out of the main aging
chains would be rather gruesome.

My third thought was that Ive done similar stuff, Im sure, where I
modeled just something like the gain of the stock, not (separately)
the basis and current value. I think the fact I want to be able to
calculate the order in which I pull stuff out of the aging chain makes
this problematic.

Having established for myself that this wasnt the way to go, I had
the nagging thought that this sounds a lot like an SD problem, and
someone here may have solved it in a straightforward manner.

Did I miss something in your answer, Ulli?

Mit freundlichem Gruss,

Bill
From: Bill Harris <
bill_harris@facilitatedsystems.com>
--
Bill Harris 3217 102nd Place SE
Facilitated Systems Everett, WA 98208 USA
http://facilitatedsystems.com/ phone: +1 425 337-5541
Bill Braun
Senior Member
Posts: 73
Joined: Fri Mar 29, 2002 3:39 am

Tracking purchase prices on past transactions

Post by Bill Braun »

Hi Bill,

This may be a wild leap, completely untested nor very well thought out for
that matter. In Powersim there is a sample population molecule that
accounts for age (young, middle, old, etc.) buckets and region (north and
south) buckets. Could you treat the region bucket as "hold" and "sell" and
set up the age buckets in some relvant time period (week, month, quarter,
etc.)? As time goes along, you could use the policies to move between hold
and sell. I would imagine stock you buy would go directly into the hold
bucket.

If this seems to have any promise I can send the equations along to you if
you dont have Powersim.

Bill Braun
From: Bill Braun <medprac@hlthsys.com>
Tom Fiddaman
Senior Member
Posts: 55
Joined: Fri Mar 29, 2002 3:39 am

Tracking purchase prices on past transactions

Post by Tom Fiddaman »

Bill -

At the risk of sounding like a broken record, what problem are we trying to
solve with the detailed tracking?

Vensim 4.1 includes new QUEUE functions that solve half your problem -
tracking attributes as a coflow with the queue elements. Unfortunately,
theyre also FIFO, so unless you move they dont help. Maybe you could
establish an offshore trading account?

Im sure its possible to build an explicit structure with arrays in your
model. As you say, the efficiency penalty might be fairly severe, as youd
have to pad the array with enough elements to handle the time resolution
you want, or treat it like a stack with enough elements to handle the
maximum number of blocks you expect to hold. Ugly.

A cleaner solution would be to create an external data structure to track
holdings (e.g. write a Vensim external function .dll) with functions to
handle buying, selling and choosing blocks. This would be easier than it
sounds if you know C, but hides some structure from the model user.

My preference would be to lump things into a couple well-mixed boxes,
treating shares and basis $ as coflows, neglecting the details. In fact the
problem isnt very SD-like - the emphasis is on detail and there isnt much
in the way of dynamics. If I wanted to worry about the details, Id be a
tax accountant, not an SD modeler :).

Regards,

Tom

****************************************************
Thomas Fiddaman, Ph.D.
Ventana Systems http://www.vensim.com
8105 SE Nelson Road Tel (253) 851-0124
Olalla, WA 98359 Fax (253) 851-0125
Tom@Vensim.com http://home.earthlink.net/~tomfid
****************************************************
Bill Harris
Senior Member
Posts: 75
Joined: Fri Mar 29, 2002 3:39 am

Tracking purchase prices on past transactions

Post by Bill Harris »

Tom Fiddaman wrote:

> At the risk of sounding like a broken record, what problem are we trying to
> solve with the detailed tracking?

Tom,

Im fond of that question, too, so I dont mind the broken record.

I didnt divulge the whole problem at first and, needless to say, that
causes problems. (I did divulge it to Ulli Koenig off-line, and he
did put together a model fragment that appears to be a good way to
start in an SD framework.)

Someone posed me this problem informally. For some reason, it hooked
me, and I got to wondering if there was a good way to solve it in an
SD paradigm. Moreover, while Ive never had an occasion when I had to
track something like this, I began to wonder if I might get a real
problem that shared similar characteristics.

Suppose you get granted Incentive Stock Options (under US law).
Typically, as I understand it, you are given N shares at a price of
X. After 12 months, you have the right to purchase N/4 shares at X;
after another 12, another N/4, and so on. After 10 years, your
rights to buy shares goes away.

The Problem: What policy do you use to buy shares? Do you buy them
as fast as you can? Do you spread purchases over the 10 years?
What is the impact of stock price evolution (i.e., whether its
stable or rapidly rising or ...) on the results of any particular
policy?

One complicating factor is US tax law. Upon exercising an option
(buying a share), you may owe Alternative Minimum Tax on the
difference between the price you pay and the option grant price X.
There is a threshold; if you have less than some amount ($35,000??)
in "Alternative Minimum Tax Income" in the year, you owe no such tax
(Im not a tax lawyer, so dont rely on any of this as certain).

When you sell a share, you owe income tax on the difference between
the sale price and the basis of the stock (the price you paid for
it). If youve held the stock at least a year _and_ its at least 2
years since the option was granted, its taxable at a lower, capital
gains rate.

Finally, you need the cash to exercise options. Assuming you dont
have the cash to pay for buying the stock, is it better to ignore
the tax savings and sell some of the stock "early" to get enough
cash to finance future purchases and the tax obligation, is a loan
better, or is a slower purchasing rate better? (Because of the tax
laws, it might be advantageous to sell in another order than FIFO.)

> Vensim 4.1 includes new QUEUE functions that solve half your problem -
> tracking attributes as a coflow with the queue elements. Unfortunately,
> theyre also FIFO, so unless you move they dont help. Maybe you could
> establish an offshore trading account?

I like your last suggestion (except its not me thats got the
options). :-)

> Im sure its possible to build an explicit structure with arrays in your
> model. As you say, the efficiency penalty might be fairly severe, as youd
> have to pad the array with enough elements to handle the time resolution
> you want, or treat it like a stack with enough elements to handle the
> maximum number of blocks you expect to hold. Ugly.

Ulli pointed out that the SHIFT IF TRUE function and an array of
stocks (of stocks) might help, but theres still the messiness of
creating flows out of each element. When I see something too ugly, I
get worried I might be going about things the wrong way.

> A cleaner solution would be to create an external data structure to track
> holdings (e.g. write a Vensim external function .dll) with functions to
> handle buying, selling and choosing blocks. This would be easier than it
> sounds if you know C, but hides some structure from the model user.
>
> My preference would be to lump things into a couple well-mixed boxes,
> treating shares and basis $ as coflows, neglecting the details. In fact the
> problem isnt very SD-like - the emphasis is on detail and there isnt much
> in the way of dynamics. If I wanted to worry about the details, Id be a
> tax accountant, not an SD modeler :).

My current thoughts mirror yours. Despite some good ideas from Ulli,
Im thinking its more of an OR problem. SD toolsets might be a
convenient way to handle the bookkeeping, except, as you note, they
dont do this sort of bookkeeping well. If I were to solve it via
simulation, Im currently thinking Colored Petri Nets offer a much
better approach. Although Ive not yet done that simulation, I have
sketched out the model, and it appears a lot more natural in that
paradigm.

Thanks, all, for your thoughts along the way.

Bill
From: Bill Harris <
bill_harris@facilitatedsystems.com>

--
Bill Harris 3217 102nd Place SE
Facilitated Systems Everett, WA 98208 USA
http://facilitatedsystems.com/ phone: +1 425 337-5541
Locked