I was a just a fish out of pond when I graduated from college with little knowledge about ERP software. I was thrown into this ocean of Enterprise Software from SAP. I started off as a ABAP Developer with a SAP Partner company, working on various SAP ERP modules for different vendors, learning different software, applications, services and systems.

And then I was fortunate enough to work for my dream company, SAP itself, where I had an opportunity to develop various products. Customer satisfaction was our primary goal. I was intrigued to learn about how the product could be tweaked according to different customer requirements.

Now I was understanding what enterprise software is all about, gradually also learning about different SAP products like customer relationship management, supply chain management, supplier relationship management, business warehousing etc, which I could relate to the real life scenarios, and that’s the beauty of SAP software. It is simple, understandable and could be tweaked to your business needs.

I had seen both the worlds, the service industry and the product development, I thought why not get into consulting now? I know what customers could ask for, and I know how the SAP software could be tweaked, and I knew what interests me having come across so many SAP products.

I figured Logistics was my area of expertise. And that is how I became a SAP Logistics Consultant. It is a whole different industry altogether, where you are constantly learning and keeping yourself updated with what is in and what is out in the industry. And it’s been a good journey so far with lot of learning. I am amazed to see how each and every industry functions differently, and how we have different products for different industry: oil and gas, logistics, manufacturing, etc. And SAP caters to all of this.

I still feel like a fish in the pond and having understood that the learning or growth never stops. And the day it stops, there is another consultant or product out there to replace you.

So my advice to all the aspiring SAP consultants out there, know what you expertise are, if you are from sales industry you could pick SAP SD or if you are from finance you could pick SAP FICO. There are tons of SAP products out there: SAP MM (materials management), SAP PP (production planning), SAP PS (project systems), SCM, SRM, CRM, EWM and what not. See what interests you, learn it, master it, and jobs will come your way.

This article by Jacqueline Dsouza took part in the joint contest, which SAP Expert ran together with Zinio.

As SAP Expert already wrote, there are several systems usually present in the SAP landscape. At a minimum, you should have Development, Test and Production.

In a green field SAP implementation project, there are some master data objects that you start to create long before a Production system may be installed. And these objects remain more or less static during the whole lifecycle of the system. I mean objects like GL Accounts, Profit Centres, Cost Centres, sometimes Internal Orders.

Some SAP configuration steps include these objects, for example automatic account determination. It means that it is very important to have these objects aligned between all the systems in SAP landscape.

Even if your project is not green field, it is important to have master data intact to run proper tests in Test or Development systems prior to moving changes to Production.

How can this be achieved?

Of course, you can ask someone to monitor all the changes and maintain the alignment of the systems. But this is not the way out, as you can understand.

There are SAP standard tools for that, specifically IDOCs. There are special types of IDOCs and even standard SAP transactions to distribute General Ledger accounts, Cost Centres, Profit Centres, Internal Orders, Banks.

Master Data Distribution

You can find them in the SAP Easy Access menu under Tools – ALE – Master Data Distribution branch. Here is a quick list of transactions for you:

• Banks – FI08
• GL Account – BD18
• Profit Centre – KE77
• Profit Centre Group – KE79
• Cost Centre – BD16
• Cost Centre Group – KAVB
• Internal Order – KOA1

As a prerequisite, you need to configure ALE between your systems. How? Talk to your Basis team, or ask SAP Expert!

SAP Expert would like to make some comments on how to use these transactions.

1. The direction of master data distribution depends on the stage your project is in. At the early stage, during implementation itself and soon after it goes live, it is easier to distribute from Development to Production. In a mature system, when processes are stable, it is better to distribute from Production to Development.
2. You can schedule distribution transactions to run periodically. That will allow automatic alignment of master data across the systems.
3. Don’t forget that IDOC may fail, so you also need to monitor incoming IDOCs in recipient systems, analyze the reasons for failure, and try to eliminate them.
4. Don’t forget that you need to distribute to at least two different systems, Development + Test or Test + Production, depending on the direction of your master data distribution. Schedule each transaction twice with a different Target System.
5. If you distribute Cost and Profit Centres, don’t forget that you also need to distribute Cost and Profit Centre standard hierarchies. Standard hierarchy technically is just a group – use relevant transactions.
6. You need to schedule distribution of Profit Centres to run before Cost Centres to avoid failures.

Do you want to know more about SAP Master Data distribution? Ask SAP Expert the question you’re after.

The company needs to pay its invoices in order to function properly. It also needs to record vendor invoices and payments in the accounting books and registers. SAP is a help here. Accounts Payable is an important part of SAP Finance.
Let’s look at the process of posting the invoice into SAP Finance. What are the options SAP gives you?

Enter manually in Finance

The most obvious way to post an invoice in SAP Finance is to do this manually. This is possibly the simplest way to process invoices. It works almost “out of the box” and requires minimal configuration. There is a range of transaction codes available, depending on the user preferences and company processes. Just a few of them:

• FB60 – Enjoy-transaction for invoice posting
• FV60 – Enjoy-transaction for invoice parking with future posting
• F-43 – “classic” transaction for invoice posting
• F-63 – “classic” transaction for invoice parking with future posting
• FB01 – “Swiss knife” in SAP Finance

Transaction FB60

Process the Purchase Order

If your company uses Purchase order processing, then you may process the invoice against the previously raised Purchase order. It may require PO to be approved and or goods or services to be accepted. It depends on the processes of your company. The whole process of invoice entry through the Purchase order in SAP is called “Logistics Invoice Verification”.
There are 2 transactions you should remember in that area:

• MIRO – Post the invoice
• MIR7 – Park the invoice

Transaction MIRO

Import IDOCs

IDOC, or intermediate document, is another method to enter vendor invoices into SAP. Of course, vendor invoice process is not the only application of this powerful tool called IDOC. SAP Expert has already mentioned another reason to employ IDOCs.
If you want to go this IDOC route, you need to think about the sources of your data. Several options are available here.

