Daily Close 2: Generate Postings

Reports Menu -> Automatic Reporting -> Function RSID20 -> runs Daily Close 2

After completing Daily Close 1: Invoice Edit, the invoices will have been moved from CURRENT status to BATCH.
The Batch invoices are now ready to generate the posting records.
The Daily Close 2 program reads each invoice, moves the invoices to history, and creates posting records.
Refer to the Daily Close Overview for procedural information and process flow.

Note: In order to successfully process all invoices, the operator running Daily Close 2 must have access to all divisions as controlled in the Divisional Restricted Views for code 'ALL'.
To avoid conflicts, the Move Invoice From Batch to Current cannot be run at the same time as the Daily Close 2 is running.

Automated Posting Option:

If preferred once Daily Close 1: Invoice Edit is completed, the Daily Close 2 process can be setup to run automatically with the resulting reports emailed to staff as defined in Automatic Reporting.
Automated posting of Daily Close 2 is controlled by RSID20.

PROGRAM ACTIVITY

• Background Tasks:
  Confirms that the Background Tasks are completed and fully running.
  This processing completes any delayed updates to various data files that were previously in use, as outlined in Background Tasks Processing.

  If the Background Tasks processing has not run within the last 5 minutes, a warning message is generated, displaying the date and time that the tasks were last run, and the current server date and time.
  Click the RUN TASKS button to initiate the Background Tasks, and contact Texada Support to re-activated the complete process.

  Note: To ensure data integrity, the Background Tasks must be run before the Daily Close #2 can be initiated.

• Release Daily Close 1 Lock:
  Releases the daily lock set on Daily Close #1 from the previous day that prevented Daily Close 1 from being run after the specified time.
  This optional posting freeze time can be set in the Company Daily Close Parameters.

• Division Locks:
  When Post DBR by Division is enabled in the Company Daily Close Parameters and another session is running Daily Close #1 a lock is created preventing Daily Close 2 from being run.
  When multiple sessions are running different batches for Daily Close #1 the divisions locking Daily Close 2 are listed in the Divisions Locked by Other Users window.

• Post Counter Payments:
  Initiate posting for Batch 'CTR' of unposted payments entered in Customer Counter Payments.
  This process is only triggered if the feature to post any unposted Counter Customer Payments as part of the Daily Close, as activated by the Post Counter Payments in Daily Close 2 flag in Company Daily Close Parameters.

  If an invalid Method of Payment on a Customer Counter Payment is preventing the posting, contact Texada Support to use the Counter Method of Payments/DBR utility for file RSMT to change an invalid Method of Payment.

  Refer to Post Customer Payments for details on the payments posting process, with the restriction that all currencies and divisions are included and that only batch CTR is included in the posting.

  Note: If Post Customer Payments is locked when Daily Close 2 is run, this posting step will be skipped.

• Division Cash Balance Information:
  Displays each last cash balance date by division, in ascending date order, with the division number, name, and phone number.
  This pop-up window is only triggered if your firm does cash balancing and posts the Daily Close by division, as activated by the Cash Over/Short setting in the Company Daily Close Parameters.

  The purpose of this information is to allow a company with multiple divisions to confirm that the store managers are running the cash balances as part of Daily Close 1.

• Error Checking:
  Tests for any errors in the BATCH invoices, such as missing or invalid tax, division, currency, G/L account, DW information, etc.
  If errors are found, they are written to the Daily Close #2 error file, and the Error Report automatically prints.
  This can also be accessed using either Print Daily Close 2 Errors or Daily Close 2 Error Log. Invoices with errors will be held back from all other Daily Close #2 processing. All others will be processed.

  Note: Refer to Daily Close 2 Error Log for examples of these errors and suggestions on correcting.

• Capture Current Rental Rates to Re-print on Invoices:
  Rental Rates are only printed on invoices if the flag to Print Rental Rates is set in the Divisional Invoice Parameters.
  The rate information for rental products on invoices that originate from a source contract reflects the rates defined on the contract even if the contract has been deleted.
  The rate information that is printed on posted Miscellaneous Invoices from History in Print Invoices reflects the rates that are captured at the time the invoice is posted in the Daily Close 2: Generate Postings.

  Note: If rates are changed for a rental product when that product is on an unposted Miscellaneous Invoice in Current status, that invoice will not print the correct rates structure as of the time of the rental, instead the invoice will reflect the updated rates as of the time of posting the invoice.

• Revenue Split on Kits:
  Splits out the revenue allocation of a primary rental item to the eligible No Charge kit rental items based proportionately on the costs of the primary item and the kit items.
  The G/L revenue posting distribution is reflected in the Sales Journal generated from Daily Close 3, and the product revenue allocation is then reflected in all the product revenue inquiries and reports.

  Note: Refer to Enter Kits for more information on this feature.

