Differences

This shows you the differences between two versions of the page.

--- premium_module [2020/03/13 11:34] – created matsz
+++ premium_module [2020/03/13 11:45] – [Basic concept] matsz
@@ Line 13: / Line 13: @@
 ====Basic concept====
+In the CAPRI supply module, premiums are always paid per activity level (per hectare or per animal) basis. They can be differentiated by the low and high yield variant of each crop activity. The premiums are calculated in the premium module from different premium schemes.
+A premium scheme (such as DPGRCU for the Grandes Cultures premiums after the Fischler reform) is a logical entity which encompasses:
+  - A specific application type (defining the basis for the payment amount)
+  - a region or regional aggregate to which it is applied,
+  - Possible ceilings in entitlements (CEILLEV) and in value (CEILVAL)
+  - Payment rates for possibly several lists of activities (such as PGGRCU for all types of Grandes Cultures or PGPROT for protein crops).
+  - Optionally an indication of the marginal payment when a ceiling is reached
+  - Optionally a modifier for different amounts per technology
+The schemes provide many-to-many mappings between policy instruments and agricultural activities: each scheme can apply to many different activities – with possibly differentiated rates – and each activity can draw support from different schemes.
+The application type defines how the nominal amount (called PRMR) is applied. Currently, the following application types are supported:
+  * perLevl	=	per ha or head
+  * perSlgtHd	=	per slaughtered head
+  * perYield	=	per unit of main output
+  * perHistY	=	per historic yield
+  * perLiveStockUnit	= per livestock unit
+  * noDirPay		= Norwegian direct payment
+  * noPriceSup	= Norwegian price support
+The application type points to a factor by which the nominal amount PRMR (for PRemiuM in Regulation) is converted to a declared value per hectare or head (PRMD). For perLevl, the factor is unity (it is already per hectare), but for instance for perYield, the amount is interpreted as a payment per unit of main output. That is used for the Nordic Aid Scheme for dairy cows in the northmost parts of Europe and for coupled payments in Norway.
+Each payment is defined for one or seveal //groups// of activities, functioning as lists of eligible activities. Additionally, the payment can be applied in different rates to the high and low yield variant, to model e.g. an extensification premium.
+Each premium scheme also has up to two ceiling values:
+  *ceilLev 	= Ceiling on LEVL, i.e. the number of hectares or heads
+  *ceilVal	= Ceiling on the total budget (envelope) spent on the scheme
+In the basic setting, the ceilings work as the old Grandes Cultures payment: if the total quantity (hectares or amount) exceeds the ceiling, then the payment to each farmer is reduced so that the ceilings are respected. This means that the marginal payment is somewhat reduced but does not become zero. For some other schemes, such as the Basic Payment Scheme of the CAP 2014-2020, there is a hard limit on the number of payment entitlements, so that the marginal payment becomes zero if the ceiling is overshot. That behaviour can be triggered by including the payment scheme set element in a special set //PSDPAY_cutEndog//, as in the following example from “pol_input\mtr_until2013.gms”.
+ PSDPAY_cutEndog("DPSAPS")  = YES; \\
+ PSDPAY_cutEndog("DPREG")   = YES; \\
+ PSDPAY_cutEndog("DPFRMS")  = YES; \\
+ PSDPAY_cutEndog("DPFRMF")  = YES; \\
+ PSDPAY_cutEndog("DPGREEN") = YES;
+The following figure shows the technical implementation at an example:
+**Figure 14: Example of technical implementation of a premium scheme**
+{{:figure14.png?600|}} \\ Source: CAPRI Modelling System. Note: The parameter PPDATA_E is now called p_premDataE.
+The sets of payments, exemplified by DPGRCU in the figure, and the activity groups, exemplified by PGGRCU and PGPROT are defined in the file policy\policy_sets.gms. Since this is a “static” GAMS file used in any simulation, it contains the gross list of all policies that currently can be simulated, including legacy ones. In order to work efficiently with the acronyms which define the application types, these are converted to numerical attributes as shown below (//‘policy\policy.gms’)//: