1 (edited by poncho1234 01/06/2018 08:31:58 pm)

Topic: Void a Transaction Functionality

If you create the following invoices:-
Sys. #         Invoice #
    1                       1
    2                       2
    3                       3
    4                       4
    5                       5

If you then void transaction # 2 you get the following:-
Sys. #         Invoice #
    1                        1
    3                        3
    4                        4
    5                        5

Which for me gives the correct functionality

However if I void the last transaction - #5 and then create a new invoice you get:-
Sys. #         Invoice #
    1                       1
    3                       3
    4                       4
    6                       5

So ignoring ‘Legalities’ and if you have already printed / issued the invoice there are now two invoices numbered #5 (If this invoice was voided and another created after there would be three invoices #5 and so on)

So:
1.    This is not consistent.
2.    This could be confusing
3.    In Colombia this is illegal (In essence invoicing software must show the same functionality as traditional pre-printed invoices, where an annulled invoice would be written or stamped ‘Annulled’ on all copies)
My current work around is not to void invoices, but issue credit notes.

Re: Void a Transaction Functionality

For now, create the new invoice and then void the previous one so that you do not void the last one.

@joe / @itronics: if this is a code bug, we need to fix it forthwith.

3 (edited by poncho1234 01/11/2018 07:04:14 pm)

Re: Void a Transaction Functionality

After a little research, it seems this change was made for 2.3,

Today version 2.3RC1 of FrontAccounting has been released. This is a release candidate, so we would stress in announce it is not ready for production use, but all users are encouraged to made migration tests on it. Please do not test extensions as they are subject to changes before final 2.3 version. Features added after 2.3beta are emphasized.

If you have already installed preliminary 2.3RC release, please just extract 2.3RC1 tarball to your FrontAccounting directory; no additional maintenance is required. Otherwise follow instructions in bundled update.html file.

News in FrontAccounting 2.3
-----------------------------------
Common
- Allow reuse of references previously used on voided transactions


but I cannot find out why it was changed? there seems to be a couple of posts pre 2.3 where users want change invoice???

Do you know the forum post where this was discussed?

I think the code is the following added to admin\db\voiding_db.inc

109:     $Refs->restore_last($type, $type_no);

Please note line number is from 3.1 version... it's line 128 in latest version.

@apmuthu, your solution requires that a new invoice be created, this is not always the case, thanks for the suggestion, but I will stick with credit notes

Re: Void a Transaction Functionality

After a little more research it seems the ref # is obtained from customer transaction, choosing the last (greatest) value as the last invoice was voided it selects the voided ref # for the next invoice.

The other work around is to manually increase the ref # for the next invoice, but you have to remember to do it which is not ideal.

Re: Void a Transaction Functionality

If the voided transactions too are taken into account when the greatest customer transaction is considered, it might alleviate this situation.

Re: Void a Transaction Functionality

You may have to give me some better clues...please

So...
search refs, find highest value for that type
if id equals id in voided
increment ref by 2
else
increment ref by 1

Re: Void a Transaction Functionality

What happens if last 2 got voided?

hence:

search refs, find highest value for that type (and year if new templated numbering is used)
search voided for highest value for that type (and year if new templated numbering is used)
Take the larger of the two and increment by 1

Re: Void a Transaction Functionality

Is the current function this one:-

File: includes/db/class.reflines_db.inc

168:     function save_next($type, $reference, $line=null)
169:     {

?

Re: Void a Transaction Functionality

The said function just saves the reflines.pattern field during setting of the Setup => Transaction Preferences.

10 (edited by poncho1234 01/13/2018 06:12:44 pm)

Re: Void a Transaction Functionality

ah...

so I should be looking at:-

File:  includes\references.inc

83:     function _parse_next($type, $template, $context=null)
84:     {

this section:-

File: includes\references.inc

169:         // retrieve last ref number in the refline from original transaction table
170:         $sql = "SELECT MAX(CAST(SUBSTR($ref_fld, ".(strlen($prefix)+1).",LENGTH($ref_fld)-".(strlen($postfix)+strlen($prefix)).") AS UNSIGNED))"
171:                 ." FROM `$trans_table` tbl
172:                     LEFT JOIN ".TB_PREF."voided v ON tbl.`$tno_fld`=v.id AND v.type=$type"
173:                 ." WHERE ISNULL(v.id)"
174:                 .($type_fld ? " AND tbl.`$type_fld`=$type" : '')
175:                 ." AND `$ref_fld` REGEXP ".db_escape('^'.preg_quote($prefix).'[0-9]*'.preg_quote($postfix).'$');
176:         $result = db_query($sql, 'cannot retrieve last reference');
177:         $result = db_fetch_row($result);

?
My understanding of this (and my knowledge of sql is worse than php!) and ignoring the Regex..
Select the largest reference from debitor_trans
Join table with voided where id and type match

so this function returns the result which is then increased or decresed in function _increment($reference, $back=false)
    {

so the changes need to be made in function _parse_next.....???

Re: Void a Transaction Functionality

Can I use:-

SELECT GREATEST MAX(CAST(SUBSTR($ref_fld, ".(strlen($prefix)+1).",LENGTH($ref_fld)-".(strlen($postfix)+strlen($prefix)).") AS UNSIGNED)), MAX(Sql to voided table)

or would it be better to use a CASE statement?

Re: Void a Transaction Functionality

There is no guarantee that the the $ref will have the $ref of the trans_no as the first part. It is better to rely on the pattern to extract it or rely on the trans_no directly. Consider the case of straddling fiscal years.

13 (edited by stefan 01/15/2018 08:11:58 am)

Re: Void a Transaction Functionality

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.

Re: Void a Transaction Functionality

I've been concentrating on the reference # number, I should be working on the trans_no and id number in debtor_trans and voided respectively.

In File: includes\references.inc

193:     function _get($type, $trans_no=0, $ref=null)
194:     


203:         $sql = "SELECT `$ref_fld` 
204:                 FROM `$trans_table` tbl
205:                     LEFT JOIN ".TB_PREF."voided v ON 
206:                 tbl.`$tno_fld`=v.id AND v.type=$type"
207:             ." WHERE ISNULL(v.id)"
208:             .($type_fld ? " AND tbl.`$type_fld`=$type" : '');
209:         if ($ref)
210:         {
211:             $sql .= " AND tbl.`$ref_fld`=".db_escape(trim($ref));
212:             if ($trans_no)
213:                 $sql .= " AND tbl.`$tno_fld` != ".db_escape($trans_no);
214:         } else {
215:             $sql .= " AND tbl.`$tno_fld`=".db_escape($trans_no);
216:         }

It checks that the reference number has not been used, so do I need to add the compare statement before this?