Batch Posting Report Numbers

A Posting Number is generated when the Post to Ledger window is opened.  If the user posting cancels the process by hitting cancel or closing the window, the posting number will not be used.  A new one will be generated when the Post to Ledger is opened.

Hello – we’ve noticed our batch posting report numbers skip sequence.  We’ve theorized that it’s related to Web batches.  If a posting contains a Web batch, the posting report number that follows adds 10 to the number.  Example: Dev posting Monday – posting report #14090.  Ticket Office Posting Tuesday containing a Web batch – report #14091.  Dev posting later that day – report #14101 (skips 10). 

I saw another forum entry from 2010 that mentioned if users don’t complete a posting, that could cause unused numbers, and skipping.  But this seems to be consistent with skipping 10 following a Web posting.  Our Finance dept is concerned that something is ‘missing’.  Is this by design?  Anyone know?

Thanks,

…Dave

This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

Thanks guys.  Yes, I knew about the situation Ryan explains, but I don’t think that’s the cause.

Yesterday: 

A morning box office posting was #14115.

A report later in the day from our sales dept was #14125.

It seems unlikely that folks would be canceling the posting window exactly 10 times every day!

Ryan explained how this works, but to your point about Finance department concerns, I would make sure they understand that post numbers are not what they should be auditing--they will always be generated in sequence (thought not always used) but postings can be backdated such that your posting numbers may not actually end up in chronological order. One way for Finance to verify they are getting all of the relevant posting numbers is to run a GL Summary Report for the posting date range in question. In Detail mode, there will be a line (for each relevant GL) for every posting number that occurred within that date range.

Just a thought.

When someone clicks Post in Batch Administrator, but doesn’t proceed with the final update (ie commit it to the GL) that uses up that posting number. And the batches remain unposted. When the posting hasn’t been committed it is referred to as a Pre-Post

If the person then goes to post those batches (or others) the posting number would then be incremented from what it was previously.

So – if someone keeps pre-posting on not fully posting batches all the time that would explain the “jumping”

Cheers

Sandra

From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Nick Reilingh
Sent: Thursday, 22 May 2014 3:01 AM
To: Sandra Ashby
Subject: RE: [Tessitura Technical Forum] Batch Posting Report Numbers

The next posting number to be used is stored in T_NEXT_ID -- you can run

SELECT * FROM T_NEXT_ID WHERE type = 'PO'

This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

Thanks everyone.  Our theory of a Web batch causing things just went out the window!  Development batch post at 3:00PM -- #14140.  Box Office post later the same day (containing a Web batch) - #14150.  Nick – I think we’ll try what you suggest to see if we can isolate.

Thanks,

…Dave

Your last post and Nick’s triggered a thought. Do you have a scheduled job running that consistently updates T_NEXT_ID (such as running the upd_next_id script used when converting data)? The reason I ask is that upd_next_id is set to increment T_NEXT_ID to the last-used value of each record type - plus 10.

That’s the only situation I’ve run across where that value is updated by that specific interval.