 In the last session, we looked at the structure of TASMOD, how it was comprised of systems that themselves were comprised of policies, and that these policies were both definitional, which define the structure of the model, but also tax benefit policies, which were part of the model that does the simulations of taxes and benefits. So in this session, we are going to gain an understanding of how tax benefit policies are constructed, distinguishing between the building blocks of functions and parameters, and then we're going to conclude by looking at how to run the model and access the output. Now, before we start, it's worth taking stock and looking at how systems relate to policies and how policies relate to functions. So systems, such as the system for 2012 or the system for 2015, contain groups of policies. The policies themselves are constructed of functions, and it's these functions that perform the calculations to create the model output. If we look at this diagrammatically, we can see that with TASMOD 1.0, as I said, we have systems for 2012 and 2015, and these systems have the following policies, tax benefit policies, income tax of various kinds, the productive social safety net policies, the fixed basic cash transfer and the variable conditional cash transfer, and then indirect taxes, such as value added tax and indeed excise duties. If we just pick one of those, the fixed basic cash transfer, it's comprised of functions, policy functions, and these functions perform eligibility tests and the amount calculation. Now, we will go through that particular policy in some detail later in this session. But to continue, functions are the building blocks of all policies in TASMOD. Different combinations from the full set of functions allow the construction of almost any policy. Functions can be classified into three categories, policy functions, which is what the main focus of today will be, for the implementing of tax benefit policies, system functions, which we looked at last time, which are useful for the definitional policies and implement the framework of the model, and then special functions, which we don't use in TASMOD as such. There are, in fact, 12 functions only within TASMOD. There's four policy functions, the Elige, BenCalc, Arithot, ShedCalc, and we'll go through all of these in detail. System functions are things like up-rate, def var, def input, def income list, income list var op, def tax unit, def cons, def output, which we touched on in the last session. Each function consists of a header displaying the name of the function and a switch defining whether or not the function is activated, and a function is then divided into a series of parameters. Many parameters appear within multiple functions and some are specific to particular functions. Most of the policy functions and some of the system and special functions provide common parameters. There are compulsory and optional parameters. For example, the parameter tax unit must be included in all policy functions, otherwise TASMOD will issue an error message and simply abort. TASMOD is told how to calculate the policy by setting the parameters of the functions to appropriate values. Let's look first at a very straightforward function. It's called Elige and Elige determines eligibility. It sets an internal variable to 1 if an individual is eligible or 0 if they're not, based on one or more conditions. The Elige function must contain the parameters Elige, Cond and TAS unit. Of course, all policy functions have to contain TAS unit, but the function Elige has to contain Elige underscore Cond. Conditions may be quite straightforward. For example, age greater than equal to 60, or using built-in queries such as isDepT child or isHeadOfTaxUnit. Each condition you'll note from the bullet point above is enclosed by curly brackets, and conditions may be combined with and using the ampersand symbol and or using the vertical line symbol. Just like in Stata. The components of the conditions can be variables, income list, numeric amounts, functions, and things called footnotes, which we will talk about. Conditions can be assessed at different levels. Again, that's something which we'll talk about later. But let's look at a very straightforward case, which is the eligibility for public works. Here we have the function Elige, the Elige parameters, Elige, Cond, Output, VAR, TAS unit, the switches, so both the policy itself turned on and the Elige function turned on. Okay, I'll actually go to this on the model itself and talk you through it what it actually means. So let's see, we were looking at Bunn. This is the eligibility for public works, which is a kind of unemployment benefit, and hence the acronym that we use is B for benefit, U-N for unemployment. Though it is under the Productive Social Safety Net Scheme an eligibility that only goes to the head of household and allows the head of household to be eligible for employment under the Public Works Program. So this whole eligibility condition is taken at the household level because if a function, the eligibility function is at the household level, then it's the head of household who is awarded the output variable, which is BUN underscore S. So basically how it works is if the household is entitled to BSA, what's BSA? BSA is the Productive Social Safety Net Fixed Basic Cash Transfer. So if the household actually receives fixed basic cash transfer, then the head of household is entitled to undertake public works. So the first condition is BSA underscore S is greater than zero. In other words, there is some fixed basic cash transfer payment in payment and is head of TU. This is a built-in query, which is, is this particular person the head of the tax unit? If so, then the BUN underscore S is awarded. It's really quite straightforward. Let's go back to the presentation. So that's the eligibility function. The other simple function is Arithop. This is a simple calculator. It must contain the parameters formula and tax unit. The formula can include variables, income list, numeric amounts, queries and footnotes. And the main operators are, as with most formulae, brackets, the plus sign, minus, multiply and divide. Queries automatically calculate particular conditions, e.g. number of children in household, or carry out tests whether or not a person is married. So you can actually use queries in Arithop because they are, some of the queries are a calculation type query. And you can use footnotes, for example, applying upper and lower limits to a functional variable. And the footnotes are denoted by hash. Again, when I walk you through the model in the last of these videos, that will become clearer. Okay. A good example of an Arithop here is the calculation of the amount of VAT. It's a simple formula. It works on the VAT income list. And that formula that you see is simply a calculation of the amount of standard rate VAT, which is included in an expenditure amount, which includes VAT. I'm not going to go through the formula in detail, but it's just a standard formula for calculating the amount of that when the expenditure amount includes VAT. Okay. Now, let's talk about combining Elige and Arithop, can we? Because Elige and Arithop are often combined. Let's take this hypothetical case. Let's say we're constructing a new social benefit for all people over 60. Excuse me. All people 60 or over who are food poor. And let's say they're eligible to a pension benefit of 170,000 Tanzanian shillings per month. Such a benefit could be straightforwardly implemented using Elige and Arithop separately. Here's how it would look. So, here is the policy, BOA underscore TZ. Next function is BenCalc. And that's turned off. I'll tell you why in a minute, because BenCalc is the way that we would actually usually model such a policy. But in this particular case, we're turning it off just so that we can see how it would be implemented using Elige and Arithop first. So, let's just look at the function Elige. That's turned on. And it has an Elige ability condition as the first parameter. And that's DAG greater than 59, i.e. the person is 60 or over. DAG being the variable name for age. And in their second condition, DFP equals 1. Now, in the base dataset, there was a separate piece of research conducted which defined who was food poor. And there's a flag in the input dataset alongside all people who are food poor. So, because our benefit is going to simply those who are 60 or over who are food poor, there has to be two parts to the eligibility condition. In other words, older people in food poor households. This is a calculation done at the individual level. So, the parameter tax unit is tu underscore individual underscore tz. Now, that function, the eligibility function, creates a system variable which is set to 1. If the person is 60 or over and food poor. Now, the Arithop function, which succeeds it, has its first parameter who must be eligible. And one person must be eligible from that eligibility function above. And one person is, if the person who is being considered by the policy is both 60 and over or over and is food poor. And then the formula, it's a simple formula, it's not even a formula really. It's just the allocation of an amount, which is dollar, old, underscore age, underscore benefit, underscore amount. Now, you'll know that anything beginning with dollar is actually a constant. So, we've actually put the 170,000 shillings per month in a constant called old, underscore age, underscore ben, underscore amount. And so that allocates to the individual who is over 59 and food poor the monthly amount agreed upon. And that amount is then put into the output variable boa underscore s. So, that's the, if you like, the long-winded way of modelling an old age benefit of that type. Now, I want to talk about BenCalc because BenCalc provides a more straightforward way of undertaking the modelling of a social benefit such as that old age benefit. So, BenCalc combines the functionalities of Elig and Arithop, particularly useful for social benefits, often referred to as the benefit calculator, hence the name of it as BenCalc. There are eligibility conditions, comp underscore cond, which is equivalent to the Elig underscore cond of the eligibility function, and formulae to calculate the value of the benefit assigned to eligible individuals or tax units. That's the comp per Elig or comp per Tu, which are equivalent to the formula in the Arithop function. So, the same rules for syntax apply as for Elig cond in Elig function for comp underscore cond, and same rules as apply to formula in Arithop apply to comp per Elig or comp per Tu in the function BenCalc. And BenCalc can have multiple conditions with different amounts being assigned for different conditions, and I'll show you one of those in a minute that we've actually used within TASMOD. Eligibility conditions and corresponding formulae are specified in separate parameters. Okay, let's look at this old age benefit that we looked at before implemented using BenCalc. Remember before it used two functions, Elig and Arithop. Here with BenCalc, it's just got the one much more straightforward function, BenCalc. The comp cond, remember that's equivalent to the Elig cond, is exactly the same as the Elig cond in the Elig function. DAG greater than 59 and DFP equals 1. Okay, the comp per Tu is exactly the same as the formula in the Arithop function, and this time just simply puts that old age benefit monthly amount, which is contained in that constant dollar old underscore age underscore Ben underscore amount into comp per Tu, and the output variable at the individual level is BOA underscore S. And that should actually be on, because we want that to be on, and these two should be off on this occasion. So that's how that should work. Okay, I've talked about three of the four functions, policy functions that are used in TASMOD. This is the final policy function that is used, and this is ShedCalc. And ShedCalc is used to apply schedules of rates, for example, income tax bans. Now, many countries have their income tax graduated in bans, a base amount of taxable income is taken in this screenshot, it's TTP underscore S. And then the bans are specified, the band rate, there's a lower limit to a band, so from 0 to 2,040,000 is 0%, and then 2,040,001 to the next limit is 11%, etc. And these tax bans, as they're called, are specified within ShedCalc like this, makes it much more concise than a complicated BenCalc or a series of arithops that could be otherwise employed. Now I'm going to go back to the model now, having gone through all of the functions, and before we go on to running the model, to actually look at both BenCalc and ShedCalc in a bit more detail. Let's first look at BenCalc, I promised I'd show you the fixed basic cash transfer, which is BSA, because first of all there is a DEF file which is a system function to define an internally used variable I underscore BSA underscore individual, that's simply set to 0, that just defines the variable. Then the first BenCalc, now I said that BenCalcs might be quite complex in that they have more than one condition allocating more than one amount, this is a classic case here, because the fixed basic cash transfer allocates amounts to individuals within a household, but it's different amounts for children than adults. So the first comp-cond is for children. DFP equals 1, it's got to be food poor, and age has got to be greater than equal to 0 and less than equal to 17, i.e. the child's got to be between 0 and 17. The amount allocated is to that individual, because this is all done at an individual level, is going to be the child amount. Now if it happens not to be a child, but it's a food poor adult, the second condition kicks in, DFP equals 1, so food poor, but this time somebody greater than equal to 18, i.e. 18 or over, and this time they're allocated the adult amount. And whichever it is at the individual level, be it child amount or adult amount, it's put into this output variable I underscore BSA underscore individual. And then the next BenCalc effectively aggregates, at a household level, all the individual amounts allocated by the first BenCalc. So the condition is that anyone in the household, as it were, has I underscore BSA underscore individual greater than 0, and the amount allocated is I underscore BSA underscore individual, but at the household level. That has the effect of aggregating all the individual amounts within the household and allocating them to the output variable BSA underscore S. Okay, I hope that's clear. Again, I'll talk through the whole thing in the model again in a different video. And finally, I wanted to show a ShedCal connection. It's actually used in two policies. I'll show the turnover tax one, first of all. For turnover tax, which is called presumptive income tax in Tanzania, there's an eligibility condition that says that the turnover has to be greater than 0 and less than the presumptive tax upper limit. And you see, when I hover over it, it actually gives the presumptive upper limit value. And the person mustn't be earning. Yeah, must equal 0. And they mustn't be working in agriculture. Yeah, equal 0. That's the eligibility condition. And if that is the case, who must be eligible? One, that's person, so at the individual level, has to be eligible. And the tax base becomes YTN, which is the turnover tax amount. And then there's a schedule which is based on lower limits, depending on what the turnover actually is. And if the turnover is under, let's get the decimal points in the right place, under 4 million, then there won't be any turnover tax payable. But between 4 million and 1, and 7.5 million, it's 3%. And then between 7.5 million and 11.5 million, it's 3.75%, etc. And that's how it works. And then the schedule adds all of the liabilities under each of these bands up and puts them into the output variable TTN underscore S. Okay, now to conclude by talking about running the model. TASMOD outputs based on two inputs, as you know, the Household Microdata, the HBS, and the rules on how to calculate tax and benefits, which are what we've just been going through in terms of the tax benefit policies and the functions and parameters that comprise them. Using these two information sources, the model calculates all tax and benefits that have been implemented. The calculations are carried out for each individual and household in the data set, and the result is written to an output file. And that output is an individual level unless otherwise specified. So, if you click on Run on the Countries tab, it actually says Run Euromod in the top left-hand corner, and that activates the Run TASMOD dialog. It doesn't run it straight away. And here you get the Run TASMOD dialog. And then, first of all, there's a list of systems which are ready to run. So you have to select a system for running or a series of systems by checking the box to the right of the system. So you could run all three together or just a couple of systems or just one. Okay. The list under data set provides a drop-down box for each system which contains all available data sets. There's only one actually in TASMOD at the moment, so there's nothing to select there. The output path at the bottom defines the folder where the model stores its output, and then finally pressing Run here starts the actual simulation process. And that generates another dialog, but this time it's running. So that's the dialog it creates. The system data set combination selected for running listed in the configuration part of that dialog. The status of the Run is the next column in the dialog. The first dialog shows it running. The second one is it finished. There's another status, Aborted, which is if something goes wrong with the process. Looking at the finished one, the time taken is then completed in the finished dialog. At any point you can actually stop the Run by pressing the Stop button. You see that's not highlighted in the first dialog, and that would just abort the Run by the user. But a Run could actually be aborted if there was a fatal error in the coding, in which case you would actually get information in an error log, which is another text file. However, in this case there are no errors. But if it does run and finish, but still produces an error log, the error log will contain non-fatal errors, which are actually warnings and assumptions, which the model makes. But this runs through quite straightforwardly and clearly. Okay, when Tasman's finished its calculations, the output stored as one or more text files at the storage place defined in the field output path. The main text file is called, for example, TZ underscore 2015 underscore STD, and that's defined in the output policy. And the file contains the variables defined in the output policy. Let's just quickly go back to the model to look at that. Close, first of all, all policies or collapse them. And then look at the output. So the file, TZ underscore 2015 underscore STD, is specified by the first parameter of def output. There it is. And then the actual variables contained are specified below. You can actually use wild cards. So var group followed by id star outputs a group of variables individually, all with id as their first two letters. So id person, id hh, id partner, will all be output by var group id star. Similarly, all the demographic variables will be output with var group d star. And these include, and obviously are in these cases, the variables from the input file as well as simulated variables. So for example, if we look at var group b star, that will output not only the benefits that were simulated, but also the benefits, if there were any, that were reported in the original file. Similarly, you can output the total of income lists by an asterisk. All the income lists will come out with that using the wild card and indeed information on tax units, et cetera, and queries. So it's very good for diagnostic purposes to actually have quite a comprehensive series of variables in the output policy. Output files can be viewed in a text editor program or imported into any statistical analysis package, for example, Stata for more detailed analysis. And the model also produces a header text file relating to the output file as well as error logs, et cetera, as text files. I think at this point it's worth actually, again, going back to the model because I find very helpful the application open output file in Excel. You have to have Excel installed on your machine, but if I can just look through my various outputs and runs I've had, there you go, tz2015std.txt. If I open that, it will launch Excel and produce a very readable file with these variables in it specified as headers to these Excel columns. Very good for testing out and checking whether a policy does what you think it's going to do. Okay, let's go back to the presentation. And in fact, the activity is the final slide here and these are reflecting the activities that we're doing class together, which is exploring the benefit and tax policies and looking particularly at the functions earlier, Gerrithoff and Ben Kalk. And then the model will be run and the output is explained. And that's it, thank you very much.