Supports two kinds of Prepaid functionalities: Where the Wallet lives on the Server, and where the Wallet lives on the meter (e.g. STS and Kamstrup).

When the Wallet (Ledger) lives on the server, it uses the normal pnpscada tariff engine and as a consequence can support very complicated tariffs.

Supports multiple STS Vending systems, whereby we can create STS tokens for various purposes, e.g. loading credit, clear tamper, and manufacturer specific tokens like switch to prepaid mode, switch to post paid mode, switch on, switch off, etc. More custom STS Vending system connectors can be developed.

Supports the optional sending of STS tokens to the STS meters over modems etc where supported, as well as loading credit to the Kamstrup meter register through the same mechanism. More STS meter protocol drivers can be developed.

For both kinds of Prepaid functionalities, we support the receiving of funds via multiple Payment Facilities, including: entry on web page by admin staff, PayFAST, PayU and PayStraight.com where the money gets paid straight into the landlord's account. More Payment Facilities can be developed and are currently in development.

More payment methods are supported by third parties via web services, for instance CitiQ prepaid and Powertime and more. Third parties can develop their own and interface it to pnpscada via web services.

For non-remote reading STS meters, we support the creation of estimated profiles that can be viewed in the normal sense.

For remote reading STS meters, we support a shadow ledger, that 'reads' when transactions happened on the meter itself, e.g. when power was loaded, used, etc. This can be used together with the 'transmission account' ledger through which the money was payed to buy the tokens.

Some companies also have the wallet live on their own system, and then interface with pnpscada to switch meters on and off remotely and/or to send credit to meters, via web services. These ones don't use the Ledger on pnpscada at all, but keeps all the accounts on their own servers.

STS - Standard Transfer Specification

It is basically the whole standard and system where you buy electricity and receive a 20 digit code, which you punch into the meter to top up

www.sts.org.za

SGC - Supply Group Code

Part of the STS IEC specifications. It is basically the unique 6 digit code to identify an STS billing authority or STS meter manufacturer. 

You can get your own one for sub-metering purposes from the Key Management Center (KMC) at Eskom. SDG's code is 

400083

Here are a few others:

  //?01?Actaris/Schlumberger/Itron?     999901

  //  04  Conlog                          999904

  //?07?Landis+Gyr                      999907

  //?14?Elster Kent/Hexing              999910 (hexing)

  //?15?Mitsubishi

  //  16?Strike

  //  17?Iskra

  //  18?Power-Link (grinpal?)

  //  24  Wasion          ??????    999924     (990439 possibly default for Netvendor? Yes, it is Netvendor, and it is NOT a Manufacturer code)

  //  37  Inhe                            999937

  // (41) Utility Systems                 999941  (this is those water guys in Durban)

Basically, the system that generates the STS codes can do so for certain SGCs. 

So you would load your own SGC on your own Vending system (STS generation system), and set it into your own STS meters, and then no-one else can load energy on your meters, just you.

Wallet based - basically, a wallet is where you keep your money, or the 'money loaded on your meter'.

For STS, the money is loaded on the meter itself, so your 'wallet' really lives on the meter. There are other meters that also supports that, e.g. Kamstrup or Echelon.

But many companies now have the Wallet living in the AMR system. 

So the remote server decides whether there is any money left on the electricity meter or not, and switches the meters accordingly, remotely.

So, 'Wallet' is just referring where the 'money' is kept. 

In a way, STS is also wallet based, it is just that the wallet lives on the meter itself.

But usually if people say 'wallet based', they mean that the customer has a balance that lives in the cloud, and when the meter calls in, they subtract from that balance, and when it goes negative, they switch the meter off remotely.

For those kind of 'wallet based' systems, the meter is usually remote meters, being read and switched remotely.

For STS based meters, you can also read them remotely, and send STS codes from remote, so they are not necessarily 'dum STS meters'. They can potentially also be smart.