ACDOCA is not made out of BSEG, BSEG is still a proper table and it stores entry view line items of the accounting document.
fa*gLFLXA (Along with BSIS, BSAS, BSID, BSAD, BSAK, BSIK, Asset tables, CO Tables and ML tables) and fa*gLFLEXT gets migrated to ACDOCA and ACDOCT respectively.
Main Finance tables in S/4 HANA are BKPF, BSEG, ACDOCA, and ACDOCT.
(Remember you can access BSEG as read-only, no updates or delete.)
SAP NOTES
1976487 , 2511926, 2156822, 2408083.
SAP Note 2156822 has a pdf attached for field mapping but it doesn’t have all fields mapping
The FIELDS which remain with BSEG & not available in ACDOCA
The fields ZTERM, ZBD1T, ZBD2T and ZBD3T are not available in ACDOCA. These fields are / remain available in table BSEG.
BSEG will continue to be used in Simple finance to manage open items. Though the universal Journal posted in ACDOCA contains all the characteristics of the line item but still open items management for all GL accounts will be managed through BSEG
we dont need to use BSEG to access data relating to Revenue and Expense.. this would be in ACDOCA and we could use BSEG to access AR and AP data
1. If you have any program/report written on any of the eliminated tables before S/4 HANA migration, you don’t need to change any selection criteria. All report shall work as it is. Of course some of the HANA compatibility adjustment need to be done in the programs and reports.
All previous written report shall work on migrated S/4 HANA system as all eliminated tables are available as view in S/4 HANA.
2. If you are writing any new report based on Entry view you should call BKPF and BSEG and if your report is little detailed )Ledger view then you shall call BKPF & ACDOCA.
Note: If you want to enhance the report with new tables then you may change the logic, and it would require functional testing as well as business testing as it is like you are writing a new report in S/4 HANA System.
SAP NOTE# 2431747 – General Ledger: Incompatible changes in S/4HANA compared to classic ERP releases
- Table BSEG containsnotall G/L postings any more in S/4HANA: The long term vision is that table BSEG will be used only for the following purposes:
– Open item management: Postings that are not related to open items will not create entries in table BSEG any more on the long run.
– Manual postings in FI: Postings that are performed in FI, for example using transaction FB01, will still create entries in table BSEG, because for such postings, the entries in table BSEG represent the original document.
As a first step towards this vision some posting processesdo not create entries in table BSEG any more.They only create entries in table ACDOCA instead. Postings without entry in table BSEG can be identified by BKPF-BSTAT = ‘U’. For example the following posting processes are affected:- Postings from Controlling like assessments or distributions (transaction KSU5, KSV5, KB11N,…).
Exception: If the posting is cross-company code then BSEG entries are created. - Foreign currency valuation (transaction fa*gL_FCV) and foreign currency translation (transaction fa*gL_FC_TRANS as of S4CORE 103).
For this transaction, the creation of BSEG entries can be switched-on again using BAdI BADI_FINS_FCV_BSTAT. For details see note2670040. - General Ledger assessments and distributions (transactionsfa*gLGA15,fa*gLGA35).
For those transactions, the creation of BSEG entries can be switched-on again using BAdI BADI_FINS_ACDOC_BSTAT. For details see note2400235.
The full list of posting processes that do not create BSEG entries any more are listed in note2383115.If you have programs where all postings, including postings with BKPF-BSTAT = ‘U’, shall be processed in BSEG format, then the source code of these programs needs to be adopted: The source code where the SELECT statements from table BSEG are performed, need to be enhanced: In addition to selecting line items from table BSEG, the line items for postings with BKPF-BSTAT = ‘U’ need to be selected from table ACDOCA. For mapping the result from structure ACDOCA to BSEG, the methodCL_FINS_ACDOC_TRANSFORM_UTIL->TRANSFORM_ACDOCA_TO_BSEG can be useful. Also methodCL_FINS_GET_BSEG->MAP_ACDOCA_TO_BSEG_EXT might be useful in some cases.
Since table BSEG was a cluster table in older ECC releases, in such older releases SELECT statements from BSEG required that the primary key is used in the WHERE-clause. Otherwise the performance would be very bad. So if in such old source code SELECT FROM BSEG statements shall be replaced, the function modulefa*gL_GET_GL_DOCUMENTcan be helpful: This function module evaluates both tables: ACDOCA and BSEG. This function modulerequires for example the document number and ledger as mandatory import parameter. The ledger will usually be the leading ledger which you can determine using function module fa*gL_GET_LEADING_LEDGER.Useful can also the the DDL sourceI_JournalEntryOperationalView. In transaction SE11 you can find this view with name IFIJRNLENTOPV. This view selects data from ACDOCA and joins fields from table BSEG and BSEG_ADD.
Remark: If you have several ledgers in G/L, table ACDOCA contains also postings that were done only into the non-leading ledger.
Such postings have BKPF-BSTAT = L. They have no entry in BSEG, instead they have an entry in table BSEG_ADD (and in ACDOCA).It isnotrecommended that you simply replace all your SELECT FROM BSEG statements by SELECT FROM ACDOCA statements without investigating the purpose of the individual SELECT statements. Reasons:
– Table ACDOCA does not contain all fields of table BSEG; so it could occur that the SELECT from table ACDOCA does not return all the info that you might require in your program.
– Assume the program that performs currently the SELECT from table BSEG also performs UPDATEs on the selected BSEG records. If you replace this SELECT so that it selects the data from ACDOCA and converts the selected data into BSEG format, this means that this logic pretends that BSEG entries exist despite this is not the case. As a consequence theupdates will fail if no BSEG entry exists.Nevertheless you might want to add some fields in table ACDOCA that are actually only contained in BSEG, for example field XREF1. You can add these fields as extension fields (in customer namesapce, for example as ZZXREF1) to table ACDOCA. The procedure is described in note2453614: You add the fields to includeINCL_EEW_ACDOCA and fill them using BAdIBADI_FINS_ACDOC_POSTING_EVENTS.
But it isnotrecommended to add all missing fields from table BSEG as extension fields to table ACDOCA: Reasons:
– Some fields of table BSEG are updated by FI programs, for example the dunning level (BSEG-MANST). In table ACDOCA the corresponding extension field would not be updated.
–If the document split is active, usually ACDOCA contains more entries compared to table BSEG because some line items are splitted. But this splitting is done only for the amount fields that are available in ACDOCA as standard fields. If you add amount fields from BSEG to ACDOCA as extension fields, for example field BSEG-SKNTO, the amount of those extension fields would not be splitted: Aggregating data that were selected from ACDOCA would yield too high amounts for such extension fields.
– In table BSEG the amount fields have positive sign whereas in table ACDOCA amounts can be negative!
For exmample the viewIFIJRNLENTOPV (see above) returns the amount fields from table ACDOCA, i.e. negative signs can occur.
- Postings from Controlling like assessments or distributions (transaction KSU5, KSV5, KB11N,…).
SAP Note 2297729 has additional info on the BSEG / ACDOCA usage. Apparently BSEG is used for the “entry view” of documents, as well as open item management. The Note points out that some postings do not require the “entry view” so they are only contained in ACDOCA (which is the “G/L view”). So ACDOCA has all documents, but not so BSEG.
BKPF: the functionality of the document header and line item tables has not changed under S/4: some fields are unique to the header and are not duplicated at every line of ACDOCA (or BSEG).
On new line item reports for S/4: transaction fa*gLL03H is an awesome new tool for aggregating and reporting on any field in BKPF, ACDOCA, and BSEG, as well as associated master data tables SKA1, SKB1, LFA1, and KNA1. Note 1671486 briefly describes these “FI Line Item Browsers”. Its highly suggested exploring this t-code and the others.
