Address mapping

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

Current mappings

Decisions to make

Shall we keep the current structure or switch to “legacy” system's structure?

• 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

Where to put the installation address? Shall we allow more than one modem/installation address per contract?

• This is not as trivial as it seems – there ere several things to consider:
  • handling of the contracts the customer signs – there should be pieces of paper for differing installation addresses and changes of these addresses
  • people that hack this data into the system have to pay attention to the addresses
    • the installation address will be used to guide ambulances
    • there has to be a doorbell panel with the “name” from installation address
    • to be continued