StructureThe Journal Voucher (JV) Transaction Type is a transaction that is not based on a single business function. The primary use of the Journal Voucher is to record accounting activities that cannot be accomplished with other transactions or do not fit the business function of any other transaction. The only updates made by this transaction are to reference queries, accounting control inquiry pages, budgets, and journals.
The Journal Voucher is structured with a single transaction Header, as all transactions are. The Header is then followed by a tab called the Line Group. Below the Line Group is the Accounting tab. There can be one or more Line Groups within a single Journal Voucher transaction. An Accounting Line has to be defined within a single Line Group. However, the numbering of Accounting Lines is one sequence of numbers for the entire transaction and not within each Line Group.
The actual number of records permitted for any transaction tab of the JV Transaction Type is controlled by records with a Property of MAX_LINE_LIMIT on the Transaction Component Requirements (DCREQ) page in the Administration Application.
Important features of the Journal Voucher Transaction Type:
The Line Group provides fields for transaction referencing information that will default to all Accounting Lines in the Line Group for data entry assistance. A user may also choose to change the references at the Accounting level to other lines or transactions. When the user changes the defaults entered at the line group, all references on the accounting lines defined for it are changed so any manual changes would have to be re-applied.
The Journal Voucher is limited in the Reference Type that it can perform. Only a Memo reference can be performed to another transaction. Partial and Final references are not allowed on the Journal Voucher. However, the Memo reference will update all reference queries and will be recorded in journals.
Referencing by Journal Vouchers is highly recommended when the transaction is being used to adjust previous accounting from another transaction. The recommended approach is to modify the original transaction to make the correction there, but that is not always possible and not always a desired procedural solution. However, it should be noted that if the Journal Voucher is used to adjust the amount or chart of account information from a previous transaction, any subsequent changes or references to that original transaction will still use the amount and chart of accounts prior to the correction.
Balancing is a very important feature for the Journal Voucher. For other transaction types, balancing is performed by the application. Line groups have different types of balance edits.
One edit ensures that the total debit lines equals the total credit lines defined to a line group. This edit is not optional and always enforced.
A second balancing edit is that all debit lines for a particular fund (including a sub fund if available) equal the credit lines for that same fund (and sub fund) within a given accounting period and fiscal year. This edit is often referred to as intra-fund balancing and is not optional either.
The Include BFY in Journal Voucher Balancing field on Transaction Control (DCTRL) can extend the second balancing edit to include budget fiscal year in addition to accounting period and fiscal year.
There is a third optional and configurable edit for balancing cash updates. The Cash Balance Level field on Transaction Control (DCTRL) has two settings that ensure balancing on accounting lines that use a cash posting code. The first is a balance across the transaction and the second is a balance within Fund and Sub Fund.
Unlike other transactions, Journal Vouchers do not default balance sheet accounts from settings on the Posting Code (PSCD) reference page. The user must enter these accounts on the transaction, where as other accounting transactions will infer such accounts for users. For example, when an internal exchange is done between a seller and buyer where cash is to be used as the offset, the Internal Exchange (IET) transaction will infer the cash account from the bank of both parties. The same accounting event entered on a Journal Voucher would require the user to enter a cash account for both parties.
The reason for this behavior is the Journal Voucher an advanced accounting transaction where accounts that would normally default on other transactions are not to be used in lieu of manual specification of another account.
The Journal Voucher is capable of performing one action that no other transaction type can perform. This action creates a second Journal Voucher in the future exactly like the first one except that the debit and credit amounts on the Accounting Lines are reversed. This action can only be performed once in the future, making it different than the main trigger type - Recurring. The same page that controls all automatically triggered transactions, the Future Transaction Triggering (FDT) page, handles this reversing action.
Information to establish reversals is contained in the Header tab of the Journal Voucher. Two fields make up the information. One is the Reversal Date, which is when the automatic creation of the reversing Journal Voucher is to be performed. It must be a date in the future. The second field, Reversal Hold, is an indication of whether or not the reversing Journal Voucher will be created in the Hold transaction status or with a status of Ready.
When the reversal is created, line groups and accounting lines will contain memo references to the original Journal Voucher. If there were references already on the first transaction, the second transaction replaces them. Because of this reference, when a user retrieves the history of either Journal Voucher, they will see that there is a second Journal Voucher that relates to the first. Another way to locate the reversing Journal Voucher is to search for the original Journal Voucher on the Future Transaction Triggering (FDT) page, as it will list that reversing transaction in the Triggered Transaction field. This second method is not as permanent as using the transaction reference query because triggers are removed based on the Expire Date found on the FDT page.
A Journal Voucher may not contain both recurring and reversing information. You can only have one of either type.
The Journal Voucher is capable of performing a different type of copy forward action that creates a second Journal Voucher exactly like the first one with all the same fields in the copy transaction action. However, there are a few exceptions:
Uses of the copy forward can be:
Reversing a journal voucher entered without a reversal date by mistake
Reversing a journal voucher on a different date than originally anticipated (would need to delete the FDT entry in such a case)
Reversing a journal voucher where the date of the reversal was not known in advance
Reversing the impacts of a journal voucher entered in error
The application is delivered with data to reverse the journal vouchers manually entered. Those from batch processed do not have an anticipated reason for reversing. If there becomes a need to reverse a batch journal voucher, then a record can be added to the Transaction Copy Forward Control page. Unlike a copy transaction action where the 2nd transaction has to be the same transaction code as the first, this copy forward action allows a user to copy one journal voucher transaction code into another, thus a special transaction code can be setup for manual reversals if necessary.
The Override of BFY Staging Allowed flag will not apply if an Event Type is not supplied. In this case, the Journal Voucher will skip BFY Staging editing. If entered, posting lines must meet BFY Staging rules. If not, a reject error will occur unless the Override of BFY Staging Allowed flag is checked, in which case the error will be an overrideable one.
The Event Type Required flag is only read by the Journal Voucher. If checked, the transaction code will always require an event type. Such a requirement will ensure users enter only the posting codes defined to an Event Type and do not use posting codes that are not defined to an Event Type.
The Journal Voucher (JV) Transaction Type contains the following tabs:
Header (only 1)
Line Group (1 - n)
Accounting (2 - n)
Different Basic Presentations:
All of the other delivered transaction codes use the same structure and HTML (fJV) as the JV Transaction Code with the following exceptions:
The JVC Transaction Code (fJVC HTML) looks different as it shows COA fields on the Accounting tab for Funding Profile, Funding Priority, and Funding Line.
The JVR Transaction Code (fJVR HTML) also looks different as it shows COA fields on the Line Group tab.
The JVP Transaction Code (fJVP HTML) looks different as it shows four payroll information fields on the Header and two on the Accounting tab.
JV
Delivered Transaction CodesThe Journal Voucher (JV) Transaction Type contains several delivered transaction codes. Many of these codes relate to a batch program that is creating journal vouchers for a specific processing need. In each case, a transaction code has been established to provide quick recognition of these transactions on the Transaction Catalog and for reporting. Further needs often exist for these transaction codes to have different security and Transaction Control (DCTRL) reference page settings. There are also several other transaction codes that are not tied to a specific batch job.
The Journal Voucher (JV) Transaction Type has the following Transaction Codes (listed alphabetically by Transaction Name) and views (HTML layouts). Differences beyond the basic layout (fJV) are detailed after the following table. The basic layout is detailed after those differences.
Transaction Name |
Transaction Code |
Intended Use |
View |
Advanced Journal Voucher |
JVA |
Data entry where an event type is not required to control posting code entry |
fJV |
Annual Close Journal Voucher |
JVAC |
Annual Close chain job to record closing activity in a year closed and roll balances into the next year Should be the only transaction code on the Allowed Accounting Periods for Transaction Code page with access to periods 0 and 99 |
fJV |
Bank Transfer Journal Voucher |
JVBK |
Bank Account Transfer chain job to move cash between banks used other than the Master Bank for a fund and that Master Bank |
fJVA |
Cost Accounting Journal Voucher |
JVC |
Reimbursable Expense Adjustment chain job to adjust funding lines to defined percentages Manual entry of cost accounting activity because of an expanded Detail Accounting tab. |
fJVC |
Investment Journal Voucher |
JVIN |
Manual entry for the acquisition and sale of investments with the Treasury Accounting area. |
fJV |
Journal Voucher Cash Sweep |
JVSW |
Cash Sweep chain job for Treasury Accounting taking cash from Participatory funds and giving to the Pool fund. |
fJV |
Journal Voucher Income Allocation |
JVIA |
Income Allocation chain job for Treasury Accounting that allocates investment income to the Participatory funds. |
fJV |
JV - Clearing Account Maintenance |
JVCAM |
Created by the Clearing Account Maintenance Chain Job when clearing Due To and Due From accounts though Cash. |
fJV |
Payroll Journal Voucher |
JVP |
Record expenditures, liabilities, and other payroll activity. |
fJVP |
Restricted Journal Voucher |
JVR |
Provides a feature to pre-populate all accounting lines with COA established at the line group to assist with data entry or ensure that all accounting lines have the same COA value(s). The reclassification revenues and expenditures is an example where certain COA values between the accounting line being reduced and the one being increased should be the same. |
fJVR |
Standard Journal Voucher |
JV |
Data entry where an event type is required to control posting code entry |
fJV |
If one of the three fields below is completed, all must be. This is the reason for the ‘conditionally required’ designation.
Field Name |
Required? |
Field Description |
Funding Profile |
Conditionally Required |
This chart of account should be blank unless a Front End Split Major Program has been inferred. Enter a value that is defined on the Funding Profile (FPRFLST) page - Funding Profile tab. |
Funding Priority |
Conditionally Required |
This chart of account should be blank unless a Front End Split Major Program has been inferred. Enter a value that is defined on the Funding Priority tab of the Funding Profile (FPRFLST) page. Note: You cannot enter a Funding Priority that has the Overflow flag checked on the Funding Profile page - Funding Profile tab. |
Funding Line |
Conditionally Required |
This chart of account should be blank unless a Front End Split Major Program has been inferred. Enter a value that is defined on the Funding Line section of the Funding Profile (FPRFLST) page - Funding Profile tab. |
Field Name |
Required? |
Field Description |
Pay Date |
Optional |
An optional date field to record the date of payment from a payroll system. The common date for Pay Date is the payroll check date. |
Pay Period End Date |
Optional |
An optional date field to record the last day of a pay period. |
Last Payroll |
Optional |
A flag indicating whether the pay period is the last payroll cycle in a month. |
Pay Cycle |
Optional |
An optional field to identify a type of pay cycle (for example, weekly, bi-weekly, monthly, and so forth). |
Field Name |
Required? |
Field Description |
Human Resource Measure |
Optional |
An optional field to record a value from the HR Measure page when recording payroll costs on a journal voucher. |
Quantity |
Optional |
An optional field to record a quantity in conjunction with the HR Measure. |
The JVP transaction does not contain the Authorization/Debt Instrument and Debt ID fields, which are present on the JV transaction.
All data validations will occur there on the Accounting Lines. COA errors made at the Line Group level will produce validation errors on each of the Accounting Line rather than the Line Group. However, fixing the error on the Line Group then validating the transaction will push the correction down to all the Accounting Lines. When validating or submitting the transaction, the system will overwrite any existing values with those entered on the Line Group level. That being said, if a value is null at the Group Line level, it will not overwrite a populated value on the Accounting Line. Because the data will be pushed from the Line Group to the Accounting Lines before any inferences or validations, there could be an instance where a powerful inference overrides what is entered at the Line Group. Likewise a weak inference, such as the Accounting Template, will not override what is entered at the Line Group level.
Field Name |
Required? |
Field Description |
Various COA fields |
Optional |
All COA fields are optional on the line group. Entry in one or more of the fields will be required if the COA field is protected from data entry at the Accounting Line while also being required by Required Budget, COA Required Element page, or Event Type Requirements. If a COA Inference page does not supply a value at the Accounting Line, a value must be entered at the Line Group. |
TasksThe "Create Manual Journal Entries" under the Common Business Tasks topic contains instructions on completing the following tasks: