The only available control that influences the entire sales order is the complete delivery indicator. When marking this in the customer master, the delivery is created when there is sufficient stock allocated to all sales order items. Normally this is only useful when there is a legal requirement that enforces this restriction. For most companies this functionality is not used as it could delay the delivery considerably. It is more likely that customer would like to receive partial deliveries, or just receive the stock that is available.

Regarding ‘partial delivery’, the standard SAP system only allows control on sales item level.
You can decide that complete delivery is required for individual sales items.
Alternatively you can force that only one delivery is created for the sales item. This can be triggered as soon as there is stock available for that item and therefore not taking into account other sales items. Another option is that you allow a zero-quantity delivery item when there is stock for other sales items.
In case of allowing partial deliveries, you can restrict up a specific maximum or else allow unlimited number deliveries for the sales order item.  In addition you can set under-delivery and over-delivery tolerances.

You would think that the standard SAP system offers enough flexibility. But there is a specific requirement that is particularly essential for the Fast Moving Consumer Goods (FMCG] industry. They require that only one delivery is created for the sales order, delivering whatever is possible and closing the sales items that cannot be delivered in full. This requirement is also referred to as Fill or Kill. As the standard SAP system does not offer a solution at the moment, a custom made solution is necessary. The customer specific Fill or Kill resolution depends on the configuration of other sales processes as well as the operational and management reporting requirements.

The Foxy Cola organisation is split into three separate companies located in the United Kingdom, Netherlands and Germany.

The company in the United Kingdom record sales within Great Britain and Ireland with warehouses in London, Birmingham and Dublin. Stock in the Dublin warehouse is sent to customers in Ireland and Northern Ireland while being replenished from the London warehouse. Stock in the London and Birmingham warehouse are sent to customers in England, Wales and Scotland depending on the location and availability.

The company in the Netherlands has one main warehouse in Eindhoven to supply the products to customers in the Benelux (Netherlands, Belgium and Luxemburg) whereas the German company serves the German market via their three main warehouses in Hamburg, Berlin, Düsseldorf and Munich.

Although manufacturing is out of scope, it is important to know that Foxy Cola has production plants located on the premises of the London and Hamburg warehouse. The production in the London plant is destined for the Great Britain and Ireland market, whereas the Hamburg plant covers demand in Germany and Benelux countries. However, stock can be moved between the London and Hamburg plants when necessary.

As Düsseldorf is located close to the Benelux countries, both Dutch and German companies have agreed that stock in the Düsseldorf warehouse may also be used for the Benelux market in case of shortages.

Sales in Belgium and Luxemburg are registered at a local office in Brussels which is associated to the Dutch Foxy Cola company.

Ever since January 1st 1993 a single European market exists for the member states of the European Union. However, there is a need to record movements of goods across the borders of the member states to a) assess the international competitiveness and dependency regarding import and export of products and b) monitor price developments in foreign trade. Therefore there is a need to collect information on goods movements within the EU, hence the introduction of Intrastat.

Please note that Intrastat reporting should not be confused with EC Sales lists which are used to collect information on all sales from UK VAT registered traders to VAT registered traders in other EU Member States.

Intrastat: When?

A company has to submit information to the local authorities when it trades within the European Union. It is enforced by law. Business within the United Kingdom need to supply a monthly report when the export value exceeds £250,000 or import value exceeds £600,000 annually. Else reporting is done every quarter.

Intrastat: What?

The level of detail in the report may differ for each member state, but the following data seems mandatory for all member states:

Dispatches and Receipts:

• Mode of transport when crossing the border (i.e. road, rail, water, air)
• Type of business transaction (i.e. regular trade, sample sale, consignment, intercompany stock transfer, customer returns)
• Commodity code (grouping of products to allow uniform reporting within the European Union)
• Value (the value should also include the costs for transport; a statistical value must be determined in case of sample sale or intercompany stock transfer)
• Weight

Receipts:

• Country of origin of the goods received (the country where the goods have been manufactured; when manufacturing has taken place in multiple countries, then use that country to which the most value has been added during the entire manufacturing process)
• Country of despatch

The SAP R/3 system uses billing information to compile the intrastat report. Therefore virtual billing documents have to be issued in the system for sample sales and intercompany stock transfers.

It is assumed that billing documents are issued on the day that goods leave the warehouse. However, the customer may negotiate that billing can only be triggered when the goods have been received at the customer site (proof of delivery scenarios). In those cases a delay regarding billing could make Intrastat reporting more complex when the goods issue is on month x and goods receipt in month x+1.

