PSM, Cash-Basis Accounting and Cash Flow Reporting

PSM, Cash-Basis Accounting and Cash Flow Reporting

Use

Table 122: Technical Data

Technical name of the business function	PSM_FA_CASH
Type of Business Function	Enterprise Business Function
Available as of	SAP Enhancement Package 4 for SAP ERP 6.0
Technical Usage
ECC application component	Fund Accounting (PSM-FA)
Directly Dependent Business Function Requiring Activation in Addition	EA-PS (Enterprise Business Function)

You can use this business function by means of a separate cash ledger or cash flow reporting by an additional splitting characteristic in the accrual ledger. Both functions, Cash-Basis Accounting and Cash Flow Reporting, are integral parts of the new General Ledger (G/L).

Prerequisites

You have installed the following components as of the version mentioned:

Type of Component	Component	Is Needed Only for the Following Features
Software Component	EA-PS 604

Features

The business function offers the following features:

• Cash-Basis Accounting
  This solution fulfills the requirement for legal cash-basis accounting.
  • It is possible to establish cash-basis accounting by means of a separate cash ledger. The cash ledger is a complete, balanced set of accounts required by and maintained for cash-basis accounting. It realizes expenses and revenue only at the time cash is paid or received.
  • The cash ledger is a non-leading ledger in the new G/L environment. Cash-Basis Accounting in the sense of this solution always needs a leading accrual ledger.
  • Typically, the only accounts posted to in Cash-Basis Accounting are cash and P&L accounts.
  • It is possible to implement Cash-Basis Accounting at a date later than your implementation of the new G/L. This is called "subsequent implementation". Migration tools in support of this are available.
• Cash-Flow Reporting
  • Cash Flow Reporting provides information on the sources of cash raised during the period, the purpose for which cash was used, and the cash balance at the reporting date.
  • Reporting of the combination cash clearing accounts/source account is possible as well.
  • Cash Flow Reporting in terms of this solution is based on an accrual ledger and does not require an additional (cash) ledger. This improves system performance by reducing data volumes.
  • Enables reporting of cash flows by source account (such as expense, revenue, taxes, or inventory).

Funds Management (PSM-FM) - WIKI

Funds Management (PSM-FM)

---

What is Public Sector Management

 The functions in this component support you in creating and executing budgets.

The purpose of Funds Management is to budget all revenues and expenditures for individual areas of responsibility, to control future funds transactions in accordance with the distributed budget, and to stop the budget being exceeded. You can adapt the budget to changes in conditions by entering releases, supplements, returns, and transfers.

Features

Funds Management enables you to control revenues and expenditures and thus control the funding of business transactions of an organization.

Closely control your budget, with the following questions in mind:

• What funds will the areas of responsibility receive?
• Where do these funds come from (source of funds)?
• What are the funds used for? (use of funds)

Control the finances of your organization by comparing commitment and actual values with current budget values.

---

What is this WIKI page good for?

This Wiki page was created to help you to find quick and adequate answers to your questions.

Here you can find help on this page

1730900 - How to use Authorization Groups for Funds Center and/or Commitment Item.

1730900 - How to use Authorization Groups for Funds Center and/or Commitment Item.

Symptom

• You want to build your authorizations for Commitment Item or Funds Center Master Data and need additional information about this topic or
• You are expecting to receive authorization errors in reporting or posting regarding restricted Funds Center or Commitment Items and system is allowing to show the data restricted by you
• You may have defined your authorization checks already but the authorization objects used are not being considered

Environment

• Financial Accounting (FI)
• SAP R/3
• SAP R/3 Enterprise 4.7
• SAP ERP Central Component
• SAP ERP
• SAP enhancement package for SAP ERP
• SAP enhancement package for SAP ERP, version for SAP HANA
• PSM-FM Add-On is active (transaction SFW5, EA-PS is on)

Reproducing the Issue

1. Run a report where you want to restrict commitment items or funds center but the data appear in the report.
2. Post a document where you want to restrict commitment items or funds center but the data can be saved.
3. You receive an authorization error message in a report or posting but you have authorization for it as per your authorizations defined in transaction PFCG.

Cause

Authorization checks for Commitment Item are done only in the case that the commitment item is assigned to some Authorization group. Therefore, the commitment item will be always displayed in reports/transactions until some authorization group is assigned. The same explanation is valid for Funds Center. In addition, if you have activated "Old Authorization check" in your customizing, you must use the old authorization objects. If you have not activated "Old Authorization check" in your customizing, you must use the new authorization objects.

Resolution

1. Use Authorization Groups for Funds Center and/or Commitment Item Master Data

        In case of Funds Center, within transaction code FMSC (fund center master data) the 'Authorization Group' field is available (the same used in the authorization rules). It is not the 'fund center' field itself, it is the group that you are grouping the fund centers only for authorization purposes.

Example: Authorization Group field in Funds Center Master Data

If, in the FMFCTR table for your FM Area, you have the same content for all records to this field, it means that all your funds center will be part of the SAME authorization group. Therefore, you should consider within your company to divide the authorization groups according your needs and adjust your roles in transaction PFCG accordingly.

If we take as an example the way that funds center works, if you do not have authorizations group in your funds center, there is no check regardless if you specify something or not in the role definition. In any case, * will mean that authorizations exist for the authorizations group. You should either specify a list of authorized funds center in the role, or assign a specific authority group to the funds center for which you do not want to allow posting.

The same is valid to commitment item where you will find the authorization group field within transaction FMCIA (commitment item master data) and table FMCI.

2. Find which authorization objects are available for the transaction that requires an authorization restriction

You should use available authorizations in transaction code SU24. The most common authorization objects available for Funds Center and commitment items are the following:

• F_FICA_FPG Funds Management: authorization group for the commitment item
• F_FICA_FSG Funds Management: authorization group for the funds center

If you are using BCS you have to use also the authorization object 'F_FMBU_ACC'. There is a short documentation in SU03 for this authorization object. Assigning only the authorization object F_FICA_FSG (in case of commitment item F_FICA_FPG) could not be enough sometimes. Use transaction SU53, SU56, SU01 and SU24 to trace authorizations.

3. Check which strategy you have customized for PSM-FM Authorizations in your system: Old Authorization Objects or New Authorization Objects

Please check the following menu path in your IMG: SPRO -> Public Sector Management -> Funds Management Government -> Basic Setting -> Authorization check -> Activate Old authorization check.

• If the flag is checked -> you are using the old authorization check.
• If the flag is not checked -> you should use the new authorization checks.

If you activate the old authorization objects, the following objects are used for the authorization check:

F_FICB_FPS  Cash budget management/Funds Management commitment item
F_FICA_FTR  Funds Management FM account assignment
F_FICA_CTR  Funds Management funds center
F_FICA_WCT  Funds Management funds center internal
F_FICA_CCT  Funds Management cross-funds center
F_FICA_FCD  Funds Management fund

These objects were referred to for the authorization check in Funds Management (FI-FM) up until release 46C.

4. Check which authorization objects you are using to be checked

To be sure about which authorization objects you are using for commitment items and funds center enter in transaction PFCG, check your rule assigned to user and activate the technical names (Menu -> Utilities -> Technical names on), then you will see if you are using the old objects or the new ones.

PSM-FM customizing must be in synch with PFCG. There is no problem to use old authorization checks but if you want to use it, the customizing of old authorization must be checked and PFCG should also use the old authorization objects for the authorization rules.

If you see that PSM-FM customizing is not in synch with PFCG, you have two options:

1. Keep the old authorization objects and set the customizing
2. Keep the customizing deactivated for old authorizations

In case you want to know more about Authorization in PSM-FM and see some examples, please check, in SAP help, the information about Authorization.

In Authorization Objects in Funds Management you will find the new authorization objects available.

NOTE: You must have for all the records of your master data (funds center or commitment item) the 'Authorization Group' field with content, otherwise it will not work. Due to a restriction in the technical design, the authorization group functionality will only work properly if you have all the records with this field fulfilled (it cannot be blank).

See Also

If you follow the instructions available in Resolution Section on how to use authorization groups and your issue still persists, make sure that you have implemented the following SAP Notes:

SAP Note 1885424 FM Report Writer: Authorizations sometimes don't work

SAP Note 1819104 RW: Wrong selection routines are executed

Keywords

FMBB, authorization object, F_FICA_FSG, F_FMBU_ACC, F_FICA_FPG, PFCG, SU24, funds management, FMKU162, FMKU 162, authorization_group, authorization, report writer, report painter.

1801529 - Error message F5727 "Maximum number of items in FI reached" when release MM document to accounting

1801529 - Error message F5727 "Maximum number of items in FI reached" when release MM document to accounting

Symptom

The problem arises when in MIRO the Invoice Verification is carried out the system shows an error because more than 999 lines exists.

Environment

• Financial Accounting (FI)
• SAP R/3
• SAP R/3 Enterprise 4.7
• SAP ERP Central Component
• SAP ERP
• SAP enhancement package for SAP ERP
• SAP enhancement package for SAP ERP, version for SAP HANA

Reproducing the Issue

You try to post an invoice by tcode MIRO.

Cause

There is a limit of 999 line items which can be posted per FI document. This is because the line item number (BSEG-BUZEI) field length is defined as 3 numeric positions. Unfortunately, there are no immediate plans to expand the number of line items beyond the current limit.

When you process an MM invoice, it's not the number of invoice items but the number of lines that are being generated for the accounting document. You may have only 250 invoice items but these could generate 5 or more accounting lines. For example, if you use external taxes and tax calculation by item is ON (t-code OBCO) each item generates 12 tax line items for the accounting document.

The tax entries in BSET also count towards the total (note 117708). If you use jurisdiction codes, you may have 4, 6, 8 or 12 BSET entries for line items with tax codes depending on your tax procedure/configuration (TTXD-XTXIT, taxes line-by-line). Even if the line items have an amount with zero tax it will still create several entries in BSET.

Resolution

The most commonly used workarounds are as follows:

1. Implement FI summarization. The error can be avoided in MRRL if you use the summarization of FI documents. You can setup the summarization with the help of the trx. OBCY and OBCYX. (see note 36353and 1779136 mentioned in 117708).
2. Cancel the original billing document and split it into smaller documents using different payment terms but actually with the same terms.

Also check the following note: 370565 No summarization of FI documents from MM due to BSE

Please read notes 1353125 and 1497092. If you want to use the functionality of these notes the functionality have to be activated using a customer-specific implementation of the BAd FI_INVOICE_RECEIPT_SPLIT. You can consider implementing notes 1353125, 1353127, 1497092,1521108 and 1601586 instead of using summarization. For that, please consider the following:

• If no summarization is maintained in transaction OBCY for the relevant reference transaction (AWTYP),
• if no net document type (-> with T003-XNETB = 'X') is used for the posting, (with the coding enhancements of the note 1521108 the posting split provided with note 1353125 is enabled for net posted invoices as well)
• if no FI document type that is assigned to a document number range that is set to use external document number assignment is used for the posting,
• if tax jurisdiction codes are active for the relevant tax calculation procedure,
• if the indicator for determining taxes line-by-line is set for the relevant tax calculation procedure (-> TTXD-XTXIT = 'X'), and
• if Funds Management (PSM-FM) is NOT active

 You can use the notes to execute an automatic document split for cases like these.

See Also

2078335 - FAQ: Error F5 727 when posting via Accounting Interface

Keywords

F5 727, F5727, Maxium number of FI items reached, limitation of max 999 lines per FI document, MIRO, MRKO, split, splitting, MIRO, MIGO, summarization, RMRP, Verdichtung, erweiterte Verdichtung, Summierung, TTYPV, OBCY, TTYPVX, OBCYX 

1628607 - Document splitting: Business process assigned in entry view

1628607 - Document splitting: Business process assigned in entry view

Symptom

In document splitting, you expect that certain business processes already contain all necessary account assignments and are no longer split, because an account assignment according to cause is not recognizable from the document to be posted. This note describes how to handle these processes in configuration.

Other Terms

CO, FI, real-time integration, company code clearing, company code clearing lines, BUV, MM, goods receipt, goods issue, item category, Customizing, document splitting, account assignment, GSP_RD, GSP_VZ3, HCM, HR, constant, document type, RFUMSV00, GLT0004, RFUMSV00, GLT2201, field overflow, CX_SY_ARITHMETIC_OVERFLOW, ELIM_ROUND_DIFF

Reason and Prerequisites

You have activated the new general ledger and document splitting with at least one document splitting characteristic as a required entry field.

Solution

During the configuration of the document splitting, you must ensure that an account assignment according to cause can be derived for all relevant business processes. There are various modules/processes that already provide all line items with the required account assignments, so that no further derivation of account assignments by document spiltting is required. There are also some technical restrictions so that cause-related splitting is not possible.

Note that all statements in this note refer to the standard GL characteristics (PRCTR, SEGMENT and GSBER). The "Segment" field plays a special role here, because the new field introduced for Release ERP 5.0 cannot be determined in some source applications and is therefore not derived until the posting in FI. For special account assignments, such as fund for public sector functionalities, other regulations may apply, because these are not known in many sending applications and must therefore be additionally derived and processed by the document splitting. The following statements are not valid for customer-defined account assignments. However, it is always the responsibility of the customer to ensure the correct derivation of customer-defined fields.


1. CO-FI Real-Time Integration (RTI)/CO Settlement
If RTI is active, corresponding documents are automatically posted in FI according to the set RTI variant in the case of transfer postings in CO (for example assessment or distribution). These documents should have already been provided with all necessary account assignments or partner assignments on the CO side. In this case the account assignments already appear in the entry view of the FI document. Normally, the account assignments are derived from the master data of the sender or receiver objects. You must therefore ensure that the master data is maintained correctly in the relevant objects. For objects that have no account assignments, for example when settling to a GL account, the account assignments can be manually added to the settlement rule directly. The partner assignments are derived from the partner relationship of the sender and receiver. In the case of cross-company code transactions that are posted from CO to FI, the company code clearing lines are also already assigned in the entry view or split if necessary. For this, Notes 995055 and 1039189 must be implemented in your system.

Because all required account assignments must already be set for the RTI, these types of documents are posted with a document type that no longer performs an additional splitting. The document type used should be assigned to a business transaction variant that contains no item categories to be processed. The standard characteristics of business transaction variant 0000/0001 is unsuitable in this case, because these contain rules for the assignment of the company code clearing lines.

2. Goods Receipt or Goods Issue from Materials Management (MM)
When posting the goods receipt or issue, the account assignments relevant to the general ledger are normally already set in MM in all lines. In the case of a purchase order with account assignment, the account assignments relevant to the general ledger are derived from the CO account assignment in the purchase order. In the case of a purchase order without account assignment, the account assignments for the general ledger are derived from the corresponding Customizing settings (for example material master record). It is therefore very important in this case that the required assignments or master records are maintained accordingly. The company code clearing lines are not created and assigned by the sending application (MM) in this case.

Because all required account assignments for this MM transaction (except in the company code clearing lines) must already be set, we recommend that you use business transaction 0600 (for goods receipt for purchase order) or 0000 in Customizing for document splitting. In the standard delivery, the standard business transaction variants 0600/0001 and 0000/0001 do not contain any splitting rules except for the company code clearing lines (item category 01100).

