Proposal SAs And Interval Consumption

Note:

Assumption. This section assumes you are very comfortable with the concepts described under Interval Billing.

Service agreements with interval data have rates that price the interval consumption using time-of-use prices and / or direct prices. Proposal SAs for interval service agreements require billing scenarios to define the time period of each simulated bill segment on the quote detail. However, these billing scenarios typically won't have template consumption (unless regular meters are used in addition to interval meters on the service agreement). Rather, interval billing proposal SAs require interval profiles and datasets, time-of-use maps, and contract options because their rates use this information to calculate the simulated bill segments.

The following points provide an overview of how interval information can be populated on proposal SAs:

  • As described under Orders Are Used To Create Proposal SAs, a proposal SA is populated using the start option defined on the package specified when an order is completed (note, a package can cause multiple proposal SAs to be created where each proposal SA references a different start option).
  • Start options can reference all types of interval information (interval profiles, time-of-use maps and contract options). If you're familiar with interval billing concepts, you know that the system treats "common" interval information differently from "SA-owned" information when a start option is used to create a service agreement:
  • "Common" interval information referenced on a start option is simply copied to the newly created service agreement. This is exactly what you want. For example, when you create a proposal SA using a start option that references a "deemed profile" or a "standard time of use (TOU) map", you don't want a new deemed profile or TOU map created. Rather, you want the start option's deemed profile and time-of-use map to be referenced on the proposal SA.
  • "SA Owned" interval information on a start option doesn't work this way. Rather, the system creates new interval information and references these on the newly created service agreement. For example, if a start option indicates the service agreement should have an SA-owned interval profile for actual consumption and another for derived consumption (e.g., excess demand), the system creates two interval profiles and links them to the new service agreement. For real SAs, this logic is perfect. For proposal SAs, this logic is perfect for interval profiles that are derived during billing. However, for interval profiles that contain actual consumption, this isn't what you want. This is because, for actual consumption on proposal SAs, you just need to reference an existing profile whose consumption can be used as the template consumption. The next point provides a few options.
Note:

Although the above describes issues related to SA owned interval profiles, similar issues may apply for SA owned TOU maps or to contract options that are specific to a specific service agreement. To successfully generate a quote for a customer, you may need to create template data for these entities as well.

  • You can choose from the following methods to populate a proposal SA with "actual consumption":
    • You could design a workflow process that asks the customer to send their template consumption to you. This could be done by creating a Proposal SA Creation plug-in on the proposal SA's SA type (note, as of the current release, this algorithm does not exist in the base package, but it would be very simple to write). When the customer sends this information to you (via a notification), the datasets on the interval profile that contain the proposal SA's simulated actual consumption can be setup. Refer to Workflow and Notifications for more information.
    • You could ask the user (during the order taking process) to define the type of consumption profile (e.g., are they a doctor's office, bakery, laundry, etc). If you're familiar with campaigns and orders, you'll know that you can do this by setting up a question on the campaign. For example, you could design the campaign to pose a question like, "Please choose the consumption profile to be used when the quote is generated". Then, based on the user's answer, you could set up the proposal SA using profiles consistent with the selected type. The following would be required to setup this type of question:
  • Create a "substitute" start option for each consumption profile. Each start option will contain the normal common and derived interval profiles that are used for a real interval SA. The interval profile on the start option that's used for actual consumption would also use a common profile. This common profile would contain the "template" actual consumption that will be used in place of the customer's actual consumption. This template consumption can be used on any interval profile created using this start option.
  • Setup a campaign that asks a user to identify the consumption profile to be used to generate the quote as described above.
  • Setup a package under the campaign for each consumption profile. Each package will have eligibility rules to indicate that it is only selectable if the respective consumption profile is chosen on the order.
  • Each package will also reference the "substitute" start option that corresponds with its consumption profile.
  • At this point, you have everything setup to create a proposal SA with a consumption profile that can be used to generate simulated bill segments (remember, the proposal SA's SA type needs a Proposal SA Creation algorithm that creates billing scenarios). If the customer accepts this proposal SA, you need to setup a real SA with the correct profiles (you don't want the consumption profile on the real SA, nor do you want any derived profiles that were created when the simulated bill segments were generated). The remaining points describe how to do this.
  • You want these proposal SAs to contain a characteristic that defines the true start option that should be used to create the real SA. To do this, simply define a default char type / value on the "substitute" start option that contains the real start option (this default information is copied onto the proposal SA when it's created). Note. The SA type of the "real" start option should be the same as the proposal SA type.
  • As described under Accepting / Declining Quote Details, you must plug-in a Proposal SA Accepted algorithm that has a parameter of the char type on the proposal SA that contains the start option to use when the real SA is created. It then does the work for you. Refer to the PSAA-PS algorithm type for more information about this algorithm.
    • Other solutions are only limited by your imagination.