query_scheduled_exchanges returns always the Total Scheduled exchange, even if Dayahead = True

[jimich]

Example for BE -DE_LU On ETP for 8/9/22 we could see

However, with these code country_code_to = 'DE_LU' # country_code_from = 'BE' startstr = '20220908' endstr = '20220909' start = pd.Timestamp(startstr, tz='Europe/Brussels') end = pd.Timestamp(endstr, tz='Europe/Brussels')

DAAlloc=client.query_scheduled_exchanges(country_code_from, country_code_to,start=start,end=end,dayahead=True) TotalAlloc=client.query_scheduled_exchanges(country_code_from, country_code_to,start=start,end=end,dayahead=False)

--> DAAlloc contains 1030 like TotalAlloc ... while it should have contained 1000

I checked the query in entsoe.py and there is well a split on contract_marketagreement (where A01 is well Day-ahead and A05 total)

    if dayahead:
        contract_marketagreement_type = "A01"
    else:
        contract_marketagreement_type = "A05"
    return self._query_crossborder(
        country_code_from=country_code_from,
        country_code_to=country_code_to, start=start, end=end,
        doctype="A09", contract_marketagreement_type=contract_marketagreement_type)

This is confirmed if I export the ScheduledMarketExchange xml from ETP for 8/9

<TimeSeries>
    <mRID>2</mRID>
    <businessType>A06</businessType>
    <in_Domain.mRID codingScheme="A01">10Y1001A1001A82H</in_Domain.mRID>
    <out_Domain.mRID codingScheme="A01">10YBE----------2</out_Domain.mRID>
    <contract_MarketAgreement.type>**A05**</contract_MarketAgreement.type>
    <quantity_Measure_Unit.name>MAW</quantity_Measure_Unit.name>
    <curveType>A01</curveType>
        <Period>
            <timeInterval>
                <start>2022-09-07T22:00Z</start>
                <end>2022-09-08T22:00Z</end>
            </timeInterval>
            <resolution>PT15M</resolution>
                <Point>
                    <position>1</position>
                    <quantity>**1030**</quantity>
                </Point>
                <Point>
                    <position>2</position>
                    <quantity>1000</quantity>
                </Point>

(...)

4 A06 10Y1001A1001A82H 10YBE----------2 **A01** MAW A01 2022-09-07T22:00Z 2022-09-08T22:00Z PT15M 1 **1000**

[jimich]

Either there is a bug in entsoe-py where the parameter is not taken (and dayahead = True is not considered) or there is an issue in my function calling ... or there is a bug in the entsoe webservice

For an unknown reason, I cannot debug anymore locally, so I cannot investigate more

[jdtrebbien]

What version of the entsoe-py package are you using? Try updating to the latest version which is 0.5.8. I tested your example and everything is exactly like on the transparency platform.

[jimich]

Indeed ... I've checked directly with the base request and I got different values with A05 and A01 ...

params = { 'documentType': 'A09', 'Contract_MarketAgreement.Type': 'A05', 'in_Domain': '10YBE----------2', 'out_Domain': '10Y1001A1001A82H' } startstr = '20220908' endstr = '20220909' start = pd.Timestamp(startstr, tz='Europe/Brussels') end = pd.Timestamp(endstr, tz='Europe/Brussels') response = clientRaw._base_request(params=params, start=start, end=end) print(response.text)

I'm using 0.5.8 pip install --upgrade --force-reinstall entsoe-py Collecting entsoe-py

I've tried to use also a local version with the last sources in order to debug and track the parameters (which is also 0.5.8), but for that one I got issue with bs4 (strangely, while it works with the installed pip version) ImportError: cannot import name 'XMLParsedAsHTMLWarning' from 'bs4.builder' (/opt/conda/lib/python3.8/site-packages/bs4/builder/init.py)

Downloading entsoe_py-0.5.8-py3-none-any.whl

[jdtrebbien]

So its working now or are you still getting the wrong data?

[jimich]

Still seeing the wrong data with the api, but not when calling directly the base ent so-e web service. Seems the True parameter is lost somewhere in the code.

[jimich]

I will try on my max instead of jypyterLab on my work pc. I have a lot of other strange issues where panda is completely stuck that I have the impression that my python is buggy. If this work in the other env, I will close the ticket

[fboerman]

hi @jimich this indeed sounds like an environment issue especially since @jdtrebbien cannot reproduce your issue. This is thus not an issue with the package and im gonna close this. if you think it is a package issue feel free to reopen.