1. Process invoices in other systems. It may be the case that you process your invoices in another system for operational purposes. Then, SAP only needs them for recording. In this case, you can build an interface.
2. Receive from vendor. Your vendors may have implemented SAP or other IDOC-enabled ERP system. In this case, you can agree on the direct interface between two ERP systems. This avoids or minimizes manual operations. Even if your vendor cannot produce IDOCs per se, they may wish to send you XML or other type of files with invoice data. In this case, use SAP PI to transform this file into IDOC. Moreover, some countries in Latin America make this e-invoicing approach mandatory.
3. Create in your own system. It may not be truly vendor invoice, but some internal processes can benefit from intra-ERP IDOC invoice processing. Just to name two examples: intercompany billing and Stock Transfer Orders (STO) in Retail.

In the case of IDOCs, you have two flavours of the process. They correspond to two types of invoice processing mentioned earlier: Finance and Logistics. Depending on your processes, your IDOC message type can be either FIDCCP02 or INVOIC02.

Third-party vendor invoice management software

There are several vendor invoice management (VIM) solutions available on the market. Just to name a couple, Readsoft and Esker.
These VIM solutions vary in the functionality they provide, but just to name a few cornerstones in AP invoice processing:

• Scan the paper document
• Optically archive the image
• Optical Character Recognition (OCR)
• Manually verify OCR versus stored image
• Map data between OCR and SAP fields
• Initiate approval cycle
• Post invoice into SAP

Similar to IDOCs, these solutions support both Finance and Logistics ways to process invoices.

With this variety of ways to process invoices, it is no wonder that many companies use a combination of them in their systems. Which ones are in use in your SAP implementation?

For better or worse – and more often worse – passwords are required to do a lot of things on the Internet, and even in your home. And, of course, in the office, especially when we’re talking about ERP-level systems like SAP. For example, you need password for your network account and your SAP user ID. The higher “responsibility” of the user ID, more secure your password should be. I mean users like SAP*.

At the same time, cracking passwords has never been easier. It’s not just for experienced hackers any more: now even the general public can buy a ready-made cracking utility, or even download one free. There are even forums that give detailed instructions so you can learn how to use it. Some people have earned a lot of Bitcoins by sharing unused GPU/CPU cycles on their computers to crack passwords on a commercial basis.

One thing you can’t do is create an unbreakable password. In principle, despite all the salting and hashing and encrypting you or a website enforces, any collection of symbols you use as the sole key for protecting your digital asset (computer, website, whatever) can eventually be discovered by a determined cracker with good resources and lots of time. The best you can do is make the cracker need huge resources and nearly-endless time – in short, make it so tough it just isn’t worth the cracker’s time.

What that means is making the best use of randomness. There have been a good many highly sophisticated arguments within the mathematical brotherhood as to whether the concept of “random” can properly be applied to the distribution of a small (maybe even just a finite) set of symbols. I leave that to the mathematicians. What I mean by randomness in passwords is this: given any limited sub-sequence of symbols in your password, there is no logical way to derive the identity of the next symbol. That is the practical meaning of “random” in passwords.

That means a password cracker must use a brute-force attack to reveal your full password: every symbol in the word will have to be tested individually against all possibilities. There will be no short cuts available: no dictionary tables to consult, no help from any of the linguistic rules the cracker programs use, and even rainbow tables consisting of the hashes of millions of existing passwords won’t reveal the brand-new randomized one you just made.

Actually, creating a good brute-force-only password is the easy half of the problem – the difficult half is remembering it. You could simply take all possible symbols available on your keyboard (or as many of them as the site will accept) and line up a dozen or more of them you choose haphazardly. That would create a password that a brute-force attack with anything less than a supercomputer would require months to crack, because the difficulty is exponential: with 95 symbols available on a keyboard (upper- and lower-case letters, punctuation, other special characters), there are 12^95 possible 12-symbol passwords. That would take 12^95×11^95×10+95x… brute force tries to crack.

How will you remember your super-safe password?

Where will you write it down? And in a very practical sense, how will you know you haven’t made a typo while you’re entering it on a website? The answer is that if you choose your password well, you can make use of all the human memory resources you have, nervous and muscular as well as purely intellectual, to recall it. Try this:

Think of a song, a poem, a quotation, or any set of words that creates the familiar phenomenon of an “ear worm” – it just keeps running through your head, and it’s hard to ignore it. Make sure it has ten or twelve words, or nearly as many as you want to have symbols in your password (only “nearly” – we can even pad it out a bit).

Got it? Okay, take the first letters of the words and line them up. That has created the Level One randomness, which is the most important of all: namely that any letter in the series cannot be derived from the prior letters unless someone knows what the original song/poem/quotation was (and that means you might not want to use “To be or not to be”). Let’s take something from the 60′s, a line from the Rolling Stones:

Have you seen your mother, Baby, standing in the shadows?

I used to run the memory of that song through my head when some dippy little advertising jingle got stuck as an ear worm – drove the worm right out, every time.)

Now we go to Level Two randomizing, in which we line up those first letters to encrypt them: HYSYMBSITS. Since there are 10, we can leave it at that, but you will quickly figure out how to expand it. We will add to the randomness by using what seems like a really stupid form of encryption: no pattern at all in how we change a letter to its symbol in the password.

But if we randomly encrypt the first S to n and the second S to # and the third S to 7, how will we be able to reverse it and decrypt the password? The answer is, we won’t. We will never need to. The end result, for all we care, might come out eRn$eI#Lp7 – it really won’t matter. Even if some short pronounceable or otherwise identifiable logical sub-sequence accidentally appears it’s not really a problem, for that would only reduce the cracking time slightly.

By now you’ve probably figured out the secret: what we’re really doing is creating a set of keystrokes that we will enter while reciting to ourselves “Have you seen your mother, Baby, standing in the shadows?” at the rate of one word per keystroke. You will be amazed how quickly that becomes a routine process, blending motor and abstract memory together, and how perfectly it comes back after a long period of disuse. It’s physical, like remembering how to ride a bicycle.

By all means, do write it down and keep it somewhere safe. But if you use several different passwords, all formed in that same way, you can just keep a list of reminders: call this one Stones, or mother, or shadows – it will often be enough to rekindle the repeated memory and as you start typing, the whole routine will come back to you. What your password has become, in an operational sense, is a sequence of motor responses set to music.

