Posting run detail information

Topic overview

In the Cockpit: Posting runs Controlling and Cockpit: Posting runs Financial Accounting applications, you can click on a posting run in order to switch to the Posting run detail information. However, it is also possible to directly call up the application from the Financials menu. In this case, select the posting run to be displayed via the value assistant for the field with the same name.

The following description refers to the Posting run detail information application, in which you can receive information on a posting run regarding its origin, status and voucher statistics. A posting run is created in the Financial Accounting, in the Asset Accounting, in the Controlling or in ERP, for example, through the following processes that are shown as origin:

  • Manual postings in Controlling
  • Generating planned values in Controlling
  • Manual postings in the Financial Accounting
  • Payment run
  • Bank statement
  • Manual postings in the Asset Accounting
  • Transfer of supplier invoices, customer invoices or inventory movements from the ERP
  • Transfer from the Asset Accounting

Every posting run has the following six status classes assigned, the status values of which deliver information on the state of the posting run.

  • General status
  • Transfer status
  • Processing status
  • Preparation status
  • Posting status
  • Cancellation status

For detailed information on the status classes and their status values, refer to the Posting run status grouping or the Cockpit: Posting runs Financial Accounting document.

The information on a posting run cannot be modified manually in this application. It can be modified only with the corresponding actions of the action role.

Application description

The Posting run detail information application displays detailed information on a posting run regarding its status, voucher statistics, etc. The information is summarized in a clear manner in various groupings.

The Posting run status grouping shows six status classes that are assigned to every posting run. The corresponding status values of the status classes deliver information on the current state of the posting run. Here you can see, for example, whether a posting run has been transferred, is pending processing or has already been posted.

Depending on the status of individual status classes, actions are available via the action role for the posting run. For example, you can accept a posting run or switch to the Cockpit: Entered postings application.

Under the Messages tab, you will find information regarding errors that occurred during the posting run.

The Posting run detail information application consists of an identification pane and a work pane.

Identification pane

The identification pane contains the fields that uniquely identify the posting run. In this case, this is the automatically assigned number of the posting run and the associated application (e.g., Financial Accounting, ERP, etc.). These fields are transferred as a default when calling up the application from the Cockpit: Posting runs Controlling or Cockpit: Posting runs Financial Accounting applications so that information on the posting run can be displayed directly.

In addition, information on the start and the last processing of the posting run are displayed.

Detailed description of fields:

  • Posting run – using the value assistant for the field, select the posting run for which the information is to be displayed.
  • Application – the application is used for specifying the affiliation of the posting run. Select the application here from the following settings:
    • Asset accounting
    • Controlling
    • Financial accounting
    • ERP
  • Last action –  this field contains information on the date and time of the last processing.

Work pane

The work pane of the application displays information on a posting run under various groupings. The information refers, among other things, to the current status of the individual status classes, to the origin, the statistics of vouchers of a posting run and to error messages, if any.

Posting run status grouping

This column indicates, for example, whether the posting run has already been processed, posted or canceled.