• Write Posting Records for On Account Invoices:
  These posting records are stored in the unposted A/R invoice file and are accessible using A/R Invoices.
  The unposted records will be posted to the General Ledger and the Customer's Account with the next step - Daily Close 3.

• Write Posting Records for Payment Methods:
  Writes posting records for invoices which are paid using Cash, Visa, etc.
  These posting records are stored in the unposted Rental Journal transactions file. If the Rental Journal is out of balance, you can use View Rental Journal Out Of Balance.
  (This might be due to a power failure during posting.)
  The unposted records will be posted to the General Ledger with the next step - Daily Close 3.

• Revenue History Update:
  Writes inventory activity to the Detailed Revenue History.
  The Detailed Revenue History shows every invoice on which the item was rented or sold, and lists the price, cost and margin for that invoice. The product history can be viewed in Revenue History .

• Business Intelligence Capture:
  When an invoice is posted the revenue information is saved into Business Intelligence ("BI") tables for use in external queries, such as Rouse Analytics as activated in Software Integration.
  The captured product information exports the same revenue values as those which get posted to Sales History (INSH), along with standard or "Book" rates for comparison.
  Each Service Code can be assigned a BI category so that Service/Damage Waiver revenue can also be saved to the BI tables.

  Note: These Business Intelligence tables are also updated in Post Customer Payments when adjustments are made to invoiced revenue because of applied trade discounts.

• Rewards Dollar Processing:
  This action only applies if the Rewards Program processing is activated in Custom Processing.
  Invoices generating Reward Dollars are checked for missing or invalid G/L posting Revenue and/or Expense account numbers in the Default Accounts for the currency of the invoice, and are reported in the Print Daily Close 2 Errors for follow-up.

  Postings for earned and used Reward Dollars are always posted to the Head Office division, regardless of divisional posting.

  Each customer's monthly business is calculated based on the total dollar amount before taxes from all invoices posted.
  Pending and Usable Rewards Dollars that should expire because of a customer's inactivity are cleared out of the customer accounts based on the expiry days setup in the Reward Program currently assigned to each customer, and are included on the Rental Journal Transaction Report generated from Daily Close 3.
  Refer to Reward Program for details on expired total Reward Dollars and expired Reward Dollars by Invoice.

• Monthly History Update:
  Writes inventory activity to the Monthly History (RSMH).
  The Monthly History shows the inventory activity on a month-by-month basis. Daily Close #2 updates the monthly totals for the # of rentals, # of sales, the Rental Revenue, Sales Revenue and the # of hours on rent.
  The Monthly History is used to produce many of the Inventory Reports including:

       Gross Margin Analysis                     
       Rental Utilization           
       Equipment Summary                         
  

• Rental Product Disposals:
  

  • Writes Disposal Reasons to the Fixed Asset Tags for sold non-bulk equipment, and to the Allocate Bulk Disposal utility for sold bulk rental products.
    For more information on this feature refer to Disposal Reason Codes.

  • Writes disposal transactions for non-bulk rental equipment sold.
    The disposal transactions track when the equipment was sold, the invoice #, the selling price, the cost and the depreciation at the time of disposal.

  • Writes interim bulk disposal records for bulk rental equipment sold.
    When bulk rental equipment is sold, the software cannot post the disposal of the equipment to the General Ledger because it does not know which Fixed Asset Tag to use for obtaining the inventory costs. The Daily Close #2 holds back any Bulk Disposals from the posting, and stores these records in Allocate Bulk Disposals.
    Later on, the staff member qualified to pick Fixed Asset Tags must review the Bulk Disposals.

  • Writes disposal transactions for bulk rental equipment sold.
    The Automatically Assign Bulk Disposals flag in the Company Posting Parameters can be set to assign the tag in order to post the cost of bulk rental equipment, by using the oldest asset tag information.

• Re-Rent Information Update:
  Writes Re-Rental Revenue transactions to the Re-Rental Transactions.

• File Integrity Checks:
  

  • Tests for damaged or missing files that are need for the posting.
    In the event that any data files being updated in this posting run cannot be read or are missing, an Automatic Rollback warning appears on the screen, and the posting stops. Previously processed invoices are committed but the posting activity for the invoice currently be processed is "undone" and the remaining invoices will not be processed.
    Rollback errors can be viewed in the Rollback Log.

  • Tests for any invoice with greater than 999 detail lines, and prevent posting. If this situation occurs, the invoice should be split into two smaller invoices.
    Call Texada Support if assistance is required.

  • Tests for any file that is nearing the maximum number of transaction numbers. When a file reaches 75% according to the GLLR count, a warning displays on the screen during Daily Close 2, advising the operator to contact Texada Support.

• Update Invoice Status:
  Moves the processed invoices from BATCH status to INVOICE HISTORY.

