,
The upstream system can transfer a posting date to FS-CD via the FS-CD payment plan interface. However, if the posting period in FS-CD is already closed, the debit entry terminates with an error message and the document cannot be posted. In this blog post I describe how in a customer enhancement the posting date can be overridden to the next open posting period so that the debit entry can be executed. read more...
,
In the classic, text-based FS-CD account balance there is a practical context menu with the most important commands. Unfortunately, this context menu does not exist in the ALV-based account balance. In this blog post I show how this context menu can be easily retrofitted. read more...
,
The accounting logic for the German fire protection tax differs considerably from the insurance tax, since the insurance company itself and not the policyholder is the tax debtor. In this blog post I would like to present different mapping possibilities and outline a solution how insurance and fire protection tax can be booked in FS-CD and evaluated on contract level. read more...
,
In order to process incoming payments, it is necessary to parse the payment notes transmitted by the bank by bank statement. FS-CD only offers the standard SAP pattern recognition with the wildcards + or *. In most cases this will certainly suffice, especially if depositors can be given standardized payment notes. However, there may be scenarios in which the payment notes cannot be standardized, for example, in the B2B area, if the payers use different accounting systems with different payment notes. In such a scenario, you quickly reach the limits of the SAP standard, and a hard-coded ABAP solution is doomed to failure from the outset because it is far too inflexible. In such a scenario, regular expressions are useful for pattern recognition. read more...
,
FI-CA Contract Accounts Receivable and Payable, on which FS-CD is based as an industry-specific enhancement for insurance companies, provides a two-level enhancement concept for industry-specific and customer-specific enhancements based on events. This makes it possible to add release-proof customer-specific logic to the system. But what happens if the requirements of several departments are to be mapped in the same system and in the same client? In simple scenarios with few events and few (two) departments, conflicts can certainly be solved by defensive programming and "department switches". With higher complexity, i.e. several departments and/or a high number of events, a more robust solution is required in order to avoid regression testing efforts in the other departments, especially for extensions for one department. read more...