Difference between revisions of "Customer:OnPac"
From Freeside
(→Add'l field handling) |
|||
Line 65: | Line 65: | ||
* '''Cross reference''' -> what is this for? | * '''Cross reference''' -> what is this for? | ||
+ | |||
+ | = Add'l charge handling = | ||
+ | |||
+ | Determine precisely how each of these fees are charged, spec & write any necessary code | ||
+ | |||
+ | * Energy base | ||
+ | * GR Fee | ||
+ | * Taxes |
Revision as of 08:43, 2 November 2006
Contents
Schema changes
- Add usage_elec table and class (see Schema Changes)
- id serial primary_key
- _date @date_type
- kwatts int
- tdsp @money_type
- svcnum int NULL (svc_external.id contains ESIID)
Usage import
- Import usage charges into usage_elec table (Usage charges)
- Add import subroutine to usage_elec.pm
- Add page to web UI to accept upload
- Needs to accept file first, add job to job queue for import/billing loop
- Landing page that shows job progress via the JS progress popup (like service definition add/edit)
- Add menu entry and ACL for new page Tools->Importing->Import electricity usage from CSV file
- Associate usage charges with specific customer/package (Static mapping)
- Trigger billing for that customer package (Billing)
- Usage charges via new rate plan below
- TDSP as a one-time charge ( cust_main->charge($amount, 'TDSP') )
Usage charges
- KW -> usage_elec.kwatts
- Invoice date -> usage_elec._date
- TDSP - PASS THRU CHARGE -> usage_elec.tdsp
Static mapping
- ESIID -> svc_external.id (associates with package and customer)
- CUSTOMER NAME -> informational only, or sanity check w/ Freeside data
- CUSTOMER ACCOUNT -> cust_main.agent_custid (sanity check with customer via ESIID)
Billing
- Add a rate plan to bill on demand, triggered by the import (FS::part_pkg::usage_elec.pm) (see Price plans)
- Calculate Kw difference from previous usage_elec record for this meter/ESIID & multiply by a rate
- rate stored in as package definition option in part_pkg_option (defined in FS::part_pkg::XXX %info hash)
- Set dates via usage_elec record rather than via frequency
- Add an optional FS::part_pkg::XXX method that indicates internal date increment calculation by the price plan
- Have cust_main::bill method use the package method to control date incrementing, if it exists
- Invoicing
- service from -> cust_bill_pkg.sdate
- service to -> cust_bill_pkg.edate
- Number days -> (edate - date) -> added to cust_bill_pkg_detail
- Rate -> stored in a part_pkg_option -> added to cust_bill_pkg_detail
- Previous read (from previous usage_elec.kwatts) -> Added to cust_bill_pkg_detail
- Current read (from current usage_elec.kwatts) -> Added to cust_bill_pkg_detail
- Usage in Kwh (difference) -> Added to cust_bill_pkg_detail
- multipler - store this as an additional part_pkg_option? use it for rate calculation and pass through to cust_bill_pkg_detail to display on invoice
Add'l field handling in import
Handle these additional fields:
- Handle Due Date
- Add new cust_bill column to store per-invoice due dates
- Have import associate this with the bills it triggers
- Invoice number -> need to store/use somehow instead of autogenerated invoice number?
- Add new cust_bill column if necessary (cust_bill.agent_invoiceid)
- Use this field when displaying instead of the internal invoice # (option to turn on)
- Search this field exclusively when searching for invoice numbers (option to turn on)
- Cross reference -> what is this for?
Add'l charge handling
Determine precisely how each of these fees are charged, spec & write any necessary code
- Energy base
- GR Fee
- Taxes