us specific sap fico

Upload: prasad-tatikonda

Post on 04-Nov-2015

118 views

Category:

Documents


7 download

DESCRIPTION

SAP FICO USA specific requirements

TRANSCRIPT

ContentsLockbox process1FAQ2Payment advice processing3Configuration3Lock Box Configuration5Automatic Posting from lockbox6Customer Master Data8Customer Invoice Posting9Lockbox file processing10Notes14Payment methods in USA16Tax process USA16

Lockbox process

OverviewA company can create accounts called 'lockbox' at its bank (or banks) that act as payment collection accounts for customer payments. The company then informs their customers that all open item payments for their accounts must be submitted to one of the established bank lockbox accounts. The bank collects these payments along with the customers' remittance information that indicates what open items the customer payments intend to clear. Data entry clerks at the bank manually enter the information into an electronic file for transmission to the company to which the lockbox account belongs. These files are typically transferred nightly to the various lockbox owners (companies). The files adhere to one of two standard banking industry transmission formats: BAI, BAI2 (Bank Administration Institute).Advantages of LockboxFollowing are some of the advantages of using the lockbox:Manual Handling of checks can be avoidedChecks can be processed in time.Easy reconciliationClearing Errors can be avoidedDifference between BAI and BAI2BAI and BAI2 formats differ in their level of information detail. BAI does not separate out the incoming check line items by invoice subtotal reference. Instead, one check total amount simply has all invoices listed underneath it. Thus, in BAI format files, the entire check amount must match perfectly (or within configured payment difference tolerances) the total amount for all invoices listed. Otherwise, the entire check will enter into SAP as:an "On account" posting (if the payment and invoice totals don't match), or An "Unprocessed" posting (if no customer account and documents could be identified from the transmission).In these scenarios, your Accounts Receivable cash application clerks will have to perform manual application to clear payments against open items on the proper accounts.Conversely, BAI2 splits the check total into separate invoice references and associated payment amounts. Thus, within a large batch, BAI2 format files will allow a "Partially applied" status in which some identifiable payments within the check total will be matched and cleared, others will land on account. As a result, your 'hit rate' percentage of payment-invoice matching from each transmission is likely to be higher when using BAI2 rather than BAI formats.

FAQ What Bank will do?Bank Receives the payments, create a data file of the customer remittance information and payment amounts, and deposit the checks into clientbank account. On regular basis, ClientCompany receives this data file for processing to update in their accounts. What lockbox data file contain?Depending upon the choice of services with the Bank, the lock box file will contain information viz., Customer name, Customer Number, Customer MICR number ( Bank routing and AccountNumber), Check amount, Invoice number, Payment date, Payment amounts and other information. What is the Lockbox Data Flow?Customers send their payments to a lockbox. Then bank collects the data and sends (either through EDI 820 and 823 formats) to R/3 users EDI server (standard Process). The servertranslates the message using as standard EDI interface into an IDOC (Intermediary documents) and sends it to the SAP Server. What happens in SAP server?Once the message is received and stored in SAP table, a program is clicked (RFEBLB30 or FLBP transaction) to check the information stored in bank statement tables and create paymentadvices with Payment amount, invoice numbers and customer number.Payment advice processing Matching of customer open itemsThe lockbox program uses detailed information from the payment advice to automatically search and match customer open items. The document number on the payment advice is matchedagainst the document number in the customer open item file. Therefore, accurate payment data is necessary for automatic clearing to take place. Payment Advice StatusIf the checks were applied or partially applied, the advice is deleted from the system after processing. If the check was unprocessed or placed on account of customer, the advice is kepton file for further processing. Post ProcessingThe post process function entails reviewing the status of the checks applied through the lock box function. User must manually clear any checks that were on-account of customer or notapplied to customer account.The Lockbox overview screen details the number of checks in each category. Depending on the status of the check, the user determines what needs to occur to apply checks.-On account: If the bank keyed in the correct invoice number, the Lockbox Import Program posts the payment on account. In the post processing step, you access the paymentadvice and correct the document number and upon saving the changes, the post process function clears the open item, deletes the payment advice and sets the check status toapply.-Partially Applied: Checks that are partially applied may require further processing. Ex: Check may have paid 5 invoices, but one was incorrectly keyed. The first 4 invoices would clear. The payment amount for the 5th invoice would be put on-account and would have to be post processed to clear.-Unprocessed:Any payment that could not be identified either by customer MICR number (check) or the document number would remain Unprocessed. Once the payment isresearched and the customer and invoice is identified, it would be applied during post processing.Configuration1. Define House BanksSAP IMG -> Financial Accounting -> Bank Accounting -> Bank Accounts -> Define House Banks (Transaction Code: FI12)2. Define Lockboxes for House BanksSAP IMG -> Financial Accounting -> Bank Accounting -> Bank accounts -> Define Lockboxes for House Banks3. Define Control ParametersSAP IMG -> Financial Accounting -> Bank Accounting -> Business Transactions -> Payment Transactions -> Lockbox -> Define Control Parameters4. Define Posting dataSAP IMG -> Financial Accounting -> Bank Accounting -> Business Transactions -> Payment Transactions -> Lockbox -> Define Posting dataAfter preparing the lockbox file (for test purpose) execute the following transaction to test the lockbox configuration:FLB2: Import Lockbox FileFLB1: Post processing Lockbox Data

