autoincrementing invoices numbers

[cotanda]

Hi!
I want to do a very simple thing (or I think so). I want to give an
specific format on our reference to receivable account's invoices (09/0001)
and that pERP autoincrements it autocaticaly but I don't realy know how to
do it. Is it posible to do?? How??
Thanks a lot for your help!!!! ^^

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 23-Apr-09, at 4:08 AM, <cotanda@...>  
<cotanda@...> wrote:

> Hi!
> I want to do a very simple thing (or I think so). I want to give an
> specific format on our reference to receivable account's invoices  
> (09/0001)
> and that pERP autoincrements it autocaticaly but I don't realy know  
> how to
> do it. Is it posible to do?? How??
> Thanks a lot for your help!!!! ^^

It depends on your definition of "auto-increments".

Try:
date(y)/%2$04d
That will auto-increment the last part for each client, but without  
the client number (%1$d) in there, you will get duplicate numbers.

A system-wide auto-increment could be implemented as %3.
The place to do so is in perp_ar/inc/class.ReceivableInvoice.inc.php,  
function suggest_invoice_number().  You can look at PayableInvoice for  
examples.  If you decide to add it, please send the diff.

Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[cotanda]

Hi!
I've done what you said (changing the code on
perp_ar/inc/class.ReceivableInvoice.inc.php) so now, when you put a %3 as
format for an invoice number you get the global number, instead of the "by
client". I think it works fine.
Now the question is... how I do to send the diff?? (I mean where do I send
it??)
^^


On Thu, 23 Apr 2009 08:08:53 -0600, Nathan Gray <nathan@...>
wrote:

> On 23-Apr-09, at 4:08 AM, <cotanda@...>  
> <cotanda@...> wrote:
>
>> Hi!
>> I want to do a very simple thing (or I think so). I want to give an
>> specific format on our reference to receivable account's invoices  
>> (09/0001)
>> and that pERP autoincrements it autocaticaly but I don't realy know  
>> how to
>> do it. Is it posible to do?? How??
>> Thanks a lot for your help!!!! ^^
>
> It depends on your definition of "auto-increments".
>
> Try:
> date(y)/%2$04d
> That will auto-increment the last part for each client, but without  
> the client number (%1$d) in there, you will get duplicate numbers.
>
> A system-wide auto-increment could be implemented as %3.
> The place to do so is in perp_ar/inc/class.ReceivableInvoice.inc.php,  
> function suggest_invoice_number().  You can look at PayableInvoice for  
> examples.  If you decide to add it, please send the diff.
>
> Nathan Gray
> nathan at goarctic dot com
>

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 29-Apr-09, at 5:59 AM, <cotanda@...>  
<cotanda@...> wrote:

> ... a %3 as format for an invoice number you get the global number,  
> instead of the "by
> client". I think it works fine.

Careful with that.  pERP keeps all invoices in the same table (AP &  
AR, credit notes, warranty credits), so that may not be quite what you  
expect.  It may jump.  If that's a problem, maybe we need specific  
sequences in egw_nextid or something?

> Now the question is... how I do to send the diff?? (I mean where do  
> I send
> it??)

If it's a short (< 10 lines) diff, you can send it to the list.  
Otherwise, you can stick it in the tracker as a patch:
http://www.projecterp.org/cgi-bin/trac.cgi/newticket

Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 30-Apr-09, at 1:52 AM, <cotanda@...>  
<cotanda@...> wrote:

> Oooops! I didn't see that one coming...
> It works fine in my enterprise because we only need (for the moment)  
> AR,
> but the thing is it should respect each type. When you say "specific
> sequences in egw_nextid"... what do you mean? A global variable or so?