Detailed description of the fields of the grouping:

  • General status – the status of this status class shows whether the posting run is generally valid, invalid or locked.
  • Origin –  here, the origin of the posting run is displayed. For a list of the possible origins, refer to the field with the same name, for example, in the Cockpit: Posting Runs Controlling and Cockpit: Posting Runs Financial Accounting documents.
  • Accounting transfer status –  based on the status of this status class, the state of transfer to the external interface is documented.
    • In process – the transfer is being executed.
    • Closed – if the transfer of data to the external interface was successful, the status class receives the Closed value.
    • Not necessary – posting runs originating from the Financial Accounting (e.g., periodic postings, payment runs or currency revaluations) do not need to be transferred. The postings have the Not necessary transfer status.
    • Pending – the posting run is ready for transfer to the external interface.
  • Transfer timestamp –  this field displays the date and time of the transfer.
  • Processing status – during processing, the posting run is transferred from the external interface to the transferred posting headers (Pre Entry Header). During transfer, it is verified whether all master data of the transaction records (accounts, tax codes, currencies, etc.) can be determined in a technically correct manner. In this status class, the processing status is assigned as follows:
    • In process – the processing is being executed.
    • Closed – if no errors occurred during verification of the transaction data at the time of implementing the master data, the transaction records are entered in the Pre Entry Header as Closed.
    • Flawed – if not all master data can be determined correctly, the transaction records of the posting run are entered in the Pre Entry Header as Flawed.
    • Not necessary – for posting runs originating from the Financial Accounting (e.g., periodic postings, payment runs or currency revaluations), the processing takes place automatically. The posting runs have the Not necessary processing status.
    • Pending – the posting run waits for being transferred to the Pre Entry Header.
  • Processing timestamp –  this field displays the date and time of processing.
  • Preparation status –  in this status class, the state of preparation of posting runs is documented. Through preparation, the posting runs are transferred to the posting dialog (Entry Header and Entry Item). Only posting runs with the Closed processing status are taken into account. In this status class, the preparation status is assigned as follows:
    • In process – the preparation is being executed.
    • Closed – if no errors were found when transferring to the posting dialog, the posting run is identified as Closed.
    • Flawed – errors were found when transferring to the posting dialog. The posting dialog is identified accordingly as Flawed.
    • Pending – the posting run waits for being transferred to the Entry Header and Entry Item.
  • Preparation timestamp – this field displays the date and time of processing.
  • Posting status –  despite having the correct master data, the postings of a posting run can be flawed. In the course of other verifications, it is determined whether all required data per posting (specification of cost centers, cost units, etc.) are available.
    • In process – the posting run is in the dialog processing.
    • Closed – this posting run is successfully posted.
    • Flawed – errors in postings were found when posting the posting run. These postings must be corrected manually in the posting dialog.
    • Pending – the posting run waits for being processed in the posting dialog.
  • Timestamp posting –this field displays the date and time of posting.
  • Cancellation status – the status class documents whether a posting run is canceled, for example. A posting run can be canceled when the preparation status is Closed and the posting status is either Flawed or Closed.
    • Not canceled
    • Canceled
    • Canceled with errors
    • In process
    • Noncancellable
  • Cancellation timestamp –  this field displays the date and time of cancellation.
Statistic generated vouchers grouping

In this grouping, you can find out, for example, how many generated vouchers, incorrectly generated vouchers or transferred generated vouchers are included in a posting run.

Detailed description of the fields of the grouping:

  • Total generated vouchers – this field contains the count of all generated vouchers of the posting run.
  • Processed generated vouchers – this field contains the count of the generated vouchers that have been processed.
  • Flawed generated vouchers – this field contains the count of incorrectly generated vouchers.
  • Transferred generated vouchers – this field contains the count of the generated vouchers that have been transferred.
  • Invalid generated vouchers – this field contains the count of the generated vouchers that are invalid.
  • Deleted generated vouchers – this field contains the count of the generated vouchers that are deleted.
Statistic vouchers grouping

This grouping indicates, for example, whether and how many posting vouchers
are included in this posting run.

Detailed description of the fields of the grouping:

  • Total vouchers – this field contains the count of all vouchers that are included in the posting run.
  • Posted vouchers – this field contains the count of posted vouchers that are included in the posting run.
  • Flawed vouchers – this field contains the count of the vouchers for which errors were found during posting of the posting run.
  • Deleted vouchers – this field contains the count of all deleted vouchers that are included in the posting run.
References grouping

This grouping shows the relationship of the posting run with other posting runs.

Detailed description of the fields of the grouping:

  • Original posting run – this field displays the original posting run number.
  • Assigned posting run – this field displays the posting run number that is assigned to this posting run.
  • Canceled posting run – this field displays the posting run that canceled this posting run.
Origin objects tab

Under this tab, it is indicated whether an original voucher is processed by the posting run.

Messages tab

If a posting run is incorrect, you can view all errors in a table under this tab.

