Merge remote-tracking branch 'origin/master' into IMP_manuals_improve…

…ment
gisce · Jan 20, 2025 · 57831b3 · 57831b3
2 parents 0aac115 + efe1315
commit 57831b3
Show file tree

Hide file tree

Showing 167 changed files with 6,201 additions and 24,231 deletions.
diff --git a/.github/workflows/python2.7-app.yml b/.github/workflows/python2.7-app.yml
@@ -12,14 +12,19 @@ on:
 jobs:
   build:
 
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-22.04
 
     steps:
     - uses: actions/checkout@v3
-    - name: Set up Python 2.7
-      uses: actions/setup-python@v4
-      with:
-        python-version: "2.7"
+    - name: Install Python 2
+      run: |
+        sudo apt update
+        sudo apt install python2 python-pip
+        sudo update-alternatives --install /usr/bin/python python /usr/bin/python2 1
+        sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 2
+        printf '1\n' | sudo update-alternatives --config python
+        cd /usr/bin
+        sudo ln -s /usr/bin/pip2 ./pip
     - name: Install dependencies
       run: |
         python -m pip install --upgrade pip

diff --git a/.gitignore b/.gitignore
@@ -1,6 +1,7 @@
 site/
 *.idea
 .idea/
+.vscode/
 *.pyc
 *.pot
 *.mo

diff --git a/docs/comer/_static/bat_virtual/FITXA_BAT_VIRTUAL.png b/docs/comer/_static/bat_virtual/FITXA_BAT_VIRTUAL.png
diff --git a/docs/comer/_static/bat_virtual/accio.png b/docs/comer/_static/bat_virtual/accio.png
diff --git a/docs/comer/_static/bat_virtual/afegir_polissa_abat.png b/docs/comer/_static/bat_virtual/afegir_polissa_abat.png
diff --git a/docs/comer/_static/bat_virtual/ascreenshot(3).jpeg b/docs/comer/_static/bat_virtual/ascreenshot(3).jpeg
diff --git a/docs/comer/_static/bat_virtual/ascreenshot(4).jpeg b/docs/comer/_static/bat_virtual/ascreenshot(4).jpeg
diff --git a/docs/comer/_static/bat_virtual/ascreenshot(5).jpeg b/docs/comer/_static/bat_virtual/ascreenshot(5).jpeg
diff --git a/docs/comer/_static/bat_virtual/bat_virtual_polissa.png b/docs/comer/_static/bat_virtual/bat_virtual_polissa.png
diff --git a/docs/comer/_static/bat_virtual/crear_bat.png b/docs/comer/_static/bat_virtual/crear_bat.png
diff --git a/docs/comer/_static/bat_virtual/crear_bat_II.png b/docs/comer/_static/bat_virtual/crear_bat_II.png
diff --git a/docs/comer/_static/bat_virtual/dins_pestanya.png b/docs/comer/_static/bat_virtual/dins_pestanya.png
diff --git a/docs/comer/_static/bat_virtual/factura_bateria_virtual.png b/docs/comer/_static/bat_virtual/factura_bateria_virtual.png
diff --git a/docs/comer/_static/bat_virtual/fitxa_bat_virtual.png b/docs/comer/_static/bat_virtual/fitxa_bat_virtual.png
diff --git a/docs/comer/_static/bat_virtual/fitxa_descompte.png b/docs/comer/_static/bat_virtual/fitxa_descompte.png
diff --git a/docs/comer/_static/bat_virtual/llistat_descompte.png b/docs/comer/_static/bat_virtual/llistat_descompte.png
diff --git a/docs/comer/_static/bat_virtual/llistat_origen.png b/docs/comer/_static/bat_virtual/llistat_origen.png
diff --git a/docs/comer/_static/bat_virtual/on_esta_bat_virtual.png b/docs/comer/_static/bat_virtual/on_esta_bat_virtual.png
diff --git a/docs/comer/_static/bat_virtual/pes_polissa.png b/docs/comer/_static/bat_virtual/pes_polissa.png
diff --git a/docs/comer/_static/bat_virtual/saldo_excedent_fact.png b/docs/comer/_static/bat_virtual/saldo_excedent_fact.png
diff --git a/docs/comer/_static/estat_pendent/Esquema_estados_Bono_Social_Correos.jpg b/docs/comer/_static/estat_pendent/Esquema_estados_Bono_Social_Correos.jpg
diff --git a/docs/comer/_static/estat_pendent/estat_ pendent_3.png b/docs/comer/_static/estat_pendent/estat_ pendent_3.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_1.png b/docs/comer/_static/estat_pendent/estat_pendent_1.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_1_polissa_form.png b/docs/comer/_static/estat_pendent/estat_pendent_1_polissa_form.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_1_polissa_form_process.png b/docs/comer/_static/estat_pendent/estat_pendent_1_polissa_form_process.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_1_polissa_llista.png b/docs/comer/_static/estat_pendent/estat_pendent_1_polissa_llista.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_2.png b/docs/comer/_static/estat_pendent/estat_pendent_2.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_2_detall_factura.png b/docs/comer/_static/estat_pendent/estat_pendent_2_detall_factura.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_2_historic_pendent.png b/docs/comer/_static/estat_pendent/estat_pendent_2_historic_pendent.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_4.png b/docs/comer/_static/estat_pendent/estat_pendent_4.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_5.png b/docs/comer/_static/estat_pendent/estat_pendent_5.png
diff --git a/docs/comer/_static/estat_pendent/estat_pendent_6_formulari.png b/docs/comer/_static/estat_pendent/estat_pendent_6_formulari.png
diff --git a/docs/comer/_static/orakWlum/actualitzar_perdues.png b/docs/comer/_static/orakWlum/actualitzar_perdues.png
diff --git a/docs/comer/_static/orakWlum/algorithm_select.png b/docs/comer/_static/orakWlum/algorithm_select.png
diff --git a/docs/comer/_static/orakWlum/exemple_cups_fetch.png b/docs/comer/_static/orakWlum/exemple_cups_fetch.png
diff --git a/docs/comer/_static/orakWlum/formulari_historics.png b/docs/comer/_static/orakWlum/formulari_historics.png
diff --git a/docs/comer/_static/orakWlum/formulari_historics_bc.png b/docs/comer/_static/orakWlum/formulari_historics_bc.png
diff --git a/docs/comer/_static/orakWlum/formulari_perdues.png b/docs/comer/_static/orakWlum/formulari_perdues.png
diff --git a/docs/comer/_static/orakWlum/formulari_previsions.png b/docs/comer/_static/orakWlum/formulari_previsions.png
diff --git a/docs/comer/_static/orakWlum/formulari_previsions_bc.png b/docs/comer/_static/orakWlum/formulari_previsions_bc.png
diff --git a/docs/comer/_static/orakWlum/gauss_example_calendar.png b/docs/comer/_static/orakWlum/gauss_example_calendar.png
diff --git a/docs/comer/_static/orakWlum/generar_historic.png b/docs/comer/_static/orakWlum/generar_historic.png
diff --git a/docs/comer/_static/orakWlum/generar_previsio.png b/docs/comer/_static/orakWlum/generar_previsio.png
diff --git a/docs/comer/_static/orakWlum/historic_exportar.png b/docs/comer/_static/orakWlum/historic_exportar.png
diff --git a/docs/comer/_static/orakWlum/historics_detall.png b/docs/comer/_static/orakWlum/historics_detall.png
diff --git a/docs/comer/_static/orakWlum/historics_resum.png b/docs/comer/_static/orakWlum/historics_resum.png
diff --git a/docs/comer/_static/orakWlum/importar_perdues.png b/docs/comer/_static/orakWlum/importar_perdues.png
diff --git a/docs/comer/_static/orakWlum/linies_historics_link.png b/docs/comer/_static/orakWlum/linies_historics_link.png
diff --git a/docs/comer/_static/orakWlum/linies_historics_llistat.png b/docs/comer/_static/orakWlum/linies_historics_llistat.png
diff --git a/docs/comer/_static/orakWlum/linies_previsions_link.png b/docs/comer/_static/orakWlum/linies_previsions_link.png
diff --git a/docs/comer/_static/orakWlum/linies_previsions_llistat.png b/docs/comer/_static/orakWlum/linies_previsions_llistat.png
diff --git a/docs/comer/_static/orakWlum/llistat_historics.png b/docs/comer/_static/orakWlum/llistat_historics.png
diff --git a/docs/comer/_static/orakWlum/llistat_perdues.png b/docs/comer/_static/orakWlum/llistat_perdues.png
diff --git a/docs/comer/_static/orakWlum/llistat_previsions.png b/docs/comer/_static/orakWlum/llistat_previsions.png
diff --git a/docs/comer/_static/orakWlum/m12_example_calendar.png b/docs/comer/_static/orakWlum/m12_example_calendar.png
diff --git a/docs/comer/_static/orakWlum/menu_orakWlum.png b/docs/comer/_static/orakWlum/menu_orakWlum.png
diff --git a/docs/comer/_static/orakWlum/previsio_exportar.png b/docs/comer/_static/orakWlum/previsio_exportar.png
diff --git a/docs/comer/_static/orakWlum/previsions_detall.png b/docs/comer/_static/orakWlum/previsions_detall.png
diff --git a/docs/comer/_static/orakWlum/previsions_resum.png b/docs/comer/_static/orakWlum/previsions_resum.png
diff --git a/docs/comer/_static/orakWlum/tasques_historics.png b/docs/comer/_static/orakWlum/tasques_historics.png
diff --git a/docs/comer/_static/orakWlum/tasques_previsions.png b/docs/comer/_static/orakWlum/tasques_previsions.png
diff --git a/docs/comer/algoritmos_orakWlum.md b/docs/comer/algoritmos_orakWlum.md
@@ -0,0 +1,164 @@
+# Algoritmes de predicció de orakWlum
+
+**orakWlum** és una eina capaç de generar **previsions de consum** a partir de les mesures històriques de l'ERP de Comercialitzadora
+amb la finalitat de tenir una base sòlida sobre la que generar les ofertes de compra a publicar a l'Operador del Mercat
+(OMIE).
+
+Per a fer-ho, tan sols cal triar una data i un **algoritme de predicció** d'entre els disponibles. Les prediccions variaran
+segons l'algoritme utilitzat, ja que cadascun d'ells empra diferents estratègies i variaran les dades històriques utilitzades
+per a calcular la predicció.
+
+[ ![Tria d'algoritme de predicció](_static/orakWlum/algorithm_select.png)](_static/orakWlum/algorithm_select.png)
+
+Un cop creada la previsió de consum, aquesta es calcularà utilitzant l'algoritme predictiu triat.
+
+## Teoria comuna
+
+Quan orakWlum tracta de trobar consum històric per als CUPS, l'algorisme utilitzat anirà recorrent les fonts en ordre de 
+prioritat ascendent, és a dir, començant per la que tingui el valor de prioritat més baix. Si no es troba el consum per 
+a les 24 hores del dia a la font consultada, es salta a la següent en ordre de prioritat, fins que s'han recorregut totes.
+
+Si després de recórrer totes les fonts, el CUPS queda sense consum, el que es fa és consultar la tarifa d'accés i calcular 
+una mitjana per tarifa i hora a partir de tots els CUPS amb aquesta mateixa tarifa que sí que han trobat consum històric 
+a les fonts.
+
+D'aquesta manera, es garanteix que s'obté el consum per a tots els CUPS, encara que algun pugui no ser present a les fonts.
+
+En el diagrama següent es mostra com un conjunt de CUPS van obtenint la previsió de consum a partir de l'històric o, per 
+al cas dels CUPS que no disposin d'aquest, de la mitjana de consum de la resta de CUPS amb la mateixa tarifa d'accés.
+
+[ ![Obtenció de Consum Històric](_static/orakWlum/exemple_cups_fetch.png)](_static/orakWlum/exemple_cups_fetch.png)
+
+Inicialment, cap dels CUPS no disposa de consum històric. A mesura que es recorren per ordre de prioritat les fonts de 
+consum històric (F5D, F1, P1, etc.) cada cop hi ha més CUPS que han obtingut consum (conjunt blau) mentre que va minvant 
+el nombre de CUPS que no l’han obtingut (conjunt vermell). En acabar el recorregut de les fonts, s'obté el consum per els 
+CUPS que encara no en tenen mitjançant la mitjana per hora dels CUPS de la mateixa tarifa que sí que han obtingut consum.
+
+Un cop feta l'obtenció del consum de cada hora per a tots els CUPS, s'agrupen aquests consums per hora i es genera així 
+la previsió.
+
+
+## M-12 (One-Year-Ago)
+
+Aquest algorisme és molt ràpid. La seva estratègia és, atesa la data per a la qual es vol calcular la previsió de consum, 
+retrocedir un any exacte en el temps per trobar aquest mateix dia de la setmana fa un any i consultar el seu històric de 
+consum a les fonts d'orakWlum.
+
+En el següent exemple, es vol generar una previsió de consum per al 21 d'abril del 2022 (marcat en groc al calendari). 
+orakWlum calcularà quin és el dijous equivalent de fa un any i obtindrà dels històrics de consum d’aquesta data el consum a 
+proposar. En aquest exemple, la data objectiu serà el 22 d'abril del 2022 (marcat en groc al calendari). Els CUPS que no tinguin 
+històric de consum en aquesta data, s'estimaran amb la mitjana horària d'acord amb la tarifa, tal com s'explica al diagrama de
+la secció anterior d'aquest document.
+
+[ ![Exemple M-12](_static/orakWlum/m12_example_calendar.png)](_static/orakWlum/m12_example_calendar.png)
+
+Aquest algorisme és molt lleuger, permet fer prediccions per a milers de CUPS en uns segons i funciona especialment bé quan 
+el conjunt de CUPS té una estacionalitat molt marcada, és a dir, quan els CUPS tenen un perfil de consum molt diferent segons 
+l'època de l'any (per exemple, els associats a hotels o zones turístiques).
+
+
+### Avantatges
+
+* Rapidesa de càlcul.
+* Bon funcionament amb carteres de CUPS amb perfil de consum marcadament estacional.
+
+### Limitacions
+
+* Sensible a desviacions provocades per perfils de consum atípics un any enrere de la data de la predicció.
+
+## Gauss (Mitjanes Normalitzades)
+
+Aquest algorisme és més robust. La seva estratègia és, atesa la data per a la qual es vol calcular la previsió de consum, 
+crear una col·lecció de dies “candidats” dels quals obtenir consum històric per calcular la previsió.
+
+Per això, en primer lloc hem de definir els “tipus de dies” de la setmana. El comportament de l'algorisme serà diferent 
+segons tractem cadascun dels 7 dies de la setmana com un tipus de dia diferent o si, com es decideix de vegades, es tracten 
+com el mateix tipus de dia els dimarts, els dimecres i els dijous. D'aquesta manera, si decidim que els dijous són un tipus 
+de dia en particular, quan es consulti el consum històric, la col·lecció de dies candidats constarà de diversos dijous 
+anteriors a la data de la predicció. Si s'opta per considerar que dimarts, dimecres i dijous són un mateix tipus de dia, 
+aleshores la predicció per a un dijous farà servir dimarts, dimecres i dijous de les setmanes anteriors a la data de predicció. 
+En tot cas, els festius i els diumenges sempre es consideraran un mateix tipus de dia.
+
+El principal objectiu d'aquest algorisme i la seva evolució respecte al **M-12** és que tinguem una mostra de consums històrics 
+més recents i més propers a la data de la previsió. Per això, es pot ajustar el paràmetre “max” per dir fins quants dies 
+enrere volem consultar quan es faci una predicció. D'aquesta manera, si el paràmetre “max” s'ajusta a 10 dies, en calcular 
+una predicció per a dijous que ve, es faran servir com a dies candidats els 10 dijous anteriors, en ordre temporal invers, 
+del més recent al més antic. És important assenyalar, que si es va establir que dijous és el mateix tipus de dia que dimarts 
+i dimecres, aleshores la mostra de dies candidats dels quals consultar el consum històric a les fonts seran per aquest ordre: 
+dimecres anterior, el dimarts anterior, dijous de fa una setmana, dimecres de fa una setmana, dimarts de fa una setmana, 
+dijous de fa dues setmanes, dimecres de fa una setmana, etc. fins arribar als 10 dies candidats, com estableix el paràmetre 
+max. Aquest paràmetre permet llavors definir com de propers volem que siguin els dies candidats per tenir en compte el perfil 
+de consum.
+
+Un problema que passa de vegades amb l'algorisme **M-12** és que com que es fa servir un únic dia per consultar l'històric, 
+és possible que aquell dia tingués unes condicions diferents del de la predicció. Per exemple, una temperatura extrema i 
+rara per a l'època o qualsevol altra circumstància que provoqui que el perfil de consum dels CUPS no fos típic i en desviï 
+la previsió. Per evitar això, l'algorisme **Gauss** té un últim paràmetre anomenat “min” que defineix el nombre mínim de dies 
+sobre els quals es consultarà el consum. Això significa que si ajustem el paràmetre “min” a 3 dies, per exemple, en lloc 
+de recórrer els dies candidats enrere en el temps i fer servir per a cada CUPS el primer dia que trobi el consum de les 24 
+hores, aniré guardant dies complets fins a tenir els requerits pel paràmetre. És a dir, que orakWlum guardarà per a cada 
+CUPS una mostra de 3 dies complets amb el consum en cadascuna de les 24 hores. Un cop acabat el recorregut, per a cada CUPS 
+es farà una mitjana normalitzada entre els consums de la mostra hora a hora, suavitzant així els possibles consums atípics 
+que poguessin desviar la previsió.
+
+Al següent exemple, es vol generar una previsió de consum per al 22 d'abril de 2021. A l'exemple de l'esquerra, s'ha ajustat 
+que dijous és un únic tipus de dia i l'exemple de la dreta, es consideren el mateix tipus de dia dimarts, dimecres i dijous. 
+En tots dos casos, s'anirà retrocedint en el temps fins al màxim de dies establert a l'algorisme (6 dies, en aquest cas). 
+Al primer exemple, veiem que només es tenen en compte els dijous anteriors a la data de la previsió, mentre que a l'exemple 
+de la dreta, es tenen en compte els dimarts, dimecres i dijous anteriors a la data de previsió fins a tenir així els 6 dies 
+candidats. Un cop seleccionats aquests dies candidats, orakWlum els recorrerà de més recent a més antic consultant els consums 
+històrics corresponents als CUPS en aquestes dates.
+
+[ ![Exemple Gauss](_static/orakWlum/gauss_example_calendar.png)](_static/orakWlum/gauss_example_calendar.png)
+
+Els CUPS que no hagin pogut obtenir una mostra de consum històric, s'estimaran amb la mitjana horària d'acord amb la tarifa,
+tal com s'explica al diagrama de la secció anterior d'aquest document.
+
+### Avantatges
+
+* Millor precisió que l'algoritme **M-12**, al ser menys sensible als perfils de consum atípics dels històrics.
+* Gran fiabilitat, al consultar una mostra de consum històric el més propera possible a la data de la predicció.
+* Major personalització, al poder ajustar els paràmetres disponibles.
+
+### Limitacions
+
+* Temps de càlcul molt més elevat que l'algoritme **M-12** al tenir que obtenir moltes més dades i normalitzar-les, abans 
+d'obtenir el consum proposat.
+
+## MVH (Millor Valor Horari)
+
+Aquest algorisme es basa en la idea de l'algoritme **Gauss** però eliminant la necessitat de consultar una per una totes
+les col·leccions de dades de consum històric. Enlloc d'això, un cop sel·leccionats els dies candidats a consultar, es farà
+la consulta únicament en una nova col·lecció anomenada `mvh` (Millor Valor Horari). El fet d'eliminar les múltiples
+consultes, fa que sigui més lleuger que l'algoritme **Gauss** mantenint una bona qualitat en les mesures obtingudes.
+
+L'objectiu principal de l'algoritme **MVH** és que no sigui `orakWlum` qui s'encarregui de recórrer totes les fonts de
+consum històric per a determinar la millor mesura horària de cada CUPS, sino que això ho hagi fet ja un procés independent
+que es pugui llançar manualment o mitjançant algun automatisme, recalculant el millor valor horari de tots els CUPS actius
+pel Comercialitzador donat un rang de dates. El resultat, és un algoritme robust però més lleuger en temps computacional
+que l'algoritme **Gauss**.
+
+A més de comptar amb la personalització de la tipologia de dia de la setmana i del màxim de dies que es permet tirar enrere
+en el temps a l'hora de generar la llista de dies candidats, amb l'algoritme **MVH** apareixen nous paràmetres:
+
+* En primer lloc la quantitat de dies candidats es volen consultar a la col·lecció `mvh` (mostra màxima) i quin pes
+  s'assignarà a la mesura de cada día. Un exemple seria la configuració per defecte: 3 dies candidats, assignant al valor
+  proposat un 70% del dia més proper, un 20% del segon dia més proper i un 10% del dia menys proper.
+* En segon lloc, un multiplicador global que, un cop obtinguda la previsió de consum hora a hora, farà que aquesta creixi
+  o decreixi, en funció de com es configuri el paràmetre. Aquest paràmetre per defecte està assignat a 100%, per a que no
+  afecti al consum proposat. Si es vol activar, cal configurar-ho a les variables de l'ERP. És especialment útil, per a
+  que les previsions compensin automàticament el desviament observat entre la previsió i la realitat.
+
+Com amb els altres algoritmes, els CUPS que no hagin pogut obtenir una mostra de consum històric, s'estimaran amb la mitjana
+horària d'acord amb la tarifa, tal com s'explica al diagrama de la secció anterior d'aquest document.
+
+### Avantatges
+
+* Bona relació entre temps de càlcul i fiabilitat de la previsió de consum final.
+* Compensació automàtica del desviament, si es configura el multiplicador per a que el corregeixi un cop s'ha generat
+  la previsió.
+
+### Limitacions
+
+* Requereix que s'hagi calculat prèviament el millor valor horari (`mvh`) pels dies que es faran servir com a candidats
+  a l'hora d'obtenir dades de consum històric.
diff --git a/docs/comer/bateria_virtual.md b/docs/comer/bateria_virtual.md
@@ -0,0 +1,98 @@
+# Bateria virtual
+## Introducció
+
+La bateria virtual és un mòdul lligat a la modalitat contractual d'autoconsum, que permet acumular aquells euros de descompte que no s'han pogut aplicar en una factura, perquè el descompte era major al cost de l’energia consumida. 
+
+Com indica l’article 14 del Real Decret 244/2019 pel qual es regula l’autoconsum d’energia elèctrica: *“En ningún caso, el valor económico de la energía horaria excedentaria podrá ser superior al valor económico de la energía horaria consumida de la red en el periodo de facturación, el cual no podrá ser superior a un mes.”* Això vol dir que no pot haver-hi una factura en què degut als excedents a descomptar sigui en negatiu (a favor del titular). En aquests casos el cost de l’energia consumida queda a 0, i la resta de descompte es “perd”. Per evitar-ho, hem desenvolupat la bateria virtual, que funciona a tall de “guardiola”, on aquest excedent pendent de compensar es guarda per poder aplicar-se en futures factures, on el cost del consum sigui superior. 
+
+La bateria virtual està formada per quatre models de dades relacionades entre si. És a dir, quatre tipus de fitxes que es poden veure en llistat:
+
+### Fitxa Bateria Virtual
+
+Es tracta de la fitxa principal. Mostra la quantitat total d'euros acumulats que hi ha per descomptar així com un quadre de text amb tota la informació dels processos executats, i l’acció d’activar contractes.
+
+![](_static/bat_virtual/on_esta_bat_virtual.png)
+
+
+![](_static/bat_virtual/FITXA_BAT_VIRTUAL.png)
+
+### Contractes/pòlisses de la bateria virtual
+
+Dins de la bateria virtual, si anem a llistats relacionats, podem veure els contractes vinculats a la bateria. Això vol dir que més d’un contracte pot ser beneficiari dels descomptes generats (receptors) pel contracte generador (origen). 
+
+Mostra la següent informació: 
+Euros totals que es pot descomptar
+Si es vol aplicar el descompte
+Pes que té dins de la bateria virtual. Com més pes més quantitat de descompte se li aplicarà a aquest contracte.
+
+Què és el concepte pes? El pes és el sistema de repartiment del descompte entre els diferents contractes que poden ser receptors. Seria com el percentatge que volem que tingui cada contracte. El càlcul és el següent: hem de sumar el pes de tots els contractes receptors i dividir entre el pes de cada contracte. Així sabrem el percentatge de repartiment de descompte per cadascú.  
+
+![](_static/bat_virtual/pes_polissa.png)
+
+Però perquè ho fem en números absoluts i no en percentatges directament? Perquè si traiem un contracte receptor de la bateria virtual, el percentatge de repartiment canvia directament als altres contractes sense necessitat de modificar-ho manualment.
+
+### Origen de la bateria virtual
+
+Tal com indica el nom, **és la font dels descomptes de la bateria virtual**. Normalment, un contracte amb autoconsum és tant l'origen d'una bateria virtual com de receptor de descomptes d'una bateria virtual. Però un contracte podria ser origen de descomptes sense rebre descomptes i viceversa.
+
+![](_static/bat_virtual/fitxa_bat_virtual.png)
+
+![](_static/bat_virtual/llistat_origen.png)
+
+Els imports que s'afegeixen a la bateria virtual es calculen a partir de les línies de saldo “excedents autoconsum” de les factures client del contracte.
+
+![](_static/bat_virtual/saldo_excedent_fact.png)
+
+### Descomptes de la bateria virtual
+
+Representa tots els descomptes que té la bateria virtual. Mostra l'import, la font del descompte o el dia que s'ha calculat, entre altres coses.
+
+![](_static/bat_virtual/llistat_descompte.png)
+
+El llistat de descomptes tindrà línies positives, representant descomptes afegits a la bateria virtual, i tindrà línies negatives, representant descomptes ja aplicats a factures. La quantitat d'euros acumulada d'una bateria serà la suma de totes les línies de descompte.
+
+![](_static/bat_virtual/fitxa_descompte.png)
+
+## Accions de la bateria virtual
+
+Per facilitar la feina, es poden veure i crear fitxes, i fer accions de bateria virtual des de la mateixa fitxa contracte/pòlissa. 
+
+![](_static/bat_virtual/bat_virtual_polissa.png)
+
+![](_static/bat_virtual/afegir_polissa_abat.png)
+
+![](_static/bat_virtual/accio.png)
+
+Si volem crear la nova bateria, podem fer-ho des d'aquí mateix.
+
+![](_static/bat_virtual/crear_bat.png)
+
+![](_static/bat_virtual/crear_bat_II.png)
+
+Si la bateria ja està creada i voleu afegir-hi un contracte, busqueu-la i assigneu-la. En aquest moment és quan podem dir si la pòlissa serà l'origen i/o receptora, i el pes que ha de tenir.
+
+![](_static/bat_virtual/ascreenshot(3).jpeg)
+
+![](_static/bat_virtual/ascreenshot(4).jpeg)
+
+![](_static/bat_virtual/ascreenshot(5).jpeg)
+
+Un cop tenim la pòlissa assignada a una bateria, al anar a la subpestanya de Bateries Virtuals del contracte, veurem la informació
+
+![](_static/bat_virtual/dins_pestanya.png)
+
+## Com es generen les línies de descompte
+
+Quan hi ha més excedent per compensar que consum a facturar, l'import de consum és 0, i es genera una línia de descompte pendent a descomptar, que s'afegeix a la bateria virtual de la qual n'és orígen aquell contracte.
+
+![](_static/bat_virtual/factura_bateria_virtual.png)
+
+En el llistat de descomptes de la bateria virtual es poden veure els descomptes generats, i quan s'apliquen. 
+
+
+
+
+
+
+
+
-Original file line number
+Diff line change
@@ -1,6 +1,7 @@
     site/
     *.idea
     .idea/
+    .vscode/
     *.pyc
     *.pot
     *.mo
@@ Expand Down @@