The additional material ledger documents that are posted together with MM documents (both MM goods movements and invoices from logistics invoice verification) within an LUW should also already contain all the G/L-relevant account assignments. Refer to Note 1884540 for information about the Customizing settings in this case.

3. Payroll (HCM)
Due to the summarized posting method of documents from HR, the document splitting does not have the required information in order to guarantee a cause-based splitting of the account assignments. For this reason, as of Release ERP 6.0 the splitting is performed directly in the HR module and transferred to FI fully assigned.

Because all required account assignments must also be set for this transaction, these types of documents should be posted with a document type that no longer performs an additional splitting. For HR postings the documents are very large and are posted to FI together within the payroll run. An exception to this is return postings to the old year if the splitting of payables was performed retrospectively on the HCM side. In this case, you must define a special constant in the business transaction variant. Splitting the company code clearing lines is not relevant in this scenario, because the payroll is posted for each company code and therefore no company code clearing lines are created. If a business transaction variant is assigned for the HR document type used, and this variant processes the rule-based document split, this largely results in performance and memory problems.

In exceptional cases, a rule-based split for tax items can be required for HR documents, because the tax items are not assigned based on cause from the HR side for technical reasons. If tax is supposed to be posted in HR, a splitting rule must be created for the item category 05100 (tax). The tax must always be defined taking into account the "Check tax code" indicator.

The technical split lines are another exception. These auxiliary lines are created if a HR document contains more than 999 lines and must technically be split in several FI documents. In this case, the technical split lines ensure that each partial document balances to zero in FI. The technical split lines also balance to zero and therefore have no business-related effect on the overall process. For this reason, they remain unassigned in the standard system and are excluded from the required field check during document splitting. You can find more details in Note 511614.

You can find further information about splitting payables in payroll in Note 1039346.

4. Periodic Closing Operations
Periodic closing entries in FI, for example foreign currency valuation, advance return for tax on sales/purchases and so on, are based on existing transaction data. You must ensure that the account assignments of the closing entries correspond to the line items referred to by the periodic postings. In order to guarantee these account assignments according to cause, a mechanism was implemented in the closing programs to derive account assignments from the corresponding line items. These are then transferred to the entry view when the FI documents are created. As a result, these documents must not be processed further by the document splitting.
The prerequisite for this are the corresponding settings in the view V_FAGL_SPLIT_FL2 (transaction SM30 - Display). For example, the indicator in the column "Val.ExchRateDif" must be set for all account assignments that are relevant for the foreign currency valuation documents. Of course you must also ensure that the original postings are assigned correctly.

An exception is the assessment and distribution in the general ledger. The allocation does not contain an item reference and therefore cannot automatically derive any account assignments. In this case, all required account assignments must be entered manually (in the cycle, for example).

Because all required account assignments must already be set for the closing entries, these types of documents are posted with a document type that no longer performs an additional splitting. The standard business transaction variant 0000/0001 (unspecified posting) is one possible allowed entry.

5. Asset Accounting (FI-AA)
For lines that are created in Asset Accounting, the account assignments are derived from the asset master record according to Customizing. The prerequisites for this are described in Note 684659.
In general, all documents that refer to a fixed asset or are created by Asset Accounting (for example depreciations, balance sheet adjustments and so on) are already provided with the account assignments in the entry view. For fixed asset lines, item category 07000 is derived automatically. In the splitting rule, item category 07000 should not be defined as an item category to be processed.

6. Contract Accounts Receivable and Payable (FI-CA)
Documents from FI-CA are posted in summary to the document splitting and do not contain the level of detail that is necessary to perform a cause-based splitting in FI. Therefore, the FI-CA documents are deliberately excluded from processing by the document spitting and from the required field check. This is based on the document origin (field AWTYP = FKKSU), regardless of the assigned business transaction variant.
As of Release ERP 6.0, there is an option to provide the "Segment" field with correct values directly in FI-CA and to post them to FI already assigned. As of Release ERP 6.04 (ERP 6.0 with Enhancement Package 4), there is also a solution for profit center in FI-CA. You can find more detailed information about this in Note 1070629, point 3 of the appendix ("Is the new general ledger compatible with FI-CA (FI - Contract Accounting)?") The following notes are relevant for the supply of general ledger-relevant fields in FI-CA: 1285775, 1269687, 1469556, 1469741, 1468167, 1473984, 1171402.

