neclaritati schema XSD

[florinser]

Am analizat schema XSD transmisa si am identificat cateva aspecte pe care va rugam sa le clarificati:

1) Va rugam sa completati documentul XSD cu descrierea campurilor/valorilor asteptate pentru situatiile in care acestea nu exista. Sunt situatii in care nu sunt clare: @value:ATRCG - ce reprezinta? @value:CERTIFICATRACORDARE

2) In cadrul schemei XSD am identificat anumite entitati cum ar fi "PLACE" in cadrul mesajelor OR, dar si FZ. In cadrul acestor entitati am identificat valori obligatorii pe care trebuie sa le livreze FZ, dar pe care acesta nu le detine:Place-TechnicalData-DocumentType - valori precum "smartMeter", "ATRGN", "ATREE","ATRCG". Va rugam clarificati aceasta situatie.

3) "Bloc, Scara, Etaj" sunt definite in cadrul schemei intr-un singur camp de tip Extended. La transmiterea catre POSF aceste date pot fi concatenate intr-un singur camp, dar la preluare din POSF acest camp nu poate fi decompus astfel incat informatiile precum "Bloc, Scara, Etaj" sa fie salvate in campurile corespondente din sistemul informatic al OR/FZ. Va rugam clarificati aceasta situatie.

4) Nomenclatorul de adrese al OR/FZ-orilor va fi diferit fata de nomenclatorul POSF, iar "Adresa" este un camp obligatoriu in multe din mesaje. Ce se intampla daca "Adresa" trimisa de FZ este diferita de cea din POSF?

5) Pentru entitatea "Previous supplier", intelegem ca FZ nou trebuie sa trimita catre POSF informatii despre "Adresa", "Legal representative" etc, informatii de detaliu pe care in mod normal nu se regasesc in sistemul informatic al FZ nou. "Legal representativ" FZ vechi este o informatie pe care trebuie sa o intretina FZ nou si sa o trimita catre POSF? Va rugam sa clarificati de ce este necesar ca FZ nou sa trimita informatii de detaliu despre FZ vechi in cadru POSF.

6) "LegalID" este de tip "Company" si are la randul ei "Adresa". Ce reprezinta si care este diferenta fata de "Adresa" de la nivel de "Supplier"?

Multumesc,

[bogdannedelcu]

Buna ziua,

1. A fost actualizata schema
2. Am retinut observatia, in masura in care emitentul mesajului nu detine acele informatii nu le va completa.
3. Analizam propunerea si revenim
4. Se vor salva in baza de date POSF toate adresele transmise. Daca vor exista diferente, un operator uman va alege vizual adresa corecta in urmatorul act emis. POSF pune la dispozitie un API prin care se poate extrage adresa unui Place asa cum este ea inregistrata in baza de date la constituirea acelui loc de consum
5. Intelegerea este corecta, legat de intrebare dvs vom reveni cu un punct de vedere
6. A fost o eroare, am actualizat schema in zona de Company/Operator/Supplier, va rugam verificati noua versiune

Multumim

[florinser]

1) In cadrul mesajului ContractSignbyClient va rog sa aveti in vedere ca urmatoarele campuri sa fie optionale, intrucat acestea nu sunt furnizate de client intotdeauna in procesul de contractare din urmatoarele motive: 1) nu exista (ex. Fax) 2) clientul isi rezerva dreptul sa nu le furnizeze (ex: numar de telefon), fie nu detine astfel de informatii (ex: adresa de email), fie nu au o importanta deosebita in cadrul procesului de contractare (ex: Serie/nr CI)

• Serie si numar CI
• Tip act de identitate
• Date de contact: fax, numar de telefon, email
• Numar Strada – practica ne-a aratat ca nu toate adresele au si un numar de strada alocat

2) Va rugam sa confirmati ca in cadrul mesajului ContractSignbyClient, campul “Contract Status=activ, incetat, suspendat” al entitatii “Contract” este o informatie care se refera la contractul nou semnat. Intelegerea noastra este ca incadrul acestui mesaj, valoarea campului va fi intotdeauna “activ” la semnarea unui contract nou de catre Furnizor. In ce situatie contract status va avea valorile “incetat, suspendat”?

3) In cadrul mesajului ContractSignbyClient, “isPRE”, “PreCompany” nu sunt informatii care necesita sa fie transmise la fiecare contract semnat si nu se regasesc in contractul de furnizare semnat cu clientul. Informatia trebuie preluata la migrarea initiala si ulterior intretinuta de fiecare furnizor la nivelul entitatii Furnizor definite in platforma POSF. Va rugam sa furnizati un punct de vedere, avand in vedere ca din schema XSD rezulta ca aceste informatii sunt oibligatorii de transmis.

4) In cadrul mesajului ContractSignbyClient, “Neinteruptibil” este o informatie pe care furnizorul nu o capteaza in procesul de contractare. Va rugam sa furnizati un punct de vedere, avand in vedere ca din schema XSD rezulta ca aceste informatii sunt obligatorii de transmis.

5) Pentru campul “Incorporation”, forma juridica ar trebui inlocuita cu CAEN, acesta fiind elementul de identificare al formei juridice. Va rugam un punct de vedere.

6) In cadrul mesajului ContractSignbyClient va rugam sa aveti in vedere ca datele de identificare FA sa fie campuri optionale. Ele nu sunt cunoscute de catre FN

7) In contextul clarificarilor solicitate anterior, ar fi util ca schema XSD prezentata sa fie actualizata, astfel incat sa rezulte care campuri sunt obligatorii/optionale pt. fiecare actor FZ/OR in cadru schimburilor de mesaje cu platforma POSF.

8) Conform precizarilor dvs., POSF pune la dispozitie un API prin care se poate extrage adresa unui Place asa cum este ea inregistrata in baza de date la constituirea acelui loc de consum. Va rugam sa puneti la dispozitie structura acestui API precum si detaliile de apelare ale acestuia , respectiv : mesaje tip sincron/asincron, modalitate de auth /securizare ? In acceptiunea noastra, intelegem ca aceste tip de apel va fi de tip sincron.

Mentionam ca pe langa informatia legata de “Adresa”, in procesul de contractare ar fi utila o interogare in timp real si obtinerea datelor de baza la nivelul locului de consum din POSF: adresa, stare loc de consum (conecta, deconecta), date client, adresa, alte informatii de baza.

Considerente:

• in POSF, OR intretine diverse informatii tehnice la nivelul locului de consum (ex conectat, deconectat) pe care Furnizorul trebuie sa le verifice in momentul contractarii; datele tehnice privind locul de consum sunt obligatorii in cadrul entitatii ContractSignByClient.
• accesul FZ la aceste date in timp real, tinand cont de termenul de 24 de ore, ar facilita verificarea datelor transmise de Client in procesul de contractare din platforma FZ si implicit ar asigura o actualizare corecta in POSF a datelor de baza, respectiv eliminare anumitor situatii care ar presupune ulterior corectii sau interventii manuale si implicit intarzieri in cadrul procesului.

9) Vor mai exista in POSF disponibilie si alte API-uri prin care se pot obtine datele entitatilor principale: Contract, Client, Loc de consum, date FA, FN, OR? Daca da , va rugam sa ne transmiteti detaliile acestora.

10) Pentru electricitate POD specificat in Regulamentul POSF reprezinta POD (cod loc consum) sau PM (codul punctului de masura). Pentru anumiti OR, POD este doar o parte din structura PM. Care vor fi datele puse la dispozitie in POSF de catre OR/CF/FZ, POD sau PM?

11) Care este mesajul/interfata prin care vine cel de-al doilea Index autocitit, conform cu art 43 lit e.?

12) Cum va fi notificat OR ca are de semnat in POSF un contract de distributie? Va exista un process de semnare contract de distributie, prin care OR si FZ sa intre in platforma POSF sa semneze contractul de distributie?

[bogdannedelcu]

Ref 8: Gasiti aici un sample care contine API pentru publicare mesaje si extras locuri de consum. Da apelul este sincron. https://github.com/posfgit/standard/tree/main/samples/python . Detalii referitoare le securizare, useri si parola veti primi odata cu operationalizarea mediului de testcu mentiunea ca vom folosi ca si standard OpenID.

[florinser]

