Company Daily Close Parameters

System Maintenance Menu -> Configure System Settings -> System -> Company & Divisions -> Company Parameters -> Daily Close Parameters

The tunable company wide Daily Close Parameters can be accessed from the window in the Company Parameters.
Refer to the Daily Close Overview for procedural information and process flow.

General Settings
POST DBR BY DIVISION
Uncheck this box to post all divisions at the same time in the Daily Close.
Daily Close 1 will not prompt for division, and all divisions will print on one DBR (Daily Business Report).

Check this box to post only one division at a time in Daily Close 1.
This results in a separate DBR (Daily Business Report) for each division. This is necessary if each division must balance its own cash.

This processing must also be activated to provide the ability to post payment postings to separate bank accounts according to the division, as setup in Method Of Payment Codes when using the Cash Over/Short feature.

Note: If Post DBR Division feature is not used the Post Customer Payments could cause file locking for all divisions when the Daily Close is run, or for specific divisions when Post DBR by Division is activated.
Refer to Daily Close 1 - 'Posting Control' for details.


CASH OVER / SHORT
This processing provides an on-screen cash balancing by method of payment from Daily Close 1 and automates the postings to the bank from the payment clearing accounts defined in Method Of Payment Codes.

Uncheck this box if your firm does manual cash reconciliation.
G/L journal entries are then required to clear the payment clearing accounts and to complete the bank deposits.

Check this box to activate automatic cash-out process.
Cash discrepancies will be posted by currency to the Cash Over/Short account assigned in Default Accounts.
Prior to activating this Cash Over/Short processing, post all outstanding DBR's through the Daily Close 1: Invoice Edit.

Clear Outstanding Postings:
An error will be displayed on the screen if there are any unposted invoices or deposits, with the division and the corresponding DBR.
These items requiring posting include: The Cash Over/Short processing can not be activated until these are posted.
Outstanding DBR's can be identified by the invoices in Hold/Release Current Invoices.

On Hand Starting Balances:
When the Cash Over/Short feature is initially activated the Cash Over/Short Balances window opens so that the beginning cash On Hand amounts can be entered for each method of payment.

DBR by Division feature:
When a firm that is posting the DBR by Division and uses Cash Over/Short, runs Daily Close 2, a window is generated listing the last cash balance date by each division in ascending date order.
This can be useful to confirm that the store managers at multiple divisions are running the cash balances.

OVER/SHORT DEFAULT
When the Over/Short processing is activated and the cash balancing screen is displayed in Daily Close 1, the current cash to be balanced can initially be displayed in one of the two positions.
It is important to note the postings that will result based on the values in these fields when the reconciliation is accepted.
The default options include:
  • Click Actual Cash option to initially display the full amount to be reconciled in the Actual Closing Cash field, leaving the Less Bank Deposits field zero until the deposit amounts are manually balanced in the detail window, which updates the Less Bank Deposits amount.
    When the cash reconciliation is completed in the "Deposit, Closing Cash, and Cash Over/Short" window and is posted, any amount remaining in the Actual Closing Cash will stay in the cash drawer and display as the Opening Cash amount in the next reconciliation.

  • Click Deposit Amt option to display the initial Opening Cash amount as fully deposited in the Less Bank Deposits field, with the associated deposit distribution by payment method in the "Deposit, Closing Cash, and Cash Over/Short" window.
    The Actual Closing Cash field is zero until deposits amounts are adjusted in the "Deposit, Closing Cash, and Cash Over/Short" window.

  • Click Deposit+Payment option to initially display the total of the payments taken this day in the Less Bank Deposits and the Opening Cash amount displays the amounts carried forward from the last reconciliation.
    In the "Deposit, Closing Cash, and Cash Over/Short" window, the dollar amounts taken for each payment method show in the Deposit Amount field and the Cash On Hand and the Over/Short fields are zero, except for the dollars carried forward from the previous balancing.


INCLUDE CUSTOMER PAYMENTS IN DBR
Check this box to include A/R Customer payments in the DBR Payment totals printed from Daily Close 1: Invoice Edit.
Uncheck this box to exclude the A/R Customer payments in the DBR Payment totals.

Note: Post Customer Payments could cause file locking for all divisions when the Daily Close is run, or for specific divisions if Post DBR by Division is used.
Refer to Daily Close 1 - 'Posting Control' for details.


PRINT DAILY CLOSE PERFORMANCE SUMMARY
Check this box to always print the Performance Summary as part of the Daily Close 1, showing a divisional breakdown of subtotals by Product Class, and subtotals for the rentals, sales, services, damage waiver and taxes, with the method of payment totals.

Uncheck this box to suppress printing the Performance Summary report from Daily Close 1.


