These RFAs, along with other functions provided by PaPM, such as allocations, calculations, joins, can facilitate various business processes of calculating values and immediately booking them as for instance Accounts Payable and Receivable.

The RFAs not only allow for postings within one company code but also enables cross-company postings, what might be interesting for entities with some affiliated company codes. In that case, as in SAP standard, the system posts a separate document with its own document number in each of the company codes. And let’s not forget that even postings between different SAP systems can be performed!

In this blogpost I am going to show you some basic information, how to use the RFA FI-AP and RFA FI-AR and also some small useful tips and tricks.

Configuration of RFA Finance Accounts Payable and RFA Finance Account Receivable

Database Connection and RFC Destination

As already mentioned in the previous blog posts written by my colleague and myself, the necessary condition would be to establish the RFC connection between SAP system(s) and PaPM. The RFC stands for Remote Function Call and is a standard SAP interface used to communicate between SAP systems. The connection needs to be set by SAP Basis guys, as it is considered as critical (SAP transaction SM59).

Once the necessary RFC set up has been configured, we need to define the destination system on PaPM side. In the On-Premise system we can do it at the environment level, in the Advanced tab. However, the creation of AP or AR might be addressed to different SAP Systems / Clients (RFC destinations). In that case, the RFC destination should be provided in the RFA function’s rules, either by mapping the component to the relevant field in the input function or hardcoded. The entry in the rule overwrites the entry in the environment.

In the Cloud you can set up the RFC connection either in the input table or it can be hardcoded directly in the RFA rule. There is no possibility currently to set up the connection on the level of the environment.

RFA FI-AP / FI-AR Configuration

Here is how to get started with the set up. In case of Accounts Payable and Accounts Receivable, you have a several possibilities delivered by PaPM.

Aside from the single RFA Finance Accounts Payable, corresponding to SAP FB60, which is the transaction used to post vendor invoices with no logistic background behind and RFA Finance Accounts Receivable, corresponding to FB70, used to post customer invoices, you can also choose the combined RFA Finance Accounts Payable/Receivable. As in SAP standard, the document type and the posting keys will be derived automatically by posting. The sign of the amount will determine the debit or credit side of the posting as well as the transaction type: Invoice or Credit Memo.

Input Tab / Input Function

The input function for the RFA FI-AP and RFA FI-AR might be a model table/view or result of any other function such as allocation, calculation, join, derivation, transfer structure. The data in the input function should contain the fields that will be mapped to the components of the RFA function.

Please see an example input function, where we store all fields necessary to create the AP / AR document:

If you intend to calculate some values like dynamically derived posting date or tax amount, you need to calculate it in the input function. In the RFA rules, you can use only the standard functions provided in the formula, data from the input function or hardcoded values. It is not possible to define own syntax directly in the formula box within the RFA rules.

Fields Mapping – the minimum necessary to be able to book the document

When you start populating or mapping the fields, the components marked as mandatory will turn green when populated and orange when not populated.

Rules tab for Accounts Payable:

Rules tab for Accounts Receivable:

Function Execution

You can execute the posting in test run mode (header-doc_status = 2) or in actual mode (header-doc_status = empty).

In test run mode, standard SAP validations will be performed upon execution, but no documents will be posted in SAP.

In actual mode, standard SAP validations will be performed upon execution, and when the provided inputs pass the validations, relevant documents will be posted in SAP.

One way to use the test / actual indicator, would be to set is as a parameter in the Process Template.

The parameter can then be used later on in the processing as a basis to populate the input function of the RFA, such as below:

In case the validation has been passed successfully, the document numbers created in the SAP system are sent back to the specific output field in PaPM to make reconciliation between PaPM and SAP possible. So please do not forget to define one output field for the SAP FI document number. To do this, you need to put one field in the action tab and assign it in the rules to component header-obj_key. In the example the technical field name is aligned with the standard SAP field name.

Result of the posting

The SAP FI document number written back to PaPM can be used in standard SAP transactions / reports to check the postings.

Cross-Company Code / Cross-system Postings

In some cases it is not possible to use standard SAP for cross-company postings or it is required to post cross SAP Clients or systems but you would like to keep the reference number as in the classic Sap cross-company posting. Such requirement can also be covered by the PaPM RFAs.
Let me present possible solution for such a business case:

The input function is in our case a Model Table. Company Code 0001 is going to invoice Company Code 1000. As the process will be initialised by Accounts Receivable, it is expected to keep the system number, company code number and created FI document number in field ‘Reference’ in the created document for Accounts Payable.

