After the data has been imported its time to post the data to the accounting module.

• Set the Fiscal Year month in company settings
• Set sales promotions as either Regular, Season, Ticket Type 3, Ticket Type 4, or Ticket Type 5 to match the G/L Accounting setup for the event setup.

Deposits

Determine the Fiscal Year end date (i.e. May 31)

Create a deposit for each Fiscal Year end date. Do not selectively pick dates, nor just do a single massive deposit to get all the imported data deposited. This is a clear sign of sloppiness. Doing it accurately will allow possible analysis down the road of the year-by-year statistics of the accounting module.

Then when you hit the current year, do a deposit for each month end.

Then when you hit the current month, do a deposit for the date that the last payment was entered for.

The deposits should appear as the following if May 31 is the fiscal year end and the last payment imported was Sep 10th.

May 31 2001

May 31 2002

May 31 2003

May 31 2004

May 31 2005

...

...

May 31 2013

Jun 30 2013

July 31 2013

Aug 31 2013

Sep 10 2013

Trick: If you want to have multiple machines performing deposits at the same time add the following search query to allow only a selection of payments.

wDepositList.$buildSearchString

Do iQueryGroup.$loadSimpleQueryString('PAY_DATE_RECVD`>=`JUN 1 2001')

This will allow you to limit a selection of payments between a date range. In this example, it would be implied that MAY 31 2001 was then the year end date for the fiscal year and the deposit date would be set to MAY 31 2002. Thus, this deposit would get a range of JUN 1 2001 to MAY 31 2002.

Creating Transactions

Use the routine File >> Import/Export >> TIckets >> Create Transactions

This is a special menu option where it will create the transactions only. It does not create the sales entry at this time. This allows you to be creating transactions in the background while data import happens without it having any effect on the G/L. This is purely used as an efficient use of time to maximize the number of sessions/machines that you have available.

Trick: If you want to have multiple machines performing transaction creation as the same time, add the following search query to allow only a selection of data.

tF_PLAYSEATS.$journalizeTickets

Calculate exists as con(exists,' and ORD_DATE >= ',$ctask.tDatabase.$sqlDATE('JUN 1 2001'))

tfOrderFees.$journalizeOrderFees

Calculate exists as con(exists,' and ORD_DATE >= ',$ctask.tDatabase.$sqlDATE('JUN 1 2001'))

Donations - no need to worry about as their transactions are created at time of creation.

Memberships - no need to worry about as their transactions are created at time of creation.

Payments - no need to worry about as their transactions are created at time of creation.

Projects - not done at this time, but could update tProjectsJournalizeList.$journalizePersonnelAndResouces for the exists() portion of the search() string.

Sales Entry

Just start the process and let it run normally.

Posting

Post as normal.

Then run the following command to update the posting date of the imported data to set it to the final date of the imported data. As well, set all this data as already been exported - to avoid having to export out all this data in case they use this function later on.

update F_GL_HEADER set GL_DATE_POSTED='2013-09-10 17:00:00', GL_EXPORTED = TRUE

This will give the imported data a consistent date posted and a clean date based on the last date of imported data. As well, it provides a way to easily know what data was imported and a way to use the GL_DATE_POSTED field in reports if we need to exclude this data from the current years reports.

Cleaning Up

If you wanted to de-activate all imported sales promotions so the client can start with all new promotions and have the old promotions not appear in the event setup window:

update fSalesCodes set SC_ACTIVE = FALSE, SC_DATE_END='yyyy-mm-dd' where SC_PROMOTION_USE = 0

Adjustments

In case you missed setting the Sales Promotions into their correct designation of Regular, Season, Ticket Type 3, Ticket Type 4, or Ticket Type 5 - it's too late to easily go back and recreate all the G/L Sales Entries. In most cases as this is historical data anyway, its not too critical (unless of coarse it is current years data and effects deferred/earned season/regular revenue).

Here is an easy way to get all the Patron Statistics to get shown correctly which is more important for when the client goes and does a historical analysis of the patron's buying history.

update all the sales promotions correctly.

delete from fPatronStatistics

select postPatronStatistics(F_TRANSACTION,true,true) from F_TRANSACTION

alter sequence fPatronStatisics_cs_seq_key restart with 1

In case you imported performances for a future date, then the client didn't use the database and you need to go and set those future dated performances (which are now in the past) as rolled over or flagged as history.

update F_PLAYBILL set PB_GL_JOURNAL_NO_CODE='History', PB_GL_SEQ=-1 where PB_PERFORM_DATE