Protivity General Ledger

Protivity General Ledger is a standardized method of storing account information from any general ledger solution for the purpose of account validation and reporting within the application.  It allows the application to remain independent yet provide a simple interface with most general ledger packages such as SGA, Daprex, YMetro, and YVision.

• Account number has a user-defined layout.
  • Must define 5 components but not all need to be used (Example:  YVision PCS code is defined but not always used).
  • Each component may be from 1 to 7 positions long with an overall max length of 26 positions.
  • Each component has a user-defined label.
  • Default layouts for YMetro GL and YVision are provided.
• Provides for security based on account line type and activity type.  The default is to allow an account to be specified on any activity.
  • Example: ensure a membership revenue account is not specified on a membership accounts receivable line.
  • Example: ensure a membership revenue account is not specified on a program revenue account line.
• Provides a consistent method of account validation and reporting throughout the application.
• Standard general ledger export file that requires a user defined program to be specified to reformat the data into the import file layout required by your general ledger solution.
  • Default programs are provided for YMetro GL and YVision.
• Account numbers on all reports will display in the format of your general ledger solution.
• The posting process has been modified to not allow the user to set transaction to permanent if invalid account strings exists.  The user is then presented an opportunity to view the invalid GL transactions in order to correct them.  Future enhancement will provide for the ability to select the invalid transaction and be guided to the table file maintenance program for that activity so the account may be corrected.
• Transaction types have been modified for greater security, data integrity and improved reporting capabilities.
  • Standard set of transaction types.   No more user defined types. 
  • New maintenance program shows all available types with their associated account basis (*Cash or *Revenue), default authorities, and whether or not sub-codes are required (such as discount codes).
  • Allows the user to change the type description, default authority, and where available contra revenue accounts and sub-codes.
  • When sub-codes are required, such as entering an adjustment transaction (ADJ) on the Work with Member Transactions display, the user must specify an existing code defined for that transaction type.
  • Controls how various transaction types can be adjusted.
    • ADJ transactions can only be adjusted with another ADJ transaction.
    • DSC transactions can only be adjusted with another DSC transaction.
    • 3^RD transactions can only be adjusted with the same 3^RD transaction.
  • Adjustment transactions on a member ledger cannot be entered if the adjustment amount is set to zero.
  • Adjustment transactions cannot be made on a member ledger that causes the total revenue for that activity to drop below zero.
• New revenue adjustment codes module.  Replacement of the current Subsidy, Adjustments and 3rdy Party module.
  • Created to provide increased security, data integrity and improved reporting.
  • New controls to indicate where the code may be specified based on activity type.  This ensures that membership codes are not specified on program activities and vice versa.
  • New control to disable a code so that it is no longer used.  This is especially important since we no longer allow the codes to be removed if they are specified on a member's activity ledger.
  • These codes are associated to specific activity types.  For example *adjustment type codes can only be specified on an ADJ transaction type.  When performing adjustments on the work with transactions display, the user may no longer leave the sub-code blank or specify their own value.  This provides great security and will allow us to provide better reporting tools such as key indicators based on the type of adjustment, subsidy or 3^rd party code that is specified.
• Corrected the Deferred Detail Transaction Report on the Branch Accounting menu to prevent the same detail row from printing multiple times with invalid amounts.
• Correct General Ledger System Analysis and Results reports to only show those transactions that are truly out-of-balance. 
• Added a mandatory entry parameter that allows the system administrator to control whether or not the general ledger accounts for an activity must be specified before exiting the maintenance window.