Sample Work
Design Document
Contents
1. Business Context.......................................................................................................................... 2
2. Requirement Breakup .................................................................................................................. 2
3. Assumptions ................................................................................................................................ 3
4. Impact Analysis ............................................................................................................................ 3
5. Out of Scope ................................................................................................................................ 3
6. Design Approach .......................................................................................................................... 3
7. Web Services ............................................................................................................................. 11
8. Additional Impacts ..................................................................................................................... 11
9. Supporting Documents .............................................................................................................. 11
10. Non-Functional Requirements ................................................................................................... 11
11. Q & A ......................................................................................................................................... 11
Sr. No JIRA ID Requirement Description
1 # JIRA ID LW should have a process to identify and create services monthly fee as on
the due dates based on the contract schedule for all active subscriptions.
2 # JIRA ID For all active contracts that have crossed the termed schedule should be
rolled on month-on-month basis until terminated and monthly fees to be
billed during this over-term period.
3 # JIRA ID LW should support tax assessment on all fee receivables generated from the
system.
4 # JIRA ID Users should be able to view all service invoice transaction details through
Power BI.
5 # JIRA ID Users should be able to view all the OT transaction details included in Service
PO through Power BI.
For the purpose of this document, the following abbreviations are used:
● LW for LeaseWave
● DB for Database
1. Business Context
1.1. BYO contracts typically have a Term of 1 month. The client would require an option at the Segment
level, which allows them to bill the BYO contract post-maturity. All active contracts that have
crossed the termed schedule should be rolled on month-on-month until terminated and monthly
fees to be billed during this over-term period. These monthly receivables should also be available
for tax assessment in LW.
1.2. Users should be able to view all the OT transaction details included in a Service PO through Power
BI.
2. Requirement Breakup
2.1. LW should have a flag at the Segment level to indicate which Segments (under Services) should be
allowed to be billed post-maturity.
2.2. System should also display the flag in read-only mode at Model Term Definition >> Service Fee
Definition grid level for each Service-Segment association.
2.3. LW should have a job to identify and select the monthly Services (booked as Recurring Sundries),
which need to be billed post-maturity.
2.4. The job should have the ability to edit the recurring sundries (from the backend) and increment the
term by 1, the payment schedule for that month, and the end date by + 1 month for such Services
based on Next Due Date and job Run Date.
2.5. The job should have the ability to edit the Recurring Sundries until a time when the it has been
inactivated or the flag has been turned off at Program >> Service-Segment Details grid level.
2.6. LW should support tax assessment on all the Sundries edited through the job.
2.7. The job should also have the ability to update SundryRecurrings.NextDueDate field with the next due
date as per a defined logic.
2.8. System should stamp Cash File Name at Receivables level so that Power BI can use it to view Service
Invoice transaction details.
2.9. System should stamp ‘Overtrade Service PO File Name’ at the Payables level so that Power BI can use
it to view Service PO transaction details.
3. Assumptions
3.1. The ‘Service Overterm’ job will only check for Recurring Sundries and not one-time Sundries, if any,
created in LW.
3.2. NSF job should be a prerequisite for this job.
3.3. All the invoices will be run in advance (33 days).
4. Impact Analysis
4.1. The following modules will be impacted by this requirement-
(i) Recurring Sundry
(ii) NSF Job/Recurring Sundry Job
5. Out of Scope
5.1. Service Overterm job for one-time sundries.
5.2. Service Overterm job for Inactive or Terminated Recurring Sundries.
5.3. Service Overterm job for Overtrade contracts.
5.4. Reports for Service Overterm job.
6. Design Approach
# JIRA ID
Programs UI >> Service Segment Details >> Segment Details
6.1. A new flag called ‘Allow Service Overterm ’ should be added when a Segment is imported under a
Service.
6.2. The flag should be enabled and checked by default. However, the system should allow the flag to be
editable. The flag indicates whether the Segment is applicable for billing after maturity (Recurring
Sundry’s end date) or not.
6.3. The flag should always be editable, irrespective of whether a contract has been booked using that
Program or not.
Model Term Definition UI >> Service Fee Definition >> Service Fee Definition grid
6.4. The ‘Allow Service Overterm’ flag should also display in the Segment-Service grid, but in ‘read-only’
mode.
# JIRA ID
Service Overterm Job
6.5. A new job should be added in the system, navigable at Business Admin >> Jobs >> Create >> Job Step
>> Task.
6.6. The job is expected to have the following specifications-
(i) Schedule Type- Recurring
(ii) Run on Holiday Option- Run on Holiday or Skip Holiday
(iii) Frequency- Daily
(iv) Frequency Type- (to be run post NSF job)
6.7. On selection of the job, ‘Setup Parameters’ option should appear on the UI.
6.8. On click of setup parameters, a child window should open having the following parameters-
(i) Process Through Date Option-
a) Process Through Date
b) Month End Date of Run Date
c) Previous Month End Date of Run Date
d) X Days from Run Date
(ii) Process Through Date (If Process Through Date option = ‘Process Through Date’)
(iii) Post Date should default to the due date.
6.9. By default, the Process Through Date Option should be ‘Process Through Date’.
6.10. Process Through Date should default to the system date.
6.11. When the job runs, it should have the following logic described below in the given order-
(i) Check if the following conditions are met for a Recurring Sundry (in the given order)-
a) Sundry.Recurrings.IsActive = 1
b) SundryRecurrings.AllowServiceOverterm = 1
c) ServiceFeeTemplates.IsMonthlySubscriptionFee = 1
(ii) Edit the Recurring Sundry for Service Overterm, End Date, and Payment Schedule. To exemplify,
if the Service Overterm is 1, it should be incremented to 2. If the End Date is Mar/31/2019, it
should be incremented by 1 month to Apr/30/2019, and a new line item should be updated in
the Payment Schedule grid as per the ‘Next Due Date’ field.
(iii) Update the field Recurring Sundries >> Services >> Next Due Date with 1 month (frequency) i.e.
next month’s Payment’s Due Day. To elaborate, if Next Due Date is 05/01/2019, then update
the payment schedule with a new payment with Due Date as 05/01/2019 and update the Next
Due Date field to 06/01/2019
6.12. To this end, a new field called ‘Service Overterm’ should be added in the Recurring Sundry >>
Payment Details section.
6.13. Service Overterm should originally be equal to Contract’s Term. However, it should be updated as
per the logic given above, every time the Service Overterm job runs.
6.14. ‘Allow Service Overterm’ flag should also display at the RecurringSundry level. Whatever is the status
of the flag at the Program level, the same should display for the Recurring Sundry and stamp in the
SundryRecurrings table. This means that if at the Program level, the flag status is unchecked, the
same shall not affect the Recurring Sundry. The Recurring Sundry should continue to be picked up by
the Service Overterm job.
6.15. Recurring Sundries created as per the above logic should have the following parameters-
Fields LW-Mapping
Id System handled
1st payment month due date.
Ex- If the start date is 15 Jan 2019 and the frequency is monthly then
FirstDueDate the First Due date will be 15 Feb 2019
2nd payment due date of the Recurring sundry from
NextPaymentDate SundryRecurringPaymentSchedules table
SundryType Hard code to 'ReceivableOnly'
Status Hard code to 'Approved'
EntityType Hard code to 'CT'
InvoiceComment NULL
Memo Default it to NULL
IsAssetBased Default it to '0'
PaymentDateOffset Default it to '0'
IsRentalBased Default it to '0'
BillPastEndDate Default it to '0'
NumberOfPayments NSFInputs.Term
Frequency Default it to 'Monthly'
NumberOfDays Default it to '0'
DueDay Default it to NSFInputs.StartDate date.
TerminationDate Default it to NULL
ProcessThroughDate
InvoiceAmendmentType Default it to ‘Credit’
IsActive Default it to '1'
IsTaxExempt NSFInputs.IsTaxExempt
IsFinancialParametersChanged System handled
IsPayableAdjusted System handled
IsServiced Default it to '1'
IsCollected Default it to '1'
IsPrivateLabel Default it to '0'
IsOwned Default it to '1'
IsRegular Default it to '1'
IsApplyAtAssetLevel Default it to '0'
RegularAmount_Amount Associated Servicefeetemplatedetails.GrossAmount
RegularAmount_Currency Default it to Legal Entity Currency
PayableAmount_Amount Default it to '0'
PayableAmount_Currency Default it to Legal Entity Currency
IsSystemGenerated Default it to '0'
IsExternalTermination Default it to '0'
Type Default it to 'Sundry'
CreatedById System handled
CreatedTime System handled
UpdatedById Default it to NULL
UpdatedTime Default it to NULL
LegalEntityId Default to Program’s Legal Entity
ContractId Contracts.ID of the Loan contract created
CustomerId Default it '1'
ReceivableCodeId ServiceFeeTemplateDetails.ReceivableCodeId
PayableCodeId Default it to NULL
BillToId Default it to default/primary Bill to of the Customer
VendorId Default it to NULL
ReceivableRemitToId Default it to default Remit to of the Legal Entity
PayableRemitToId Default it to NULL
LocationId Default it to NULL
CurrencyId Default it to Legal Entity Currency
LineofBusinessId Default it to Program LeaseCo
InstrumentTypeId Default it to contract Instrument Type
CostCenterId Default it to contract Cost center ID
RowVersion System handled
BranchId Default it to NULL
SKUTermDefinitionServiceFeeTemplateDetails.TelcoProgramServiceSeg
mentID ->
VAS_ID_Name TelcoProgramServiceSegments.ServiceID -> Services.VASName
SKUTermDefinitionServiceFeeTemplateDetails.TelcoProgramServiceSeg
mentID ->
VAS_ID TelcoProgramServiceSegments.ServiceID -> Services.VASID
SKUTermDefinitionServiceFeeTemplateDetails.TelcoProgramServiceSeg
mentID ->
Segment TelcoProgramServiceSegments.SegmentID -> Segments.SegmentCode
SKUTermDefinitionServiceFeeTemplateDetails.ServiceFeeTemplateID ->
Service Fee Template ID ServiceFeeTemplates.ID
SKUTermDefinitionServiceFeeTemplateDetails.ServiceFeeTemplateID ->
Service Fee Name ServiceFeeTemplates.ID -> ServiceFeeTemplatedetails.ServiceFeeName
Next due date System handled
Start Date NSFInputs.StartDate
IMEI # NSFINputs.IMEI_Serial
6.16. Refer to the flow chart below to understand the job logic explained above.
Start
Check all the following
conditions in a Recurring
Sundry-
A.
IsAllowServiceOerterm
=1
B. IsActive = 1
No Skip the Recurring Sundries
C. IsMonthlyServiceFee =
1
D. Job Run Date + 1 =
SundryRecurrings.NextD
ueDate
Yes
Update the following-
A. Payment Schedule
B. Service Overterm
C. End Date
Stop
6.17. The Next Due Date field should initially be stamped through the NSF file at the time of contract
booking when a recurring sundry is created for a Service. In such case, the Next Due Date field should
be + 1 month on Max of [SundryRecurringPaymentSchedules.DueDate]. After which, the Next Due
Date should be updated every time the Service Overterm job runs. The logic for Next Due Date
stamping can be better understood from the example illustrated below-
Example-
Let’s assume there is a 4 Months Recurring Sundry created post-NSF (Service Booking) job with the
following Payment Schedule-
Number Due Date Receivable Amount Active
1 05/01/2019 100.00 USD Yes
2 06/01/2019 100.00 USD Yes
3 07/01/2019 100.00 USD Yes
4 08/15/2019 100.00 USD Yes
5 09/15/2019 100.USD Yes
Hence, the ‘Next Due Date’ field should be stamped as ‘09/15/2019’. Then, when the Service Overterm
job runs and passes all the checks as per the job logic given above, it should update the ‘Next Due Date’
field as ‘10/15/2019’.
Service Overterm Job >> Job logs
6.18. On completion of the job, the following messages should be logged and displayed on the Job
Instance Details page-
(i) Number of Sundries created: {Number}
>> Database
6.19. A new column called ‘AllowServiceOverterm’ should be added to the ProgramServiceSegments table.
The column should not be NULL at any point in time.
6.20. ‘AllowServiceOverterm’ should also be added to the SundryRecurrings table.
6.21. A new column called ‘Term’ should be added to the SundryRecurrings table.
JIRA ID
6.22. Power BI should be able to track Receivable details pertaining to a Service Invoice using the next ‘PF
File Name’ field present in the Receivables table.
JIRA ID
6.23. Power BI should be able to track Payable details pertaining to a Service PO using the ‘Overtrade
Service PO File Name’ field present in the Payables table.
JIRA ID
Invoice Job UI>>
6.24. A new ‘Monthly Invoice’ job should be used for generating invoices.
6.25. The job is expected to have the following specifications-
(i) Schedule Type- Recurring
(ii) Run on Holiday Option
(iii) Frequency- Monthly
(iv) Frequency Type-
6.26. On click of setup parameters, the following existing parameters should be made non-mandatory-
(i) Process Through Date
(ii) Legal Entity
(iii) Lease Program
6.27. Lease Program should be renamed to ‘Program’.
6.28. On click of setup parameters, the following mandatory Parameters should be added to the Invoice
job-
(i) Process Through Date Option (should default to: X Days from Run Date)
(ii) Process Through Date (appears only if Process Through Date option is selected as ‘Process
Through Date’)
(iii) Number of Days from Run Date (appears when Process Through Date option is selected either
as ‘X Days from Run Date’ or as ‘Invoice Sensitive’). It should default to ‘31’.
6.29. The ‘Number of Days from Run Date’ option in Invoice Parameters should default to 31 days, as the
Invoicing will be done in advance of a monthly billing cycle. This will not have any impact on the
contract booking, which will still be done on an arrear basis.
6.30. The job should check if TelcoPrograms.IsTelcoLevelInvoicingRequired = 1. If yes, only then generate
the report, else skip.
6.31. The Invoice Report should be split for each Program Account Id.
6.32. There should be separate invoices for each month. Hence, if we have two Program Account IDs and
receivables for the month of May and June for each Program Account Id, then a total of 4 invoices
should be generated.
6.33. Refer to the Invoice document attached in the ‘Supporting Documents’ section for more details.
6.34. After processing the job, the system should log the following message-
(i) Invoice Update Reports generated at (location)/
Invoice Reports >>
6.35. There should only be one report generated post-completion of the job. The report should have the
following columns-
Column Name Description Mapping Header/Body
Fee SKU ID AX SKU ID or LW Vendor Change as per ReceivablesCode
SKU ID
InvoiceNumber LW Invoice Number Hard Code to
‘INVStatementNumber’
RunDate Invoice Generation Date Get Date
Time Invoice Generation Time Time stamp
TotalNumberOfFees Total Number of Services Count (SundryRecurrings) group by
SundryRecurrings.ContractId
PerUnitFee Amount per Fee Average
(SundryRecurrings.RegularAmount
_Amount)
Fee Total Sum
(SundryRecurrings.RegularAmount
_Amount) group by
ProgramAccountId, group by
BillingMonth
TaxonFee Tax portion of the Fee Sum
(ReceivableInvoiceDetails.OriginalT
axAmount_Amount) group by
ProgramAccountId, group by
BillingMonth
Sum Total of the Fee line Sum (Fee + TaxonFee)
ProgramAccountId AX Customer Account Id Programs.ProgramAccountId
TelcoNumber Telco ID Telco Id
TelcoName Telco Name Party Name
LWJobStepInstanceID Job Id that generated the JobStepInstanceID
xml
ProgramID LW Program ID Programs.Id
BillingMonth This shows the current Billed month calculated as per
billed month of that fee Invoice job Run Date
6.36. The Invoice download file name should be ‘INVStatementNumber_TimeStamp’.
Testing Scenarios
6.37. Test the setup of the ‘Allow Service Overterm’ flag at the Program level.
6.38. Test the setup of the ‘Allow Service Overterm’ flag at the Model Term Definition level.
6.39. Test job parameters of Service OverTerm job.
6.40. Test the job logic as per the given flow.
6.41. Following scenarios could be used to test Monthly Billing (Invoicing)-
NSF File Processing Date: 15 Jan; Contract Booking Date: 15 Jan
Billing Start End Date LW Due Date LW Inv. Date ‘Monthly Invoice’ Billing
Period Date Run Date Month
Month 1 15-Jan 14-Feb 15-Feb 15-Jan 31-Jan Jan
Month 2 15-Feb 14-Mar 15-Mar 13-Feb 28-Feb Feb
Month 3 15-Mar 14-Apr 15-Apr 15-Mar 31-Mar Mar
NSF File Processing Date: 03 Feb; Contract Booking Date: 15 Jan (backdated contract)
Billing Period Start Date End LW Due Date LW Inv. ‘Monthly Invoice’ Billing Month
Date Date Run Date
Month 1 15-Jan 14-Feb 15-Feb 03-Feb 28-Feb Jan
Month 2 15-Feb 14-Mar 15-Mar 13-Feb 28-Feb Feb
Month 3 15-Mar 14-Apr 15-Apr 15-Mar 31-Mar Mar
NSF File Processing Date: 28 Feb; Contract Booking Date: 28 Feb
Billing Period Start Date End Date LW Due Date LW Inv. Date ‘Monthly Invoice’ Billing
Run Date Month
Month 1 28-Feb 27-Mar 28-Mar 28-Feb 28-Feb Feb
Month 2 28-Mar 27-Apr 28-Apr 28-Mar 31-Mar Mar
Month 3 28-Apr 27-May 28-May 28-Apr 30-Apr Apr
NSF File Processing Date: 31 Jan; Contract Booking Date: 31 Jan
Billing Period Start Date End Date LW Due Date LW Inv. Date ‘Monthly Invoice’ Billing
Run Date Month
Month 1 31-Jan 27-Feb 28-Feb 31-Jan 31-Jan Jan
Month 2 28-Feb 30-Mar 31-Mar 28-Feb 28-Feb Feb
Month 3 31-Mar 29-Apr 30-Apr 28-Mar 31-Mar Mar
7. Web Services
Not Applicable.
8. Additional Impacts
Not Applicable.
9. Supporting Documents
Invoice Format.xlsx
10. Non-Functional Requirements
Not Applicable.
11. Q & A
# Question Response