1466979 - FM Financial transactions to be used in FI line items

1466979 - FM Financial transactions to be used in FI line items

Symptom

You are not sure which commitment item (FIPOS) should be used on the line items of a financial document.

Other Terms

FIVOR, FMIFIIT, FIPEX, Financila Transaction

Reason and Prerequisites

The correct update of documents in Funds Management depends on the financial transaction assigned to the commitment item used in each line item.

Solution

SAP strongly recommends that you are deriving/entering the correct commitment item in your items so the correct financial transactions are being used:

ACCOUNT CATEGORY	FINANCIAL TRANSACTION	ITEM
Revenues	30	2
Expense	30	3
GR/IR lines in goods receipt documents	40	3
GR/IR lines in invoice receipt documents	30 (typically the commitment item from the PO)	3
Clearing account for cross-company code transactions	50 (this means also no account payable, no account receivable!)	2/3
Check clearing / bank clearing	80/90	1
Bank/cash desk	90	1
Accounts receivable	60	2
Accounts payable	60	3
Input tax	30	2
Output tax	30	3
Withholding Tax	30	2/3
Cash discount received	30	2/3
Cash discount paid	30	2/3
Cash discount clearing	60	2/3
Price difference accounts and other automatic created lines which are posted with payments	30	2/3
Down payment accounts (with and without asset)	30	2/3
Down payment clearing	30	2/3
Pool/Assets: Acquisitions	30	2
Pool/Assets: Issues	30	3
Payables from consignment warehouse or from pipeline	40	3

- HCM/HR documents should follow one of the financial transaction sorting mentioned in the following notes:
886094 Transferring staff costs to Funds Management
644804 Integration of HR into Funds Management

- With the transfer of a Payroll from the HCM/HR module to accounting, the FI document being created is split (into several documents) if more than 990 FI line items are created.
HR clearing lines will be created in the documents to guarantee a balance to zero in the document. These clearing items are purely technical lines that have no business importance and therefore do not contain any account assignments.
The commitment item of the clearing (Document split account) item should have a financial transaction "50" so it doesn't get updated in FM.
This is explained in the following notes:
511614 HR: HR clearing items in FI document  w/ document
886094 Transferring staff costs to Funds Management

- Security Deposit documents should follow the financial transaction sorting mentioned in the following note:
350336 Security deposits and Cash Budget Management

- For additional information about specific Asset Accounting postings (i.e.: Transfer postings, Retirement with Revenue with Customer, Depreciation, etc.), please go to the SAP documentation help for public sector:
http://help.sap.com/saphelp_erp60_sp/helpdata/en/f0/ca5716260211d28a430000e829fbbd/frameset.htm
All the necessary financial transactions for postings that involve assets are mentioned under: Recording Actual and commitment data -> Integration with Asset Accounting -> Example: Transferring Posting Data from Asset Accounting.
Additionally, please review the following note:
77726 Budget-relevant transaction types in FI-AA

- In PSCD or FI-CA documents, the commitment items should have the following Financial Transactions:
Financial Transaction 30: To be used for updating; to be set in Revenues/Expenses, Taxes, Discounts #
Financial Transaction 60: To be used in reconciliation accounts.
Financial Transaction 90: To be used in Bank / Bank clearing accounts and also in clarification accounts with Commitment Item Category 5.
Financial Transaction 50: To be used only in case of vendor interface in clearing lines without update.
More detailed information about the commitment item sorting that is relevant for these documents can be found in note:
686383 FM integration in contract A/R and A/P: Restrictions