View Source

Here you can see how the address mapping is done in NMS Prime and what decisions have been made.

Background/motivation

Currently there are some 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

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

??

current structure has its weak points (see above)
- I think
switching would be imply a great effort (especially for modules billing and provvoipenvia)
- if we decide to switch we should do this soon
  - not trivial to convert existing databases (maybe there is some manual work (or supervision) necessary
  - the later the switch, the bigger the implementation costs