• G/L Posting ID:
  If the Posting by Inventory and by Customer Type processing has been activated in the Support Application Parameters, any sales or rental of non-bulk rental equipment are checked for valid Posting ID codes and Posting ID G/L accounts.
  

  A report prints out a list of any deleted Contract or Invoice transactions or documents, that may have updated the Posting ID code for a non-bulk rental product. This report is for information only, and because changes to Posting ID codes are not reversed if the transactions are deleted, the current status of these products should now be confirmed using Rental Inventory or Posting Identification By Product.
  When the report is completed, deletion records are written to Posting Identification Deletion Inquiry, providing an audit trail of the deleted records.

  Errors are captured to the Print Daily Close 2 Errors and the Daily Close 2 Error Log. Invoices with errors will be held back from all other Daily Close #2 processing. All others will be processed.

  Note: Refer to Daily Close 2 Error Log for examples of these errors and suggestions on correcting.

• XML Invoice Data Exports:
  If the processing to Export Invoices in Daily Close #2 is activated in the Company Daily Close Parameters, as invoices are moved successfully from batch status to history these "printable" invoices are marked to be exported to XML.
  Only invoices for customers assigned 'Credit Ratings' that match the Credit Rating XML Selection are included in this export action.

  As the Daily Close 2 is completed, the data fields for the marked invoices are exported to an XML file, which includes the G/L Revenue Account for the transaction.
  A parser can then be used to reformat the output, with selected data that can then be converted to new formats.
  Utilities in XML Data Export Menu can be used to review, modify, or regenerate the XML export transaction information as outlined in Export Invoices.
  The View XML Parser Log tracks the success or error results of the export.

  Note: Other XML exports that can be executed as part of Daily Close 3 include G/L transactions, A/P invoices, and A/R charges information, which can be activated from the Company Daily Close Parameters.

• VERTEX Taxing:
  If VERTEX, a third-party tax software is utilized, tests for the Vertex tax numbers and commits the final tax values to the Vertex Register.

• Invoice Printing:
  A feature of 'Daily Close #2' is the printing of invoices by division.
  A parameter can be set in the "Print Settings" of the Divisional Invoice Parameters that causes all invoices to be printed now, or just unprinted invoices, or just unprinted On Account invoices, or just unprinted Cash invoices, or no invoices at all.
  If one of the options to print some or all invoices in the Daily Close is selected for a division, a second parameter can be set to print or suppress any Zero dollar or credit invoices.

  Note: To minimize the customer receiving duplicate copies of an Invoice, the printing and emailing of invoices executed from 'Daily Close #2' only prints/emails invoices that pass DC2 successfully and are written to history.
  Invoices that do not pass 'Daily Close #2' because of outstanding errors that need to be addressed such as Cost errors, are not printed or emailed.

  If the Use Contact Document Emailing feature is activated in the Company Email Configuration, and your firm uses Jasper documents, invoices that pass 'Daily Close #2' will automatically be emailed to the corresponding eligible contacts for customer/site setup in the Contact Information, instead of printing.
  Invoices that were not emailed will still print.
  When the invoices are emailed or printed a Document Reprint Log is generated listing the documents with recipients.

  The invoices can be directed to different printers according to the invoice division. The printers are assigned in Daily Close Printers.
  This allows specific invoice letterhead to be used for the various divisions.
  If no printer is assigned to a division the current printer selection is applied.

ERRORS ?
If the warning that "There Are Pending Inventory Adjustments For Components Which Need To Be Printed/Posted" appears, these G/L value adjustments can be posted using Post Inventory Adjustments.

If the Daily Close program becomes locked because another session is currently accessing Customer Information, the relevant customer number is displayed in the Status Bar at the bottom of the screen in the lock warning.
In Oracle systems, this customer number can then be used to Generate a Lock in Database Lock Inquiry for that customer in order to identify the locking session so that the ARCFLOCK can be released.

After the invoices print, there is a prompt to change the invoice paper for plain paper, to print any error reports.
A printer can be selected from the Printer option located on the menu bar at the top of the screen, or window to display the errors on the screen instead of printing the report.
These errors can always be viewed later from Daily Close 2 Error Log.

Posting Control Daily Close 2
The Daily Close 2 - Generate Postings program is designed to be run by one operator at a time.
Locking will occur if another operator attempts to run the program at the same time, or if the first operator did not exit the posting program correctly.
A Posting Control Information warning will appear on the screen preventing the second operator from proceeding, and only operators with Security Role permission to reset the Daily Close 2 - Generate Postings flag will have access to the RESET button that unlocks the program.
Whenever the posting control flag for Daily Close 2 is reset, a record is written to the Delete Log for the Function RSIH51.

Refer to Daily Close 1/2/3 Process Locks for further status on GLPF locks for this function.