1. Referitor la Art. 34, alin. (4), va rugam sa ne comunicati daca documentele despre care se mentioneaza ca POSF le genereaza si le transmite succesiv la incheierea unui contract de furnizare (contractul de distributie, conventia tripartita/multipartita, contractul de furnizare înregistrat, notificarea privind încheierea contractului de furnizare, respectiv notificarea privind finalizarea procedurii) vor fi transmise catre OR de POSF si sub forma de document atasat sau doar sub forma de campuri distincte in fluxul din interfata cu informatiile existente in fiecare document in parte. Solicitam aceasta clarificare in conditiile obligatiei OR, in cazul in care clientul care doreste contract de distributie cu OR si nu are cont in POSF, de a descarca contractul de distributie si conventia tripartita/multipartita si sa le semneze cu CF extra POSF.

2. Avand in vedere posibilitatea ca documentul contract de distributie sa fie semnat in POSF sau extra POSF in functie de situatia in care se gaseste CF (are sau nu are cont in POSF), va rugam sa ne comunicati daca OR va fi notificat de POSF cand CF nu are cont in POSF pentru a sti daca este necesar sa descarce contractul de distributie si de a contacta CF in vederea semnarii contractului de distributie extra POSF conform obligatiilor de la Art. 34, alin. (4), lit. a), (i).

3. Referitor la Art. 34, alin. (4), lit. a), (ii) prin care se specifica faptul ca:

   • in cazul in care CF alege sa nu incheie contract de distributie direct cu OR, POSF genereaza catre OR contractul de distributie care va fi semnat de OR cu FN doar in cazul in care intre OR si respectivul furnizor nu există deja un contract de distributie,
   • iar daca deja exista contract de distributie intre OR si furnizorul care a solicitat locul de consum, POSF va transmite doar notificare privind preluarea CF în contractul cu respectivul furnizor,
   • avem rugamintea sa ne precizati daca, in cazul in care un furnizor cu care OR nu are incheiat contract de distributie va semna contracte de furnizare cu mai multe locuri de consum din distributia unui OR si le va transmite in acelasi timp in POSF, cu aceasi data de includere, POSF va genera pentru fiecare solicitare in parte contract de distributie sau va genera contract de distributie doar pentru prima solicitare, iar pentru restul solicitarilor va genera notificarea privind preluarea CF în contractul cu respectivul furnizor.

4. Referitor la Art. 47, alin (4), lit. a) in situatia in care clientul renunta la contractul incheiat cu un FN(FN1) inainte ca acesta sa produca efecte si doreste incheierea unui contract de furnizare cu un alt FN (FN2), noi am identificat doua situatii pentru care va rugam sa ne ajutati cu o clarificare in privinta modului de tratare: 4.1. clientul solicita contract cu FN2 cu o data anterioara intrarii in vigoare a contractului cu FN1. In aceasta situatie, mai este necesara aplicarea procedurii de schimbare a furnizorului de la FN1 la FN2, sau se poate face direct trecerea de la FA la FN2? 4.2. clientul solicita contract cu FN2 cu o data ulterioara intrarii in vigoare a contractului cu FN1. Consideram ca aceasta este situatia care poate fi tratata conform cu prevederile de la Art. 47, alin (4), lit. a), aplicarea procedurii de schimbare de furnizor de la FN1 la FN2. Este corecta intelegerea?

5. Luand in considerare fiecare din aspectele intalnite in practica cu privire la rezilierea unui contract de furnizare: incetarea contractului de furnizare prin ajungere la termen, rezilierea contractului de furnizare de catre FA, reziliere definitiva solicitata de CF cand acesta nu mai doreste alimentarea cu gaze natutale la un loc de consum va rugam sa ne comunicati pe ce interfata va fi transmisa catre OR informatia de reziliere a unui contract de furnizare si care va fi parcursul fluxului de reziliere prevazut de POSF intre FA si OR.

6. De asemenea, va rugam sa ne transmiteti daca s-a luat in considerare situatia in care se renunta la solicitarea de reziliere a unui contract de furnizare dupa ce mesajul de reziliere a ajuns din POSF catre OR si pe ce interfata se transmite catre OR.