Handling of customer complaints and the impact on Intrastat reporting

For example, goods are delivered to a customer in another EU member state. When the goods are received and inspected, your customer discovers that part of the delivery is damaged. For the subsequent damaged goods regulations or warranty process, the following possibilities exist:

1. The damaged goods are returned for a credit memo
   For the returned goods, you need to submit an INTRASTAT declaration for receipts. The values in the credit memo must be paid.
2. The damaged goods remain with the customer and a credit memo is issued
   You need to create a declaration for the dispatch. The amount of the credit memo for the damaged goods must be included.
   If the INTRASTAT declaration for the dispatch has not yet been submitted, the credit memo can be excluded immediately.
   If the INTRASTAT declaration has already been submitted, the original declaration for the dispatch must be corrected.
3. The damaged goods are returned and you deliver a cost-free replacement
   You need to submit an INTRASTAT declaration for receipts for the returned damaged goods. For the replacement delivery, you need to submit an INTRASTAT declaration for dispatches.
4. The damaged goods remain with the customer and you deliver a cost-free replacement
   For the delivered replacement goods, you need to submit an INTRASTAT declaration for dispatches (again).

As shown in the examples above, sometimes debit and credit notes need to be included when a financial correction was necessary linked to a business transaction involving import or export of goods. Complexity regarding Intrastat reporting may occur when the goods were delivered and invoiced in month x and the financial correction was registered in month x+1.

Intrastat: Executing the report in SAP R/3

In order to execute the INTRASTAT Declaration in SAP R/3, you need to perform three main steps for receipts and dispatches:

1. Collect transactional data from the SAP system and store them in a worklist.
   During this phase you can analyse and correct missing data necessary for INTRASTAT Declarations while executing a test run.
   When you execute an update run, then the worklist is created that is necessary for the second step.
2. Prepare INTRASTAT Declaration by deleting, changing and/or adding entries in the worklist.
3. Issue the INTRASTAT Declaration based on the data in the worklist.

It is advised to perform a material consistency check regularly to avoid incomplete transactional data in the SAP system.
It is possible to execute a Material Master Consistency Report (transaction code VE81). Issues may be found in the maintenance of weights, commodity code, country of origin and various codes to identify and control import/export processes.
During the processing of the Intrastat report also missing transactional data may trigger the need for manual intervention (transactions MEIS, VI99, VEFU). Apart from the missing material specific master data, also incoterms and (statistical) value might not be captured during the purchase or sales process. This needs to be maintained before the Intrastat report can be submitted.

Some companies have special business triggering import/export within the EU for which data cannot be collected via billing documents. This normally happens when the standard SAP R/3 system has been enhanced. Special custom made programs have to be created to allow reporting of these exceptional business transactions.

Conclusion

Pay close attention to the quality of the master data. That would speed up the lead time for collecting and submitting the Intrastat report.
In addition the company needs to be aware of exceptional transfer of goods between the member states of the European Union when they are not identified by collecting billing information.

This post shows the types of configuration I have encountered that requires a manual effort in each system.

Although considered master data, General Ledger accounts are vital. Else no end-to-end business process can be recorded by the system because the assignment of General Ledger account is part of system customising that can be transported between systems.
As Foxy Cola is prototyped based on the official SAP demo system, the model company code 1000 can be used as reference. So that avoids the need for data migration development.
Use the SAP transaction OB_GLACC01 to copy the General Ledger accounts using a reference company code.

Each system has various calendars, for example to define when the factory is open for business and to define public holidays.
It is important to verify whether these calendars have been maintained far enough into the future to avoid issues with planning related business transactions in the system. For example, you cannot execute Material Requirements Planning in a specific year when the calendars have not been maintained.

In order to analyse profitability in the Controlling module, you need to maintain a Profit Center Hierarchy and a Cost Center Hierarchy. These structures for profit centers and cost centers have to be maintained manually in each individual system. Be aware that General Ledger accounts may be linked to individual profit and cost centers. So it is important that the structure set-up in the development environment is mirrored in the other environments.

Also number ranges need to be maintained manually in each single system. Various types of number ranges are required in financial accounting and controlling. regarding controlling, it may be necessary to execute the correction program RKTKA04C when you experiences difficulties in maintaining the number ranges.

When you are serious in using the controlling module, you need also to have a Operating Concern. You can create one from scratch, but Foxy Cola uses the existing operating concern code 1000.
Use the transaction KECP to create an operating concern based on data from an existing one.