Please have a look at the modeling flow below:

This is our input model table. The field Partner Company Code will be used as Look Up predicate to derive the created FI document number.

Firstly the AR will be posted, then in the Join, the already created document will be caught and written back in the input for AP in a new field together with RFC destination and invoicing company code.

Of course, just one function will be executed. In our example it will be RFA ‘Post AP Entries Blog’. This function will trigger all other activities in that chain. So in the result we see the AP document which has been created and the reference to the AR document.

Let’s check the results in SAP via transaction FB03 Display Document:

Classic Cross-Company Posting

Cross-company postings are also possible, where the system posts a separate document with its own document number in each of the company codes. Intercompany postings (also called cross company code transactions) occur in the system when a single transaction is posted to one or more company codes (this must occur on separate line items). For these postings, an intercompany clearing (payable/receivable) account must be maintained in SAP (SAP standard configuration -> transaction OBYA).

If the configuration on SAP side has been set up properly, you can start to define the input function and the RFA function. The most important fields are of course the company code in the document header and the company code in the document line item.

After successful execution, based on the SAP document number written back to PaPM you can check the documents posted via SAP transaction FBU3 (Display Cross-Company Code Transaction).

The post Post Vendor and Customer Invoices Using PaPM’s Remote Function Adapter Finance Accounts Payable and Receivable first appeared on ERP Q&A.

We live in a dynamic world today that is ever changing. Companies are acquiring other businesses or are being acquired. All of these acquisitions present challenges for all companies involved. One key change that frequently occurs is when the parties involved have different fiscal years. This blog will discuss a change that involves including a 13th month in the transition fiscal year. I will look at the FI side of this first and then close the blog with a look at how it impacts Fixed Assets.

In this example we have the acquired company with a 4-4-5 week cycle for it’s 12 month fiscal year. So instead of closing each period at the end of a calendar month, each period is open 4 weeks, 4 weeks and then 5 weeks. At the end of the 5 week period you repeat the 4-4-5 cycle. The acquired company’s fiscal year closely resembles a calendar year fiscal year. The acquiring company, in contrast, has a fiscal year that runs from February 1 of one year through January of the following year. Because of this January of the new year was combined with December of the prior calendar year just closed to form a one time 12th period that actually includes 2 months.

The changes all begin with transaction code OB29.

What you see here is the original 4-4-5 week fiscal year alignment. The month and day are the actual calendar month and day the period closes. Then you identify which period it is and leaving a 0 in the Year Shift column means that the calendar year and Fiscal Year are the same. When you end on a week instead of the actual month end day you get the oddity in the last row of this table. This table needs to be completed through the end of the calendar year. Since their FY ended on December 26 for 2021 that means you have 5 calendar days to account for so you add the last line.

This last line includes every day after 12/26/2021 through 12/31/2021 but notice it is Period 1 and the +1 means that the Period 1 is part of FY2022(2021 + 1)

Now let’s take a look at the changes that need to be made in this table. I will show you a “new” FY2021 set up along with Fiscal Years 2022 and 2023.

So you go back into OB29 and select the Fiscal Year Variant and then click on Periods.

The new set up for FY2021 now includes the whole month of December in period 12. Now let’s look at FY2022.

Here we see some oddities when a business decides to break down periods by weeks instead of calendar month. Saturday is the day they are using as the end of the week. Here are the keys to notice in this screen print

1. January is actually Part of period 12 for FY2021, remember this was a transition year so FY2021 period 12 includes weeks in both December, 2021 and January, 2022.
2. During the year you have 3 calendar months when the first Saturday of the month is actually the end of the period for the previous month.
3. For 2022 it just happens that Period 11 ends exactly on December 31st. This won’t always be the case.
4. Period 12 2022 is not seen on this screen because period 12 for FY2022 is calendar month January, 2023.

Now let’s look at one more year, FY2023, because it’s not impacted by the transition year of FY2021.

One more time let’s look at the key points in this screen shot.

1. Now you see that January through 01/28/2023 is actually period 12 for FY2022
2. This time we only have 2 calendar months when the first Saturday of the month is the end of one fiscal period while the last Saturday of the month is also the end of a period.
3. Notice Period 11 ends on 12/30/2023 as a result 12/31/2023 is actually the first day of period 12 FY2023.

