Holes in document sequence

[nmicoud]

Hi everyone,

I'm coming back with another issue which can cause some troubles.

Steps to reproduce :
Log with GardenAdmin
Goto Invoice (customer) window
Create a new invoice, save it.
Write down the document number
Now, change the document type target (Invoice > Credit Memo)
Save.
Change again the document type target (Credit Memo > Invoice)
Save.
Look at the document number : you just create a hole in document sequence !
The one you write down will never be used...

This is not a big problem for orders, but for invoices (and especially sales invoices), it sucks !
And accountants people don't like when it sucks

As a workaround, i put a read only logic on C_DocTypeTarget (@C_Invoice_ID@!0 & @IsSOTrx@=Y) so that it is impossible to change doc type after the first save.
But i think it is not the best solution. This should be handled by sequence itself, which should find the correct number.

Any ideas ?

Regards,

Nicolas

[globalqss]

Hi Nicolas, to solve that issue I added in a previous version the "Overwrite Sequence on Complete", take a look to the example attached.

Regards,

Carlos Ruiz

[nmicoud]

Thank Carlors for your reply,

I knew there was this checkbox but never understand how it works (i mean using a temporary sequence).
I'll try this. Maybe users will find disturbing to have temporary numbers, but at the end, we can avoid holes which is the most important !

Nicolas

[nmicoud]

Found a bug !

If you apply this solution to GL Journal (or any document that support Re-activation), you can create holes. Because the number is set in the completeIt.
So if you complete, then reactivate, and then complete again, your document has new number !

Steps to reproduce (i've just done it on demo.globallqss.com):

Window Document type :
Document sequence = Temporary Sequence
Check Overwirte n° on complete and select GL Journal for Definite Sequence

Create new Journal Batch (using GL Journal as Doc type)
Complete it. Write down numbers (fot both batch and journal)

Re-activate it.

Complete it again.
Numbers have been updated.

IMHO, updating journals numbers seems not too risky, but if you allow users to reactivate invoices, that could become complicated
Maybe the call to setDefiniteDocumentNo should be based on the previous status of the document ? (if drafted, you call it, otherwise, you don't) ?

WDYT ?

Regards,

Nicolas

[globalqss]

Thanks Nicolas, that was solved for Orders as reported by Dirk here:
http://jira.idempiere.com/browse/IDEMPIERE-63

Maybe the easier is you reopen that ticket adding your comment about GL Journal.

AFAIR the GL Journal cannot be reactivated, so maybe that's a customization from your side. But, I agree that maybe is useful to implement the same solution for all documents to cover these customization cases.

Regards,

Carlos Ruiz

[nmicoud]

I've added a comment on jira ticket but can't reopen it (don't see what i must do ; maybe i don't have the privilege to).

And i don't customized your version (not as far ) and the reactivation is available

Regards

[globalqss]

Thanks Nicolas - I reopened the ticket.

Regards,

Carlos Ruiz

[nmicoud]

Carlos, i've made some tests on demo.globalqss.com and i think there should be another control.

If you reactivate your completed document and change the document type (those document must use different sequences ; eg. Invoice >> Credit Memo or GL Journal >> GL Journal Batch in my case), the first attributed number is lost.
And you have holes again !

This behaviour is not very common but it should be centrally handled by a control like "You can't change DocTypeTarget or DocType for a document that have been previously processed".

And the user could void the document or use it later (with the same document type)

WDYT ?

Regards,

Nicolas

[globalqss]

Nicolas, I agree partially, this is, that is an interesting validation for some documents, but that ability is still needed for some other.

Firstly, invoices cannot be reactivated, that's not implemented yet, and if implemented it requires some additional coding to avoid double application of AR.

Secondly, is a valid business case in sales orders to change from proposal to quotation (to reserve inventory), and from quotation to standard order. So, that validation must not apply for those cases.

So, validations must be restricted just for some very specific cases.

Regards,

Carlos Ruiz

[nmicoud]

Thanks for explaining.
Every table has his own behaviour and it is not possible to handle them the same way.

Regards,

Nicolas