Create House banksA. Menu Path: Financial Accounting General Ledger Accounting Bank Related Accounting Bank Accounts Define House BanksTransaction Code: FI12

Under the house bank create Bank account from FBZP transaction code.

After creation of House bank and Bank account under company code, it should look like this in FBZP transaction code.

Lock Box ConfigurationA. Path: IMG Financial Accounting Bank Accounting Business Transactions Payment Transactions Lock box Define posting parametersT Code: OBAX

Select highlighted row and click on change item button.

Document Number Length:Field is only applicable for BAI recordA. Num. of doc numbers in type 6:Field is only applicable for BAI recordB. Num. of doc numbers in type 4: Field is only applicable for BAI recordG/L account Postings:Activate this indicator to make postings to your cash account in the G/L for deposits. Activating this field is recommendedIncoming Customer payments:Activate this indicator to make postings to A/R sub ledger in order to clear customer accounts and create residual postings. Activating this field is recommendedInsert Bank Details:Applicable for batch input session name that updates bank details of master records for customers who have either changed bank information or did not have bank information maintained for themG/L account posting type1 - Creates posting to G/L account for every check in the file2 - Creates one posting to the G/L account for entire lockbox file3 - Creates one posting to the G/L account for entire batchAutomatic Posting from lockboxI. IMG Financial Accounting Bank Accounting Business Transactions Payment Transactions Lock box Define posting dataOBAY

Destination:This field should contain the destination code the bank submits to you in your lockbox fileOrigin:This field should contain the your lockbox number (bank account) number at the bank

IMG Financial Accounting Bank Accounting Bank Accounts Define Lockboxes for House bankClick on first option

Customer Master DataTransaction Code: XD03Maintain Bank details in customer master data which bank will send in lockbox file

.Customer Invoice PostingPost one 600 amount customer invoice. Invoice will display in open state.T code FB70

Open the invoiceTransaction code: FB03

T code: FBL5N (Customer Report)Below report shows customer item and its not cleared.

Lockbox file processingSAP gives option of using one of the two standard algorithms for lockbox processing. A common misrepresentation is that one can create own algorithm which is not correct. We can only use the pen delivered by SAP. Program RFEBLB00 is the processing program. Documentation can be viewed for this program from SE38 transaction code. This program contains lot many user exits whether one can add any additional business logic.Two algorithms that are used are 001 and 003. If file contains checks that cannot be applied against specific invoice but for which customer account is known, SAP posts them on the customer account without reference to any specific invoice. Using algorithm 003, SAP distributes the check across open invoices, beginning at the oldest invoice and working its way forward until the check amount is fully distributed.File Import:A. Menu Path: SAP Easy Access Accounting Financial Accounting Banks Lockbox FLB2 Import.Transaction Code: FLB2Save the lockbox file attached with this document and modify the document number in file with open customer invoice.

Click on green execute button.

Click on back button.

Transaction Code: FLB1Enter Lockbox details and click on execute button

Select the one which contains data in file. For example if file contains 1123456 is second session name will be 1123456. Right click on 1123456 and select Process Checks options.

Right click on Session name and click on Process option.

Vendor Document Clearing ReportAgain view customer invoice it will be displayed as cleared from the payment received and posted via lockbox

Notes1)If you get below message, modify the following in file. Unique key for each lockbox file is its header record i.e. Destination, Origin name, Date and time. Modify the seconds part and rerun the file.

1)Sap file generation Use Test Lockbox Generation Programs RFEBLBT2 to generate BA12 format and RFEBLBT3 for IDOC format. These programs will generate customer open items and a lockbox file for processing. Utilize program RFEBKA96 to delete loaded test data2)Sample File Understanding100MANGDESTINMANGORIGIN1309031235572000000000000000000000056660011123557130903MANGDESTINMANGORIGIN666600200000600000110003900345205865100000002466600360191800000023 0000000060000000000076660041123557130903001000006000086660051123557130903000100000600009000000File content explanation with help of differnet Color Codes100000002=Check Number666= Batch ID1800000023= FI customer Invoice123557130903= Date & time in Header (i.e. first record) and Time & Date in below records.600000= Check/Invoice Amount depending on Row110003900345205865= Customer Master Record Bank details.3)Sample file of BAI2 program can also be generated from SAP directly on execution of programsSame can be downloaded and uploaded with just modification of document number else copy from below location100MANGDESTINMANGORIGIN1309031235572000000000000000000000056660011123557130903MANGDESTINMANGORIGIN666600200000600000110003900345205865100000002466600360191800000023 0000000060000000000076660041123557130903001000006000086660051123557130903000100000600009000000

Relationship between EBS and LockboxAssume on Day 1 company receives Lockbox file from bank and on Day 2 receives EBS file.Day 1When the bank receives a check from customer with remittance information its sends it in Lockbox file. Lockbox file when processed will generate below accounting posting Dr Bank Clearing account - incoming Cr Lockbox Clearing Account Dr Lock box clearing account Cr Customer account (customer sub ledger)Day 2when the check is cleared in bank, it appears in EBS. EBS when processed produces below accounting entryDr Bank Main GL Cr Bank Clearing Account - incoming

Payment methods in USA

1) ACH (takes 2 days to transfer funds. Electronic file generates to send file to Bank)2) Wire transfer (Transfer Funds immediately. Electronic file generates to send file to bank)3) Credit Card Payment

Tax process USA

Sales tax Vs Use Tax:The sales tax is imposed on retail transactions. It applies to all retail sales of tangible personal property, and in some states services, in the state. The use tax is imposed on consumers of tangible personal property that is used, consumed, or stored in this state. Consumers use tax applies to purchases from out-of-state vendors that are not required to collect tax on their sales. Sales and Use tax generally applies to most leases of tangible personal property. The sales tax and the use tax are "mutually exclusive", which means either sales tax or use tax applies to a single transaction, but not both.

Vertex:

It is a third party tax solution for SAP FICO. Usually it gets integrated with SAP system using RFC. It gives integrated solution for various kind of tax such as income tax, sales tax, consumer use tax, value added tax (VAT), payroll tax etc.It is tax compliance software which makes sure tax compliance for income tax, corporate tax, VAT, service tax, use tax and other types of taxes. It gets integrated with SAP FICO system and automatically calculates tax liabilities to government.

Data flow:

SAP Vertex dataflow

SAP VERTEX O - Series Integration:

We do need tax procedures and pricing procedures for integration.

Tax procedure: For this purpose, we need to create a new tax procedure based on SAP country templates with Vertex tax conditions. Tax procedure assigned to country for output and input tax.

Vertex tax procedure

Pricing Procedures:We can define new or use existing pricing procedure with Vertex defined condition types.

Tax interface configuration:

External tax interface is appended to receive and pass data between VAT O series and SAP.SAP code need to be changed to enable other countries to call the external tax interface.

Change:

Vertex O series and SAP interface component (SIC) must be installed for the SAP tax interface Remote function call (RFC). Establish the communication through RFC and transnational RFC.

RFC destination:

Program IDlinks RFC to SIC.

Vertex RFC destination

SIC:

SIC links RFC to Vertex O series.

SIC link RFC to Vertex O series

