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.

A couple more minor fixesRelease 1.2 is now available.

@Digger that looks like it would work.  auto_increment_increment = 2 on both machines.  auto_increment_offset = 1 on the first machine and auto_increment_offset = 2 on the second machine.  The first machine would generate 1,3,5,7... the second machine would do 2,4,6,8 etc.

No code change required.  That's a nice easy option :-)

Here's the mySQL reference.

@Digger the reason why auto increment is used is to prevent a race condition.  Suppose two users both action an insert at the same time.  The only mechanism for serializing the request is the mysql server itself which will put the two requests in sequence.  The server then returns the id that it chose to identify the record it just wrote.  If the php code were to do this then there is the remote possibility that a write would be attempted with two identical keys.

The usual way to code around this is to get a key on creation.  This is called a GUID (or a UUID).  These are typically many bits long and created taking into account things like the local (to the FA web server) ethernet card MAC address and time.

IMHO this is not such a trivial change as you might think.

A couple of minor fixesRelease 1.1 is now available.

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.

Assuming that folk use the check_value(...) function in ui_input.inc all would be fine.  Without this mod requires that all checkboxes be explicitly handled via intentional use of the check_value function or similar.  This change makes the humble checkbox handling the same as other input controls which have value.

I'll be keeping this functionality in my fork.

Hi,

Here's a PR for a bug introduced in 99df2fbc2f147b3a1e20a4cdfa70c2720e67e4cb 27 May 2016

Just one extra comma in line 312 of purchasing/manage/suppliers.php

https://github.com/FrontAccountingERP/FA/pull/17

BTW, this was picked up by the E2E tests on Travis when I brought my unstable-cp branch up to date.  Any chance of having these integrated some time?  The Travis tests can be viewed here:

https://travis-ci.org/cambell-prince/frontaccounting/branches

While writing a module I found that the checkbox value is not set for unchecked checkboxes.  I propose a fix to js/utils.js such that unchecked checkboxes come through to php with a value of ''.

A pull request is here:

https://github.com/FrontAccountingERP/FA/pull/15

No, the Github pull request has not been merged.  There seems to be little interest in this and other proposed changes.

This theme is not complete.  I was working on getting the rendering delegated so that bootstrap could be used in each of the frontaccounting core screens. e.g. http://demo.saygoweb.com/frontaccounting/sales/sales_order_entry.php?NewInvoice=0 is responsive and should work well on all devices.  However, the login screen and menu system are not yet responsive.

This demo is not a normal frontaccounting theme, it includes the changes to the core that have been proposed to delegate rendering allowing a bootstrap theme to be properly implemented.

If the code changes go into core I'm sure we'll see a lot of bootstrap (and possibly Material) themes being produced.

I recommend the FrontAccounting SimpleAPI module.  There are some functions that are not yet implemented, but its very easily extended, has unit tests, and the author is very responsive to pull requests.

Thanks Apmuthu.  Currently the domain referenced seems to be unavailable.  The approach taken to implementing the new UI requires significant changes to the frontaccounting core.  I'd like to advocate for an approach in the code that allows delegation of the rendering to the theme as proposed in this thread:

https://frontaccounting.com/punbb/viewtopic.php?pid=24867

With this method there is no need for extensive changes to the core just to implement a theme.

89

(13 replies, posted in Wish List)

@dz, there's several things that are not responsive in the demo http://demo.saygoweb.com/frontaccounting.  The menus are not properly responsive, so that when they collapse (as on a phone), the main menus no longer work.  Also, main page for each menu is also not responsive.  Most of my effort was focussed on getting bootstrap 3 to work inside each view that you get from the menu system.  If you are viewing one of these pages, it should be properly responsive.  If viewing the menu it will not be responsive.

This is really only a proof of concept.  If the developers of front-accounting were to adopt this type of technique then I'm sure we'd see more bootstrap themes become much easier to produce without hacking the core.

Cambell

This thread relates to the FA Planet fork which appears to be no longer working.  i suggest that this thread should no longer be sticky.

I've updated the theme to FrontAccounting v2.3.24.  All-in-one downloads are available on github.

92

(13 replies, posted in Wish List)

Thanks for that apmuthu.  Having many css files is contrary to current good practice which seeks to minimize the static assets loaded by a page.  Bootstrap itself is built using less, so given that this is a Bootstrap 3 theme it seems natural to use less to produce a single default.css which is what I'm doing here.

I'm not quite sure to what you are referring as being 'tweaked'?  The changes to core were necessary to delegate the render to the theme.  These are not tweaks, but a significant change to allow delegated rendering.  This change has been proposed as a pull request here.  The current core code include html markup that cannot be fit to Bootstrap, the markup needs to change.  I think it is appropriate that rendering be done by classes in the theme at this stage of FA development, rather than propose extensive modifications to the core.

If you've got a specific issue that you would like to see addressed that you would like added to the PR do let me know and I'll look into it.

93

(13 replies, posted in Wish List)

@apmuthu.  The php files are not split / joined.  The only split / joined files are the css files in which less is compiled into css.  I find that the advantages of less are worth the effort.  Further, the compilation process provides a map file which modern browsers support showing the reference to the source less quite clearly.

Having said that if there is a concrete example you have of something being cumbersome I'm happy for the feedback.

This feature currently requires modifications to the Front Accounting core which need to be installed before this theme would work.  So, its not as simple as simply installing the theme and having it work.  That's why I've made the 'all in one' package available, to make it easier for folk to evaluate.

94

(13 replies, posted in Wish List)

@maulana I get an email from the forum to topics I've already posted on, so I do see them.  Also I'm on developers@lists.frontaccounting.eu that's a good way to get hold of me.

95

(13 replies, posted in Wish List)

@maulana It looks like you've tried to install it from the 'source' not the tar or zip package.  As you're on windows I've added a zip package for you.  You can download the all in one zip package from the release page.  Choose the green button (all in one package), not the grey one (source code).

Have another read of the instructions, it looks like you're trying to install it as a developer rather than the packages that a user would prefer.

The longer answer, is that the source code for the themes does not have the css styles 'built'.  The source for bootstrap styles comes as less files which are then 'built' into the final css used in the theme.  I've provided gulp build tasks for building the bootstrap less into the final 'default.css' file.  The theme also uses twig templates which are installed via composer.

With modern web development tools end users cannot simply install the source and expect it to work.  There are dependencies to install (via composer), and processes to run (via gulp) to generate the final set of files that would be used.

96

(13 replies, posted in Wish List)

I've added a tar package and updated instructions.

I've fixed the Inventory Item Status combo box.  You can see that in the demo.

The menu text for each category can easily be enlarged.  However, I'm leaving it at a consistent size to keep with the goal of a minimal change bootstrap theme.  Other themes can make more artistic changes based on this minimal theme.

98

(7 replies, posted in Modules Add-on's)

I've made modifications and a theme available for a Bootstrap 3 responsive theme.  See the announcement here.

99

(7 replies, posted in Wish List)

This work is now as complete as I'm going to make it for the moment at least.  See the announcement here.

Hi,

I've made some modifications to the core to support delegating the view render to themes.  This makes it possible to produce a Bootstrap 3 responsive theme.

The pull request for the modifications are on github.

The sample Bootstrap 3 is available this github repo.

You are welcome to view the demo site.

This is as complete as I'm planning on making it at this stage.  I'm moving on using AngularJS in a Front Accounting module.