[Web-erp-developers] Thanks

[skaill <sk...@ro...>]

Just downloaded the latest cvs and noticed some things:

First the fixed that have been done...

1) css had no comma after font
2) ConnectDB needed double quotes to do the $SQL variable properly.

Thanks to whoever noticed and fixed those issues.

Now for issues that may need fixing...

I think there may be an issue with the way the following has been =
converted for Multilanguage in ConstructSQLForUserDefinedSalesReport...

If ($ReportSpec["GroupByData2"] !=3D _('Not Used')) {

I believe this field is filled in by whatever is in the database.  Not =
sure what puts it in the database but I'm think whatever does probably =
puts it there in English.  If so, it should only be converted when being =
displayed, not when being tested in an IF condition.  Possibly whatever =
puts it in does translate it though...

Here's another one in SalesAnalRepts...

if ($_POST['GroupByData3']=3D=3D'Not Used' AND =
$_POST['GroupByData4']!=3D'Not Used'){

Testing of this variable in GLJournal.php may be incorrect in the same =
way as GroupByData explained above.

if ($_POST["JournalType"]=3D=3D_("Reversing")){

and

} elseif ($_POST['Process']=3D=3D_("Accept")){ //user hit submit a new =
GL Analysis line into the journal

Same here in GLProfit_Loss.php...

if ((! isset($_POST["FromPeriod"]) AND ! isset($_POST["ToPeriod"])) OR =
$_POST["SelectADifferentPeriod"]=3D=3D_("Select A Different Period")){

and

if ($_POST['Detail']=3D=3D_('Detailed')){

which is in more than one place.  Possibly some still work because here =
it is also translated on the submit form button but we agreed to try to =
test for isset rather than get into testing translations when at all =
possible.

In MailInventoryValuation the variable $DetailedReport is set to 'Yes' =
but throughout it is $_POST['DetailedReport'] that is checked.  This may =
be incorrect.

In MailSalesReport this does not look right but I guess could be somehow =
such as returning value I guess...

/*The Sales report to send */
$_GET['ReportID'] =3D 2;

In PDFDeliveryDifferences.php, again, it tries to translate strings =
before session.inc is run.  I think there was varying opinion on whether =
that would work when gettext was not installed on the server.  I'm =
thinking it won't.

Not sure the string in this sql statement in StockCostUpdate should be =
translated.  I know usually they should not be, only when they are =
displayed...

$SQL =3D "INSERT INTO GLTrans (Type, TypeNo, TranDate, PeriodNo, =
Account, Narrative, Amount) VALUES (35, " . $CostUpdateNo . ", '" . =
Date('Y-m-d') . "', " . $PeriodNo . ", " . $StockGLCode["AdjGLAct"] . ", =
'" . $StockID . ' ' . _('cost was') . ' ' . $OldCost . ' ' . _('changed =
to') . ' ' . $NewCost . ' x ' . _('Quantity on hand of') . ' ' . =
$_POST['QOH'] . "', " . (-$ValueOfChange) . ")";
=20
Possibly because it is only a message.

In Tax.php I'm thinking this is probably incorrect because it tests if =
the amount is 0 but doesn't exit like it used to...

if (ABS(round($TransTaxLeft,2))>0.01){
   $WarningMessage[$MessageCounter] =3D  _('The total tax on') . ' ' . =
$DebtorTransRow['TypeName'] . ' ' . $DebtorTransRow['TransNo'] . ' ' . =
_('of') . $LineItemsRow['LineTaxAmt'] . ' ' . _('as per the transaction =
header record was not equal to the sum of the line items - there is a =
data inconsistency of') . ' ' . $TransTaxLeft ;
   $MessageCounter++;
}

I think the latest cvs may have the DatabaseName in config.php =
incorrect.  It says testsys instead of weberp.

The biggest source of problems because of translation I believe will =
come from converting strings that are tested and incorrectly translating =
and testing of Submit and Option.

Just hitting the issues proactively that I can find before others =
encounter them at a less convenient time.

What is this PrnMsg?  Are we supposed to be using it and if so then when =
and where?

There will be times often when people will not want rounding permanently =
fixed at 2.  For instance, in an item price (price, not amount) and =
several other reasons.  The additional code for rounding is a good idea, =
however there should be variables that can be set instead of hard coding =
2 in all these places.  Item price should use a different variable than =
Amount because item price is often set to 4 whereas Amount is often set =
to 2.

Looks like the messages.po file is getting there with much more in it :) =
 We need to drive toward getting it ALL done.  Please give me 5 more =
files for translation, Phil...


Steve