It helps automating tax solution for any organization. It can automate tax system as well provide accuracy and smooth processing. It automates mostly every aspects of personal property tax, corporate tax, compliance cycle and other management efforts. With vertex, its easy to get up to date tax data so an organization can stay informed about it. Moreover, it provides complete set of tools to help in consumer tax liability and audit purposes.

Vertex Q series:

We implemented SAP ECC 6.0 about 3 years ago, including all core modules, as well as SCM ICH , APO/DP and BW. As part of the implementation, we chose Vertex Q Series for the Sales Tax Jurisdiction and Tax rate determination functions since it was one of the SAP certified offerings available in the market.At the time of selecting the software, we had a choice between Vertex Q series and Vertex O series product lines. We were assured by Vertex that both these products were fully capable of meeting our needs. We were also told that the 'O' series implementation was more involved while the 'Q' series product was easily installed and implemented.We were on a very aggressive implementation schedule, due to various business considerations, including the fact that our business by nature is very seasonal and our window of going live were between the months of July through September, otherwise, we would have to wait a whole another year.

We started the project in December '07 and were to go live August 1, '08! In addition to Vertex, we had to also implement other packages such as Open Text Livelink, Paymetric PCI and also build custom interfaces to other legacy systems that would continue to exist post-SAP go-live. In addition, we had to interface a ton of EDI transactions as well.Given this backdrop, we opted to implement the 'Q' series from Vertex. As advertised, the install and implementation of this product were fairly straight forward. We did have some issues integrating with SAP, but that was mainly due to the SAP implementation team's inexperience in this regard.We went live on Oct 1, '08 and had a very difficult first 6 months thereafter as is quite common with any ERP implementation and especially with projects like ours, with such aggressive implementation times. We immediately started facing numerous issues with the Vertex Q series, almost all of them relating to US City/Zip codes that when entered on SAP Customer Masters / Vendor Masters or Ship-To addresses in Sales Orders returned 'No Jurisdiction Determined' error, even though these were either 'Actual' city names or 'Acceptable' city names according to the United States Postal Service official web site.We called Vertex support and each time, we were told that the cities in question were not supported in their database because those cities did not meet their 'criteria' for inclusion. They always also made it a point to tell us that the Q series was not an 'Address Verification' system, even though we were not using it for such purposes.Initially we asked users taking the orders to enter a suitable city for that zip code that was the one stored in Vertex for that zip-code and in the same county as the 'missing' city. However, we ran into problems with this because we had shipments going to the wrong place when the same street name existed in both cities!We then implemented a workaround via user exit and z-table to pass the actual city name to Vertex, for such instances and adding entries to this table as and when users reported new instances. This was manageable for a while, but over time, we are seeing more and more entries being added to the table as our company begins collecting taxes in more states.Recently we ran a listing of such missing cities in the Vertex database using a zip-code database we subscribe to for our Dealer location calculation and found almost 7000 missing cities that USPS considers Acceptable. We also found more than 100 cities that USPS terms as the Actual cities for those zip codes.We also discovered that the Vertex Q series only stores first 25 characters of the city name, even though SAP allows up to 40 characters and there are a number of cities in US / Canada whose city name exceeds 25 characters.We have sent this list to both Vertex and SAP. We had conference calls with Vertex , including personnel from their Research department and Product Development and while sympathizing with our problems and admitting that there is a gap in the core functionality, they have refused to add any of the cities in the list provided and also refused to add any expansion of the functionality to accommodate these cities. Instead, they are asking us to implement an address verification software (3rdparty) that will sit between SAP ECC and Vertex and provide Zip+4 codes that may find a hit in the Vertex Q series database. They do not have a solution using this approach that they can demo and have been very vague as to what kind of custom development will be needed to interface this additional software to either SAP or Vertex. Alternately, they want us to implement their O series product which would involve additional acquisition costs and would be a full implementation project, since there is no automated upgrade path from Q series to O series. We would need to use their consulting services to accomplish this as well.We have not heard back yet from SAP; our Rep tells us that the matter has been referred to Germany. He has also started talking about the Business Objects Address Verification services, leading us to believe that SAP will not be forcing Vertex to close the gap in functionality.We cannot be the only ones facing these issues and we feel quite strongly that the Q series should not be certified by SAP and Vertex should not be marketing this product for use with SAP.I would like to invite those of you who have experienced the same problems and would like to hear how you are handling this.