• From: New Zealand, Wellington
  • Registered: 06/19/2014
  • Posts: 128

Topic: Recurring Sales / Invoice Module Released

Hi,

I've just released a new module for FrontAccounting that does recurring sales / invoices.  The key differences between this module, and the core implementation of recurring invoices are:

- Recurring orders are entered on the Sales Order Entry screen.
- The recurring specification is more flexible. Start dates; end dates; recurring on date
- Invoices (and deliveries) are attributed against the original Sales Order.

My use case is for recurring billing of a web hosting company.  The customer orders a inherently recurring subscription product which is invoiced periodically.

Note: This module is for FrontAccounting version 2.4.x only.  It is not likely to work on 2.3.x (I haven't even tested it).

The releases are available here.

More information, and the source code, is available on Github.

As a side note to other module developers, this module includes automated unit testing run on Travis.  If you would like to do something similar for your modules you can have a look at the .travis.yml and gulpfile.js files on Github.

Cambell https://github.com/cambell-prince

cambell's Website

  • From: Singapore, India, Chennai
  • Registered: 05/02/2009
  • Posts: 6,089

Re: Recurring Sales / Invoice Module Released

@cambell: Great work.
@joe: can it be natively incorporated into FA 2.4? If so, can the extra fields in an existing table substitute the need for a new table?

The module and menu items are hard coded. Since the normal table prefix is used, the FA backup will restore the new table used here.

apmuthu's Website

  • From: New Zealand, Wellington
  • Registered: 06/19/2014
  • Posts: 128

Re: Recurring Sales / Invoice Module Released

A couple of minor fixes.  Release 1.1 is now available.

Cambell https://github.com/cambell-prince

cambell's Website

  • From: New Zealand, Wellington
  • Registered: 06/19/2014
  • Posts: 128

Re: Recurring Sales / Invoice Module Released

A couple more minor fixes.  Release 1.2 is now available.

Cambell https://github.com/cambell-prince

cambell's Website

5 Reply by apmuthu (edited by apmuthu 08/26/2016 05:34:25 pm)

  • From: Singapore, India, Chennai
  • Registered: 05/02/2009
  • Posts: 6,089

Re: Recurring Sales / Invoice Module Released

What will be the values of "every, repeats, occur" if we wish it to recur
1. every 3 months on the 7th starting Feb?
2. every 2 years on May 5th starting 2015?
3. every fortnight on Wednesday?
4. every month on the 12th and 27th (possibly using 2 entries)

The mm-dd or dd-mm format for "occur" should be mentioned somewhere.

Eliminating the charset and collation in the sql definition will help take the defaults of the db used.

Providing it for FA 2.3 will have many testers.

apmuthu's Website

  • From: New Zealand, Wellington
  • Registered: 06/19/2014
  • Posts: 128

Re: Recurring Sales / Invoice Module Released

apmuthu wrote:

What will be the values of "every, repeats, occur" if we wish it to recur
1. every 3 months on the 7th starting Feb?
2. every 2 years on May 5th starting 2015?
3. every fortnight on Wednesday?
4. every month on the 12th and 27th (possibly using 2 entries)

1. every 3 months on the 7th starting Feb?

repeats: monthly
every: 3
occurs: 7

2. every 2 years on May 5th starting 2015?

repeats: yearly
every: 2
occurs: 05-05 (that must be mm-dd at the moment)

3. every fortnight on Wednesday?

Not supported, sorry.  If I did weekly then it would be repeats: weekly, every: 2, and there would probably be a drop down to pick the day of the week.

4. every month on the 12th and 27th (possibly using 2 entries)

You would need two Sales Orders to achieve this.

Sale Order #1
repeats: month
every: 1
occurs: 12

Sale Order #2
repeats: month
every: 1
occurs: 27

apmuthu wrote:

The mm-dd or dd-mm format for "occur" should be mentioned somewhere.

Eliminating the charset and collation in the sql definition will help take the defaults of the db used.

Providing it for FA 2.3 will have many testers.

I'll add the mm-dd requirement into the tooltip and documentation on the github wiki.  I'll change the sql also.  Thanks for the feedback.

Sorry I'm not going to make it available for 2.3 myself.  I've upgraded to 2.4.RC1.  If there was demand from someone who really wanted this module for 2.3 in production after they'd experimented in 2.4 I would be happy to see what needed to be done.

Cambell https://github.com/cambell-prince

cambell's Website

7 Reply by apmuthu (edited by apmuthu 08/29/2016 04:31:22 pm)

  • From: Singapore, India, Chennai
  • Registered: 05/02/2009
  • Posts: 6,089

Re: Recurring Sales / Invoice Module Released

To port it to FA 2.3, what gotchas need to be looked out for? Any FA v2.4 specific dependencies are in place?

Can the "vendor" folder in the release be removed and all references to include_once(__DIR__ . '/vendor/autoload.php'); be expanded out or moved to an include-able file since practically everyone uses PHP >= 5. Alternatively include the vendor folder in the git tree.

Also please include the file views/view_sales_order.php in the github code tree as it is still referred to in generate_recurring_invoices.php and is available in the release.

References: DataMapper ORM,  DesignPatterns and Namespaces.

apmuthu's Website

8 Reply by apmuthu (edited by apmuthu 08/30/2016 07:15:34 am)

  • From: Singapore, India, Chennai
  • Registered: 05/02/2009
  • Posts: 6,089

Re: Recurring Sales / Invoice Module Released

This module installs correctly in FA 2.3.25+ but the 3 menu links in it lead to blank pages.

Post's attachments

SayGo_Sales_Screenshots.zip 33.8 kb, 4 downloads since 2016-08-30 

You don't have the permssions to download the attachments of this post.

apmuthu's Website

9 Reply by apmuthu (edited by apmuthu 08/30/2016 11:37:11 am)

  • From: Singapore, India, Chennai
  • Registered: 05/02/2009
  • Posts: 6,089

Re: Recurring Sales / Invoice Module Released

Sample diffs to sgw_sales/sales_order_entry.php to isolate real changes from sales/sales_order_entry.php in FA v2.4.RC1+ to make porting to FA v2.3.25+ easy.

Post's attachments

sales_order_entry.patch 2.4 kb, 3 downloads since 2016-08-30 

You don't have the permssions to download the attachments of this post.

apmuthu's Website

10 Reply by cambell (edited by cambell 08/31/2016 01:05:12 am)

  • From: New Zealand, Wellington
  • Registered: 06/19/2014
  • Posts: 128

Re: Recurring Sales / Invoice Module Released

apmuthu wrote:

To port it to FA 2.3, what gotchas need to be looked out for? Any FA v2.4 specific dependencies are in place?

The main view is taken from a copy of the sales order module in core.  So that file has been updated to v2.4, and I've modified it further from there.  So, to make it work for v2.3 it is necessary to backport the changes to the v2.3 version of the sales order entry file.

I can't imagine the v2.4 sales order entry working with v2.3 out of the box.  As you point out in your second post, it didn't work for you.

apmuthu wrote:

Can the "vendor" folder in the release be removed and all references to include_once(__DIR__ . '/vendor/autoload.php'); be expanded out or moved to an include-able file since practically everyone uses PHP >= 5. Alternatively include the vendor folder in the git tree.

This is a PSR-4 autoloader (as specified by the PHP Framework Interop Group), via composer.

This is the current best practice method for producing an autoloader, which then does not need any require statements at all (other than of course including the autoloader).

Developers can recreate the vendor folder entirely by doing 'composer install'.  All other users should use the tarball releases supplied, which include all the required files.

apmuthu wrote:

Also please include the file views/view_sales_order.php in the github code tree as it is still referred to in generate_recurring_invoices.php and is available in the release.

Done. Thanks for that.

apmuthu wrote:

References: DataMapper ORM,  DesignPatterns and Namespaces.

The PHP Design Patterns site is good.  I don't recommend the first link on DataMapper ORM.  IMHO that author has conflated the concepts of Object Model and Data Mapper.  A Data Mapper should be able to persist any model.  An object model should not care how it is persisted.  My DataMapper class would be better named FrontAccountingMySQLDataMapper to be more descriptive.

Cambell https://github.com/cambell-prince

cambell's Website

  • From: New Zealand, Wellington
  • Registered: 06/19/2014
  • Posts: 128

Re: Recurring Sales / Invoice Module Released

For those interested, here's a link to the patch between sales/sales_order_entry.php and modules/sgw_sales/sales_order_entry.php

Cambell https://github.com/cambell-prince

cambell's Website

  • From: Singapore, India, Chennai
  • Registered: 05/02/2009
  • Posts: 6,089

Re: Recurring Sales / Invoice Module Released

@cambell: Refer lines 41,42 of your patch. Any reason for replacing the original $_GET['ModifyOrderNumber'] with $_POST['trans_no']? Also does the order of the root path statement affect the file? The patch to your modded file in my previous post will provide for minimal diffs from the core file.

apmuthu's Website

13 Reply by cambell (edited by cambell 08/31/2016 01:56:06 pm)

  • From: New Zealand, Wellington
  • Registered: 06/19/2014
  • Posts: 128

Re: Recurring Sales / Invoice Module Released

@apmuthu. At that line it would be fine, but the use of POST becomes more consistent now that we've had to assign the $_POST['trans_no'] 2 lines above.  This is because we've introduced an ajax refresh into the page which needs the trans_no to be present in a hidden control which is added on line 155 of the patch (line 822 of the real file).  Your patch is not comparing the correct files I think.  It might pay to note that the first commit in the github repo didn't start with the original sales_order_entry.php, it had already been modified prior to the first commit.  Note also that the patch shown is only for that single file.  All the other files are required also.  Particularly the includes/ui/... which have also been modified.

The order of $path_to_root doesn't matter.  But, this is a recurring sales module, not a proposed change to the core sales module.

If you're looking to backport it to 2.3, there's a bit more work to do that than applying a patch.  As I've indicated above, I've got no interest in doing that myself (sorry).

Cambell https://github.com/cambell-prince

cambell's Website

14 Reply by apmuthu (edited by apmuthu 09/01/2016 05:42:36 am)

  • From: Singapore, India, Chennai
  • Registered: 05/02/2009
  • Posts: 6,089

Re: Recurring Sales / Invoice Module Released

@cambell: I just wanted to minimise the differences between the core file and the modified one (sans white space diffs as well) so as to focus on the main code changes. Porting it to FA 2.3 requires removal of FA_Assets based code and replacing functions and variables with their older counterparts.

How is FA 2.4 in terms of stability - is it ready for production use yet?
Was the move to InnoDB for all tables justified?

Post's attachments

UnDROP tool for InnoDB.pdf 397.6 kb, 5 downloads since 2016-09-01 

You don't have the permssions to download the attachments of this post.

apmuthu's Website