At this point I’d like to mention how this impacts the period in the MM Module. When you open a period with MMPV in the MM module whatever period is open, it’s linked directly to the same Fiscal Period in FI. For example, documents that are post in January, 2022 post to Period 12, FY2021. So as long as the material movement falls within a legitimate date range it will post to the same Fiscal Year and Fiscal Period as the FI documents.

In the final piece to this I’d like to cover how it impacts Fixed Assets. First and foremost in the year of transition you may need to post “unplanned” depreciation so first make sure you have automatic GL Account assignment set up in t-code AO90 for “Unplanned depreciation account assignment” section.

This is required because posting depreciation with t-code AFAB takes the annual amount of depreciation and divides it by 12 for straight line depreciation. In this example a 13th month was added to FY2021 so I had to account for that extra month of depreciation. To account for the additional depreciation one needs to use t-code ABAA and post “unplanned” depreciation. So it’s a three step process.

1. Execute AFAB for the normal depreciation run
2. Post the unplanned depreciation for the additional fiscal year period
3. Re-run AFAB for the period using the “Repeat” mode.

Here is an asset acquired in period 11 FY2021 that was handled this way at the end of FY2021.

Using AW01N you can view the results. The planned depreciation amount was $277.78 per month. You can see here that Period 11 & 12 depreciation was post as Ordinary Depreciation while January, 2022 Depreciation was post with the ABAA as “unplanned” for the same monthly amount. Now look at the Comparison Tab in AW01N:

The key here is that the Net Book Value is reduced by both the Ordinary Depreciation and the Unplanned amounts so the timing of when the asset will be fully depreciated will stay the same as expected without the Fiscal Year change.

This process has proven to be very successful for when a Fiscal Year Change has involved extending the transitional fiscal year.

The post Change to a new Fiscal Year first appeared on ERP Q&A.

A letter of credit or LC is a document issued by the importer’s bank (opening bank) on importer’s behalf. Through its issuance, the exporter is assured that the issuing bank will make a payment to the exporter for the international trade conducted between both the parties.

The importer is the applicant of an LC, whereas the exporter is a beneficiary. In an LC, the issuing bank promises to pay the mentioned amount as per the agreed timeline and against specified documents.

A guiding principle of an LC is that the issuing bank will make the payment based solely on the documents presented to it by the exporter or the exporter’s bank and they are not required to physically ensure the shipping of the goods. If the documents presented are in accordance with the terms and conditions of the LC, the issuing bank has no reason to deny the payment.

2. Importance:

A letter of credit is beneficial for both the parties as it assures the seller (i.e. exporter) that he will receive his funds upon fulfillment of terms of the trade agreement and the buyer (i.e. importer) can show his creditworthiness and negotiate longer payment terms, by having a bank backing the trade transaction.

3. Process:

• Issuance of LC

After the parties to the trade agree on the contract and the use of LC, the importer applies to the issuing bank to issue an LC in favor of the exporter. The LC is sent by the issuing bank to the advising bank. The latter is generally based in the exporter’s country and may even be the exporter’s bank. The advising bank (confirming bank) verifies the authenticity of the LC and forwards it to the exporter.

• Shipping of goods

After receipt of the LC, the exporter is expected to verify the same to their satisfaction and initiate the goods shipping process.

• Providing Documents to the confirming bank

