Search options (Page 7 of 11)

That would be one way of doing it.  I guess I prefer the way I coded it though, because no extra boolean switch is needed.

Well I guess that won't work, will it?  Successive lines need some kind of continuation symbol for the reference field.  I updated my fork to use '+'.   However, this code is 2.4 based and might not work in 2.3.

@apmuthu:

I would be surprised if anyone was using FA 2.4.x osc_orders except me, but even then I use a customized version.   I still use osCommerce v2.2RC2a but will be discontinuing it in the near future.

The roll-your-own web store has been waning in popularity and I doubt that almost anyone would use osCommerce  for new installations.  Rather, webbuilders and canned web sites along with commercial integrated accounting seem to be the popular choice at the moment.

Can you suggest what kind of pertinent info you would like to see in the person/item field?  A normal bank transfer uses a Miscellaneous name in the format From Acct To Acct.   I suspect that is what you might want.

However, as pointed out by @rafat and @kvvaradha, if the G/L account is listed in a supplier as an accounts payable account or in a customer as an accounts receivable account, a counterparty (person) will be added to the g/j line.

So to have the same kind of person/item as a normal bank transfer, the code would have to scan the accounts used and if they were bank accounts, set the person name.    It would have to assume that credits would set the From and debits would set the To.  It would have to handle the case when more than two accounts were in the g/j and if there were a mix of bank accounts and non-bank accounts. 

Another possibility is to use the Quick Entry name if no other name was specified.   This would be more generic because it would not be limited to bank accounts.    It would be simpler to code, but still non-trivial, because the QE name would have to be added to the cart.   Editing is an issue, because the QE name could be lost, because it would exist only in individual items, which could be lost if the accounts are changed.

A final thought is to create a Bank Transfer Quick Entry type, rather than using G/J.   This would require a code change to the Bank Transfer page to support quick entries.  This seems to make the most sense.

Make sure your code matches the code in FA24ExtensionsRepo.   The individual transaction lines should not show up in green, so maybe you have old code?

Each transaction should look like:

Ignoring payment. Use same csv under payment processing.(line 2 in import file 'bank_en_GB.csv')
3:1086
Added to table 'bank_trans': 2, 16, 102/2019, 02/01/14, 300, 2, 1 (line 3 in import file 'bank_en_GB.csv')
Added to table 'gl_trans Credit:': 2, 02/01/14, 5710, 0, 0, -300, cash on account, 2, 1 (line 3 in import file 'bank_en_GB.csv')
Added to table 'debtor_trans Credit: Payment from customer': 300 (line 3 in import file 'bank_en_GB.csv')
Added to table 'gl_trans' Debit bank account: 2, 02/01/14, 1086, 0, 0, 300, cash on account, 2, 1 (line 3 in import file 'bank_en_GB.csv')
Ignoring payment. Use same csv under payment processing.(line 4 in import file 'bank_en_GB.csv')

Does the table show up at all?  Do you see the table title Deposit Processing?

Or does the table show, but just the total line is missing?

This is coded in sales/create_recurrent_invoices.php.  The code:

        $ar = array('PARAM_0' => $min."-".ST_SALESINVOICE,  'PARAM_1' => $max."-".ST_SALESINVOICE, 'PARAM_2' => "",
            'PARAM_3' => 0, 'PARAM_4' => 0, 'PARAM_5' => "", 'PARAM_6' => user_def_print_orientation());
        display_note(print_link(sprintf(_("&Print Recurrent Invoices # %s - # %s"), $min, $max), 107, $ar), 0, 1);
        $ar['PARAM_6'] = 1; // orygina³
        $ar['PARAM_3'] = 1; // email
        display_note(print_link(sprintf(_("&Email Recurrent Invoices # %s - # %s"), $min, $max), 107, $ar), 0, 1);

looks to me to be in error, because as I listed in my first post, PARAM_6 is the customer and PARAM_7 is the print orientation.

The code should probably be:

       $ar = array('PARAM_0' => $min."-".ST_SALESINVOICE,  'PARAM_1' => $max."-".ST_SALESINVOICE, 'PARAM_2' => "",
            'PARAM_3' => 0, 'PARAM_4' => 0, 'PARAM_5' => "", 'PARAM_6' => "", 'PARAM_7'=>user_def_print_orientation());
        display_note(print_link(sprintf(_("&Print Recurrent Invoices # %s - # %s"), $min, $max), 107, $ar), 0, 1);
        $ar['PARAM_3'] = 1; // email
        display_note(print_link(sprintf(_("&Email Recurrent Invoices # %s - # %s"), $min, $max), 107, $ar), 0, 1);

Ha ha.  I had been testing using customer 1, and the code erroneously hard coded PARAM_6 to 1, so coincidentally it worked for me.

Good work!  Now you can see the url that does work (Direction invoice creation) and the url that does not work (recurrent invoice) and lo and behold they differ which must somehow explain why one works and the other doesn't. 

Oddly, on my 2.4.6 system, the direct invoice email link is:

/reporting/prn_redirect.php?PARAM_0=11-10&PARAM_1=11-10&PARAM_2=&PARAM_3=1&PARAM_4=&PARAM_5=&PARAM_6=&PARAM_7=0&REP_ID=107

and the recurrent invoice email link is:

/reporting/prn_redirect.php?PARAM_0=12-10&PARAM_1=12-10&PARAM_2=&PARAM_3=1&PARAM_4=0&PARAM_5=&PARAM_6=1&REP_ID=107

Oddly, these seem to be reversed on your system?  (Might I assume that you got them backwards in your post?)

Note that you can enter these urls in your browser and they should send mail, although we know the recurrent invoice url on your system will not work.  I suggest putting the recurrent invoice url into your browser, and removing the "1" after PARAM_6.

On my system, the link would be:

/reporting/prn_redirect.php?PARAM_0=12-10&PARAM_1=12-10&PARAM_2=&PARAM_3=1&PARAM_4=0&PARAM_5=&PARAM_6=&REP_ID=107

All these urls send mail on my system.  My latest guess is that you might be having a php version issue that is causing this problem.  What version are you running?

@joe

I really didn't do any testing, but I think it is safe, because the edit just is a copy of the existing delete code, and then just defaults the newline to the edit line values, so it shouldn't cause any harm.

My five minute edit solution (delete the g/l item but then default the fields on the new line) is:

diff --git a/core/purchasing/includes/ui/invoice_ui.inc b/core/purchasing/includes/ui/invoice_ui.inc
index b6d3d4f..53b4f3c 100644
--- a/core/purchasing/includes/ui/invoice_ui.inc
+++ b/core/purchasing/includes/ui/invoice_ui.inc
@@ -199,6 +199,7 @@ function invoice_totals(&$supp_trans)
 function display_gl_controls(&$supp_trans, $k)
 {
        $accs = get_supplier_accounts($supp_trans->supplier_id);
+    if (!isset($_POST['gl_code']))
        $_POST['gl_code'] = $accs['purchase_account'] ? 
                $accs['purchase_account'] : get_company_pref('default_cogs_act');
 
@@ -316,7 +317,8 @@ function display_gl_items(&$supp_trans, $mode=0)
                        {
                                delete_button_cell("Delete2" . $entered_gl_code->Counter, _("Delete"),
                                          _('Remove line from document'));
-                               label_cell("");
+                               edit_button_cell("Edit" . $entered_gl_code->Counter, _("Edit"),
+                                         _('Edit line from document'));
                        }       
                        end_row();
                        if ($mode > 1) {
diff --git a/core/purchasing/supplier_invoice.php b/core/purchasing/supplier_invoice.php
index 3e1bcdc..a0bb0fd 100644
--- a/core/purchasing/supplier_invoice.php
+++ b/core/purchasing/supplier_invoice.php
@@ -352,6 +352,15 @@ if ($id4 != -1)
        $Ajax->activate('gl_items');
 }
 
+$id4 = find_submit('Edit');
+if ($id4 != -1)
+{
+       display_notification($_POST['gl_code']);
+       $_SESSION['supp_trans']->remove_gl_codes_from_trans($id4);
+       reset_tax_input();
+       $Ajax->activate('gl_items');
+}
+
 $id2 = -1;
 if ($_SESSION["wa_current_user"]->can_access('SA_GRNDELETE'))
 {

Use at your own risk.

It is hard to guess what is going wrong, so perhaps you could so some more troubleshooting to find the source of the bug.

1. On your browser, position your cursor on the Email Recurring Invoice line.  On Firefox, the url will display in the lower left corner and you can right-click to bring up a menu with the Open Link in New Tab/Window or Copy Link Location.

This should run the code to send your invoice email, but obviously that does not work on your system.  But you can examine the URL to see if there is anything wrong with it.

REP_ID=107 is the Print Invoices report, the same one that appears in Customer Sales Reports.   In this report,

    $from = $_POST['PARAM_0'];
    $to = $_POST['PARAM_1'];
    $currency = $_POST['PARAM_2'];
    $email = $_POST['PARAM_3'];
    $pay_service = $_POST['PARAM_4'];
    $comments = $_POST['PARAM_5'];
    $customer = $_POST['PARAM_6'];
    $orientation = $_POST['PARAM_7'];

One change in 2.4 is more flexible reference numbers.  Perhaps PARAM_0 or PARAM_1 have some unsupported special characters?

2.  You have said that  the Print Invoices report works on these invoices.  If so, then the problem has to be the calling parameters or some obscure problem with the print redirect page, which is very simple.  The next step then would be to instrument these pages to see where the call is being dropped.

3.  Look to see if the email is being sent out of your system.  On most linux systems, this is logged in /var/log/syslog.   Or, if you have a SMTP server, you can log into that and review its log files.   Do this to confirm that the problem is indeed internal to FA.

I made a pull request on github FrontAccountingERP:master with my original code changes plus the addition of a company preferences option.