Share
Report
545Good afternoon,
I have been tasked with implementing Recurring Invoices within our billing system.
At the moment, my companies recurring invoice implementation involves programmatically (via eConnect) creating a Single-Use Invoice Batch and stuffing it with a number of Invoices. One invoice per Customer (the Customer being a Company), and each Customer is billed for a total service charge based on the number of Employees that had for a given billing cycle (Each Employee is a line item having a fixed price). The number of employees per Customer may vary from cycle to cycle to the invoice total may not be the same. At the moment, the cost of the service does not vary. Invoice total = number of employees * cost of service. All invoices are submitted bi-annually by running this external process twice a year (a .NET application leveraging eConnect). The cost of the service is fixed in GP by means of an Item Number definition (the cost of the service is not overriden by the external Invoice generation process).
It has been recommened that I create a Sales Document within SOP and mark this document to Allow Repeating Documents and use this Document ID to create Sales Transaction. I have been experimenting with this and the setup is failrly straight forward. However, I am having a hard time understanding how a Sales Transaction Entry based my experimental Sales Type ID (set Allowing Repeating Documents) would "recur". The Batch ID that was created when I submitted the Sales Transaction Entry did not ask nor mention a recurring Frequency. It seems to be a Single-Use sales batch job.
I feel as though I am missing something as far as the above is concerned. It could be possible that the vary fact an Invoices varying line item detail would/should warrant a completely new invoice and recursion is not appropriate in these situations. I am not a financial type so I cannot answer this question. Rather than writing custom applications to cause automatic creation of various types of invoives having various billing cycles, I would rather have GP manage that.
Later, I will be tasked with implementing a Service Tier pricing structure in which the actual Invoice Line Item pricing changes based on Customer (ie Company) variants. And also the possibilty of applying discounts to the Invoice total based on other variants.
I think it is important to implement Recurring Invoicing properly early on given more and more dynamic pricing changes will be asked for in the future.
A nudge in the right direction would be greatly appreciated.
Many thanks!
Don
*This post is locked for comments
All responses (
Answers (