WRITE INVOICE SUMMARY RECORDS TO ASCII FILES
Uncheck this box to skip writing the ASCII files during Daily Close.

Check this box to write the ASCII files RSIHA and RSDPA during Daily Close 2.
The ASCII files created in the posting, can then be pulled into other software applications.
Import Daily Close 2 ASCII File can be used to re-import the ASCII file as required.

Note: When this is activated, the options to Clear Posted G/L Details File and to Post On Account Invoices As Paid are enabled in the Support Application Parameters.


FREEZE DAILY CLOSE #1
This parameter can be used to define a time to freeze Daily Close 1, preventing Daily Close 1 from being run after this time each day.
If a freeze time is set, Daily Close 1 is frozen each day at the set time until 12:00 midnight, and then the following day it can only be run after Daily Close 2 has been run which releases the freeze status.
Tighter Daily Close posting controls can be set, by protecting Daily Close 2 with password and access restriction security in the Security Roles.

If entering a freeze time, use the 24 hour clock.
e.g. 7:30 PM would be entered as 1930

Leave the freeze time blank, if no freeze is required.

Note: The freeze time can also be set from the Daily Close #1 Freeze Option.


POST COUNTER PAYMENTS IN DAILY CLOSE #2
Uncheck this box to always post the customer payments entered in Counter Customer Payments using payment Batch CTR in Post Customer Payments.

Check this box to provide the option to post any unposted customer payments that were entered in Counter Customer Payments, as part of the Daily Close posting when Daily Close 2 is initiated.

This option in Daily Close 2 ensures that outstanding counter payments get posted and are not overlooked.
It does not prevent posting from Post Customer Payments.

Note: Counter Customer Payments for Batch CTR can also be setup to post automatically by the ARCP10 job in Automatic Reporting.
This is useful if Daily Close 2 is rarely run manually because it is being automatically posted in Automatic Reporting.


PRINT TRANSACTION TO FILE IN DAILY CLOSE #3
Uncheck this box to always print the Daily Close reports from Daily Close 3: Post Invoices on the selected printer.

Check this box to write the Daily Close reports to an ASCII transaction file instead of to the printer.
When the reports are accepted, the transactions are saved in a text file in the specified directory.
The files can be viewed before they are accepted in Daily Close 3 and also later in View A Text File.

To ensure system functionality only the SCS operator can change the file directory, xml export directory, and xml parser

Note: This processing should not be used in the SaaS environment because of the length of the directory pathname.

The setup prompts include:
DIRECTORY
Enter the preferred directory where the transaction files should be stored.
If this field is left blank, the default directory used is "pro4data".
e.g. Windows: C:\TMP or C:\DAILYCLOSE
LINUX: /u/pro4data/tmp or /u/pro4data/dailyclose

EXPORT ONE FILE PER DAY
Check this box if Daily Close 3 is run only once a day, and thus only one Rental Journal Transaction Report and one Accounts Receivable Sales Journal are printed each day.
The transaction file name is the Company Code plus the posting date, with an extension of .RJ for the Rental Journal report or an extension of .AR for the A/R Sales Journal.
e.g. Rental Journal Transaction Report = TRS20101130.RJ
Accounts Receivable Sales Journal = TRS20101130.AR

Note: If multiple closes are done on the same day, the transaction file will be over-written and replaced by the latest file of the day.

Uncheck this box if multiples Daily Close 3's are run each day and thus multiple reports must be saved each day.

The file naming convention is then, the Company Name, underscore, AR or RJ for the appropriate report, underscore, the posting date, underscore, the posting time, with a .DAT extension.
e.g. Rental Journal Transaction Report = TRS_RJ_20101130_080844.DAT
Accounts Receivable Sales Journal = TRS_AR_20101130_081232.DAT

XML Data Exports
This option can be used to configure the XML data exports.
All field values of the following xml data sources can be generated as part of the Daily Close posting processes:
The XML export file that is generated is saved in a folder on the fileserver as defined below.
Selected XML export files can be pulled down to a local drive using the Transfer XML Export File utility.
A parser can then be used to reformat the output with selected data that can then be converted to new formats.

Additional exports not generated through the Daily Close but exported from a utility or CRON job to the defined folder on the fileserver, include:

These exports do not require the use of a parser because the data will overlap and it is not transactional in nature.
A prior batch cannot be re-exported.

The following XML data exports can also be generated automatically as a CRON JOB when set to run in Automatic Job Scheduling:

* Note: If XMLEXP4A - Export A/P Invoices or XMLEXP5A - Export A/R Invoices has been included to be run automatically in the Automatic Job Scheduling then the corresponding export will NOT be triggered by the Daily Close posting process as well.

To ensure system functionality only the SCS operator can change the file directory, xml export directory, and xml parser
Define what and how the data is exported as follows:

DIRECTORY
Enter the location on the server where files will be exported.
If a directory is entered with no "path", the directory must be within the pro4data directory.
i.e. xml or c:\pro4data\xml

If this directory is not valid or does not exist, any XML Exports run from the Automatic Job Scheduling will fail.

Note: If exported in Playdata the resulting XML files will be prefixed with 'play_'.


PARSER
A custom or default parser should always be defined if an XML export option is selected.

Use of a parser is not required, however if an XML export option is selected, a parser needs to be entered to avoid triggering an error reading the log file when it attempts to determine the success or failure of the export.

Default Parser
 A default parser is provided to validate the output files and return an OK status.
The XML documents will be left in the export directory previously defined.

  • For Windows enter: c:\scsbin\tsi_scripts\xml_parser.exe
  • LINUX systems requires Python to be installed, and then use xml_parser.py

Email
 To trigger an email with the exported output append the parser name, with a space and then --email
i.e. xml_parser.py --email

The email will be sent to the address defined for the operator that generated the export files, as setup in Operators.
The sender will be the user logged in at the LINUX level.

Custom Parser
 If your firm has a preferred parser, enter the program which will be used to parse the xml file.
This will also need to be on the server and the full path name and parser should be defined.
i.e. c:\scsbin\srm_parser.exe
Parsers may optionally move the XML files to an existing 'processed' subdirectory underneath the original export directory.

Note: Contact Texada Support for assistance customizing a parser.


EXPORT INVOICES IN DAILY CLOSE #2
Uncheck this box if "printable" invoices do not need to be exported to an XML file.

Check this box to capture invoices when they are moved successfully from batch status to history in Daily Close 2.
These "printable" invoices will be marked to be exported to XML. After Daily Close 2 has completed, all marked invoices will be exported to an XML file which includes the G/L Revenue Account for the transaction.

Note: Invoices generated directly to history from Post Customer Payments for Trade Discounts given, are also captured in the XML IHIH file.
For more information on this discount feature refer to the Trade Discounts.

The XML file naming convention is TRS_IHIH_00000000000000000161.xml where TRS represents your 3 digit company code, IHIH (Invoice History) is the data type, and 00000000000000000161 is the sequential XML transaction number that is referenced in XML Data Exports Menu.


EXPORT G/L TRANSACTIONS IN DAILY CLOSE #3
Uncheck this box if G/L transactions do not need to be exported to an XML file.

Check this box to capture G/L transactions as part of the Daily Close 3.
After the posting of the A/R invoices is completed in Daily Close 3, any G/L transactions including journals and GL checks, that have been posted since the last running of Daily Close 3, are exported to an XML file.

The XML file naming convention is TRS_GLGL_00000000000000004912.xml where TRS represents your 3 digit company code, GLGL (General Ledger) is the data type, and 00000000000000004912 is the sequential XML transaction number that is referenced in XML Data Exports Menu.

Note: If the Post A/R Invoice portion of Daily Close 3 is not completed then the XML export will not execute.
Records will post with the next Daily Close 3 that is completed.

NUMBER OF TRANSACTIONS
A minimum number of G/L transactions can be defined that will be considered when exporting and if there are less than this number of G/L postings in the current export capture then G/L transactions from prior XML Exports may be included to meet this number.
For example, if the last exported G/L transaction was number 10,000 and the “Number Of Transactions” was set to 1,000 the system will then ensure that GL transactions from 9,000 on will be included in the XML export.
It is important to note that transactions are exported based on their posting reference, so if transaction 9,000 was in the middle of a posting batch the system may include earlier transactions to ensure that the exported transactions will balance.

Warning: SETTING THIS VALUE COULD CAUSE GL TRANSACTIONS TO BE RE-EXPORTED.
THIS MAY CAUSE ISSUES WITH EXTERNAL SYSTEMS READING THE XML DATA!

When the minimum “Number Of Transactions” applies:
This "minimum" number of transactions value is respected in the XML GL Exports based on the "Export G/L Transactions In Daily Close #3" flag.
When G/L transactions are exported from Daily Close 3 then the minimum “Number Of Transactions” is only respected when the XML file is generated from Daily Close 3 and not when it is generated run from Automatic Reporting for XMLEXP3.
Conversely when "Export G/L Transactions In Daily Close #3" is not activated then the minimum “Number Of Transactions” is respected when the XML file is generated when XMLEXP3 is run from Automatic Reporting.
The minimum “Number Of Transactions” is never respect when the Export G/L Transactions is run manually as the Posting Reference files can be defined for the run.

