It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by itronics
Those two invoices were issued using two different pricelists (aka 'sales types'). If you need explicit net value on the invoice, just use pricelist which have 'tax included' option unchecked. Then you will have net total stated on the invoice printout.
This works in 2.4.* exactly as it worked in 2.3.
Janusz
Strange, I cannot find 'Price without taxes' message in FA 2.3 sources.
But if you mean just lack of calculated Net amount, this works exactly as before, and depends on what price list you are using. If you have declared the price list used in invoice as 'tax included' on Sales Types page, the net amount (amount without taxes) is not displayed.
Janusz
Yes, indeed there is a bug in references handling during document edition. It will be fixed in next 2.4.* release.
In mean time, if you don't want to wait, just fix it in your local app sources.
Thank you for pointing this problem.
Janusz
The faulty behaviour existing in 2.3 was fixed in 2.4.1. If you want remove invalid PO you have to explicitly void related GRNs first.
There cannot be hanging GRNs without PO in database.
Janusz
Those issues just has been fixed in stable branch:
https://sourceforge.net/p/frontaccounting/git/ci/f11b39846d81bd043490ba9596224b859e47467c/
Regarding issue reported in post #11, once prepayment order is partially invoiced, it can no longer be edited. This is because for orders maintained in prepayment mode in fact partial payment is invoiced, not delivery. This is necessary to keep the invoice amount intact during whole payment process till final invoice.
Thank you for reporting the bugs.
Janusz
There was a bug in above procedure, just fixed in FA repo here.
To install your module you have to set Version variable in your _init/config file to be compatible with current FA version, i.e. the version string have to begin with '2.4'
Thank you for pointing out the problem.
Janusz
I have made suggested tests. There is indeed small bug in html entities handling in support for TextWrap pdf fields. When text is longer then place for printing, it was stripped and sometimes not decoded properly. This is the only problem found. Regarding display, encoded names are always handled properly, and edition does not change anything here. Fix for the pdf problem is here.
Small explanation to the db_escape function. We are not aware about backup file readability (they are created just for database restoring), our main concern is application security, and this is why db_escape works as is. When you will change the escaping code removing html entities encoding, you will make an application vulnerable to XSS attacks.
To prevent permanent XSS vunerability you have to prevent special html characters to be stored in database, or have to be encoded whenever it is displayed back to browser. We have chosen the former approach and implemented it in db_escape() function code (beside simple sql escaping).
The latter approach would require rewriting all the data displaying code in FA, which is just time wasting.
Regarding the lacking support for ISO-8859-2 in htmletities, this is old, never solved php problem, so we have to ommit is somehow. As all dangerous chars are included and have the same placement in both ISO-8859-1 and ISO-8859-2 sets, we can just fake encoding declaration here.
Janusz
I'm not sure what you mean.
If you have apostrophe in company name, it should be stored encoded. So exact sql is:
UPDATE sys_prefs SET value = 'Carmen's' WHERE name='coy_name';So, when you look into your database with e.g. phpmyadmin you will see in one sys_prefs record Carmen's, and this is perfectly OK.
Where you encounter problem with this?
Janusz
Well, this is just how HTML POST method works in browsers for checkbox type input field (not ticked checkbox is ignored). Changing it will lead to problems in forms which just look for POST variable existence, which is standard way of dealing with checkbox controls.
Janusz
db_escape is crucial for application security. It prevents SQL injection and XSS attacks encoding all the content once before it is stored in database. This way we have no need to clean the db content later, in all the places where it is displayed in application.
If there is any problem with encoded chars in generated PDF file, the reason is probably either in PDF generation class or in php report file. To fix it I would like to see real step by step scenario ending with the problematic pdf file.
Janusz
Yes, indeed this is a bug. Correct solution has been sent to git repos
Thank you.
Janusz
2.,4RC1 is release candidate, so it is not quite stable. 2.3.25 is current stable version until final 2.4 is relased.
Janusz
I have never seen item barcodes on invoices received from my many suppliers so far, and probably if I would find ones, this would be not very helpful for me during purchase invoice entry (most of received invoices are based on previous purchase order, so all the items are already in the system).
You can can consider customizing rep107.php which is responsible for sales invoice printing, if you feel it is worth of the effort.
Janusz
I have responded to your doubts in the mentioned previous thread, but in short words: customer payment made with generic Bank Deposit form have to be settled on 'Allocate Customer Payment or Credit Note' page. Until that it is not settled. Or better you should just use Customer Payments form instead, which allows allocation during payment entry.
Janusz
Well, I still cannot understand where you see bug here.
When the business return back the sold product and wanted to issue Invoice at the same time for replacement, top of invoice shows “Current Credit” amount for that customer. It says business should pay 100$ for that customer because of that product he/she returned.
The customer credit link shows current balance on customer's account, and not how much customer should pay for product in current transacion.
Now consider replacement invoice again issued, when we check the “Customer Payments” notice that unsettled payment for the replacement. In fact that customer has not due for business but in “Customer Payments” wrongly show a record of unsettled payment. And in no way can't remove that record.
No, customer is due until the credit note is settled with new invoice. You can do it on Allocate Customer Payments or Credit Notes page, then the record will not reappear in Customer Payment.
Regarding payment entered via generic Bank Payment form, you cannot allocate this payment to selected invoice in this form, but again, you can do it later on Allocate Customer Payments or Credit Notes page too. This is just proper workflow in FA. So, where is the problem?
Janusz
this one appears in Customer Payment allocation
Well, table names are rather self explaining. Journal table stores transaction headers for basic Journal Entry transactions, while reflines table is slightly extended sys_types table found in 2.3 db scheme. Reference line record defines transaction numbering sequence.
Janusz
I guess you should create two Tax Groups, one for VAT suppliers and another one for CST suppliers. Tax setup for the groups should contain only one of the two taxes respectively. Then you should create Item Tax Type which contains both the tax types, and use it for PCB inventory item. Now, the effective tax used will be defined by buyer's tax group.
Janusz
We cannot reproduce the problem, I guess it is somewhat specific to tax setup on your system.
Please send minimal database content on which you observe the issue to our contributions mailbox, together with the problem description. This will allow us fix the issue.
Janusz
If the problem appears in FA 2.3.* you can increment the number and try save document again. In 2.4 you can define reference number template which will use separate identifier for every user, so effectively every user have its own numbering line.
Janusz
@apmuthu
Yes, I'm aware of this supp_trans method. But in fact the purchasing module needs wider redesign anyway, so I don't want to introduce more changes in 2.3 than absolute minimum.
Thank you all for pointing this problem out 
.
Janusz
The issue has been fixed.
The unbalanced postings on clearing account were result of different net value calculations made in invoice and GRN processing. Now in both cases net value for goods received/invoiced is calculated from overall line tax included value.
Janusz
I think that removing roundings is not the right way to solve the problem. All the GL postings are made with defined (usually 1 cent) accuracy, and this should be preserved. I guess the problem lies somewhere in calculations/roundings order. I will try investigate it.
Janusz
Issue has been fixed in stable repo
Thanks for patient cooperation 
.
Janusz
This is operation recalculates value of your foreign currency savings in GL using current daily exchange rate.
Ok, the module deactivation works right on my installation by accident, but surely there is some bug here. I will push solution to repo later today.
Janusz
FrontAccounting forum → Posts by itronics
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.