The more you use such a password, the easier it is to remember it. Oddly, the more songs and poems and quotations you convert to motor typing memories the more of them you’ll find you can remember. You don’t have to master the recall capabilities of the ancient bards who could recite hours of epic stories, but you can learn from them: they set their tales to meter and rhyme to make it easier to remember – now you can do that with passwords!

Wow, we created a secure password. That’s a time to relax now. Let’s listen to good music!

Initially posted on Linux notes from DarkDuck

If you ask your business user what is the most powerful reporting tool, SAP or Excel spreadsheet, I can predict the answer. Most business users think that Excel is the most powerful tool to interrogate the data.

I will object. SAP has a very powerful reporting tool called ABAP List Viewer, or ALV for short.

Most of the users face ALV when they get reports from SAP – it is the common tool used in many SAP reporting programs to represent lists of data. This tool, of course, has an option to extract results into files. But what will most of the users do when they get data in the spreadsheet?

The most common business user will apply filtering and grouping functions in Excel, then sort the data in a certain order, and then most likely save or print out the report.

Stop! Why do this in Excel then? ALV has built-in tools for sorting, filtering and grouping data.

For example, let’s look at the report with a list of GL account line items, transaction FBL3N.

FBL3N flat list

Say you want to filter out the details of Cost Centre 5_1110, then group data per Cost Centre and period, and show only totals.

Start with filtering. Click the header of the Cost Centre column. There is a button with a funnel on the panel – click it and then set up the filter to exclude value 5_1110.

FBL3N filter criteria

Now click on the Document Date column header and do subtotals with the corresponding button on the panel. You may need to do a grand total first, if there is no total yet.

FBL3N subtotalled list

Now go to the menu and select item Settings – Summation level – Define breakdown. This will help you to remove all individual lines in the report.

FBL3N define breakdown

After this step, you only have subtotals in the list, no individual items.

FBL3N subtotals list

Is it the list you wanted? Now you can print it, or extract the output to spreadsheet for saving.

If you repetitively do the same operation with the list, why not save the layout using the Save Layout button on the panel? While saving, you can also keep filter and subtotals criteria.

FBL3N save layout

Next time simply specify the pre-saved layout on the selection screen of the report.

Of course, the example in this article is based on the functions of transaction code FBL3N. But I assure you that most ALV-based lists have similar functionality. You just need to find the option to customize the output layout.

Once you have done the layout configuration, train the business users! Make SAP do all the routine for the business user! They have an option to spend their time differently now, for example reading for more informative useful articles on SAP Expert!

PS. For more information about what you can do with ALV please refer to training course AC280.

Taxes in SAP are a very important part of functionality. It is a topic of interest for different segments of the SAP community: Finance business users, Finance functional consultants, Logistics consultants and so on.

From the functional viewpoint, the taxes’ configuration is quite simple. There is a Sales Tax section within the Finance part of IMG. Most of the configuration for particular tax codes you can do in the transaction code FTXP.

However, have you ever thought about how SAP stores the data for tax configuration? If you ever had to write an overview of existing tax codes in your system, then you probably have already thought about this.

The diagram below summarizes some of the tables and their relations for tax codes’ configuration in SAP. It also shows the fields you need to extract to get a simple report: Country, tax code, GL account and description. I must warn you that SAP Expert had to slightly simplify the diagram, excluding the tables that hold tax rates. If you need to get the rates, you need to add KONH and KONP tables into the overview.

I hope the diagram will be useful for the readers of SAP Expert. If you want to get a MS Visio version of the same file for a small fee, or have additional questions, please contact SAP Expert for details.

Tax Tables in SAP
(click to enlarge)

As companies have grown over the past several decades, the necessity for business process management (BPM) has increased exponentially. This need is the lifeblood of companies like SAP that deliver robust solutions for enabling companies to operate efficiently and in an organized way. Over time, enterprises have become increasingly more complex, further driving the demand for business applications and services that facilitate the management of corporate information and collaboration. Longtime SAP customers now face the challenge of extending their BPM investment to the personal devices central to daily life of the typical employee, a new necessity with a very high barrier to entry but nearly immeasurable ROI.

Few IT leaders will refute the benefits of going mobile, but even fewer will be able to outline a realistic plan for getting there. That’s where Capriza can help. Capriza’s end-to-end mobility solution for SAP customers is the simplest way to transform SAP desktop workflows into lightweight, HTML5 mobile apps (which we call “zapps”).

 Real Life Example

We recently assisted a large manufacturing company that needed to provide its hourly employees with a way to complete time sheets from their mobile devices, using SAP Employee Self-Service. With Capriza’s technology, which requires no coding, no APIs and no integration in order to create lightweight mobile apps, this company successfully designed version 1 of the app in a matter of days. The IT professionals managing the project quickly deployed the app to a test group of employees, collected feedback and made improvements. They then initiated a rollout of the app to a broader group of users, which included international employees and contractors. This company was successful from the beginning because the IT team had a particular SAP workflow in mind when it began designing the mobile app.

As with any Capriza customer, once the first app was well-received by the business users, IT came up with several other SAP workflows to mobilize and has begun working on those. The key thing to remember is mobilizing SAP begins with defining what business needs must be met through the mobile app.

Prizes for Capriza

Half of the battle involved in mobilizing SAP is becoming mobile ready, but with Capriza, you are already ready to go mobile just by being a user of one of SAP’s web-based technologies. For CIOs and IT Directors thinking, ‘There’s got to be a better way’ when evaluating native application development platforms and outsourcing options, Capriza should provide that light bulb moment. The technology certainly wowed the SAP TechEd attendees in Amsterdam when it won the HANA Cloud App Challenge in early November.

For particular elements of an enterprise mobility strategy, native applications and 6-month development cycles are absolutely necessary; however, for specific workflows on SAP systems, be them ERP, CRM or ESS, Capriza is the most effective way to achieve internal mobility.

This is a guest post by Kelly Fee, Product Marketing Manager at Capriza, www.capriza.com

by Kevin Ko

From my experience, dealing with SAP Testing is slower than a turtle with no legs.

All development teams around the industry struggle to understand what the impact of change will have on their landscape. People are unsure what to test and they fear that something may break in production. For this reason, business users and application managers often take the “test everything” approach. Not only is this approach a huge drain on resources and time, but I have found that it often has a higher margin for error!

“Test everything” assumes that our documented tests are complete and actually do test what’s affected by change. Customer experience shows this to be a false assumption. Tests must evolve in line with system changes. The only effective way to

• (a) know what should be tested; and
• (b) how the tests should adapt is to do a full impact analysis and use the results to guide focused risk-based testing.

This is where LiveCompare comes in to save the day. LiveCompare, IntelliCorp’s bread and butter software, replaces costly, time-consuming, manual testing processes with an automated impact analysis, that will drive answers to key testing questions in a fraction of the time, reducing the cost of application maintenance.

LiveCompare also identifies unused custom code. Retiring unused code can mean your SAP systems are cheaper to operate, easier to change and easier to test. Use LiveCompare to minimize the technical debt of custom code. LiveCompare’s industry standard complexity analysis identifies customizations that are spiraling towards unmanageable complexity. Complex code is more likely to suffer production defects.

With that in mind, LiveCompare 3.1, the latest version, will be getting a public GA release at the end of the year. The general theme behind LiveCompare 3.1 is “Complex Made Simple.” The three major features of this release are: simple “apps” interface, simple generation of dashboards and simple access anytime/any device. LiveCompare apps will be familiar to anyone who uses a smartphone or tablet.

From talking with the engineers working on this incredible software, I was able to snag a few previews. LiveCompare provides an app store from which users choose the apps they need to get their job done. Apps are shown on a home screen that is personalized to each user.

The beautiful dashboards elegantly summarize the detailed analysis. Apps and dashboards are available on any device such as an HP Slate 7:

LiveCompare apps are pure HTML. This means they run in any browser on any device at any time. Here’s another example, this time from an iPad:

For more information about LiveCompare, please visit IntelliCorp (www.intellicorp.com).

Kevin is a SAP expert. He has had extensive knowledge in SAP testing and Impact Analysis for over 5 years. Previously, Kevin has worked as a consultant and project manager for a global translation company.

The post about ABAP List Viewer saw very warm welcome in the SAP Expert’s community. As an additional help to those who wants to get more out of this powerful SAP tool, Martin Crangle offered his tutorial for end users. You can download this guide in PDF or DOC, or read it below, if your browser supports this feature.

I must warn you before you start reading the text below that it mostly relates to “core” SAP systems, such as SAP ECC, BW etc. It may not be relevant to new-wave technologies like HANA, Ariba, Fiori, mobile… you will understand why.

In my life, I have taken part in multiple SAP projects. These were greenfield full lifecycle implementations, roll-outs, extensions of existing functionality, reviews, or just one-off problem solving consultancies.

I have seen how SAP is implemented in different companies, and what the approach to SAP implementation is. Of course, it varies, but more often than not, it can be categorised into 2 types.

SAP is a Master

If a company tries to follow SAP’s standard business model, then it can be considered as “SAP is a Master” model. In this case, the company understands that SAP has accumulated best practices from all over the world in its 40 years history. In short, this model can be explained in a phrase “If the business process does not work properly in SAP, then the process is wrong and must be changed”. Of course, if the company follows this approach, then SAP implementation mostly means change management for the business. Lots of business processes have to be reviewed, analysed, streamlined and reorganized. It is a painful process, often a REALLY painful process. But as a result, SAP technical implementation becomes easy, almost like a walk in the park. The number of bespoke developments in the system is low, and the number of “tricks” and manual intervention in the process is low.

SAP is a Puppet

If a company considers itself as unique, then most often company management tries to use SAP as a tool to achieve other (not always business-related) goals. Subsequently, lots of existing business processes in the company migrate to SAP “as is”, without analysis and review. The approach is to use “SAP as a puppet” in users’ hands.

The most common explanation of why this happens is “our business processes are unique and they are our competitive advantage”. As a result, SAP implementation becomes a rodeo where consultants need to tame the users’ requirements and literally put a square peg into a round hole sometimes. The technical SAP implementation becomes a nightmare. It means lots of customer-specific developments, lots of manual steps in the process, lots of headaches.

Business users think that once they state their requirements as “it must be like this”, their part of implementation ends. It is not so. This approach backfires. Business users need to test and re-test the developments, explain requirements again and again to different team members. That is chaos.

Who is responsible?

You would be surprised, but sometimes either consultants themselves, or salespersons of consulting companies, are responsible for the chaos they create at customer side. Why?

Consultants may have not enough knowledge of existing SAP functionality or soft skills to convince the customer their best move is to follow the SAP standard logic.

Salespeople may have pressure from company managers to sell more ABAP developers to the customer, as they have a bench. Of course, nobody will ever confirm this.

How to fight this?

Even though you as consultant may not be responsible for the sales process, you may control what is happening on the project when you arrive there.

Let’s assume you have knowledge of company business and SAP functionality. You see that users press for the bespoke solution where a business process change may make SAP standard solution usable. How can you explain the users that they are wrong? Ask them to explain the reason. Very likely the answer is “because I need to send this report/spreadsheet/document to another person”, or “I am not responsible for another part of the process, there is a separate person to do this”, or “it was done like this since the Romans era, hence it is the only correct way”.

Do not be lazy; try to track the path and the use of report/spreadsheet all the way to the final point. Check what value the second person in the process adds. And then tell users (and their managers!) a story…

Once upon a time, there was a group of scientists. They took a box and put a dozen of rats there. Then they took a piece of cheese on a rope and started to lower it. As soon as rats started jumping for the cheese, all the rats were showered with cold water. Eventually, rats were trained that they should not touch the cheese until it reaches the bottom of the box.

Then, one rat was replaced with a new one, who was never showered before. Scientists started to lower the cheese, but… the new rat did not jump! One by one, all the trained rats were replaced with new ones, and none of new ones ever felt the cold shower. Nevertheless, no single rat jumped when scientists lowered the cheese. Why?

Because it was the rule out there!

It means that “it was done like this since Romans era” is not a proper explanation of the reasons. If there is a better way to achieve the business goals with SAP, it should be employed. Or users should find the real reasons (cold shower) to do things differently. SAP implementation is not for the end users’ convenience, but for the management decisions. The better the process – the better and cleaner the reporting to management gets – the better management decisions are.

What is the approach to SAP implementation in your company?

Taxes are an inevitable part of our life. Like death is.