7. In descrierea interfetei ContractChangedInfo se mentioneaza ca este destinata evenimentelor legate de actualizarea datelor pe contractul de furnizare care nu implica activitati in fluxul informatic, iar exemplele furnizate sunt: TechnicalData, adresa de facturare, nume schimbat. Va rugam sa ne detaliati exprimarea “nu implica activitati in fluxul informatic”. Mentionam ca informatia de modificare a numelui este necesar sa genereze un flux catre OR intrucat OR are nevoie in raport cu alte obligatii legislative sa poata actualiza/schimba denumirea clientului (transmiterea datelor de inspectii tehnice, efectuarea operatiunilor aferente serviciilor conexe: deconectare/reconectare instalatie, montare contor la cerere, etc). Totodata, actualizarea numelui implica modificari si in contractul de distributie incheiat intre furnizor si OR si va rugam ca aceste informatii sa fie vehiculeaza prin intermediul unui flux, asa cum se vehiculeaza datele si urmare incheierii contractului de furnizare.

8. In structura mesajelor PlaceCreatedByOperator, PlaceUpdatedByOperator, PlaceDisconnectedByOperator prin care operatorul transmite catre POSF informatii despre locurile de consum din portofoliu, se gasesc si informatiile cu privire la OR: adresa completa a societatii, CUI, cod postal, adresa de contact, nr. de telefon, fax, etc. Avand in vedere ca aceste informatii despre operator au fost migrate de OR la momentul transmiterii initiale a tuturor datelor existente si de asemenea avand in vedere ca in cadrul OR aceste informatii se modifica foarte rar, va rugam sa luati in considerare ca acestea sa nu mai fie campuri obligatorii de fiecare data cand se transmit catre POSF mesaje de actualizari periodice aferente locurilor de consum, aceste date urmand sa fie transmise de OR doar cand se produce o modificare intr-unul din aceste campuri. In acest context, am observat ca dintre datele pe care trebuie in acest moment sa le transmita OR despre entitatea acestuia pe interfetele mentionate mai sus, toate sunt obligatorii cu exceptia campului operatorld. Propunem ca acest camp operatorld sa devina camp obligatoriu si prin intermediul acestuia sa se mapeze restul datelor aferente OR existente deja in sistemul POSF. Totodata, asa cum cunoasteti codul locului de consum transmis de OR contine in denumirea sa un cod de litere unic ce poate fi asociat doar unui operator, conform cu legislatia in vigoare, situatie in care prin primirea unui CLC se va cunoaste implicit si OR care asigura serviciul de distributie la locul de consum respectiv asociat CLC.

9. Avem rugamintea sa ne precizati ce informatie se asteapta in POSF in campul operatorld.

10. In structura mesajului PlaceCreatedByOperator, prin care OR transmite catre POSF instiintarea despre crearea unui nou loc de consum, apar drept campuri obligatorii informatiile despre contor (counterSeries,CounterType, s.a.). Insa, intrucat acest mesaj se transmite de catre OR spre POSF dupa punerea in functiune a instalatiei de racordare, cand inca nu este efectuata punerea in functiune a instalatiei de utilizare si montarea mijlocului de masura, OR va fi pus in imposibilitatea de a transmite aceste mesaje. Astfel, va rugam sa luati in considerare ca mesajele ce contin date cu privire la mijlocul de masurare montat in urma unei puneri in functiune initiala a instalatiei de utilizare sa poata fi transmise de OR pe interfata PlaceUpdatedByOperator si nu pe interfata PlaceCreatedByOperator In acelasi context, va rugam sa luati in considerare ca si campul status cu atributele CONECTAT, DECONECTAT sa fie transmis de OR pe interfata PlaceUpdatedByOperator si nu pe interfata PlaceCreatedByOperator odata cu datele de contor.

11. Referitor la data pressure din structura mesajului PlaceCreatedByOperator, data care este obligatoriu a fi transmisa in format decimal (numeric) va rugam sa aveti in vedere ca OR sa poata transmite aceasta informatie si in format text sau interval. Solicitam acest lucru intrucat pe ATR eliberat in urma solicitarii CF de loc nou de consum, aceasta informatie se gaseste sub forma de treapta de presiune (joasa, redusa, medie,inalta) si nu sub forma de valoare absoluta.

12. Va rugam sa ne precizati care sunt mai exact evenimentele dupa care se vor transmite date de catre OR pe interfata PlaceUpdatedByOperator.