A global variable would not persist or be available for everyone.
eGroupWare provides a table, egw_nextid, that lets you store the next  
number in a particular sequence.
So if we use an appname like 'perp_ar:invoice', (and perp_ap:invoice')  
and update the ID column for every invoice, that should work.

The trick is when to update that ID.  Every time a new invoice is  
created?  If the invoice is cancelled instead of posted, you'll get a  
missing invoice number.  Some countries have problems with that (it's  
illegal).  If you update the number when saved or posted, there is the  
possibility of duplicates in a multi-user system.  Duplicates can be  
dealt with, of course, by just checking and trying the next ID in order.

> It would't be desirable a field on the table that indicates which  
> kind of
> invoice are you working with??

Not a bad idea.  It's something I've been considering for Orders, so  
maybe its something that should be done for both Orders and Invoices.  
It's not something that has been needed until now, because there's  
only 2 types, AP and AR, and it's easy to tell the difference based on  
the supplier_id & client_id.

Thanks for looking into this.

Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[cotanda]

Hi, sorry for being so late, I was on holidays xD

> A global variable would not persist or be available for everyone.
> eGroupWare provides a table, egw_nextid, that lets you store the next  
> number in a particular sequence.

I have a concern about the egw_nextid table. You should start from 0
everytime you make a new installation or, if you want to have an initial
number, you should add a field on the ar (and ap, etc) site configuration
menu. Having a type field on the database would be not much space (and I
guess not much work) and you will be able to specify the initial invoice
number just puting manually the first one (and if not, it would
automatically  be 0). So on you will also have all the invoices clasified
for further uses (I can't imagine right now, but I guess i could be usefull
to have the option). The bad news on changing the database is that all the
insert queries should be changed to add the new field, but I guess I would
capable of that xD. What do you think it would be more desirable? I would
try with the egw_nextid while I wait for answer ^^

Thanks for all
Jose


On Thu, 30 Apr 2009 08:29:31 -0600, Nathan Gray <nathan@...>
wrote:

> On 30-Apr-09, at 1:52 AM, <cotanda@...>  
> <cotanda@...> wrote:
>
>> Oooops! I didn't see that one coming...
>> It works fine in my enterprise because we only need (for the moment)  
>> AR,
>> but the thing is it should respect each type. When you say "specific
>> sequences in egw_nextid"... what do you mean? A global variable or so?
>
> A global variable would not persist or be available for everyone.
> eGroupWare provides a table, egw_nextid, that lets you store the next  
> number in a particular sequence.
> So if we use an appname like 'perp_ar:invoice', (and perp_ap:invoice')  
> and update the ID column for every invoice, that should work.
>
> The trick is when to update that ID.  Every time a new invoice is  
> created?  If the invoice is cancelled instead of posted, you'll get a  
> missing invoice number.  Some countries have problems with that (it's  
> illegal).  If you update the number when saved or posted, there is the  
> possibility of duplicates in a multi-user system.  Duplicates can be  
> dealt with, of course, by just checking and trying the next ID in order.
>
>> It would't be desirable a field on the table that indicates which  
>> kind of
>> invoice are you working with??
>
> Not a bad idea.  It's something I've been considering for Orders, so  
> maybe its something that should be done for both Orders and Invoices.  
> It's not something that has been needed until now, because there's  
> only 2 types, AP and AR, and it's easy to tell the difference based on  
> the supplier_id & client_id.
>
> Thanks for looking into this.
>
> Nathan Gray
> nathan at goarctic dot com
>

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 4-May-09, at 3:15 AM, <cotanda@...> <cotanda@...>  
wrote:

> Hi, sorry for being so late, I was on holidays xD
>
>> A global variable would not persist or be available for everyone.
>> eGroupWare provides a table, egw_nextid, that lets you store the next
>> number in a particular sequence.
>
> I have a concern about the egw_nextid table. You should start from 0
> everytime you make a new installation or, if you want to have an  
> initial
> number, you should add a field on the ar (and ap, etc) site  
> configuration
> menu.

Starting from 0 is easy, but it's easy enough to make that configurable.

> Having a type field on the database would be not much space ...
>  The bad news on changing the database is that all the
> insert queries should be changed to add the new field

Not that hard, and a good idea.
Done in SVN r3434, new column is named 'class'.

> What do you think it would be more desirable? I would
> try with the egw_nextid while I wait for answer ^^

Adding the column was a good idea in general, so you have the option  
to do it whichever way works out best.

Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[cotanda]

One simple question (and maybe a little naive: :$:$)
When you make an invoice, you don't call the post method on
class.ReceivableInvoice.inc.php ??

I am trying to do the next thing:
  *When you add a new invoice you give it its invoice number, which won't
be necesarily definitive.
  *When you post an invoice (you make it definitive) and you give as
invoice number the first "non posted" invoice number available. That way,
you swap both numbers.
  *When you delete an invoice, you change its number with the last "non
posted" invoice number.

It's maybe a little weird, but this way you won't have to change posted
invoices (which is suposed to be imposible) when you delete an invoice, and
you won't get any jump in your posted (or not) invoices, even if the number
order will be the posting one and the invoice numbering could dance before
you post an invoice. It's posible to put messages informing the user when
adding a new invoice.
What do you thing... too weird???

Regards!



On Mon, 4 May 2009 09:13:57 -0600, Nathan Gray <nathan@...> wrote:

> On 4-May-09, at 3:15 AM, <cotanda@...> <cotanda@...>  
> wrote:
>
>> Hi, sorry for being so late, I was on holidays xD
>>
>>> A global variable would not persist or be available for everyone.
>>> eGroupWare provides a table, egw_nextid, that lets you store the next
>>> number in a particular sequence.
>>
>> I have a concern about the egw_nextid table. You should start from 0
>> everytime you make a new installation or, if you want to have an  
>> initial
>> number, you should add a field on the ar (and ap, etc) site  
>> configuration
>> menu.
>
> Starting from 0 is easy, but it's easy enough to make that configurable.
>
>> Having a type field on the database would be not much space ...
>>  The bad news on changing the database is that all the
>> insert queries should be changed to add the new field
>
> Not that hard, and a good idea.
> Done in SVN r3434, new column is named 'class'.
>
>> What do you think it would be more desirable? I would
>> try with the egw_nextid while I wait for answer ^^
>
> Adding the column was a good idea in general, so you have the option  
> to do it whichever way works out best.
>
> Nathan Gray
> nathan at goarctic dot com
>

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 6-May-09, at 5:55 AM, <cotanda@...> <cotanda@...>  
wrote:

> One simple question (and maybe a little naive: :$:$)
> When you make an invoice, you don't call the post method on
> class.ReceivableInvoice.inc.php ??

"Make" is a little ambiguous.
The post method is only called when the {Receivable | Payable}Invoice  
is posted.
There is a common Invoice class, in perp_api, where everything common  
to invoices is kept.
ReceivableInvoice and PayableInvoice extend Invoice, and change things  
to be AP or AR specific.

> I am trying to do the next thing:
>  *When you add a new invoice you give it its invoice number, which  
> won't
> be necesarily definitive.
>  *When you post an invoice (you make it definitive) and you give as
> invoice number the first "non posted" invoice number available. That  
> way,
> you swap both numbers.

I think you lost me.  Could you spell it out with an example?

> It's maybe a little weird, but this way you won't have to change  
> posted
> invoices (which is suposed to be imposible) when you delete an  
> invoice, and
> you won't get any jump in your posted (or not) invoices, even if the  
> number
> order will be the posting one and the invoice numbering could dance  
> before
> you post an invoice. It's posible to put messages informing the user  
> when
> adding a new invoice.
> What do you thing... too weird???

Could be.  I think some of the other reference numbers can change when  
saving, so it's not unprecedented.

Invoices, however, are a little different in that you can save them  
(for a quote, for example), print them out, and give them to a  
client.  My concern is about confusion.  If the client accepts the  
quote, somebody brings up that invoice and posts it, the reference  
number may jump.

It may not be avoidable in a multi-user system, with multiple invoices  
being entered at the same time.  If you want, I can try to run it past  
accounting here, and see what they say.


Thanks,
Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[cotanda]

> "Make" is a little ambiguous.
> The post method is only called when the {Receivable | Payable}Invoice  
> is posted.
> There is a common Invoice class, in perp_api, where everything common  
> to invoices is kept.
> ReceivableInvoice and PayableInvoice extend Invoice, and change things  
> to be AP or AR specific.

When I said "make" I wanted to say "post", my mistake. But the thing is
when I put some code on the RecivabloInvoice function post... it's only
executed sometimes. I don't know, I will get a deeper look, because I think
I don't get to totally understand :$

>> I am trying to do the next thing:
>>  *When you add a new invoice you give it its invoice number, which  
>> won't
>> be necesarily definitive.
>>  *When you post an invoice (you make it definitive) and you give as
>> invoice number the first "non posted" invoice number available. That  
>> way,
>> you swap both numbers.
>
> I think you lost me.  Could you spell it out with an example?

For example, you create three new invoices: 09-001, 09-002, 09-003.
    a) Posting 09-003 will cause it to be renamed to 09-001 and the
formerly "09-001" would be renamed to 09-003.
    b) Deleting 09-002 will cause the actual "09-003" to change its number
