Background/motivation
currently Currently there are some issues issues, which mainly rose from our decision to avoid the customer level:
- we cannot generate invoices to other than the contract address ⇒ so we need an invoice address, e.g. in extending the contract database table/MVC
- there is no explicite possibility to have more than one contract per customer – and doing so implicit will probably raise problems with Envia API
- the existence of modems (holding the installation address) is not mandatory – Andre mentioned switch-port depending systems and TR-069 configurations
- is it better to avoid address data in this level of our system?
- if e.g. the installation address is placed here then we will need an abstract layer (even if there is no physical expression) only to keep this data
Current mappings
| iDocsis | “legacy” km3 system | EnviaTEL |
|---|---|---|
| contract⇒address | customer⇒address (used as invoice address) | customer⇒address (Envia customerreference also stored in contract table) |
| modem⇒address | contract⇒address (used as installation address) | contract⇒installation_address (Envia contractreference also stored in contract table) |
| n/a | modem⇒address | ?? |
Decisions to make
Shall we keep the current structure or switch to “legacy” system's structure?
...