After creating the operating concern, check the derivation rules as they may cause inconveniences when processing a sales order flow when releasing billing document information to accounting.
Regarding the Foxy Cola prototype some changes were necessary to maintain the derivation rule regarding customer intercompany indicators.

Finally, take close attention to opening and closing posting periods as that is quite fundamental when using the system to record business transactions with a financial consequence.

Basic configuration

You need to use a Notification Type to control the process of registering a Customer Service notification. Such a notification can be based on a problem, progress on an current activity or a service request.
A received call may need further processing and therefore it makes sense to link the Notification Type to a service order or sales order (Sales and Distribution module).

The next step is to maintain the Catalog Profiles which is a hierarchy of information to categorise the call received. Also it is important to control the Priority Types to assign and control the desired response times.

It is interesting to note that the screen access is very flexible when registering a notification. But that also requires quite some knowledge on the type of calls that will be received to ensure that the registration is as user friendly as possible.

Although the standard customising may be sufficient, making any changes should not be taken lightly. Also defining follow up functions via workflow will take a considerable amount attention.

More information will follow soon…

Most people would expect that free lancers are mainly driven by money. They are correct. But the desire to earn as much as possible is a universal drive for both free lancers and employees.
Being employed reduces the risk when experiencing economic thunderstorms. Yes, you can be made redundant, but there are various forms of social security to secure an income.
Free lancers cannot expect any financial compensation from the government. They need to reserve their income during the ‘good years’ to survive the ‘challenging years’. That explains why the rate may seem high, but that is to compensate the risk they take. A day not worked is a day not invoiced.

Why do people take the risk to become a free lancer? For sure your chances diminish when money is the only factor. You may be able to keep up with the Joneses for a while, but eventually you will realise that you can never sustain such a lifestyle. In my past I have met many self employed professionals who confessed that they have no financial reserves. Basically their debts exceed their assets even when they charge customers a high market rate. Those are the first who have to accept permanent roles when the going gets tough.
Successful contractors are driven by freedom and passion while constantly seeking new challenges. They want to be seen as entrepreneurs instead of a virtual employee. As from the first day they work hard to earn recommendations and referrals.
Whenever a contract extension is offered, they will tend to kindly decline when they conclude that acceptance is primarily based on personal convenience.
You can identify whether a free lancer behaves as an entrepreneur: Their resume shows more short term assignments, covering various customers in different industries.

When it comes to my career so far, it has followed quite a traditional path.
At first I was employed by a large consultancy firm. They placed me at one of their biggest customers as a programmer to support a software package that was based on outdated technology. It was put on ‘life support’ as soon as they decided to replace it with SAP R/3. Many of the team members moved to the exiting SAP project and it took quite some persuasion to let me join that group as well and make the jump from developer to configurer at the same time.
As soon as I had some SAP knowledge I changed employer to increase my annual salary. This time it was a young consultancy company organised in small ‘financial independent groups’. It became a stepping stone before taking the plunge to become a free lancer. But only after being SAP certified in the SD (Sales and Distribution), MM (Materials Management) and FI (Finance) modules.

This year I will celebrate a decade being a free lancer. SAP is still my core passion in my working career. Whatever the assignment, I want to put on my wellies and stand in the mud to resolve problems. And there are many opportunities to be in my element when being part of a SAP project or support team. Recently I realised that I see myself as an entrepreneur and therefore joined the coaching program called “The Strategic Coach”.
Another recent discovery is that I only accept  a contract after assessing whether it could be challenging enough, even during this period while demand is scarce. In the meanwhile I focus on enhancing my skill set. Therefore I am very pleased with the fact that I have access to my own personal SAP sandbox system. Currently I am exploring Plant Maintenance and Customer Service modules within SAP R/3 in order to extend my Foxy Cola prototype.

Regards,

Isard Haasakker.

It would be possible to introduce vending machines in the prototype. Then it would make sense to add Customer Service functionality to register the request for service, log the actions when executing the service and finally collect the required data for billing.

Configuring Customer Service in SAP R/3

When to use Technical Objects

Several decisions need to be made when configuring Customer Service. You have to decide whether to use various forms of technical objects such as functional locations and equipments or else materials and assemblies.
Basic rule is that you use a technical object when the specific product or component can be repaired and not exchanged in the event of a breakdown. Main advantage is that you can record the maintenance or service history.
Use materials and assemblies when the product or component has to be exchanged in the event of a breakdown because repairing it is not worthwhile due to its low value.  But be aware that this does not enable you to document a maintenance or service history. However, the material and assembly can be transferred from a customer service order to a sales order (Sales and Distribution module).