to "09-002"
    c) Once an invoice has reached "posted" status (for example
"PostedReceivableInvoice") it will remain with its numbering... but since
that the number may change. I think that way you could avoid "jumping"
numbers... but its always under the assumption than an invoice "only gets
serious" (gets it's real number) when posting it.

That is what I think it's a weird solution, and I don't know if it is
really a solution or it's only messing around with no benefit (if it's
necessary a solid numbering for non posted invoices it would not be a
solution at all).

Thanks, and best regards!
Jose


On Wed, 6 May 2009 08:07:59 -0600, Nathan Gray <nathan@...> wrote:

> On 6-May-09, at 5:55 AM, <cotanda@...> <cotanda@...>  
> wrote:
>
>> One simple question (and maybe a little naive: :$:$)
>> When you make an invoice, you don't call the post method on
>> class.ReceivableInvoice.inc.php ??
>
> "Make" is a little ambiguous.
> The post method is only called when the {Receivable | Payable}Invoice  
> is posted.
> There is a common Invoice class, in perp_api, where everything common  
> to invoices is kept.
> ReceivableInvoice and PayableInvoice extend Invoice, and change things  
> to be AP or AR specific.
>
>> I am trying to do the next thing:
>>  *When you add a new invoice you give it its invoice number, which  
>> won't
>> be necesarily definitive.
>>  *When you post an invoice (you make it definitive) and you give as
>> invoice number the first "non posted" invoice number available. That  
>> way,
>> you swap both numbers.
>
> I think you lost me.  Could you spell it out with an example?
>
>> It's maybe a little weird, but this way you won't have to change  
>> posted
>> invoices (which is suposed to be imposible) when you delete an  
>> invoice, and
>> you won't get any jump in your posted (or not) invoices, even if the  
>> number
>> order will be the posting one and the invoice numbering could dance  
>> before
>> you post an invoice. It's posible to put messages informing the user  
>> when
>> adding a new invoice.
>> What do you thing... too weird???
>
> Could be.  I think some of the other reference numbers can change when  
> saving, so it's not unprecedented.
>
> Invoices, however, are a little different in that you can save them  
> (for a quote, for example), print them out, and give them to a  
> client.  My concern is about confusion.  If the client accepts the  
> quote, somebody brings up that invoice and posts it, the reference  
> number may jump.
>
> It may not be avoidable in a multi-user system, with multiple invoices  
> being entered at the same time.  If you want, I can try to run it past  
> accounting here, and see what they say.
>
>
> Thanks,
> Nathan Gray
> nathan at goarctic dot com
>

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 7-May-09, at 1:45 AM, <cotanda@...> <cotanda@...>  
wrote:

> ...I put some code on the RecivabloInvoice function post... it's only
> executed sometimes. ...

Weird.  Sorry, no tips for that.


>> I think you lost me.  Could you spell it out with an example?
>
> For example, you create three new invoices: 09-001, 09-002, 09-003.
>    a) Posting 09-003 will cause it to be renamed to 09-001 and the
> formerly "09-001" would be renamed to 09-003.
>    b) Deleting 09-002 will cause the actual "09-003" to change its  
> number
> to "09-002"

I don't think you can do that.
It's a bad idea in Canada (confusion), and may be illegal in some  
places.

>    c) Once an invoice has reached "posted" status (for example
> "PostedReceivableInvoice") it will remain with its numbering... but  
> since
> that the number may change. I think that way you could avoid "jumping"
> numbers... but its always under the assumption than an invoice "only  
> gets
> serious" (gets it's real number) when posting it.
>
> That is what I think it's a weird solution, and I don't know if it is
> really a solution or it's only messing around with no benefit (if it's
> necessary a solid numbering for non posted invoices it would not be a
> solution at all).

I invite others to add their thoughts at this point, but what if:
1.  After an invoice is posted, no changes (current)
2.  If an un-posted invoice is cancelled, its number is still consumed
3.  Cancelled invoices are kept, so you know where the number went,  
and can see that it is permanently cancelled, and not posted

Keeping cancelled invoices would get around the problem of numbers  
disappearing.  We don't have to worry about jumps, because even if the  
invoices are posted out of order all the numbers are still there.

There is still a possible edge case that needs attention:
1.  Two new invoices, A & B, are created, but not yet saved.
2.  Both get the number 09-004
3.  A is saved with 09-004
4.  A new invoice, C is created with number 09-005
5.  C is saved with 09-005
*6* B is saved, and before saving (only for the first time) its number  
should be updated to 09-006.


