Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Exposes a single read-only endpoint that returns a customer's invoices within a date range.

The domain is SonWin billing: invoice header rows live inSonlincin Sonlinc.AKOND, enriched with supply type (AUDEBFORS), PBSI payment rows (also in AKOND), and a "has a rendered PDF" existence check (AKONDDOC -> BDOC).

The resultis result is mapped into the Bright-facing BrightInvoice model.

...

The controller requires authentication ([Authorize] at class level).

It declares 200/400/401/404 response types, but in practice only 200 :

 200 (success), 401

 401 (missing/invalid auth, enforced by the framework) and 500

 500 (any thrown exception) are actually produced — see the SCOPE LIMITATIONS and the status-code notes below.

...

Visibility/filtering is configuration-driven. Each filter toggle is resolved as "local appsettings config wins, otherwise defer to the company's BCHEC flag"

(Sonlinc.BCHED, cached in memory). The SQL is assembled from pure-SQL fragments so only the active clauses appear in the executed statement.

...

  - ALL errors surface as HTTP 500. The catch blocks for ArgumentException (400)    and  and KeyNotFoundException (404) are commented out in the controller; only the

    generic `catch (Exception) -> HandleError` remains, which returns 500 with    the with the raw exception message.

    The declared 400/404 ProducesResponseType codes     are therefore never produced by controller logic.

  - The 404 "customer not found" path in the service (repository.CustomerExistsAsync)     is commented out (dead). Customer

     Customer existence is instead validated via     commonValidator.ValidateCustomer (account-search validator) which THROWS on     failure -> surfaces as 500, not 404.

...

    El -> consumption_trade,

    Vand -> water, 

    Varme -> heating (or cooling when     AFREGNTYPE='KØL'),

    Antenne -> tv,

    Bredbånd -> broadband,

    Reno -> waste,

    Gas -> gas_trade.

    Grid/production variants (consumption_grid, production_grid,     production_trade, gas_grid) are TODOs and return null.

    All other supply types     and a null supply type also return null.

  - `InvoiceStatus` never returns several enum values:

      collection, reminder,    deferred deferred_with_interest, deferred_without_interest, investigation, paid_out.

    The KORTSTATUS values that would drive these are not yet identified (TODOs in    MapInvoiceStatusin MapInvoiceStatus).

  - `InvoiceType` only ever returns "pdf" or "missing"; "html" is never produced.

  - The `ocr` Info key is defined in the enum but NEVER emitted (source field in     SonWin not yet identified).

  - The "description" Info entry and the "Tekst" Info entry carry the SAME value     (r.Tekst) — duplicated under two different labels.

...

     Validates the customer and the input range, resolves the company's invoice      visibility filters, runs the list query, and maps each row to a BrightInvoice.

...

       - dateFrom out of SQL range -> "Missing or invalid parameter 'DateFrom'.

                  Provide a date                                        between date between 1753-01-01 and 9999-12-31 (e.g. 2000-01-01)."

       - dateTo out of SQL range   -> "Missing or invalid parameter 'DateTo'.

                  Provide a date                                         between 1753-01-01 and 9999-12-31 (e.g. 2030-12-31)."

       - dateFrom > dateTo         -> "Parameter outside of allowed range:

                  'DateFrom' must be                                        earlier be earlier than or equal to 'DateTo'."

       - limit < 1                 -> "Parameter outside of allowed range:

                 'Limit' must be 1 or greater."

       (A missing/unparseable date query param binds to DateTime.MinValue, which is below SQL         Server's datetime min; the range check catches this up front to avoid a cryptic SQL error.)

...

     The two domain catches in the controller are commented out      ("we make use of the internalerror500 for all errors inside the api"), so a

     so a      bad date or an unknown customer returns 500 (not 400/404). The validation     messages validation messages above are wrapped by ValidationHelper into:

             "The operation [{invokingMethodName}] could not be completed due to the          following validation errors: \n <message(s)>"     and  and that wrapped text becomes the 500 body.

...