In FA 2.4 table stock_moves was designed as log of changes in inventory, but due to some inconsistencies in table's fields usage in the code, when some costing problem appears it is not easy to track where the problem arose. Therefore we plan to change stock_moves structure in next major release, to make it better also for inventory cost tracking purposes.

Following changes are planned:
1. 'reference' field removed
Rationale: this field is both not used and double redundant to refs table and reference fields in respective transaction tables.
2. `standard_cost` changed to `avg_cost` - store for item average cost (stock_master.material_cost)  before transaction
Rationale: while this field is not strictly necessary, it make tracking average cost changes easier. BTW the standard_cost name is just historical artefact not  related to what is stored here now;
3. `price` superseded by `unit_cost` - store for unit_cost in transaction
Rationale: currently price field is used for cost calculations, while this is the cost which is needed finally. Price is stored in transaction lines records, and always can be retrieved if needed.

Finally planned stock_moves table structure in FA 2.5:

CREATE TABLE `0_stock_moves` (
  `trans_id` int(11) NOT NULL AUTO_INCREMENT,
  `type` smallint(6) NOT NULL DEFAULT '0',
  `trans_no` int(11) NOT NULL DEFAULT '0',
  `stock_id` char(20) NOT NULL DEFAULT '',
  `loc_code` char(5) NOT NULL DEFAULT '',
  `tran_date` date NOT NULL DEFAULT '0000-00-00',
  `qty` double NOT NULL DEFAULT '1',
  `unit_cost` double NOT NULL DEFAULT '0',
  `avg_cost` double NOT NULL DEFAULT '0', 
  
  PRIMARY KEY (`trans_id`),
  KEY `type` (`type`,`trans_no`),
  KEY `Move` (`stock_id`,`loc_code`,`tran_date`)
) ENGINE=InnoDB;

All comments are welcome.
J.

@boxygen,
Yes, this is how I plan to implement cost update logging.

Regarding database update for inventory adjustment, we will have to add this in upgrade procedure to release 2.5. We do not have updating procedure for minor releases, so implementing this in 2.4.* would require run the query outside user's awareness. Skilled user suffered with this problem can run the query manually anyway.

J.

There are at lest two fixes still needed:
. changing item cost in Cost Update has no track in stock_moves;
. the price is in transaction currency, but there is lack  of currency exchange rate recorded in stock_stock_moves, so logging in stock_moves is unreliable (you can at any time change currency exchange rate in exchange_rates table);

We will refine the logging feature of stock_moves in the next days, however the changes will go probably to unstable branch. for next 2.5 release.

J.

Yes, you are right, the transaction update was improperly added some times ago. I have rolled it back. Also the other your fix has been added to the repo. Thank you for poitning this problems.
J.

Yes, indeed, there is possibility to insert watermark, or even whole externally designed blueprint in documents generated in FA.
The blueprint have to be designed as PDF-1.4 file (other pdf formats may also be supported), and you will have to put it  in the /reporting/forms folder.

Out of the box two blueprints are supported for two basic document layouts:
Header2.pdf - for reports 107-113, 209,210 and 409
Header.pdf - for all other documents

If you want to test this feature, just put attached file in the forms folder and generate Sales Invoice. In real design some small changes in repxxx.php files can be necessary.

Of course this feature does not address directly the problem of ad-hoc per document  watermarks, but is ready to use if e.g.  you plan to hire artist to design your  invoices wink.

Janusz

seahawk wrote:

Number 3 is also important, since the Bank Account is technically a supplier of service to you, and you pay VAT on Bank transaction Costs, Aditional serves, and Bank Account fees and any other fees that the bank would charge. These services carry service Input Tax that needs to be part of the claim back against your invoice, Supplier and Customer Credit Notes VAT payble.

Currently only sales/purchase invoices and credit notes are supported as taxable transaction in FA, other operations like bank transaction or GRN/sales delivery are not directly taxable, so they are not included in tax report. This has not changed since 2.3 version. For every other business operation which is subject to VAT we can use low level Journal Entry. This is also the case for taxable bank operations.