Would that solve the weirdness?  Numbers won't jump around, they won't  
disappear, and with the exception of that edge case, they will be  
absolutely sequential.


Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[cotanda]

> Keeping cancelled invoices would get around the problem of numbers  
> disappearing.  We don't have to worry about jumps, because even if the  
> invoices are posted out of order all the numbers are still there.

:o They say that the easiest solution is usually the best one. I think this
is the case, is easiest to keep the cancelled invoices than to make the
numbers xD. I just changed the cancel method so it add a "Cacelled" prefix
on the class field (I really love this field :$).

> There is still a possible edge case that needs attention:
> 1.  Two new invoices, A & B, are created, but not yet saved.
> 2.  Both get the number 09-004
> 3.  A is saved with 09-004
> 4.  A new invoice, C is created with number 09-005
> 5.  C is saved with 09-005
> *6* B is saved, and before saving (only for the first time) its number  
> should be updated to 09-006.

I have managed that to work just fine. Now the system doesn't admit
duplicates, and it changes by the next sequence number as long as there is
an invoice format defined (it works both for global numbering or per client
numbering).

I have now a big problem concerning the invoice_id field. Now I get the
right invoice reference number but somehow I overwrite some invoices (for
example on the previous example saving B would cause it to save with the
correct "our_reference_number" but over the entry of C). I guess reviewing
the code will tell me where the problem is.

The last thing is: I'm doing my practices of the career and I spend this
time trying to do this feature, so my boss has told me that it would be
desirable to have my name (and the company's) on some kind of credits (and
that way it would be a great CV line for me ^^).

Regards!!
Jose




On Thu, 7 May 2009 08:32:30 -0600, Nathan Gray <nathan@...> wrote:

> On 7-May-09, at 1:45 AM, <cotanda@...> <cotanda@...>  
> wrote:
>
>> ...I put some code on the RecivabloInvoice function post... it's only
>> executed sometimes. ...
>
> Weird.  Sorry, no tips for that.
>
>
>>> I think you lost me.  Could you spell it out with an example?
>>
>> For example, you create three new invoices: 09-001, 09-002, 09-003.
>>    a) Posting 09-003 will cause it to be renamed to 09-001 and the
>> formerly "09-001" would be renamed to 09-003.
>>    b) Deleting 09-002 will cause the actual "09-003" to change its  
>> number
>> to "09-002"
>
> I don't think you can do that.
> It's a bad idea in Canada (confusion), and may be illegal in some  
> places.
>
>>    c) Once an invoice has reached "posted" status (for example
>> "PostedReceivableInvoice") it will remain with its numbering... but  
>> since
>> that the number may change. I think that way you could avoid "jumping"
>> numbers... but its always under the assumption than an invoice "only  
>> gets
>> serious" (gets it's real number) when posting it.
>>
>> That is what I think it's a weird solution, and I don't know if it is
>> really a solution or it's only messing around with no benefit (if it's
>> necessary a solid numbering for non posted invoices it would not be a
>> solution at all).
>
> I invite others to add their thoughts at this point, but what if:
> 1.  After an invoice is posted, no changes (current)
> 2.  If an un-posted invoice is cancelled, its number is still consumed
> 3.  Cancelled invoices are kept, so you know where the number went,  
> and can see that it is permanently cancelled, and not posted
>
> Keeping cancelled invoices would get around the problem of numbers  
> disappearing.  We don't have to worry about jumps, because even if the  
> invoices are posted out of order all the numbers are still there.
>
> There is still a possible edge case that needs attention:
> 1.  Two new invoices, A & B, are created, but not yet saved.
> 2.  Both get the number 09-004
> 3.  A is saved with 09-004
> 4.  A new invoice, C is created with number 09-005
> 5.  C is saved with 09-005
> *6* B is saved, and before saving (only for the first time) its number  
> should be updated to 09-006.
>
>
> Would that solve the weirdness?  Numbers won't jump around, they won't  
> disappear, and with the exception of that edge case, they will be  
> absolutely sequential.
>
>
> Nathan Gray
> nathan at goarctic dot com
>

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[cotanda]

