Billing of a miscellaneous service — NB view
The process describes the communication between NB and LF on the billing of another service that is contained in the price sheets for disconnection costs, late payment charges or reactive energy of the NB and, where applicable, the automated complaint case. An invoice correction always comprises a cancellation invoice and a new invoice.
Process flow from the perspective of the NB
Process steps
Invoice for another service
NB LFCheck identifiers
- 31011 — Invoice for other service · AS4
Flow
Message to LF · AS4
Write endpoint
- Transaction updated — Update process data
POST /updateProcessData
Updates the existing transaction in the backend once the message has been created.
- Transaction updated — Update process data
Response
NB LFFlow
Message from LF · AS4
Response per decision tree
33002→ E_0503 · LF · Check invoice for a miscellaneous service
Write endpoint
- Transaction updated — Update process data
POST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
- Transaction updated — Update process data
Notification that the original invoice for another service was correct
NB LFCheck identifiers
- 29001 — Rejection of REMADV · AS4
Flow
Message to LF · AS4
Response per decision tree
29001→ E_0504 · NB · Check non-payment advice
Write endpoint
- Transaction updated — Update process data
POST /updateProcessData
Updates the existing transaction in the backend once the message has been created.
- Transaction updated — Update process data
Response
NB LFFlow
Message from LF · AS4
Response per decision tree
33002→ E_0505 · LF · Check invoice for a miscellaneous service again
Write endpoint
- Transaction updated — Update process data
POST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
- Transaction updated — Update process data
Cancellation of the original invoice
NB LFCheck identifiers
- 31004 — Cancellation invoice · AS4
Flow
Message to LF · AS4
Write endpoint
- Transaction updated — Update process data
POST /updateProcessData
Updates the existing transaction in the backend once the message has been created.
- Transaction updated — Update process data
Response
NB LFFlow
Message from LF · AS4
Response per decision tree
33002→ E_0506 · LF · Check whether a response to the cancellation is required
Write endpoint
- Transaction updated — Update process data
POST /updateProcessData
Updates the existing transaction in the backend with the data of the incoming message.
- Transaction updated — Update process data
Decision trees of this process
| EBD | Name |
|---|---|
| E_0503 | Check invoice for a miscellaneous service |
| E_0504 | Check non-payment advice |
| E_0505 | Check invoice for a miscellaneous service again |
| E_0506 | Check whether a response to the cancellation is required |
Process information
Wording of the consolidated version, profile ch. 3.4.5.1, pp. 98–99.
Preconditions
- The current fees for other services (price sheets disconnection costs, late payment charges and reactive energy) have been transmitted by NB to LF within the use case „Transmission of price sheet NB to LF“.
- An other service can be represented by one of the article IDs of the price sheets disconnection costs, late payment charges or reactive energy of NB.
Results
The LF will pay the invoice for the other service issued by the NB.
Error case
Error cases
- The invoice contains items that are not included as an article ID in one of the price sheets for disconnection costs, late payment charges or reactive energy of the NB.
- The price of an article ID stated in the invoice does not match the price of the corresponding article ID stated in the relevant price sheet.
Further requirements
- The case of an invoice for another service that has been complained about or turns out to be incorrect (the cancellation of the original invoice is carried out either without a prior complaint by the LF or on the basis of a prior complaint by the LF) forms part of the standard process and, apart from clarifications, must be handled fully automatically. In the event of a complaint, the so-called “all-or-nothing principle” applies, according to which an invoice is either accepted in full as correct or rejected in full. The processes to be handled in the event of a conflict as part of receivables management or the dunning procedure are not shown and are to be resolved bilaterally.
- An invoice within the interruption and restoration of grid connection use references the underlying disconnection order.
- Via the use case „Billing of another service“, late payment charges,
- which have arisen in connection with a grid usage invoice,
- as well as in connection with an invoice for another service, are invoiced. A unique reference to the underlying invoice must be specified.
- If the final customer is itself the grid user (= grid user without an all-inclusive contract), it assumes the role of LF within the meaning of this process description, insofar as these provisions are applicable to it accordingly.
Trigger
- An other service has been ordered via the use case „Interruption of grid connection use (disconnect) on the instruction of LF“ or
- late payment charges have arisen at the NB or
- the LF voluntarily takes over the billing of the reactive energy article ID towards the AN.
First message
The party involved on this page is itself the sender of: „Invoice for a miscellaneous service“ to LF (step 1).
Objective
The NB has been informed that the LF accepts the invoice for the other service.
Other views of the process
The same process through the eyes of the other parties involved: the same steps, each read from their point of view.
- View LF — LF
Notes on this page
The steps are the possible messages of this process, not a sequence — the source lists neither conditions nor alternatives. The small box on the step names the own view on the left: with ← it receives, with → it sends. Collapsed steps run between other market partners.
The source does not yet name the event that triggers these steps.
Applies to: 1
The connector table lists no write call for these steps. Derived from the process flow: the own role was already involved in this process, so the transaction already exists.
For the check identifiers of these steps there is no test case in the test data set; the »Try it out« button of the write interface therefore offers no body.