Equipment features worthwhile mentioning:

• A piece of equipment can be serialized by assigning a material number and serial number to it. This makes inventory management possible for the equipment.
• A piece of equipment can be configured by using a super bill of material or variant configuration.
• Pieces of equipment can be installed in functional locations.
• A piece of equipment that is installed in a technical object can store the history of its installation location. The system records a usage period for each installation location, enabling you to track the complete installation history.

Introducing the benefits of defining a Installed Base

An Installed Base represents a hierarchy of components for a specific object at a customer site, such as a vending machine. Each component can refer to a functional location, equipment, material, assembly or another installed base.

An Installed Base is more flexible compared to a Maintenance Bill of Material as it allows the following:

• Multi-level representation of components
• Components do not have to be represented as equipments
• Record additional data for the components, such as batch and revision level

Ideas how to introduce Customer Service for Foxy Cola

With regard to the Foxy Cola prototype by introducing vending machines, the physical location of the vending machines within the London Underground are identified by functional locations. Then it depends on the type of product or component whether to use an equipment, material or assembly.

It would make sense to identify two different types of service orders to make a distinction between repair and refill task.

More details will follow soon…

• Create invoices based on deliveries of goods and/or services
• Issue credit and debit memos
• Create pro forma invoices
• Cancel billing transactions

The special billing processes are:

• Create billing plans
• Create instalment plans
• Create rebate agreements
• Issue retroactive billing

Billing plan

A billing plan is a schedule of individual billing dates in a sales document that can be applied to the whole document or for a specific item. With a billing plan you are able to control periodic billing, milestone billing and down payments.

Periodic billing activates the creation of billing documents on a period basis until an optional horizon is reached. This billing process is useful for rental contracts.

Milestone billing activates the creation of billing documents when an event is about to start or is finished. This billing process is useful when using projects such as the assembly and delivery of customer specific projects.

Down payments are payments made before completion of the product, with no interest. They represent short or medium term outside capital procurement and therefore improve the company’s liquidity situation.
The SAP system handles a down payment as a variant of milestone billing.

Instalment plan

The instalment plan allows the customer to pay in instalments. With the instalment plan the system creates one invoice for all instalments. On the basis of this billing document you can print an invoice listing all the instalments with the relevant payment dates and amounts to be paid by those dates.

The instalments are calculated by the system by taking a percentage of the total invoice amount for each instalment. The system takes into account any rounding differences for the last payment date.

For each instalment the system creates a customer line item in financial accounting.

The instalments are defined by the payment terms, which are controlled by the payment terms key.

Rebate agreements

A rebate is a special discount that is paid retroactively to a customer. This discount is based on the customer’s sales volume over a specified time period. Details concerning the possible discount are settled in rebate agreements. In the agreement you specify, for example who receives the rebate payment, on what criteria the rebate is based (customer, customer and material, and so on) and how long the rebate agreement is valid.

Within the rebate agreement you create separate pricing condition records for each product the customer buys. These records specify the rebate amount or percentage for each product. You can also specify a pricing scale so that the customer can earn a better rebate by ordering more. Because rebates are always paid retroactively, the system keeps track of all billing documents (invoices, credit and debit memos) that are relevant for rebate processing. The system can, if you wish, automatically post accruals so that the accumulated value of a rebate is recorded for accounting purposes.

A rebate agreement is finally settled when you issue a credit memo to the customer for the accumulated rebate total.

Retroactive billing

Retroactive billing refers to additional billing documents issued after re-evaluation of billing documents that have already been processed and settled based on new pricing agreements made with the customer.

Example: An invoice has been created for a product using the historical net price of £10 each when the current net price is £9 each. Therefore a correction needs to take place.
The system calculates the difference between the net value of the invoice (£10) and today’s net value based on the new price (£9). It then creates a credit memo with the net value of £1 to be credited to the customer.

The system calculates retroactive billing values for primary documents. It can use secondary documents to help calculate this value.

Invoices are always primary documents. Debit or credit notes can be classified as primary or secondary documents, depending on the order reason assigned. Examples of order reasons include price changes, poor quality or ruined material. Depending on how the order reason you entered is customized, the debit or credit note becomes relevant for retroactive billing.

How does SAP identify and control intercompany sales?

Basically intercompany processes are triggered when the delivering plant, warehouse or distribution centre is linked to a different legal entity when comparing with the company that received the customer order. Then the company that owned the stock wants to receive a commission from the the company that made the sale to the customer.

Let’s assume that a British sales organisation sells stock shipped from a plant in Germany that is owned by a French company. Two invoices are issued. At first a customer invoice is created by the British sales organisation, followed by an intercompany invoice issued by the French company to be paid by their British counterpart. Note that the physical location of the stock has no direct impact on the intercompany process.

Of course the system needs to be configured to make this intercompany process possible. You need to pay attention to a) controlling the process flow, b) connecting enterprise structure elements and c) locating the origin of master data.

• At first you need to identify which type of intercompany billing needs to be used per sales scenario. You do this by linking billing document types (i.e. intercompany invoice, intercompany credit note) to specific sales order types (i.e. standard sales, credit memo request). Please note that there may be a need for multiple intercompany invoice billing types when different pricing rules and/or different automatic postings to the accounting modules are necessary.
• Then it is important to determine the sales area that is used to register the intercompany sale. For this you need to identify the sales area used in the intercompany billing document when goods are shipped from a specific physical location.
• Finally, customer master data must exist that represents the physical location from which goods are shipped. This customer must be maintained against the sales area used for issuing the customer invoice. The maintenance of the customer master data is important to allow the system to automatically create an intercompany billing document that contains all the required default transactional data (i.e. pricing, terms of payment).
  

When evaluating the pricing in the billing documents, you normally see two different approaches. The customer invoice is by default based on the net price with additional discounts and surcharges, whereas the intercompany invoice uses the cost price to determine a profit margin.

Certainly, free-lance consulting is not for everyone. It sometimes can be a very solitaire affair. You never really belong to a group. You do meet a lot of great people, but somehow they never really become friends. Probably due to the fact that ‘out of sight is out of mind’ does apply in most cases.
Also travelling can be a blessing or a curse. Still I remember the first business trip to Paris’ La Defance area. It has been many years ago, so the carbon footprint issue was not on the agenda. So no explanation was required why I took a return flight between Eindhoven and Paris every week for several months.
Airports can be very exciting. There are a lot of things to see and to explore. Therefore I was quite surprised to notice so many people who seem to be bored. But quickly I did join them, as the novelty of air travel quickly becomes as stimulating as taking a bus.

When you ask what is on a free-lance consultant’s mind, you will not be surprised that it is somehow relates to money. That is why amongst ourselves we resort to discuss whether to be part of an umbrella organisation or to do business via your own limited company. For me the decision was quite clear. Although you tend to pay more tax when offering your services through a limited company, it does have my preference.

Main reason within the UK for choosing the ‘umbrella’ route is avoiding the IR35 legislation. IR35 exists to find and prosecute free-lance consultants who try to avoid paying tax. The ‘umbrella’ idea is to give you hardly any salary and only live on dividends. So the income tax payments become neglectable. You make yourself more vulnerable when choosing to work via an umbrella organisation. It has to be mentioned that hardly any ‘umbrella consultants’ have been successfully charged with avoiding tax. To me it looks like a Tom and Jerry game, having the government to play the role of Tom. And as in the cartoon, just ask yourself the question how often Tom is considered the winner.
But I rather live on a modest salary though my own limited company and avoid the entire IR35 bonanza. True, I pay more income tax than other colleagues. That does not bother me. A rather have a clear conscience.

Regarding money, a lot of people see free-lance consultants as “the rich as infamous”. It is true that some drive in the latest sports car and show off their hot designer clothes. But it makes more sense to live below your means. All entrepreneurs are aware that ‘cash is king’. Especially in this economic climate it shows that saving money during ‘the good years’ is far more important than trying to keep up with the Joneses. Building a financial buffer allows you to focus on personal development when there are hardly any assignments available.

That brings me to one specific disadvantage when being on your own. You do not have an organisation that can assist you in learning new skills. My SAP SD, MM and FI certifications were done whilst still employed at a large Dutch consultancy firm. Also this company was able to give me access to the SAP training system.
When on your own, you quickly find out that ‘learning on the job’ becomes the norm when you want to add additional skills to your belt. It certainly is not my preferred method of acquiring knowledge. Therefore I was dreaming of my own SAP sandbox system as a present that I can unwrap under the Christmas tree.
Luckily, after almost 10 years of waiting, an UK company called ‘SID’ allows me to have my own SAP client. It is a copy of the official SAP demo system. Now I have the opportunity to use my certified skills to set-up my own fictitious company and demonstrate my existing and newly developed skills.
Now I pretend that I am involved in configuring a SAP system for the company called “Foxy Cola”. My aim is to take full advantage of standard SAP functionality. And you can stay up to date with my adventures when you follow my blog.

Regards,

Isard Haasakker.