One rapid question:
Where is the "invoice_id" field assigned?
I understand it's done here (at the perp_api's class.Invoice.inc.php):

        // Write Invoice
                        $GLOBALS['egw']->db->insert(self::invoice_table,
                                $this->toArray(false) + array(
                                        'class' => $prefix.get_class($this)
                                ),
                                array(
                                        'invoice_id' => $this->get_invoice_id()
                                ),
                                __LINE__, __FILE__, 'perp_api'
                        );

                        if(!$this->invoice_id) {
                                $this->invoice_id =
$GLOBALS['egw']->db->get_last_insert_id(self::invoice_table, 'invoice_id');
                        }

and you got the id from SQL. My thing is now, somehow, when starting two
invoices at the same time, the second one overrides the first one and is
saved with the same "invoice_id" number. Any idea?

Thanks a lot!
Best regards!!


On Tue, 12 May 2009 12:51:36 +0200, <cotanda@...> wrote:
>> Keeping cancelled invoices would get around the problem of numbers  
>> disappearing.  We don't have to worry about jumps, because even if the  
>> invoices are posted out of order all the numbers are still there.
>
> :o They say that the easiest solution is usually the best one. I think
this
> is the case, is easiest to keep the cancelled invoices than to make the
> numbers xD. I just changed the cancel method so it add a "Cacelled"
prefix

> on the class field (I really love this field :$).
>
>> There is still a possible edge case that needs attention:
>> 1.  Two new invoices, A & B, are created, but not yet saved.
>> 2.  Both get the number 09-004
>> 3.  A is saved with 09-004
>> 4.  A new invoice, C is created with number 09-005
>> 5.  C is saved with 09-005
>> *6* B is saved, and before saving (only for the first time) its number  
>> should be updated to 09-006.
>
> I have managed that to work just fine. Now the system doesn't admit
> duplicates, and it changes by the next sequence number as long as there

is
> an invoice format defined (it works both for global numbering or per
client
> numbering).
>
> I have now a big problem concerning the invoice_id field. Now I get the
> right invoice reference number but somehow I overwrite some invoices (for
> example on the previous example saving B would cause it to save with the
> correct "our_reference_number" but over the entry of C). I guess
reviewing
> the code will tell me where the problem is.
>
> The last thing is: I'm doing my practices of the career and I spend this
> time trying to do this feature, so my boss has told me that it would be
> desirable to have my name (and the company's) on some kind of credits
(and
> that way it would be a great CV line for me ^^).
>
> Regards!!
> Jose
>
>
>
>
> On Thu, 7 May 2009 08:32:30 -0600, Nathan Gray <nathan@...>
wrote:

>> On 7-May-09, at 1:45 AM, <cotanda@...> <cotanda@...>  
>> wrote:
>>
>>> ...I put some code on the RecivabloInvoice function post... it's only
>>> executed sometimes. ...
>>
>> Weird.  Sorry, no tips for that.
>>
>>
>>>> I think you lost me.  Could you spell it out with an example?
>>>
>>> For example, you create three new invoices: 09-001, 09-002, 09-003.
>>>    a) Posting 09-003 will cause it to be renamed to 09-001 and the
>>> formerly "09-001" would be renamed to 09-003.
>>>    b) Deleting 09-002 will cause the actual "09-003" to change its  
>>> number
>>> to "09-002"
>>
>> I don't think you can do that.
>> It's a bad idea in Canada (confusion), and may be illegal in some  
>> places.
>>
>>>    c) Once an invoice has reached "posted" status (for example
>>> "PostedReceivableInvoice") it will remain with its numbering... but  
>>> since
>>> that the number may change. I think that way you could avoid "jumping"
>>> numbers... but its always under the assumption than an invoice "only  
>>> gets
>>> serious" (gets it's real number) when posting it.
>>>
>>> That is what I think it's a weird solution, and I don't know if it is
>>> really a solution or it's only messing around with no benefit (if it's
>>> necessary a solid numbering for non posted invoices it would not be a
>>> solution at all).
>>
>> I invite others to add their thoughts at this point, but what if:
>> 1.  After an invoice is posted, no changes (current)
>> 2.  If an un-posted invoice is cancelled, its number is still consumed
>> 3.  Cancelled invoices are kept, so you know where the number went,  
>> and can see that it is permanently cancelled, and not posted
>>
>> Keeping cancelled invoices would get around the problem of numbers  
>> disappearing.  We don't have to worry about jumps, because even if the  
>> invoices are posted out of order all the numbers are still there.
>>
>> There is still a possible edge case that needs attention:
>> 1.  Two new invoices, A & B, are created, but not yet saved.
>> 2.  Both get the number 09-004
>> 3.  A is saved with 09-004
>> 4.  A new invoice, C is created with number 09-005
>> 5.  C is saved with 09-005
>> *6* B is saved, and before saving (only for the first time) its number  
>> should be updated to 09-006.
>>
>>
>> Would that solve the weirdness?  Numbers won't jump around, they won't  
>> disappear, and with the exception of that edge case, they will be  
>> absolutely sequential.
>>
>>
>> Nathan Gray
>> nathan at goarctic dot com
>>
>
>