The most common tax in the business world is value added tax (VAT), or sales tax. You have probably read the article that describes the difference between the two.

VAT or sales tax should be calculated on every sale the company makes. Even if the transaction is non-taxable, or taxable with a zero percent rate, you need to prove it first. You probably know that most cross-border sales are usually tax-free, that some customers don’t pay VAT thus VAT should not be charged on sales to them, that some products (usually books, food etc) have special low VAT rates.

How can you manage all this complexity?

SAP gives you a wonderful tool to calculate taxes during the sales process: pricing conditions, which are part of pricing procedures. Pricing conditions for taxes usually consider the following parameters:

• Country of the company
• Country of the customer
• Tax category of the customer
• Tax category of the product or service

For each of the possible combinations you can determine the tax code, which will bring up the tax rate for the particular item in the invoice. The rates and other details of tax code are stored in special tables in SAP.

Next, tax reports can show you tax and tax base amounts for each of the tax codes, together with the possible drilldown to the document level.

But is it mandatory to calculate VAT or sales tax in SAP for all transactions?

Of course not! It is not possible sometimes to ask SAP for this calculation.

Here is a short list of examples, where tax calculation happens externally.

Sales tax in the USA

There are so many “tax jurisdictions” in the USA, and their tax rates change so often, that it is impossible to catch up with all of the changes. In this case, special external systems (taxware) are there to help. If necessary, SAP can transmit their amount, ZIP code of the customer, date of the sale, and get an amount of tax to be added to the sales invoice.

Sales managed in external system

There are cases when companies manage all or some portion of their sales in external operational systems. The best examples are billing systems in telecoms, or highly specialized IT services systems. It is quite often that these systems calculate and produce the customer invoice. In this case, the external system is responsible for tax calculation. SAP is only a receiver of the information for financial reporting. There are different ways to organise the transfer: IDOC, batch input etc. However, whatever the transfer mechanism is, the SAP team needs to ensure that tax is transferred between the systems in the way it was shown on the customer invoice, and not re-calculated again.

Retail

Retail sales are one of the flavours of the previous point, but still worth separate mention. Effectively, retail companies manage their [retail] sales externally, through the Point-of-Sales (POS) system. Of course, the SAP ECC system has its own version of POS, which can use SAP functionality to calculate taxes. But it is more common to use 3rd party solutions for POS terminals. Each POS terminal then calculates VAT either itself, or through the permanent connection to the POS management system. Periodically, the POS management system sends the data to the special SAP POS DM (POS Data management) system. POS DM aggregates the data before the financial part of it is sent to SAP ERP system for financial records. Because both POS DM and ERP system are SAP-based, the most common mechanism on the last leg is IDOC.

As you can see, SAP ERP system receives the tax data from POS terminal through a number of intermediary systems. It is very important to test that tax amounts are calculated and aggregated correctly on each part of the journey.

Which system is responsible for the calculation of taxes in your company?

In the corporate world, many companies receive critical discounts from their vendors by paying their invoices early. Should the invoice be sufficiently large, one missed discount by an accounts payable clerk can offset months of small, positive gains.

Imagine a technological solution that greatly reduced the chances of a missed discount ever happening.

Automation carries a wide range of benefits for businesses. As illustrated in the following infographic, some of the benefits from automation revolved around improved accounts payable operations.

It was found that automation in accounts payable operations increased productivity by 30 percent. Automation also reduced the cost per invoice by up to 60 percent.

After all, a human accounts payable clerk can only handle so many invoices per hour on his or her own. Instead, machines are able to do most of the work automatically, with the accounts payable clerk functioning in a supervisorial role. That way, the discounts can keep on coming.

Thanks for checking out our latest infographic, and let us know if you have comments or questions.

© 2014 Dolphin

Each company needs to pay its suppliers. It is usually payments for vendor invoices. And, of course, company needs to account for its liabilities and payments.

Of course, SAP is here to help. It has options to generate payments without invoice registration, even without creation of a vendor master record. But this is a rare case. More often, payments are generated against invoices, which are posted on vendor accounts.

There are several options to post an invoice into SAP. Are there several options to pay the vendor?

Yes, there are.

Let’s list them, more or less trying to keep the chronological order.

Cash

You may wish to pay the vendor in petty cash. These are usually small amounts, but some processes may still require physical bank notes and coins to be present on the table.

SAP gives you transaction FBCJ – Cash Journal to register petty cash transactions, both incoming and outgoing.

Transaction FBCJ

Cash Journal transaction was deliberately made simple by SAP. It does not have any clearing facilities in it. If you want to clear petty cash payment against an invoice, you need to do so separately as a consecutive step, for example with transaction code F-44.

Cheque

Cheques (or checks like they call them in some countries) are now extinct in most of the countries where they were in use. But some countries like United Kingdom, India or USA fail to get rid of cheques time after time, because some of the wide variety of processes that people use in everyday life are dependent on cheque payments.

With SAP, you have the option to print out a cheque either with Automatic Payment Program (F110) or manually with transaction F-58.

Transaction F-58

When a cheque is generated, the vendor invoice gets cleared in SAP.

If you print out cheques from SAP, you are likely to need a printer of a special type with magnetic ink cartridge. Also, most cheques require a special MICR font to be used on them.

Letter of credit

Letter of credit is a bank instrument that allows both parties to be sure that the vendor is only paid when he fulfills the contract conditions. It is especially important in bulk international trade, where contract conditions are complex and amounts are large. Letter of credit itself is issued by a bank and sent to the vendor. Vendor sends back to the bank a confirmation of contract execution, for example Bill of Lading, after which the bank makes the transfer and charges the customer’s bank account.

As you can understand from this, you cannot generate Letters of Credit from SAP. What you can do though is to mark the vendor or a specific document as eligible for LC payment, thus avoiding duplicate payment by more usual methods. Once the bank informs you about the payment made, you can clear the vendor invoice via transaction code F-53.

Paper Payment order

You can generate a payment order for the bank, which can later be physically sent to the bank for execution.

SAP can generate payment order forms and send them to the printer as a part of the Automatic Payment Program (F110) process.

