Skipping No. Series

Comments

• Options

  vijayanderson Member Posts: 207

  2009-06-10

  Hi,
  
  By report it seems that number series are skipping but by process its not, I will explain you in detail.
  
  When you are posing sale invoice, the Posted sales invoice number gets automatically populated in Posting number in Sales order/Invoice header only after that invoice gets posted. By default if you get any error the number does not gets updated because only after checking all the required parameter the number gets populated in the Sales order.
  
  There are two scenarios (as far as i Know ) where the number gets populated in SO header even before posting, hence the Posting number remains in header , so when you post the same order later, it gets posted in the old populated number.
  
  a) When any customization is done, and the error is generated after Number series is populated in order
  
  b) If you have altered Lot number information after posting the receipt and before invoicing.
  
  Solution : Bring in the Posting number series to visibility in header and try posting it and check when the Posting number is getting populated.
  
  Hope this help you.
  
  Cheers,
  Vijay

  0
• Options

  imurphy Member Posts: 308

  2009-06-10

  If the users have access to the number series they can change the last used document number, skipping one and just register a document. The following day you change the last used doc number putting it back to just before the skipped doc, register your doc and then reset the last used doc no again.
  
  While this is possible to do, you'd have to ask if a user is capable of doing this and why on earth they would.
  
  Another (remote) possibilty is a clock problem. If you are using sql and a domain then this is unlikely. Is it possible that the person who registered SINV/GALCO/003630 has their PC clock incorrect? Do you do late night processing? Even with a domain you have several minutes of tolerance in which machines can work without problems. It may be possible to register a document from PC1 at 23:58 with an incorrect clock set to 00:01 and have someone on PC2 register another document 1 minutes later @ 23:59.
  
  I'm speculating here and have never checked out what would happen in a case like this. In the case of a native db I would suppose the client writes its local time, in the case of SQL I'm not sure. I don't know if nav has any built in time checks.
  
  Ian

  0
• Options

  KARPURSHRIKANT Member Posts: 35

  2009-06-10

  vijayanderson wrote:

  Hi,
  
  By report it seems that number series are skipping but by process its not, I will explain you in detail.
  
  When you are posing sale invoice, the Posted sales invoice number gets automatically populated in Posting number in Sales order/Invoice header only after that invoice gets posted. By default if you get any error the number does not gets updated because only after checking all the required parameter the number gets populated in the Sales order.
  
  There are two scenarios (as far as i Know ) where the number gets populated in SO header even before posting, hence the Posting number remains in header , so when you post the same order later, it gets posted in the old populated number.
  
  a) When any customization is done, and the error is generated after Number series is populated in order
  
  b) If you have altered Lot number information after posting the receipt and before invoicing.
  
  Solution : Bring in the Posting number series to visibility in header and try posting it and check when the Posting number is getting populated.
  
  Hope this help you.
  
  Cheers,
  Vijay

  
  
  Vijay,
  
  Thanks for the prompt description, But As described by you I Intentionally tried to do the posting the next day but in that senario the Order number has missed the sequence and not the invoice number, as you can c the detail as below.
  
  
  Senario Created Today
  Invoice No. Posting Date Order No.
  SINV/GALCO/003689 08/06/2009 ALAF/ORD/DOM/004911
  SINV/GALCO/003690 08/06/2009 ALAF/ORD/DOM/004913
  SINV/GALCO/003691 09/06/2009 ALAF/ORD/DOM/004912
  
  
  Also as described by Ian we havent given the access to the posting number series screen as its preassigned and generated automatically. This incidencess have occurred 3 times since since january at different periods and occassions.
  
  
  Also about the clock problem is very remote as we are on native database and the transactions are closed verymuch before 5:30 PM
  
  Further more on your comment of first line "number series are skipping but by process its not" I would like to more elaborate the situation as what had happened during that day,
  
  It happened that the invoice being printed continously on 25th May were from 3620 to 3632 and during the reconsillation it was found that the 3630 invoice missing on that day, furthe next day when the day started
  
  we came across the 3630 invoice
  
  Practically what ever be the case, i m failing to understand how could it have skipped the 3630 # on 25th
  
  Appreciate if you could elaborate more on the same.
  
  Rgds,
  
  Shrikant K.

  0
• Options

  imurphy Member Posts: 308

  2009-06-10

  I have no experience with the Native Db at all but if the clock is incorrect on a PC it will just write incorret values into the db. If this is the case, dates and times written by this client will be wrong. There isn't any way to control this.... other than installing ntp on the pc's and monitoring them.
  
  you said

  Practically what ever be the case, i m failing to understand how could it have skipped the 3630 # on 25th

  
  In the case of the date being wrong on a client pc nothing would have been skipped. The incorrect pc would have looked up the next sequence number (ALAF/ORD/DOM/004912) and inserted a record with a date of 09/08/2009.
  
  The next person, with their PC's clock correct, would have inserted a record with a seq number of ALAF/ORD/DOM/004912 but a date of 08/08/2009.
  
  Both operations would have taken place on the 08/06/09
  
  Try a test. Open your test db. change your local system clock to 1 month in the future, create a document, change the clock back.
  
  Ian

  0