------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks
to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Perp-developers mailing list
> Perp-developers@...
> https://lists.sourceforge.net/lists/listinfo/perp-developers
>

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 12-May-09, at 4:51 AM, <cotanda@...>  
<cotanda@...> wrote:

>  I just changed the cancel method so it add a "Cacelled" prefix
> on the class field (I really love this field :$).

That's not really what that field was designed for, doing that may  
cause some 'Class not found' errors when I get finished implementing it.
I'd prefer to add a 'deleted' field.  I could add a deleted_by field  
too...  Give me a day or so and I'll put that in for you.

> The last thing is: I'm doing my practices of the career and I spend  
> this
> time trying to do this feature, so my boss has told me that it would  
> be
> desirable to have my name (and the company's) on some kind of  
> credits (and
> that way it would be a great CV line for me ^^).

Add yourself here:
http://www.projecterp.org/mediawiki/index.php/PERPWiki:Community_Portal

Make sure the diff has your name in an appropriate place (function  
header doc, for example).


Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 13-May-09, at 5:37 AM, <cotanda@...>  
<cotanda@...> wrote:

>
> One rapid question:
> Where is the "invoice_id" field assigned?
> I understand it's done here (at the perp_api's class.Invoice.inc.php):
>
> // Write Invoice
> $GLOBALS['egw']->db->insert(self::invoice_table,
> $this->toArray(false) + array(
> 'class' => $prefix.get_class($this)
> ),
> array(
> 'invoice_id' => $this->get_invoice_id()
> ),
> __LINE__, __FILE__, 'perp_api'
> );
>
> if(!$this->invoice_id) {
> $this->invoice_id =
> $GLOBALS['egw']->db->get_last_insert_id(self::invoice_table,  
> 'invoice_id');
> }
>
> and you got the id from SQL. My thing is now, somehow, when starting  
> two
> invoices at the same time, the second one overrides the first one  
> and is
> saved with the same "invoice_id" number. Any idea?

That shouldn't be possible.
Things to try:
- Save the same invoice twice, make sure there are no additional  
invoices created
- Debug the write, and check to make sure invoice_id is getting set,  
and returned


Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 20-May-09, at 10:14 AM, <cotanda@...>  
<cotanda@...> wrote:

> Sorry, I have had my mail a little unattended this days.
>
> I am totally a mess, I did the diff file and then I put on the  
> ticket not
> only the php, I put the old php. I think I have uploaded the real  
> one now
> (the diff I mean).

I am using this format for testing:
C_ID:%1$d C#:%2$s U#%3$03d (date(Y))

Client ID 502
First invoice ever.
I expect:
C_ID:502 C#:1 U#001 (2009)

Which I got.  That's good.

What is the purpose of this loop:
do{
        $extract_regex = '/' . preg_replace($regex, '(?P<_\2>.+)',  
$invoice_number_format) .'/';
        preg_match_all($extract_regex, $row_glob['our_reference_number'],  
$values, PREG_PATTERN_ORDER);
}while (!$values['_3'][0]);

In my tests, it does not exit for the second invoice.



Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers

[Nathan Gray]

On 20-May-09, at 3:40 PM, Nathan Gray wrote:

> I am using this format for testing:
> C_ID:%1$d C#:%2$s U#%3$03d (date(Y))
>
> Client ID 502
> First invoice ever.
> I expect:
> C_ID:502 C#:1 U#001 (2009)
>
> Which I got.  That's good.
>
> What is the purpose of this loop:
> do{
> $extract_regex = '/' . preg_replace($regex, '(?P<_\2>.+)',
> $invoice_number_format) .'/';
> preg_match_all($extract_regex, $row_glob['our_reference_number'],
> $values, PREG_PATTERN_ORDER);
> }while (!$values['_3'][0]);
>
> In my tests, it does not exit for the second invoice.

Any comment on this?
Can you confirm this behaviour with the above format string?

Nathan Gray
nathan at goarctic dot com


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers