use of Budget Billing procedure field

[Astrid_Gambill]

Hi All

I'm evaluating a proposed change to the use of the BB Proc field on the Contract Account - FKKVKP-KZABSVER.  We currently bill bi-monthly, and have an enhancement that auto-changes the value from 00 to 03 when customer requests BPP, and a 2nd enhancement that reverts it when the plan is de-activated.

We are now switching to monthly billing and also want to limit the creation of BPP to residential accounts.  The plan is to remove both enhancements and perform a mass update to switch all non-BPP residential accounts from 00 to 03.

Having the value preset will allow users to create BPP without an enhancement or extra manual work, and with the value being 00 for non-residential accounts the plan creation is prevented unless there's some back office intervention.

While the possible values in the field aren't changing, the meaning of those values is, which I believe is technically "overloading", and I'm concerned about downstream impacts.

Can anyone advise as to what those impacts might be, or am I worrying un-necessarily.

Thanks

Astrid

[william_eastman · Accepted solution]

Astrid:

Can you explain what you mean by overloading?  The field is meant to identify if an account is eligible at a basic level for budget processing.  For your scenario, that rightly is a proxy for residential and non-residential.  For some customers, all accounts would have a 3 (or other value for non-US) or all have a 0. As to downstream, this field only controls budget applicability and so would not impact anything else in the standard solution.  The basic idea for this field should not be a dynamic attribute for an account and so eliminating this change process is a good idea.

regards,

bill.

[Astrid_Gambill]

Hi Bill

I have a new role in Data Governance, and my concern is the change in meaning of the values.

My understanding was that the field was a high level indication of the presence of BPP, not eligibility, which is reinforced by the SAP definition in the help file for the field.  my emphasis.  the 3 should indicate that installments will be invoiced, rather than the regular usage amount.

" If you enter 3 (payment plan procedure), the budget billing amount is requested as the new bill amount instead of the bill amount determined by billing and invoicing. The difference between the actual bill amount and the payment plan amount is managed in a special item. This procedure is used for monthly billing "

This SAP definition no longer applies if the value is the same for all residential customers whether they have active BPP or not.

Overloading is a data quality term that refers to extra values being added to fields they weren't originally designed for.  more info here http://www.information-management.com/issues/20051101/1040185-1.html.

Given the values are staying the same this change doesn't qualify as overloading, and maybe the original design for the field, and it's dynamic nature was the bad design, that we now have the opportunity to correct .

We're also verifying that there's no reporting/BI impact as part of the due diligence process.

Regards

Astrid

[william_eastman]

Astrid:

The bb procedure field does not itself indicate that there is a plan for the account, merely whether they are allowed.  Plans are still created/identified at the contract level.  But if the procedure value is 0, then no plan can be created for the contract under any scenario.  I would suggest that the field help is slightly incorrect in that manner.  Identifying accounts with plans is done by looking at the contracts, not the accounts, where the plan type and schedule is maintained.  The permissibility of budget billing for an account should not be dynamic, whereas the existence of a plan on any account would be dynamic depending on the service details and the eligibility rules.  As an example, a utility might only permit customers on budget if they have 6 months of history. The procedure value would be 3 for all accounts but only after 6 months could the plans be created.

regards,

bill.