Currently levies can either applied to production (prod), consumption (cons) or both (net). I actually think the net type doesn't make sense, at least with the way MUSE2 currently works, and I suggest we get rid of it.
Naively, you might think that it applies to net production of a given commodity... but you'd be wrong 😄. In MUSE2, processes can either produce a given commodity or consume it, but not both, so there's no "net production", just production. If it were possible for commodities to both produce and consume a particular commodity, then this might make sense: e.g. your process both produces and consumes a waste product, but policymakers only want to tax net production (production minus consumption). You couldn't express this without the net balance type. But, as I say, this isn't possible with MUSE2 and I don't think we want it to be(?), so I don't think it's needed.
What the net balance type does is apply exactly the same levy to both production and consumption. This seems like a decidedly odd thing to want to do. For example, if you have a levy on CO2 with a balance type of net (actually, this is how it is in the examples) this means that consumers of CO2 (e.g. carbon capture plants) are taxed just as much as producers, which makes no sense. I might be wrong, but I can't imagine that policymakers would want exactly the same tax on production and consumption of a commodity all that often.
I can imagine that you might want a different tax on production and consumption, however. For example, you could put a tax on both buying and selling coal -- it just seems weird that this tax has to be the same number for both (you might even want to incentivise consumers, in the case of CO2).
I've got an alternative suggestion: currently, you can only provide one levy for a given region/year/time slice combo and I think it would be better if you could provide both a prod levy and a cons one if you like. If there are any users who want to model the equal-tax-on-producers-and-consumers scenario then they could do this by adding two entries.
Currently levies can either applied to production (
prod), consumption (cons) or both (net). I actually think thenettype doesn't make sense, at least with the way MUSE2 currently works, and I suggest we get rid of it.Naively, you might think that it applies to net production of a given commodity... but you'd be wrong 😄. In MUSE2, processes can either produce a given commodity or consume it, but not both, so there's no "net production", just production. If it were possible for commodities to both produce and consume a particular commodity, then this might make sense: e.g. your process both produces and consumes a waste product, but policymakers only want to tax net production (production minus consumption). You couldn't express this without the
netbalance type. But, as I say, this isn't possible with MUSE2 and I don't think we want it to be(?), so I don't think it's needed.What the
netbalance type does is apply exactly the same levy to both production and consumption. This seems like a decidedly odd thing to want to do. For example, if you have a levy on CO2 with a balance type ofnet(actually, this is how it is in the examples) this means that consumers of CO2 (e.g. carbon capture plants) are taxed just as much as producers, which makes no sense. I might be wrong, but I can't imagine that policymakers would want exactly the same tax on production and consumption of a commodity all that often.I can imagine that you might want a different tax on production and consumption, however. For example, you could put a tax on both buying and selling coal -- it just seems weird that this tax has to be the same number for both (you might even want to incentivise consumers, in the case of CO2).
I've got an alternative suggestion: currently, you can only provide one levy for a given region/year/time slice combo and I think it would be better if you could provide both a
prodlevy and aconsone if you like. If there are any users who want to model the equal-tax-on-producers-and-consumers scenario then they could do this by adding two entries.