Normally, vendor invoice is immediately cleared in SAP when a payment order is generated. But there is a special configuration of APP that allows generation of payment orders without postings, thus without clearing. Bear in mind that if a payment order is generated against the invoice, this invoice can only be searched in the usual clearing transaction via a reference to that payment order.

Manual electronic transfer

You may transfer money to your vendor account electronically using the on-line facilities of the bank. There is always an option to make an individual manual payment.

Of course, you need to record that payment in SAP. Transaction F-53 is the best way to do so. It also gives you an option to clear the invoices if they are paid.

Transaction F-53

File electronic transfer

Most banks nowadays are happy to accept payments via files. It gives you and the bank an opportunity to process payments in bulk.

You can generate payment files via Automatic Payment program (transaction F110). Similar rules to clearing of original invoice that we mentioned in the Paper Payment Order section above apply here. There are different file formats in use. Some of them are bank-specific, some of them are country-standard, and some of them are standardized by global organisations (SWIFT, ISO). You need to agree on the file format with your bank.

Once the file is generated, you have several options of transmitting it to the bank.

• You can extract the file to your local drive and then upload to the bank software or internet site.
• You can run an automatic job to extract the file and move it to the location where bank software can reach it. In this case, you need to remember that payment files are stored in SAP in the logical filesystem TemSe. You need to extract them from TemSe first.

Direct Debit

Direct Debit is an option in some countries that allows vendor to charge customer’s bank account automatically. Of course, Direct Debit has to be set up first, thus informing the bank about customer consent for charges from that vendor.

If you set up Direct Debit for the vendor, you need to mark vendor master record or specific invoices from it so that these invoices are not picked up by a normal payment procedure. The most obvious way to do so is putting a Payment Block against the vendor or invoice.

Once direct debit is processed through the bank, you can clear invoice against the bank transaction using bank statement transaction FEBA or FEBAN, or using a universal tool like F-53.

Another option to deal with Direct Debits is not to register DD-relevant invoices in SAP at all, if your local legislation allows that. Once the charge is processed by the bank, you can allocate these charges directly to a P&L account.

IDOC

IDOC is a vehicle of data exchange between two enabled systems, or even within the same system. SAP Expert wrote earlier about usage of IDOCs for master data alignment and vendor invoice posting.

IDOC also is a more advanced way to transfer information between the computer systems of the bank and bank’s customer. To a certain extent, IDOC is another file format. We discussed the way to generate files from SAP earlier. The same rules apply here, with the exception that you don’t have an option to upload IDOCs manually to the bank software. Instead, you need to configure a communication channel between your SAP system and bank systems.

Using IDOCs, you can send to the bank not only the electronic funds transfer information. Some banks give you an option to send information for the cheque payment, thus outsourcing the printing function.

PAYEXT is the most used IDOC message type that can be used for data exchange.

With this many options to pay vendors, which are in use in your company? Maybe you have something to add to the list?

Accounts Payable is an important part of every company’s life. You normally need to pay your invoices in order to continue business.

There are several ways to register an invoice in SAP, as well as several ways to make a payment. But one important thing that happens between invoice and payment is time. You need to know when to pay your invoices, leaving your vendors happy to continue business with you.

Here we need to say that Accounts Receivable need to know similar information. Once you issue an invoice, you need to estimate when it is going to be paid. It helps you to keep relationships with your customer (don’t chase the debt until it is really due), plan your cash flow and so on.

SAP has a tool that helps you to make necessary calculations of due date both on customer and vendor sides. It is called “Terms of payment”. It usually consists of 3 major components:

• Baseline date, the date when the calculation begins
• Number of days (up to 3), when invoice has to be paid
• Early settlement discount percent (up to 2) offered on invoice.

Effectively, you may get up to two time ranges when invoice can be paid with a discounted value, and one day when invoice should be paid in full without being overdue.

Here we need to note that the vast majority of invoices use the invoice date as a base for the due date calculation. In other terms, the invoice may say “due within 10 days”, which means 10 days after invoice date.

But there is still a chance that you need to calculate the due date not as a number of days, but set it as a specific date in the month. Examples of business cases for this may be:

• Contractor who works on a per-case basis, and sends you separate invoices for each case. But the contractor expects you to pay all invoices for the month together, and treats this payment as salary.
• Supplier who sends you goods in a continuous flow, invoices each day/week/fortnight, but still expects one payment per month.

In other terms, you need to have the ability to set the due date on the invoice as a fixed date.

Is it possible to configure this in SAP?

Yes, and actually there are 3 ways to do so.

Configuration of Payment Terms in SAP is done on this screen

Configuration of payment terms

Let use an example in which you need to set your due date to be the 7^th of the next month.

Option 1

Set up the fixed date as “7″ and additional months as “1″ in section 1 of the screen. Leave section 3 empty.

Payment terms – option 1

In this case, system will calculate the baseline date in the document and set it as the 7^th of the month, following the one specified in section 2. For example, if your invoice is dated in December, but you physically enter it in January, the calculated baseline date will be either the 7^th of January or 7^th of February, depending on whether the radio-button shows “Document date” or “Entry date” respectively.

Because we left section 3 empty, the system will add zero days to the baseline date for the due date calculation.

Option 2

Set up the fixed date as “31″ in section 1, and “7″ as a number of days in section 3. Leave other fields in sections 1 and 3 empty.

Payment terms – option 2

In this case, system will calculate the baseline date as the last date of the month derived from the section 2 setting. If number of days in the calendar month is less than 31, the baseline date will be adjusted automatically to be the last calendar day of that month. The number of days in section 3 will be copied in the document and added to the baseline date to calculate the due date.

Option 3

Set up the fixed date to be “7″ and Additional months to be “1″ in section 3, leaving section 1 empty.

Payment terms – option 3

In this case, when you enter the document, system will set up baseline date as per rule in section 2. Then, it will calculate the number of days between the baseline date and the 7^th day of the next month, and put this value in the document field.

For the screenshot above, the document line item will look like this:

Sample document

Do you use fixed-day payment terms in your company? Which way do you set them up?

If you need help with understanding the Terms of payment configuration, or any other SAP-related question, why not ask SAP Expert?

SAP is a well established industry in the world nowadays. There are many companies that use SAP in their everyday life. But still there are many companies who implement SAP software anew.