Regarding till slips, there is no direct support in FA for this type of sales, but there are two workflows which could be used here. First, you can use generic 'retail customer', and register all such transactions as Customer Delivery documents for this generic customer. Then once a day you can make Batch Invoice against those deliveries, which would appear in Tax Report as expected. This workflow is suitable if you want to track all your sales correctly on the stock level. Second method is just entering your daily sales summary report using Journal Entry page, with 'Include in tax register' option enabled.

Must I now setup the Bank as a supplier, Issue Supplier Invoices for each line item that is Vatable on the bank statement, and then make a supplier payment. This is tons of extra work that is not neeeded.

I understand the problem, but bank transactions are not considered taxable at the moment.  I guess basic bank fees are tax exempt in many countries, or at least this is the case here in EU. Anyway, if this is real problem suffering FA users, we should consider some mechanism to handle this. I'm open for any prepositions how to implement it in FA.

When you write Customer payments off as bad debt, you cannot use the Customer Credit Note so that you can claim back the VAT. I created a Bad Debt recon Account as a "Bank Account" so that the process against a Customer with bad debt is easier, but under 2.4 that did not pull through to the Tax report.

I agree Credit Note is not right for this process. Currently bad debt  should be moved to separate account using taxable Journal Entry, then it will appear in tax report too.

For now short term solution is to allow Bank Transactions be included in tax report, but due to reasons explained in previous post, we can implement this as an option selected either in config.php or company preferences (and not as general fix).

J.

Hi,

Frankly I see no reason to put the option in printing parameters: this report is either used as designed (only for taxable transactions) or for current tax balance review, so for most users the option will be selected once during app configuration. As current tax duties can always be found in chart of accounts balances, I would prefer simply adding the option in config.php (here is the place for all usage specific and less usaed options), but I would accept also placing it in company preferences. Maybe we should ask Joe opinion?
Janusz

Hello guys,

Adding config.php option for including Bank transactions is good idea (please, set it off by default). Probably due to time constraints suffering me recently I was not fortunate enough to reproduce the other problems, but I believe you they really exists. Please allow me only make final review on the code you are working on, then I will push proposed changes to the code repo. Thank you all for the time spent on this bugfix.

Janusz

@Braath  Waate

Thank you for explanation. Most of your assumptions are right, but I think there is some  misunderstanding about purpose of tax report. Under VAT regulations as introduced in many countries (and I think this apply also to other taxing schemes), every tax payer has to maintain tax registers, for all transactions subject to tax. Both bank payments and bank deposits (due to tax refunds) from/to tax authorities are not taxable transactions, so should not appear in tax report. At any time, current balance on tax account shows current company tax duties.

Basically most amounts in tax report will mirror sales and purchase invoice transactions, but sometimes there are other more specific GL transactions which should be included in either input or output tax registers. For example sometimes company can lawfully withdraw some part of tax related to overdue payments from customers. This can be recorded as journal entry moving tax between input/output and some clearing GL account, and this should be visible in tax report.

So in other words, tax report is official document, which calculates company's tax duties for selected period. Sums from the report are then declared to tax authorities, and company pays  (or receive) tax with Bank Payment/Bank Deposit which is outside scope of tax report.

Summarizing, third of your assumption is not valid. But if there is any scenario when assumptions  1,2, or 4 seems still not work, we have  aug which should be fixed.

J.

@Braath Waate

I'm not sure I understand the problem right, but the change in gl_db_trans.inc effectively excludes from tax summary all journal entries which user explicitly included into input tax register, which is not acceptable. Instead the change proposed includes bank payments and deposits, transactions which are not taxable per se, at least in EU tax system.

I understand that tax rules may differ in other jurisdictions, so I would like to include a fix solving problems you have encountered. But to avoid any misunderstanding, it is much better to maintain more complex issues like this via our Mantis bugtracker. Mantis really helps in bugfixing process, encouraging clear problem description. Please put the issue on bugtracker together with some short step by step description how to reproduce the issue. You can also attach proposed code change for completness (I'm not sure all the changes are in gl_db_trans.inc).

Janusz

This issue has been fixed in repo.

Thanks for pointing out this problem.
J.

Ok, I have fixed the issue introducing direct string to numeric  data conversion in sql query. This should fix also any problems which could arise in other places where the add_trans_tax_details is called.

Janusz

Yes, this seems to be side effect of just introduced strict mode. But the proposed patch can have side effect too. In some countries there is existing tax rate 0% which is not the same as null tax (i.e. tax not applicable).
Where you encountered the problem, and which was the SQL query triggering the error?
Janusz

64

(14 replies, posted in Report Bugs here)

I have added fix solving this problem to frontaccounting code base.
The number templates for short and long form of fiscal year number is {FF} and {FFFF} respectively, which seems to be more intuitive. Thank you for the idea. This will be available with next minor release.
Janusz

65

(82 replies, posted in FA Modifications)

Current javascript support in FA is sufficient for most needs, so I have not considered adding big js libraries like jquery to the main code. But if you want to have some functions which would be hard to implement in plain javascript, I'm not entirely against including jquery, providing the new code would be handy to use in other parts of FA interface.

When considering inclusion of javascript libraries one thing have to be guaranteed for sure: all the library code have to be included in FA distribution i.e. no external references to e.g. google apis, or other online js repos is allowed. This is because FA in many cases is installed on LANs with no access to internet for many reasons including security.

Janusz

This is legacy of architectural flaw in FA predecessor db scheme. Original author have used trans_no/id for two purposes:
. as internal transaction id, which is unique for every completed document revision;
. as document reference for legal purposes, which have to maintain continuity in most countries, and is the same after document edition.

Those two purposes for trans_no are in permanent conflict, which emerges e.g. when you void a document. Or, in other words, this is the same problem british government tries to resolve unsuccessfully since two years at least: you can't have your cake and eat it too.

To avoid this (and make document numbering scheme more flexible),  we have added reference field to all documents, which is preserved after document edition. You should always use this field as unique identifier, and leave trans_no/id for internal use.


Janusz

67

(3 replies, posted in Report Bugs here)

The COA has been fixed. Thanks for reporting the issue.
Janusz

68

(5 replies, posted in Setup)

As stated above proposed changes in list helpers functions are not necessary, so the patch will not be integrated.  But, yes, using get_post() is encouraged in such a context.
J.

69

(5 replies, posted in Setup)

The patch contains only changes in stock_items list helpers, which are not necessary. You can have the same effect on the current FA version passing required filter in 'where' options, e.g.:

stock_items_list('stock_id', null, false, array('where'=>'s.categpry_id='.$filter_cat));

Janusz

Problem with captcha has been fixed.
Thank you for reporting the bug even without access to  bug tracking system :-)
Janusz

Transaction number is internal database record number, which should not be used directly as reference. For this purpose transaction reference should be used, which is preserved ensuring journal edition. If you want to use simple numbers as journal references, you can use default numbering template (the one with empty prefix) for this purpose.
Janusz

72

(4 replies, posted in Report Bugs here)

Hints are visible for those html form elements which have 'title' property defined. Unfortunately this feature is used inconsistently in FA code. As FA is multilanguage application using gettext text coding, adding database table for hints storage is not the best option. On the other hand adding hints to all the form elements would enlarge translation files enormously, while the feature is rarely used, and only until user is accustomed to FA features.

The irreversible contradiction between translation completeness and newbie FA user comfort is the real source of inconsistent hints implementation. To change this status we should probably implement some mechanism to use separate gettext domain for hints, which would help prioritize text translations in FA.

Janusz

Cannot reproduce this issue, on my installation all the permissions are the same in both backups, however their order changes.

I guess you restore admin backup file on non-first company in your setup, so site administration permissions are removed automatically. Only first company has administration rights allowed.

J.

74

(3 replies, posted in Setup)

Fixed.
Janusz

75

(3 replies, posted in Setup)

Yes, indeed. I'm not sure when the bugs slipped in, but I will try to fix them asap.
Janusz