After the goods have been shipped, the exporter (either on their own or through a Freight Forwarder presents the documents to their advising/confirming bank.

• Settlement of payment from importer and possession of goods

The advising/confirming bank (i.e. bank of exporter/seller), in turn, sends the documents to the issuing bank and the amount is paid, accepted, or negotiated. The issuing bank verifies the documents and obtains payment from the importer. It sends the documents to the importer, who uses them to get possession of the shipped goods

4. Scenario:

User has a scenario of import of goods through LC. For this purpose, user approaches a bank to pay on their behalf to the exporter. Initially user completes the process of PR and PO then asks the import department to generate the LC request from the bank and after the agreement of both the parties (Importer and Exporter) bank opens the LC. After the completion of LC process exporter shipped the goods and sends the original documents to the advising bank then advising bank sends all relevant documents to the importer’s bank after the payment. Eventually the user withdraws the documents from the bank after payment from their bank account. Currently they don’t book the foreign supplier invoice but for audit purposes they record stock in transit in period end closing activity.

5. Solution:

In SAP we follow the following menu path to map in system:

Purchase Requisition → Purchase Order → LC request → LC opening → LC Document Retire→ Foreign Vendor Invoice → LC Bank Payment to Foreign Vendor → Stock In Transit → Goods Arrived at port→ Invoice & Payment of local Vendors → Goods Receipt

In our scenario we will take the example of LC opening of USD 3000 with reference to the Purchase Order

• LC Start Date 01.09.2021
  
• LC End Date 01. 04.2022
  
• Shipment Period 01.2022 to 31.01.2022
  
• Purchase Order 4000000005
  
• Presentation Date 01.01.2022
  
• Payment Date 31.01.2022

Step 1: Creation of PR:

When a need or a will of material arises, user will create the PR for the material.

Step 2: Creation of PO:

With reference to the PR, user will create the PO and map all the condition types of Import/Local in the purchase order i.e. Freight, Warfare, Custom Duty etc.

Step 3: LC Request:

Once the Purchase order is made import user will request the bank to open the LC. User will enter all the relevant information in the system in T-Code (FTR_CREATE) i.e. Treasury Partner Information, Amount of LC etc.

LC Request Created in system Transaction #200000000000029

Step 4: LC Opening:

After the opening of LC, bank generates the LC number with start and end dates of it. Every detail which is mentioned in the LC opening form user will edit the transaction number# 200000000000029 in T-Code FTR_EDIT.

Transaction Number: Key which uniquely identifies a financial transaction within a company code.

Purchase Order number is inserted in the field given from where we can easily extract the LCs against One Purchase Order.

Step 5: LC Acceptance:

After the acceptance of LC user will use the T-Code FTR_EDIT to change the status of LC /Transaction Number from draft to accept. Once the user give acceptance to the LC system generate the contingent liability in the system.

Accounting Entry for Contingent Liability

Dr: Technical Clearing A/C XXX

Cr: Contingent Liability XXX

To create the contingent liability user will use the T-Code TBB1 for the acceptance and record bank’s liability.

Note: User can change the payment date before the settlement

Step 6: LC Settlement:

After Receipt of LC, the foreign vendor/exporter expected to start the shipping process. After shipping of goods foreign bank (Advising/ Confirming Bank) pays the amount to the exporter on the presentation of the document. Then these documents send to the importer’s/User’s bank (Issuance Bank) than the bank obtains the payment from the user whatever the date may decide for payment.

By Using T-Code FTR_EDIT User will settle the LC after the acceptance.

User will use the T-Code TBB1 in month end or as per the need for the generation and posting of accounting entries in settlement.

Accounting Entries in System for Settlement:

In the below entry Technical clearing account created for LC noting has been knocked off

In the below accounting entry system generated an entry against the bank and accrued liability has been knocked off from the above Entry:

Step 7a: LC Acceptance of Payment

On the decided date of Payment system will generate the following accounting entry

System knocked off the accrued liability account/contingent liability and also created the acceptance of payment accounting entry:

Treasury Line Item Display( FBL5N)

Step 7b: Posting of Foreign Vendor Invoice:

User will use the T-Code MIRO to enter the vendor invoice with reference to the Purchase Order.

Step 7c: Payment to Foreign Vendor from Bank A/c.:

User will use the T-Code F-04 to clear the Vendor Payment from the treasury partner bank a/c. These two accounting entries will be done parallel.

Treasury Line Item Display after the payment made to the Foreign vendor from Bank

Line item View of Clearing Payment obligation from Bank to Vendor (Cleared Item)

Open Item the acceptance of payment which will be paid to the Bank

The payment which is still unpaid at the retirement of Document.

Step 8: Payment to the Bank A/c

User will use the T-Code F-31 for post payment .

Treasury Bank Partner will be paid from the outgoing bank GL account

Step 9: Recording of Stock in Transit

User books the stock in transit on closing activities from the T-Code F.19

Month End Closing Entry for stock in Transit

In the month closing activity system analysis the GR/IR and pass the accounting entry

Stock In Transit Dr 3000

Adjustment Clearing A/C Cr 3000

Note: Adjustment Clearing will be knocked from the other GR/IR accounts which is mapped with Inventory.

Reversal of the Stock in Transit

On the 1st of the next month the system pass the reversal as

Adjustment Clearing A/C Dr 3000

Stock In Transit CR 3000

Step10: Payment to Local Vendors/ Goods Receipt:

In the end of the process all the charges of import in the importer’s country will be paid and goods will be received as per the standard.

The post Letter of Credit/Import Process (Issuance) – Trade Finance first appeared on ERP Q&A.