Skip to forum content
FrontAccounting forum
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 1 of 3)
I think it should follow the document language (customer or supplier).
Example:
I am Bulgarian language user.
Amount in words on my docs is in Bulgarian.
When I issue an invoice in English to an international partner the stated amount in words remains in Bulgarian.
I use 2.4.RC1 - maybe it is noticed and changed in newer versions.
I mentioned it briefly in the first post, maybe I had to give more details.
In the table purch_order_details under description the text is correct for each line, as it should be.
In this table the same item exists with different descriptions on earlier orders.
The wrong description is one of them.
When I have time I'll dig it deeper, but thanks for trying.
No...
In fact it's not at report level, when I checked the PO by view_po.php I see the old description there too. (just like browser cache, but it's cleared)
A brief observation...
I have noticed that after editing the Item description in PO line entry I do not get it correctly on the PDF (rep 209).
I get some old text used for the same item, and not the changed description.
In the database the correct description stays, but not on the PDF.
Any clues?
Is this question about FA user or about DB user? If DB user, you can do it only if you use databases with no prefix.
As you mentioned inventory adjustments - it can be an easy solution, if you really know what are you doing, including pricing calculations. In this case all production will be in the same stock location, like the used materials.
You have to decrease used materials items and increase manufactured items, all with corresponding prices.
I guess there is something like active filtering or something else, that results in no valid return of your request.
Compare it with this discussion:
https://frontaccounting.com/punbb/viewtopic.php?id=7181
I would add something to what elax wrote.
Just make the account owner responsible for EVERYTHING that happens through his own account. Let him change the password today and from now on make sure everything wrong is on his responsibility/penalty.
This way you will make it worse for him to keep the things as they are.
This explanation is somewhat confusing.
If you are paying some amount back to the buyers, (it might sound like this, but I think it is not your case) best could be if you use some of the discount functions of the invoices.
If you are paying to the suppliers of the distributed goods - just create another Inventory Item (service type) for the rent/fee. You should get some kind of invoice for this - use this invoice with the service item, it will be tracked only for the payment...
If you are not paying to the suppliers, just receiving % of the sold goods, then they are currently your customer (for services). You have to create a supplier with the same details and track on the supplier part the payments to the same company.
If I understand what you mean, add the needed fields in the DB table sales_orders and then edit in sales/includes/.. in DB or UI first the corresponding SQL-s and then the UI includes to add the needed cells. When it's all working, you will need to see in the reporting what of them is needed on the printouts.
The DB field is TINYTEXT and this should be more than enough for 50 chrs so maybe you have to give more details. Encoding and used language, do you see the full description or just 50 ch in the DB, do you use " or ' in the description etc.
Give some real example...
"@stefan: Sales Order Tracking will then have to be manual on the description / memo fields."
@apmuthu: Yes, that's why I wrote "not so fine, but acceptable"
Sometimes you just have to keep up with the customer's requirements, no matter what the code logic is...
An easy work around (if you don't track huge information of this kind) is to create a virtual branch, named Complex, Combined, Flexible or ?????, and use the address field and comments field to specify the real branch detailed enough. It saves the additional complications and is fine on documents, not so fine but acceptable in inquiries...
However I have only a few like this.
Hi, Phong, is your school project free?
Just an additional comment.
I think that both kinds of voiding are needed. When you change it, you may find the way it works now is quite often useful.
Here for your scenario we issue Credit Notes too(if invoice is already printed and delivered, no matter what is the reason to cancel it).
I think you might get into "user" problems if many people use your system and have too many empty/voided invoices if you don't have the option to void it like it is voided now. It might cause extra tax inspections for example...
Voiding is used here when everything is still internal and you are sure you can fix the problem quietly and smoothly.
What is the presumption to include this way the zero price in this check???
if ($_POST['order_price'.$n]==0 ||
input_num('ChgPrice'.$n)/$_POST['order_price'.$n] >
(1 + ($margin/ 100)))
Isn't it better like this
if ($_POST['order_price'.$n] !=0 &&
input_num('ChgPrice'.$n)/$_POST['order_price'.$n] >
(1 + ($margin/ 100)))
The original way you are stuck if the order is with zero price...
Find this file
/reporting/includes/reports_classes.inc
there find this:
if ($ctrl == '')
{
if (($id == 102 || $id == 202) && $cnt == 3) // set default Show Also Allocated to Yes in aged reports 2014-09-19 Joe Hunt
$_POST['PARAM_'.$cnt] = 1;
if (isset($_COOKIE['select'][$id][$cnt])) // saved parameters 2010-10-06 Joe Hunt
$_POST['PARAM_'.$cnt] = $_COOKIE['select'][$id][$cnt];
$ctrl = $this->get_ctrl('PARAM_'.$cnt, $type);
}
change the first part like this:
if (( $id == 202 && $cnt == 3) || ($id == 102 && $cnt == 4 ))
$_POST['PARAM_'.$cnt] = 1;
// if (!($document == ST_SUPPAYMENT || $document == ST_CUSTPAYMENT || $document == ST_CHEQUE ))
// return "";
@rafat if I remember well there was some session or cache issue with this filtering - delayed change.
If it's still not working and for you amount in words is important, you can simply comment the line and it will be active for all documents.
You quoted a reply...
What did you do? You tried with the mentioned file from the repo or you changed the code in the file of your system?
If you tried with the mentioned file, it's still not changed to add words to invoices.
You have to find it and change the mentioned code. When reply was made apmuthu mentioned line 793 but it obviously was quoted before some other changes which increased the lines.
As of today it is at line 829.
I don't know about 2.4.3 but first of all check whether it shows when you set user languge and system default language to English 'C' .
If it works - something is wrong with your locale amount in words.
This would fully resolve it, mine is work arround. In fact only invoicing dates are needed. It is already there for non default currencies...
@Alaa, if I really understand your need, your biggest problem is the exchange rate on the date of invoice (if it's not stored for some other invoice).
An easy work arround would be if you change the function of the "Comments:" param in your changed report and manually input the exchange rate there. Of course some code changes are needed too.
Than you can make it work relatively well (it will not folow the rate changes of the selected period, if there are some). In fact the manual input can be used only for blank dates.
It will not be stored, just used to print or e-mail what you need.
I guess it is an issue of headquartes with other currency???
Great module!
Is the printing active in the demo, I can't find it.
I'm not arguing, just explaining - in landscape mode you have print costs double...
I don't mind if it is without spaces.
Posts found: 1 to 25 of 57