Automated G/L Export
If the option to "Export G/L Transactions In Daily Close #3" is activated in the 'Company Daily Close Parameters' most GL transactions will be flagged to be exported as part of the next Daily Close 3 run and they will not be included in the Automatic Reporting XMLEXP3 export task.
Posting References that are flagged to post in the next Daily Close 3 can be viewed in the Reserved Daily Close Posting References window.

The data export for G/L transactions that is triggered automatically by including XLMEXP3 in Automatic Reporting is useful when "Export G/L Transactions In Daily Close #3" is NOT activated and it can be used to output any G/L transactions that have not yet been exported to an XML file and date-stamp them as exported.
When the XML file is created, a summary of the Debit and Credit totals is emailed to the addresses specified in the Auto-Reporting program.


EXPORT A/P INVOICES IN DAILY CLOSE #3
Uncheck this box if A/P invoices do not need to be exported to an XML file.

Check this box to capture A/P invoices as part of the Daily Close 3.
After the posting of the A/R invoices is completed in Daily Close 3, the information from any A/P invoices that have been posted since the last running of Daily Close 3, is exported to an XML file.
The exported data fields include those that are viewable in the header of Vendor Account Inquiry.

The XML file naming convention is TRS_APAP_00000000000000000334.xml where TRS represents your 3 digit company code, APAP (Accounts Payable) is the data type, and 00000000000000000334 is the sequential XML transaction number that is referenced in XML Data Exports Menu.

Note: If the Post A/R Invoice portion of Daily Close 3 is not completed then the XML export will not execute.
Records will post with the next Daily Close 3 that is completed.

As an alternative, the A/P Invoice information can be exported to an XML file regularly using the Automatic Job Scheduling by scheduling the job XMLEXP4A.


EXPORT A/R INVOICES IN DAILY CLOSE #3
Uncheck this box if A/R invoices do not need to be exported to an XML file.

Check this box to capture A/R invoices as part of the Daily Close 3.
After the posting of the A/R invoices is completed in Daily Close 3, any A/R transactions including invoices, credit invoice, and finance charges, that have been posted since the last running of Daily Close 3, are exported to an XML file.
The exported data fields include those that are viewable in the header of Customer Account Inquiry.

The XML file naming convention is TRS_ARAR_000000000000000104556.xml where TRS represents your 3 digit company code, ARAR (Accounts Receivable) is the data type, and 00000000000000104556 is the sequential XML transaction number that is referenced in XML Data Exports Menu.

Note: If the Post A/R Invoice portion of Daily Close 3 is not completed then the XML export will not execute.
Records will post with the next Daily Close 3 that is completed.

As an alternative, the A/R Invoice information can be exported to an XML file regularly using the Automatic Job Scheduling by scheduling the job XMLEXP5A.


EXPORT EDI PURCHASE ORDERS IN DAILY CLOSE #3
Uncheck this box if Purchase Orders do not need to be exported to an XML file.

Check this box to capture Purchase Orders as part of the Daily Close 3.
After the posting of the A/R invoices is completed in Daily Close 3, any P.O. information for vendors tagged for EDI, that has been entered since the last running of Daily Close 3, is exported to an XML file.

The XML file naming convention is TRS_INPO_000000000000000174316.xml where TRS represents your 3 digit company code, INPH (Inventory Purchase Orders) is the data type, and 00000000000000174316 is the sequential XML transaction number that is referenced in XML Data Exports Menu.

Note: If the Post A/R Invoice portion of Daily Close 3 is not completed then the XML export will not execute.
Records will be written with the next Daily Close 3 that is completed.


CREDIT RATING XML SELECTION
The Credit Rating XML Selection window is provide to set filters on customers, so only invoices for customers assigned the selected 'Credit Ratings' are included in the Export Invoices data.

UPLOAD XML VIA FTP
Fill in the server name/IP address, username and password to automatically upload all generated XML files to the FTP site.
The port# (default is 22) is required if the site uses secure FTP.
If directory is given, then the upload will try to put the files in that directory. The directory must exist as it will not be created.

XML PARSER LOGS MESSAGES
When the default parser is used, errors and success messages are written to this log file.

Window to view the Parser Log as outlined in View Application Log or to export the data to Excel.
After viewing the data in the spreadsheet format, the option is provided to delete log records in that reporting range.

Note: If a custom parser is called to do further processing, the parser needs to write a log file (i.e. TRS_GLGL_00000000000000004912.xml.log in the same directory as the original XML file, with a one-line status message that either starts with "OK" or "ERROR errormessage" according to the export results.
Without this log file the status logging will not work, even though the files could still be parsed.


Finished?
Click OK to accept the settings and exit the Daily Close Parameters window.
Note: Any changes made to these parameters will not be applied until the Company Parameters are accepted.
Topic Keyword: GLCN90M (3840)
Converted from CHM to HTML with chm2web Pro 2.85 (unicode)