You are aware that a SAP consultant should have certain skills. But having skills is not enough. You need to apply them properly. Because of the wide variety of SAP projects, skills need to be applied differently.

SAP Consultant on a project

Let’s look at different types of projects and what is required there.

SAP Greenfield Implementation: Improve

Greenfield implementation is when company migrates from some old ERP or accounting software to a SAP solution. This type of project is the most difficult for the consultant to handle.

On one side, there is a customer that has some established processes. They may not fit well with a SAP standard solution. Business users may have a strong desire to keep their processes, making SAP a puppet in their hands. The SAP consultant needs to use soft skills to persuade the user that the SAP solution is better.

Of course, in order to prove the point, a SAP consultant should know his own solution thoroughly. It means that he should be an expert in his own field, which may be very wide. Lack of knowledge of SAP functionality may mean trying to impose unnecessary changes to the company or SAP code.

The main slogan for the Greenfield implementation should be: Use the SAP project to improve pre-existing processes.

SAP Roll-out: Don’t Break

Roll-out projects usually follow Greenfield implementations. At this stage, a company’s template is extended to other companies of the Group, not covered by the initial implementation. They may be in different countries, or in different business areas, or both. At this stage, a SAP consultant should be very cautious about the requirements he gets from new users. They may request some significant changes to the existing SAP functionality or processes. When considering this, you need to assess the impact that changes make on production users. Sometimes it is better to have a workaround than to follow the requirement directly.

The main slogan of the Rollout should be: Don’t break what is working.

SAP Extension: More SAP

Enhancement projects usually follow the Greenfield implementations, Roll-outs, or both. This is when a company decides that the scope of the initial implementation was not enough, and wants to use more of the vast SAP functionality. SAP consultant at this stage should have a very deep knowledge of the new functionality that is involved, and should also have an ability to quickly understand the existing solution. The task here is to assess costs and benefits for the new SAP functionality the company wants to implement.

The main slogan of an Extension project should be: More SAP! More Functionality!

What project type are you currently working on?

Image by Nadezhda Malovechko, with owner permission

SAP Expert recently wrote about the mechanism that allows moving configuration objects between clients in the SAP system and between the systems themselves.

This mechanism, the Transport System, is used for almost all the objects in SAP. However, there are some exceptions that require “special treatment”. One of them is Tax Codes.

SAP Expert believes there are at present no SAP Finance-related blogs, sites, or other resources that have reference to the tax code transport procedure. It is now SAP Expert’s turn to write about it.

There are 10 simple steps that allow you to move tax codes between the clients and between the systems.

1. Run transaction code FTXP, specify country and create or change necessary tax codes, including their rates. Save your changes. Leave the transaction. Please note: you should only change the tax rate in the tax code if it has never been posted in the Production system. Otherwise you may face inconsistency in the reports.
2. Run FTXP again, specify the country, and then without getting into any tax code details (!) select menu Tax code – Transport – Export.
3. Include the tax codes in question in the Transport Request and save.
4. Move transport to the target client via SCC1 or transport system.
5. Open the client. You may need to ask the Basis team to do so. They usually know about this exceptional procedure for tax codes, so will be happy to help.
6. Run transaction FTXP in the target client, specify the country, and then without getting into any tax code details (!) select menu Tax code – Transport – Import.
7. Select your Transport Request and country, run the importing process. This generates a batch input session that will be executed immediately.
8. Run transaction SM35 and check that the batch input session finished without any error.
9. Close the client. You may need to ask the Basis team to do so.
10. Check tax codes and their rates. Yes, you need to do so after closing the client. This is to avoid the temptation of manual “adjustments” to the tax codes in the target client.

SAP Expert would like to add a small remark here. In addition to tax codes and their tax rates, you also need to ensure that assignment of GL accounts has also been imported in the target client. If for whatever reason GL account assignment has not been properly moved, go to transaction code OB40, select the relevant Posting Transaction (VST, MWS…), specify the Chart of Accounts and then choose a menu Posting Transaction – Transport – Entries in TR. You can move the GL account assignment between the clients and systems with the usual process. No “special treatment” is required for this change.

SAP is one of the largest software corporations in the world. It ranks at the same level as such giants as Oracle, IBM, Microsoft.

SAP mostly operates on the corporate market: its most widely-known software is its ERP system. Recently SAP also moved to in-memory database areas with HANA, and also acquired a lot of companies in mobile and other market segments.

One of the products that SAP offers is their database MaxDB. This is an entry-level database management system, compatible with their ERP product among other applications. There was a time when MaxDB was available under GPL license. It is no longer so, as of release 7.6.

However, SAP announced on the 1^st of April 2014 another strategic change in their licensing model. Not only MaxDB, but a whole set of other SAP applications, including ERP system, will be GPL-licensed.

If you are not aware what GPL license is, I can give you a simple example: this is the license that allows Unix, Linux and other software to be free and open to everyone. Free as a beer and free as freedom.

SAP Expert welcomes this change and hopes that SAP and SAP eco-system will only benefit from this wise decision.

Before you start ranting… please note – this article was published on the 1^st of April 2014… don’t be silly

While SAP is a fully inclusive and integrated platform which considers all aspects and facets of business applications, it may sometimes be necessary, and even imperative for SAP user – clients to introduce, enforce and deploy upgrades. The business functioning environment may have changed, due to vertical integration, or even due to business mergers, amalgamation and takeovers, and thus, it now becomes necessary to conduct and enforce new SAP Programs and Upgrades to suit the new demands of business. It could either be in terms of complete overhauling of existing platforms or may be in line with software and other kinds of upgrades, depending upon the scope, level and intensity of changed business environment.

Indeed the main areas could be that of additional functional needs, minimizing interfacing of legacy systems, actions to prolong, or amend technical limits of actions, lapse of maintenance contracts with vendors. While the end results of SAP is indeed gaining operational efficiencies in all major areas of public accountability and stakeholder trust upliftments, the fact remains that SAP upgrades are not without organizational challenges and confrontations from several quarters.

This could assume aspects like Time management, budgeting, resource planning, project leadership debates, business processes, matters of release customizing versus delta customizing, migration of modifications back to SAP Demanded Standards, Interfacing and testing of Customer Programs and a whole gamut of other demands in terms of testing, usage, sizing, planning, execution and inspection / feedback.

