Summary


The document provides technical details for building centralized SAP Finance Document validations that can be called remotely. The SAP validations are set up on the ECC system to validate a SAP documents before posting. there are various scenarios in which the ECC is the central instance for document postings/Payments however itself isn’t a UI system for document entry, it just takes feed of document from various interconnected systems.

This document provides a solution to build a centralized Finance validation which can then be used to call from any SAP or Non-SAP integrated systems. The situation is very specific to business need and mostly applicable for highly integrated environment consisting of more then one Document posting systems with a centralized ECC.

The Need

Mergers, Mobile Apps, Integrated systems, cloud services are the Buzz word in IT, there are lot of integration’s point behind all of these vast processes, Processes as they are much more than a mere technology and cater to a larger segment within a business processes.

In larger companies, where we have one of our ECC as a central instance and numerous technological setups connecting to it to produce an outcome, it becomes utter important to build a fully integrated system, whereby each system is talking in a real-time manner to others. This not only makes the integrated environment much more stable at a time but also helps to keep the customer trust (sic). The later is much more important for our ecosystem of providing flawless IT services. Having a centralized document validation not only decreases data footprint but also makes the maintenance cheaper, document entry faster and drastically decreases the time and resource utilization (man and machine) in re-validating documents at various stages of system interconnections.

The solution don’t apply to scenarios were the connected system are posting directly to ECC using BAPI, obviously that don’t require it as well, but for the cases whereby we consolidate our postings in a lot and post them on a single go or cases whereby the postings are happenings in a non-real time basis likewise using IDOCS, which decouples the fronted postings to IDOC travel and thereby imposes a fractions of delay or may be more.

The scenario


There are two business scenarios, one from a system merging and another from the point of generating a document


During my one of the merger implementation I come across a scenario of two ECC systems. Both were independent systems performing Procure to pay, end-to-end till the merger happened. Post merger one of the system has to give way to the other as a central payment system, but keeping the reporting’s and other downstream processing as it is. This means some of the relevant data (read postings) has to flow to the downsized (in terms of process) ECC for reporting’s and downstream.The replication of the documents was done using standard FIDCC IDOCs and is the reason the validation from the destination system were deferred to the time IDOCS were posted. This raised the need to call it earlier in time of posting at source system to avoid any IDOCS failures in receiving system..

As the reporting was separate so the validations for posting the same document in two different systems.

Another case is whereby we have a custom mobile applications for generating an invoices which are later posted onto ECC at a defined time in a day using file upload, Replicating the validations on to the mobile applications isn’t a lean method of achieving the design, so our best bet was to call the ECC validations into the mobile engine, this make the usability more transparent for the user and at the same time a document posted on mobile guarantees a unstoppable posting on ECC. This was a hit from validation maintenance perspective as well

The Solution

Before we start with the solution the expectation is that it’s a complete custom solution, so must be used based on the need basis, it can be tweaked on requirement basis and must be thoroughly tested.

We will be using the three major standard function modules which are mostly called by standard SAP while running the Documents validation check.

Overall document validation check: FI_VALIDATION_DOCUMENT

CALL FUNCTION ‘FI_VALIDATION_DOCUMENT’
TABLES
t_bkpf        =
t_bseg        =
EXCEPTIONS
error_message = 3
OTHERS        = 4.

Header validation check: FI_VALIDATION_HEADER

CALL FUNCTION ‘FI_VALIDATION_HEADER’
EXPORTING
i_bkpf        =

EXCEPTIONS
error_message = 3
OTHERS        = 4.

Item validation check: FI_VALIDATION_ITEM

CALL FUNCTION ‘FI_VALIDATION_ITEM’
EXPORTING
i_bkpf        =

i_bseg        =
EXCEPTIONS
error_message = 3
OTHERS        = 4.


In our case, we built a wrapper remote function to call all these three validation in a go; this will serve as a final validation call at the remote application before it can be posted into the SAP system. The wrapper FM acts as a centralized validation engine which can be called at various applications be it connected R/3 or non–SAP System.

Conclusion

The document provides a basic guide to achieve centralized validation for integrated Finance document postings. The information can easily be leveraged to build some more complex and integrated Finance scenarios with other SAP or Non-SAP systems.

Feel free to add you views/Ideas in comments.

New NetWeaver Information at SAP.com

Very Helpfull

User Rating: Be the first one !