ColumnExplanation
Sub systemThis column contains the application area of the incorrect posting run, e.g., Financial Accounting.
Posting numberThis column displays the voucher number of the incorrect voucher from the posting run.
ItemThis column displays the line item number of the incorrect voucher from the posting run.
Message classThis column displays the message class of the error
for this posting run (e.g., application area of the error).
Message number This column displays the message number of the
error. This is unique in combination with the message class.
Text This column contains explanatory text of the error
message.
Detail If you move the cursor to this column, you will receive a detailed representation of the error.

In the Posting run detail information application, the following applicationrelated actions are available, depending on the status:

  • Convert and post
  • Accept
  • Cockpit: Transferred posting headers
  • Cockpit: Created postings
  • Cancel posting run
  • Repeat posting run
  • Release
  • Block
Convert and post

As far as the status of data transfer allows, you can convert and, at the same time, post the posting run in the displayed dialog immediately or in a batch operation. It is also verified whether all master data of the transaction records (accounts, tax codes, currencies, etc.) can be correctly determined in technical terms. Vouchers generated without errors are transferred to the posting server. If the data are incorrect, no posting will take place. The errors are logged and must be corrected before they are posted.

Accept

With this action, a dialog opens where you can accept the posting run with specification of the Immediately or In batch operation conditions, as far as the status of data transfer allows. It is also verified whether all master data of the transaction records (accounts, tax codes, currencies, etc.) can be correctly determined in technical terms, however, without starting the posting immediately in case of flawless vouchers. If errors are found, they are logged.

Cockpit: Transferred posting headers

With this action, you will proceed to the Cockpit: Transferred posting data application. The posting run is transferred as a default in order to directly display the information included in the record. In this application, only posting runs with the Closed transfer status will be displayed. In this cockpit, you can use the [Generated vouchers] action, depending on the associated application, in order to switch to the Generated items Financial Accounting or Generated items Controlling applications, for example, in order to exchange flawed data for correct data.

Cockpit: Created postings

Depending on the associated application (Financial Accounting or Controlling), you can use this action in order to switch to the Cockpit: Entered postings Financial Accounting or Cockpit: Entered postings Controlling application. In this application, you will gain an overview of the created postings of the posting run and, for example, you will be able to correct every single record with the [Post] action for a flawed posting run (the Flawed posting status).

Cancel posting run

With this action, the posting run including a posting text and a posting period is canceled. The original voucher is not canceled, but a cancellation voucher is generated for this posting. A posting run can be canceled only when the preparation status is Closed and the posting status is either Flawed or also Closed.

Repeat posting run

With this action, you can repeat the posting run immediately or in a batch operation. However, the precondition is that the posting record is canceled.

Release

With this action, you can release the blocked posting run. After that, the posting run can be processed with the corresponding actions of the action role in this application or in the Cockpit: Posting runs Controlling or Cockpit: Posting runs Financial Accounting applications.

Block

With this action, you can block the posting run. A blocked posting run must not be processed with the [Convert and post], [Accept], [Cancel posting run] and [Repeat posting run] actions.

Customizing

The Posting run detail information application does not need any specific settings in Customizing.

Business entities

The following business entity is relevant for the Posting run detail information application that you use, for example, in order to:

  • Assign authorizations,
  • Set up activity definitions or
  • Import or export

Interface definition

com.sem.ext.app.fin.general.obj.InterfaceDefinition

The business entity is a part of the following business entity group:

com.sem.ext.app.fin.general.OrderData

Authorizations

Authorizations can be assigned by means of authorization roles as well as through a content-based authorization (by assignment to organizations). The authorization concept is described in the Authorizations article.

Special capabilities

The Posting run detail information application has no special capabilities.

Organizational assignments

If the Content-based authorizations function is activated in the Customizing application, a person can only use the Posting run detail information application if an organization that is linked to at least one of the following organizational structures has been assigned to him or her in the partner master data:

Special features

The Posting run detail information application has no special features.

Authorizations for business partners

The Posting run detail information application is not released for business partners.

Czy ten artykuł był pomocny?