It is also necessary to understand that SAP Upgrades come in different categories depending on need, software requirements and a host of other impinging factors, of direct or indirect bearing.

SAPUp is the name given for standardized SAP upgrade tools and comes in two categories- firstly, SAPup for ABAP Stack and secondly, SAPJup for Java Stack. It also comprises of two programs, upgrade program which performs the upgrade, and control program, also called GUI which is used to upgrade processes.

The upgrade GUI is the user interface wherein it is possible to visualize upgrade phases or progressions via roadmap steps. Through this it is also possible to perform Combined Upgrade (CU) and Unicode Conversion (UC) also.

The first aspect to discuss is that of SAP Enhancement Package Installer (SAP EhPi), which, as the name suggests, is utilized for enhancement, especially for enhancing functionality of SAP Business Site 7 and higher installations like the SAP NetWeaver 7.0 and others. Besides, it is also possible to upgrade Dual Stack Based System via Synchronized procedures. This could also be used for SAP Support Packages. Now what we have is Software Update Manager or SUM.

Next, SPAM/SAINT/JSPM tools which are usually used for installation and up gradation of adds-ons, Support Packages and further installation of further technical uses of EhPs. SAINT is usually used for upgradation in ABAP Stack and JSPM in Java Stack. Since both are hosted directly by ABAP AS, they are free of any platform dependency.

Software Update Manager-SUM or Software Logistic Toolsets are software logistic tools that are used for different kinds of implementation processes. Besides Application Specific Upgrade or ASU is a tool hosted by ABAP Stack to collect all data before or after upgrade activities, tasks and other aspects.

Author bio:
Michael Collins is a Technical degree holder and more enthusiastic on the latest applications using new technologies. He is currently working for some recommended essay writing companies to assist students. The choice of most technical students is Michael Collins and he is trustful and offer a best quality content than every other writers can provide. Since he is updated every day with new things, he is enough capable to present effectively before his audience.

As SAP Expert has already emphasised several times, aligning objects in different SAP systems is a very important part of the multi-system landscape maintenance.

We have discussed the fact that the transport system is the most usual way to move configuration changes throughout the landscape, and how you can align certain master data.

However, some objects in SAP require “special treatment” when moving them across. One of them is tax code, and you can read about the process of moving tax codes across the landscape.

Today we will discuss another “special treatment” object – number range.

Number range is an object in SAP that is assigned to another object that requires automatic or manual numbering. A good example is document number range. You specify different document types, and assign number ranges to them. Then you need to maintain number ranges separately – assigning lower and upper limit of each of them, splitting by company code, year and assigning other parameters. You have an option to edit “status” of number range too – the last used number for automatic numbering. Opposite to many other configuration objects, you will not be asked for a transport request for number range when saving data in Development system. It means that you have 2 options to maintain number range:

1. Do it separately in each client. You may need additional authorisations for that.
2. Include number ranges in the transport request in Development system and move across the landscape.

You need to decide yourself, based on your project needs and approaches, what is the best option for you. If you decide to use transport requests, SAP Expert can give you some recommendations.

1. To include number ranges in the Transport Request, please use menu Interval – Transport to include number ranges in the Transport Request. You may get additional questions, depending on the object you are going to transfer. Please read them carefully and act accordingly.

   Transporting Number range

2. Include Number Ranges in a separate Transport Request, and mark it as “move once only” in the text. Of course, you must move the transport request only once in each client. This is because SAP removes existing number ranges, including their statuses, in the target system before importing the transport request. If your target system already has some documents, the status of the number range will not be the same as stored in the transport request. Re-importing the number range from transport request will change the status. This will most likely block the process of new document posting. Of course, this can be solved by manual editing of the status in the target client, but it is way better not to create the problem initially. So, “move once only!!!”

Next time we will talk about other objects with “special treatment”.

SAP Expert continues a series of articles about the SAP transport system and objects that require “special treatment” when moving across multi-system landscapes.

We have already spoken about Tax Codes, Number Ranges and Substitutions/Validations.

Today it is the turn of Calendars

Introduction

Calendar is an object in SAP that is used in different situations. For example, HR uses calendars to properly calculate payroll. Logistics uses calendars to plan production and delivery activities. Even Finance may use calendars for some background job planning.

Calendar maintenance can be split into three layers. They are like three parts of the SCAL transaction.

Transaction SCAL

1. First, you need to maintain a list of holidays that are relevant to your calendar. Each holiday may have different rules for calculation, like fixed day, or offset to Easter, or even floating day from year to year.
2. Second, you assign holidays to your holiday calendar and specify the validity of the calendar itself and of the holidays within it.
3. And third, you create a logistics (or sometimes it is called a “factory”) calendar, which has default workdays, uses the holiday calendar, and may have some special rules.

This is the logistics calendar which may be used in delivery planning or job scheduling.

Including Calendar in the transport

Calendar is a cross-client object. It means that if you have maintained your calendar in the Development client of your Development system, all other clients in the same system get exactly the same changes immediately. You do not need to do anything in this case.

However, if you need to move calendar changes across to the Test or Production system, you need to use the transport system.

Before moving changes, you need to consider whether it is better to maintain the calendar in each system individually, or move changes via the transport system. Both approaches have benefits and downsides, and it is up to you to decide for the project who does the maintenance of the actual Production calendar, and in which system it is done.

If you decided to make changes in the Development system and then move them across, you need to bear in mind two things:

1. Transporting Calendar includes the full, and only full, content of SCAL transaction: holidays, holiday calendars, logistics calendars. You cannot move only part of it.
2. Transport, once in new system, will erase all calendar-related data in the target system, and fully rewrite it with new data. Therefore, it is highly advisable to either always maintain Calendar in Production or always transport it. Cross-over will not do any good.

So, if you decided to include the calendar data into the transport, here are 5 steps for it:

• Create or request creation of workbench transport request.
• Call up transaction SCAL.
• Select menu Calendar – Transport.

Transporting Calendar

• Read and confirm information shown on the pop-up window.
• Specify transport request.

Now you are ready to release the transport request and move it to your target system using the Transport System functionality.

How do you maintain Calendar in your system? How do you use Calendars?