13. Referitor la structura interfetei PlaceUpdatedByOperator care se transmite catre POSF de catre OR catre POSF atunci cand are loc o actualizare pe un loc de consum a diverselor informatii gestionate de OR, am constatat ca aproape toate campurile sunt obligatorii si se transmit de fiecare data chiar daca nu au suferit o modificare in sistemul OR. Consideram ca aceasta transmitere integrala a datelor de fiecare data ar putea duce la ingreunarea sistemului si a timpilor de transmitere a datelor intre sisteme. Va rugam sa luati in considerare ca datele din fiecare categorie a interfetei sa fie optional de transmis. Astfel, sa fie vehiculate pe interfata doar datele care au suferit o actualizare pentru updatarea acestora, iar restul, deja existente sa ramana nealterate in POSF.

14. Referitor la structura interfetei PlaceDisconnectedByOperator prin care OR transmite catre POSF instiintarea despre deconectarea unui loc de consum, va rugam sa luati in considerare, tot din considerente de optimizare a timpilor necesari transmiterii de date, ca mesajele ce insotesc informatia cu privire la starea instalatiei si care se gasesc deja in structura interfetei PlaceUpdatedByOperator sau altele date pentru care obligatia de a fi intretinute/actualizate in POSF cade in sarcina CF sau furnizori prin intermediul altor interfetei si care se gasesc deja in sistemul POSF in momentul in care pe interfata DisconnectedByOperator OR transmite informatia instalatie deconectata, sa nu mai fie transmise inca o data de OR si pe interfata Place DisconnectedByOperator. Ca argumente in favoarea celor solicitate mai sus completam cu urmatoarele:

    • datele referitoare la client transmise pe aceasta interfata sunt obligatoriu de transmis de OR, inclusiv datele de contact (telefon, email, s.a.), insa CF are dreptul sa nu transmita aceste date de contact sau sa nu detina unele din mijloacele de comunicare/contact prevazute in structura interfetei. Totodata, in cele mai multe din cazuri, intre CF si OR nu este o relatie contractuala directa, comunicarea efectuandu-se intre furnizor si clientul final, iar sistemul OR se poate sa nu aiba actualizate la zi aceste informatii; astfel, consideram oportun ca aceste date sa fie transmise doar de catre FA pentru a nu se genera date inconsistente in POSF;
    • datele grupate sub denumirea correspondenceAddress, se schimba si se intretin intre CF si furnizorul acestuia este posibil sa nu le aiba actualizate la zi, iar transmiterea lor atat din sistemul FA sau de la CF cat si din sistemul OR ar putea genera informatii inconsistente in sistemul POSF;
    • datele uninterruptible si vulnerable sunt informatii pe care FA le are la dispozitie in baza relatiei contractuale cu clientul; informatiile sunt intretinute si in sistemul OR, insa ele nu vor fi actualizate de OR in timp real fata de data cand se actualizeaza in sistemul furnizorului si transmterea lor si de catre OR ar putea genera informatii inconsistente in sistemul POSF.
    • alte campuri obligatorii si care sunt la dispozitia/in sarcina furnizorului/CF pentru a fi actualizate sunt: isAgregate, isPre, prosumer insa ele tin de activitatea de electricitate si nu reiese in clar daca ele sunt obligatorii a fi completate si pe interfata aferenta clientilor de gaze naturale Pentru campul type (tip act de identitate) care intra tot in componenta interfetei PlaceDisconnectedByOperator reiese din atributul Details ca informatiile asteptate pe aceasta interfata vor de tipul “CNP, CUI, OTHER,PASSPORT” Va rugam sa reanalizati acest aspect, intrucat informatia CNP/CUI nu este un atribut al informatiei tip act de identitate.

15. Va rugam sa ne precizati daca informatia de modificare a starii instalatiei din deconectat in conectat se va transmite catre POSF pe interfata PlaceUpdatedByOperator sau tot pe interfata Place DisconnectedByOperator.

16. Va rugam sa ne transmiteti pe ce interfata va primi OR mesajul de semnare a contractului de furnizare in POSF. In materialele puse la dispozitie pana acum pe hub-ul de comunicare a datelor tehnice, interfata ContractSignedBySupplier este destinata comunicarii mesajului de incarcare a contractului semnat de catre furnizor in POSF a contractului de furnizare semnat cu clientul extra POSF, iar interfata ContractSignedByClient figureaza ca este transmisa doar catre Furnizor si nu si catre OR.

17. Va rugam sa ne ajutati cu mai multe detalii cu privire la procesul declansat in POSF urmare accesarii interfetei ContractMoreInfo si cui ii este destinata comunicarea prin aceasta. In descriere se mentioneaza interfata este destinata solicitarii de informatii si mesajul este trimis de furnizor/operator care solicita mai multe informatii de la cealalta parte. Insa redirectionarea mesajului apare ca se face catre Furnizor sau WebPOSF, iar OR nu mai figureaza printre entitatile care primesc mesajul.

18. Va rugam sa ne precizati daca incarcarea contractului de distributie semnat intre CF si OR extra POSF in situatia cand CF nu detine cont in POSF se incarca de OR in POSF prin interfata ContractNetworkSignedByClient.

19. Referitor la mesajul ContractNetworkSignedByClient va rugam sa aveti in vedere ca in situatia in care CF semneaza contractul in POSF acesta sa fie transmis si catre OR.

20. Va rugam sa ne comunicati mai multe detalii cu privire la scopul mesajului ContractNetworkCancelledByOperator. Din denumire reiese ca este un mesaj transmis de OR insa OR nu apare mentionat ca entitate nici la sursa de date, nici la destinatar. Este necesar sa apara atat ca sursa, cand este initiatorul actiunii cat si ca destinatar, pentru cazurile cand initiatorul actiunii este CF sau furnizorul.

21. Care este mesajul prin care furnizorul nou este notificat ca procedura de schimbare furnizor s-a finalizat cu succes ?

22. Care este mesajul prin care furnizorul nou este notificat ca s-a primit INDEX-ul de la OR ?

[florinser]

Ref 8: Gasiti aici un sample care contine API pentru publicare mesaje si extras locuri de consum. Da apelul este sincron. https://github.com/posfgit/standard/tree/main/samples/python . Detalii referitoare le securizare, useri si parola veti primi odata cu operationalizarea mediului de testcu mentiunea ca vom folosi ca si standard OpenID.

Buna ziua, Multumesc pt raspuns. Va rog sa ma ajutati si cu o clarificare pentru restul intrebarilor din acest thread.

[IulianaPantilie]

Buna ziua,

Am o nelamurire legata de entitatile TechnicalData, TechnicalDataGas si TechnicalDataElectricity.

Entitatea Place are in componenta entitatea technicalData care, conform xsd, este de tipul TechnicalData. Descrierea elementului respectiv este: “Poate fi de tip TechnicalDataElectricity sau TechnicalDataGas”.

Ca aceste trei structuri, i.e., TechnicalData, TechnicalDataGas, TechnicalDataElectricity sa poata fi folosite, dupa caz, pentru un loc de consum de gaz sau pentru un loc de consum de Electricitate, nu ar trebui ca entitatea TechnicalData sa fie construita de exemplu ca in xsd-ul atasat (l-am atasat ca txt pt ca nu l-a acceptat ca xsd)?

Multumesc.

TechnicalData.txt

[bogdannedelcu]

@IulianaPantilie am adaugat exemplul de request POSTMAN pentru cele doua cazuri: EE si GAZ https://github.com/posfgit/standard/blob/main/samples/POSF-TEST.postman_collection.json

[IulianaPantilie]

Buna,

Se pot adauga totusi campurile specifice TechnicalDataGas si TechnicalDataElectricty in entitatea TechnicalData si, bineinteles, sa nu fie obligatorii? Eu folosesc SAP PO si maparea ar fi mult mai usor de facut.

Multumesc, Iuliana Pantilie

[bogdannedelcu]

Verificati in exemplul de POSTMAN cum se poate crea. Se includ toate campurile in TechnicalData si se modifica Type

[axinitza]

Salut. Tocmai asta era si Recomandarea " Se includ toate campurile in TechnicalData si se modifica Type", adica campurile din TechnicalDataGas si TechnicalDataElectricty sa fie incluse in "TechnicalData" , exp:

"TechnicalData" contine campurile :

consumption>{0,1}{0,1}{0,1}{0,1}{1,1}{1,1}{1,1}{1,1}{1,1} smartMeter>{1,1}{1,1}{1,1} consumption>{0,1}{0,1}{0,1}{0,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{0,1}{1,1}{1,1}{1,1}{0,1}{0,1}{0,1}{0,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{0,1}{0,1}{0,1}{0,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{0,1}{1,1}{1,1}{1,1} consumption>{0,1}{0,1}{0,1}{0,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{0,1}{0,1}{0,1}{0,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{1,1}{0,1}{1,1}{1,1}{1,1}