Special Business Processes

Content

Cross-company transactions
Sales

Cash sales
Rush order
Sales Order Fulfillment with Requirements Reduction in Pieces
Bills of Materials in Sales Documents
Control of Batch Determination
Consignment Stock Processing
Returnable Packaging
Make-To-Order Production

Assembly-to-order

Intercompany Business Processing

Intercompany sales processing

Cross

Individual Purchase Orders
Third-Party Order Processing
Intercompany Business Processing

Intercompany stock transfer

Procurement

Subcontracting

Finance

SEPA debits

Production
Additional information

137686 - ALE_INVOIC01: Internal allocatn Customizing in FI

Cross-company transactions

A characteristic of cross-company-code sales is that the sales organization, in which the sales order is created, and the delivering plant are assigned to different company codes and, as a result, a revenue allocation or cost allocation is required.

Delivery related

Sales order - delivery - customer billing document - internal billing document / Billing relevance (TVAP-FKREL) = A

A customer orders from sales organization 0001 (selling company code 0001), but the goods are delivered from plant LY02 (company code of the delivering plant LY02).
The delivery occurs in the shipping point provided in the order that is assigned to the delivering plant.
The customer billing document (delivery-related) is created by sales organization 0001. The internal billing document (delivery-related) is created by the sales organization of the delivering company code and is sent to the selling company code.
Delivering plant LY02 must be assigned to sales organization 0001 so that sales organization 0001 can sell goods delivered by plant LY02. Plant LY02 can be assigned to several sales organizations since the relationship of sales organization to plant is a 1:n relationship.
It is possible that the sales organization of the delivering company code (for example, LY01) belongs to a different company code than the delivering plant LY02. This means that there is one sales organization of the delivering company code and it is used for intercompany billing. The delivering plants themselves belong to different company codes.
See also SAP Note 99641.
You can use the dependency on the distribution channel to differentiate further the plants of a sales organization.

Order - delivery - internal billing document - customer billing document

You can create the internal billing document before the customer billing document only by using transaction VF01 (Create Billing Document) and by specifying the billing type ‘Intercompany Billing’. Billing can be carried out using the billing due list (transactions VF04 and VF06) only if SAP Note 38501 has been taken into consideration.

Purchase order - replenishment delivery - internal billing document (CROSS-COMPANY-CODE STOCK TRANSFER, STOCK TRANSPORT ORDER)/ Billing relevance (TVAP-FKREL) = D

A plant procures materials from the stocks of a different plant that belongs to a different company code. SAP Note 109254 describes the relevant Customizing settings.

Internal billing document - internal credit memo (Cancellation)

The document types for intercompany billing are not canceled using the usual document type "S1" but:- IV with IVS- IG with IGS

Returns request (IR) - returns delivery - customer credit memo - internal credit memo (Returns)

The customer credit memo is created for the returns request and the internal credit memo is created for the returns delivery.

Order related cross-company processes

Order - customer billing document - internal billing document/ Billing relevance (TVAP-FKREL) = B

This process of cross-company-code sales without delivery is implemented using the report RVIVAUFT (as of Release 4.0B). Before Release 4.0B, you can copy this using the report ZZIVAUFT.For this, compare SAP Notes 63459 and 381042. Note that this SAP Note does NOT make any further reference to this process.

Order related cross-company processes for 3 rd party business

Order - purchase order - invoice/ Billing relevance (TVAP-FKREL) = F

The vendor who delivers the sales order is assigned to a sales organization that works in a different company code than the sales organization that has received the sales order.

Intercompany Business Processing

Intercompany business processing describes business transactions that take place between two companies (company codes) belonging to one organization.

Intercompany sales processing

Processing sales orders

The intercompany charge appears in the pricing screen of the sales order as a statistical value (the charge has no effect on the final value of the sales order for the customer). Since the intercompany charge is of internal interest only, this pricing element is not printed out on documents for the customer.

Processing deliveries
Billing

The delivering plant processes the delivery to create an intercompany billing document (billing document type IV) for the selling company. The ordering company code posts invoice entry for this billing document. The billing document is automatically billed to the internal payer that is assigned to the sales organization. The intercompany charges that appear in the intercompany billing document represent the actual amount that the delivering plant is charging the sales organization.
If the selling company is selling the goods to a customer, it processes the delivery to create an invoice for this customer. The system can take the prices from the order or determine new prices. It takes the quantity to be invoiced from the delivery.

Cash Sales

Cash sales is an order type for when the customer orders, picks up, and pays for the goods immediately.

The delivery is processed as soon as the order has been entered.
A cash invoice can be printed immediately from the order and billing is related to the order.
Receivables do not occur for the customer as they do for rush or standard orders, because the invoice amount is posted directly to a cash account.

Rush order

In a rush order transaction, the customer picks up the goods or you deliver the goods on the same day as the order is placed. When you save this sales document , delivery is automatically created and billing is related to the delivery.

Sales Order Fulfillment with Requirements Reduction in Pieces

Fulfill sales orders for a material with a batch-specific material unit of measure not only in the base unit of measure but also in pieces

Example: A customer orders 10 x 1,000 meters of cable. If you fulfill the sales order in the base unit of measure, nine batches with 1,112 m each are sufficient. If you fulfill the sales order in pieces, ten batches are required (for example, 10 x 1,200 m or 10 x 900 m)

In Customizing for Batch Management under Batch Determination and Batch Check Strategy Types Define Sales and Distribution Strategy Types, you have selected for your strategy type setting A (Display in stockkeeping unit) in the Display UoM field.
In the material master for the configurable material or material variant, you have defined product units of measure with an integral (whole number) alternative unit of measure.
You have created a configuration class (300) and a batch class (023) for the material. Each class comprises the characteristics Factor, Length, and Total Quantity. You have assigned a production unit of measure to the Length characteristic.

Control of Batch Determination

You can define for each item in the sales order which characteristic values the system is to use during batch selection. Whether the system uses the characteristic values of the configuration or the batch selection criteria (defined in the sales order) for the batch determination.

For batch determination for length-based materials, the system can also automatically calculate intervals from the characteristic values for individual length, minus tolerance and plus tolerance.

SEPA Direct Debits in SD

SEPA stands for ‘Single Euro Payments Area’. It’s a system that is designed to create financial efficiency for countries using the currency Euro by providing a unified system in which to perform financial transactions. The SEPA seeks to create a better system for credit transfers, an improved debit system and a cheaper way for individuals and firms to make transactions within member countries or regions.

The payer and the biller must each hold an account with a payment service provider (PSP) located within SEPA. The accounts may be held in either euro or in any other currency. The transfer of funds (money) between the payer’s bank and the biller’s bank always takes place in the euro currency.

The implementation of SEPA is mandatory by 1st of February 2014 for the Euro area countries.

Payers use SEPA mandates to grant their vendors or service agents the authorization to debit their account with the appropriate payment amount as part of a SEPA direct debit.

The Sales and Distribution component (SD) supports the processing of direct debits within the Single Euro Payments Area (SEPA) in compliance with legal requirements.

In the Sales and Distribution component (SD), you can process SEPA mandates in sales documents such as quotations, sales orders, and customer contracts.

Direct debit pre-notifications inform payers of the debits from their accounts. SD can create a direct debit pre-notification for the payer as part of the invoice printout. You have to integrate the relevant fields from the mandate into your print forms (see Create Direct Debit Pre-Notification for SEPA Direct Debit).

You can use all billing functions in sales documents with a SEPA mandate. The system uses the payment method to determine whether the sales document is SEPA-relevant. Before the SEPA direct debit is posted, the customer receives a direct debit pre-notification.

Consignment Stock Processing

Consignment goods are stored at the customer location but are owned by your company. The customer is not obliged to pay for these goods until they remove them from consignment stock.

Special Stock Partner (SB): The special stock partner has been defined for carrying out consignment stock processing by means of a third party rather than the customer. It makes sense to use the special stock partner if your customer is using decentralized order processing but manages consignment stock centrally.

Processes

Creating a Consignment Fill-Up ( consignment special stock is created for the customer concerned )
Creating a Consignment Issue

The goods are then reduced by the relevant quantity in the special stock assigned to the customer. This goods issue also reduces your total stock.
Invoice the delivery which issues the consignment goods.

Creating a Consignment Pick-Up ( a transfer posting from the customer's special stock to your plant stock )
Creating a Consignment Return

The goods issue posting cancels the goods issue posting that was carried out when the consignment goods were issued. This posting records the return of the goods to the plant where goods receipt was carried out.
Create a credit memo for the consignment return

Intrastat 2027405 - INTRASTAT: Consignment stock processing

Company code CC01 in EU country A maintains a consignment store at the customer site. The store is located in EU country B.

Consignment fill-up (order type KB): Dispatch of goods out of country A

Consignment fill-ups are, by default, not relevant to billing because no change in ownership takes place.
To enable an automatic selection for the Intrastat declaration, you must enter a billing document with the billing document type WIA ("Plants Abroad").
This (technical) document is selected by the selection report for dispatches (transaction VE01).

Consignment pick-up (order type KA): Arrival of goods in country A

For the consignment pick-up, there is no automatic solution in the absence of an appropriate billing document.
The activity must be entered manually (call transaction VEFU or use the menu path "Logistics --> Sales and Distribution --> Foreign Trade/Customs --> Periodic Declarations --> Periodic Declarations --> Operational --> Individual Maintenance --> INTRASTAT")

MM View (Vendor Consignment): A vendor from EU country C maintains a consignment store for company code CC01 in EU country A.

Consignment fill-up: Arrival of goods in country A

The INTRASTAT selection report for arrivals (transaction MEIS) selects the consignment order (contains items with item category 2) to the vendor in country C. Reporting is done based on the goods receipt in the consignment stock (see purchase order history of item).
The pricing is not active for a consignment order. The change in ownership occurs during the withdrawal from the consignment stock to your own stock. The value determination also occurs at this time. So that the Intrastat selection program (transaction MEIS) can run a value determination, observe the information from SAP Note 317787 regarding this topic.

Consignment pick-up: Dispatch of goods out of country A

For the consignment pick-up, there is no automatic solution in the absence of an appropriate billing document. The activity must be entered manually (call transaction VEFU or use the menu path "Logistics --> Sales and Distribution --> Foreign Trade/Customs --> Periodic Declarations --> Periodic Declarations --> Operational --> Individual Maintenance --> INTRASTAT").

Additional information

The Customer Consignment Stock (Special Stock W) is stored in table MSKU. The table MSKU for the Customer Consignment stock only has Unrestricted use and Quality Inspection stock types available. There is no field for Restricted use for the Customer Consignment Stock.
1995932 - Consignment delivery is intercompany billing relevant after packing

This is a design problem that comes from the fact that (possible) intercompany billing relevance is a property of delivery header (LIKP-FKAIV), not a delivery item.
Yet both delivery items refer to different (default) order types (KB, DL) that have different customizing concerning the relevance of internal billing in the table TVAK of order types.

1837299 - Unable to Transfer of Consignment Stock between 2 Customers

First, post a 562 mvt with special stock W to issue the customer consignment stock from customer X.
Then, post a 561 mvt with special stock W to receive the customer consignment stock to customer Y.

2842899 - New process for intra-community call-off stocks (a.k.a. consignment stocks) in the EU effective as of January 1st, 2020

Let's assume a delivery from a vendor/supplier in Germany (DE) to a consignment Stock in France (FR) consumed by a customer in France (FR).

Consignment Fill-up: Supplier (DE) delivers goods to Consignment Stock (FR) for Customer (FR).

Goods are still owned by the supplier.
Not yet considered as an intra-Community acquisition in FR
Supplier does not need to be VAT registered in FR
VAT ID of Customer (FR) and new Tax Code needed in ERP FIN
"WIA" Invoice used to cover the above step

Consignment Issue: Customer (FR) consumes goods from Consignment Stock (FR)

Goods are now owned by Customer (FR)
Supplier (DE) bills product to Customer (FR) as an intra-Community supply
Supplier (DE) bills products tax-exempted to customer (FR)
Customer (FR) takes care of intra-Community acquisition in FR

The ERP-SD process for the Consignment Fillup needs to use the new zero percent tax code e.g.

"KO" (or CO) as described in SAP Notes 2854506 and 2854593.

Create a new transaction type for the Consignment Fillup e.g. ZKB (as a copy of the existing transaction type KB). This way the "old" which might still be needed for other intra-community consignment processes remains unchanged.
Create a new Billing document Type e.g. ZWIA
New Pricing procedure for above transaction types e.g. RVWIA2 (with new condition type e.g. WIA4 which determines 0 % tax and tax code KO via access 008 (departure country DE, destination country FR)
New BAdI badi_sd_bil_external with method DATA_TRANSFER_STCEG_DET to assure that VAT-ID of customer is determined instead of WIA-setting based VAT-ID of plant abroad
New implementation of exit LV60BU01 / RV_ACCOUNTING_DOCUMENT_CREATE customer-function '008' … … to assure that the customer number is transferred from the ZWIA invoice to the financial posting line(s)
Now the "new" process requires the Tax Departure Country to be set to the country of the delivering plant. By using USEREXIT_MOVE_FIELD_TO_VBAK to fill Tax Departure Country
(VBAK-LANDTX) with the Country of the delivering plant (VBAPD-WKLND) create a new Sales Order Transaction Type for the Consignment Pickup e.g. ZKA as a copy of the existing transaction type e.g. KA And assign new pricing procedure e.g. RVWIA2 and new Invoice transaction type ZWIA as in the new Consignment Fillup

Returnable Packaging

Returnable packaging consists of materials that are stored at the customer location but which remain the property of your company. The customer is only required to pay you for the returnable packaging if he does not return it to you by a specified time.

Stocks of returnable packaging must be

Managed separately from the rest of your stock so that you know exactly what stock is stored at the customer location (V)
Managed separately for each customer

A prerequisite for returnable packaging processing is that the value LEIH (returnable packaging) is in the Item category group field.

If you want to manage returnable packaging for a carrier, for whom a vendor record already exists, you must also create a customer master record for the carrier. You are then able to assign returnable packaging stock to the carrier.

Processes

Creating Returnable Packaging Shipments

When you sell goods to a customer, you may send the goods in returnable packaging.

Creating Returnable Packaging Pick-Up (SD doc LA)

If the customer returns the returnable packaging to you

Creating Returnable Packaging Issue ( SD doc LN)

In the following situations, you can create a returnable packaging issue order (order type LN)

Make-To-Order Production

Make-to-order production is a process in which a product is individually manufactured for a particular customer.

The system saves the sales order and creates individual requirements for the make-to-order items. This initiates production. The production orders which are created on the basis of the requirements are assigned to the appropriate sales order items. The special stock indicator E.

When you delete items, the system does not check whether any planned orders or production orders have been created for these items. Any such documents must be deleted manually.

Assembly-to-order

An assemble-to-order environment is one in which the product or service is assembled on receipt of the sales order. Key components are planned or stocked in anticipation of the sales order. Receipt of the order initiates assembly of the customized product. Assemble-to-order is useful where a large number of finished products can be assembled from common components. In the SAP system, assemble-to-order is a special kind of make-to-order planning strategy.

If you use an assemble-to-order strategy, you can check material and resource availability at the moment when the sales order is created.

Changes to quantities or dates for production or procurement of components are passed back to the sales order of the finished product where the committed quantity or confirmation date is also changed. Similarly, changes to quantities or dates in the sales order are passed on to production and/or procurement.

When you create a sales order, a customer quotation, or an inquiry with one of the assemble-to-order planning strategies, the system automatically creates an assembly order. An assembly order is one of the following procurement elements:

Planned order
Production order
Process order
Network (project)
Service order

The choice of procurement element is determined by the strategy group in the material master record.

Individual Purchase Orders

Individual purchase orders are used when your customer orders goods from you that are not in stock and must be ordered from one or more external vendors.

Trigger

During sales order processing, the system automatically determines individual purchase order items.

BANC in the field Item category group on the Sales: sales org. 2
Set the item cat. TAB

Changes you make in the sales order are always automatically reflected in the corresponding purchase requisition, as long as this is permitted by the release status for the purchase requisition.
When you create a delivery, the system checks if goods are available in the sales order stock.

Costs

If you activate F in the Billing quantity field, the value is calculated from the incoming invoice and copied to the VPRS condition. This assumes that the customer billing document can’t be created until the vendor invoice has been posted, checked by copying requirement 004.
If you activate F in the Billing quantity field, the value is calculated from the incoming invoice and copied to the VPRS condition. Goods receipt for customer purchase orders is not normally evaluated and the value from the purchase order is used as the cost.

Enhancements

Use the business add-in BAdI: Determine Delivery Date for Items with Purchasing (BADI_SD_TPO_IP_DELIVERY_DATE) to implement your own logic to determine the vendor's delivery date to a delivery plant more accurately. The system will still add the goods receipt processing time to your delivery date to set the material availability date.
Use the Business Add-In BAdI: Update of Shipment Scheduling from Individual Procurement (MM06EF0S_CUSTOMER_SD_UPDATE) to implement your own logic to merge events with different priorities for the update.

Bills of Materials in Sales Documents

A bill of material (BOM) describes the different components that together create a product. Once you have entered a bill of material in a sales order, the system runs pricing, inventory control, and delivery processing at:

Main item level if the material is assembled, or (ERLA)

the components only function as text items and are not relevant for delivery

Component level if the material is not assembled (LUMP)

During processing the system automatically creates a delivery group.

Using the item category, you can control whether the bill of material alternative is selected manually or automatically. If you switch off the manual alternative selection function for a particular item category, the bill of material alternative is selected automatically and exploded in the sales order.

In Customizing for item categories, you can control that the system should generate correlated schedule lines for the delivery group. You can do this by selecting A in the Generate delivery group field for the item category in the bill of material main item.

Parameter Effectivity

Within Engineering Change Management, you can define specific effectivity types for changes to the product. For example, seasonal changes, by changing the color for example, for a certain time period or a certain customer. The relevant functions are combined in Customizing (go to Logistics - General Engineering Change Management Parameter effectivity ) and are activated at client level.

The parameters that you can freely define (for example, material, date, customer, serial number) are assigned to an effectivity type (such as a serial number or time range). You can assign several parameters to one effectivity type (also known as validity type), for example customer and date, which allows you to make changes to a product for one particular customer for a certain time period.

Third-Party Order Processing

In third-party order processing, your company does not deliver the items requested by a customer. Instead, you pass the order along to a third-party vendor who then ships the goods directly to the customer and bills you.

You process third-party items by creating a normal sales order. In overview for the order, you can then overwrite the default item category (TAN in the standard system) with the special item category for third-party items: TAS.
If relevance for billing indicator for the item category has been set to B (relevant for order-related billing on the basis of the order quantity) in Customizing, the system includes the order in the billing due list immediately.

If, however, the indicator has been set to F (relevant to order-related billing on the basis of the invoice quantity), the system does not include the order in the billing due list until an invoice from the vendor has been received and processed by the purchasing department. In the standard system, item category TAS (third-party order processing) has been given billing-relevance indicator F.

Credit Memo Processing in Third-Party Business Transaction

If the vendor grants you a credit memo on a quantity or a value basis, you can then send this credit memo directly to your customer.

The billing type Third-party credit memo (G2S) is available for this. The billing type Third-party credit memo works with the item category TASG (third-party credit memo item). The Billing-relevance indicator F is set in Customizing for Sales for this item category. This means that the cost is not created. In Customizing for Sales, the item category TASG is set at item level in copying control for the billing type G2S (copying control sales document by billing document) as the target item category (source: TAS-> Target:> TASG.)

Retroactive billing

If the vendor calculates additional costs for you once third-party business transactions have already been billed (for example, shipment costs), the costs from the invoice receipt are then corrected in the customer billing documents which have already been created.

You can use report SDMFSTRP to create a list of all sales orders with third-party order items for which there are discrepancies between the quantities ordered, invoiced, canceled, or credited in Sales and the quantities ordered, invoiced or credited in Purchasing.

95024 - Sales order: Data transfer to purchase requisition

151533 - Partially billed third-party orders are completed

This is the logic for third-party processing with billing-relevance according to the invoice receipt quantity, and this logic is required by a large number of SAP users: The invoice of the vendor should be used as the trigger for the subsequent billing document and thus control the billing status; however, the quantity specified in the invoice receipt should not directly influence the completion of the SD document.

549972 - FAQ: Rejecting third-party items or individual PO items

1. Question: When may I delete a third-party item or individual item?

Answer: You may delete a third-party item or customer individual item as long as no purchase order exists for this item (or another subsequent document such as a delivery, billing document). As soon as a purchase order or another subsequent document has been created for the third-party item or individual purchase order item, you can only reject it in the sales order even if you delete or cancel all subsequent documents. In this context, also see SAP Note 210470.

2. A purchase requisition (PReq), but no other subsequent document exists for my third-party item or individual purchase order item. May I delete this item?

Yes, you may delete this order item. A PReq is not a subsequent document in the sense of the answer to the previous question. Instead, it is generated automatically during the creation of a third-party item or individual purchase order item and is used as a template during the creation of a purchase order.

3. Question: How do I reject a third-party item or individual purchase order item correctly?

Answer: If an active purchase order belongs to this third-party item or individual purchase order item, you must delete this active purchase order before and undo or cancel all further follow-up actions such as the goods receipt and the invoice (in reverse sequence compared to the creation). Otherwise, the system issues an error message when you attempt to reject the order item. The reason for this is that otherwise, your customer would obtain the goods in the case of a third-party process despite the rejection of the order item if the purchase order would not have to be deleted. For additional information, see SAP Notes 356895 and 392945.

4. Question: May I reject an individual purchase order item for which a purchase order and a goods receipt already exist?

Answer: Yes, you may reject this individual purchase order item. This is the only exception to the rule that all follow-up actions must undone before. The reason for this is that, in this constellation, the goods are in your warehouse so that you can decide yourself whether or not you want to deliver them to your customer. The system nevertheless issues a warning message to delete the purchase order, which you may ignore here. For additional details, see SAP Notes 356895 and 97272.

5. Question: I have rejected an individual purchase order item for which a purchase order and a goods receipt already existed. I cannot remove the reason for rejection because the system issues an error message. Why?

Answer: The error message is correct. If you remove the reason for rejection, the system does not know whether the purchase order was changed in the meantime and whether these changes would have to be transferred to the sales order so that a data inconsistency would occur. SAP Note 97272 describes how you can use a report to remove the reason for rejection.

6. Question: Why does the system issue an error message telling me to delete the respective purchase order item when I attempt to reject a third-party item or individual purchase order item? This purchase order item was already deleted during the archiving.

Answer: The error message is correct because although the archiving process has removed the purchase order from the system, the procurement transaction occurred and was not cancelled. As a result, you cannot reject the order item. SAP Note 403524 describes how to reject the order item in a way that complies with the system if necessary and adds an explanatory long text to the error message that is misleading in this context.

7. Question: For a rejected third-party item, I no longer find an overall processing status on item level. Is this correct?

Answer: It is the correct system response to determine the overall processing status of a rejected third-party item as "not relevant" and thus not to display it if the order-related billing has been set. In this case, all statuses of this item, particularly the billing status, are "not relevant". SAP Note 210885 describes additional consequences of this system response.

549583 - FAQ: Order confirmation status of third-party and individual purchase order

1. Question: What information does the order confirmation status provide?

Answer: In the case of a third-party item or individual purchase order item, the order confirmation status provides information about whether the vendor has already confirmed one or more purchase order items belonging to this order item. If no purchase order item exists yet, this status has the value 'unconfirmed'.

2. Question: In which table fields can I read the order confirmation status?

Answer: A PReq item, and therefore a purchase order item, belongs to each request schedule line of a third-party item or individual purchase order item. The order confirmation status is therefore determined in the table field VBEP-WEPOS at the schedule line level. As a result of linking all of the VBEP-WEPOS schedule line statuses belonging to an item, the order confirmation status results at the item level VBUP-COSTA. For additional information, see SAP Notes 377981 and 401058. You can display the contents of these fields in transaction SE16.

3. Question: How is the order confirmation status determined at the schedule line level VBEP-WEPOS?

At the schedule line level, the order confirmation status VBEP-WEPOS is set to the value 'C' (confirmed) in a confirmed schedule line if the purchase order item belonging to this schedule line has been confirmed. If the purchase order item has not been confirmed or if a purchase order item does not yet exist, it has the value 'A' (unconfirmed). Pure request schedule lines (confirmed quantity VBEP-BMENG = 0) have the value ' ' (not relevant). For details, see SAP Note 401058.

4. Question: When is a purchase order item confirmed?

Answer: A purchase order item is explicitly confirmed if a purchase order item of the type 'AB' has been entered. However, it can also be confirmed automatically. The most common scenario for this is if the checkbox for the order acknowledgment requirement is not set in the purchase order item and no entry was made in the confirmation control. SAP Note 401058 contains more information about this.

5. Question: Where can I find the order confirmation status in the sales order?

Answer: You can find the order confirmation status in the status overview in the document flow of the sales order. Select the order item and choose 'Environment -> Display document flow'. Then choose the button for the status overview and expand the menu tree. Depending on the value of the table field VBUP-COSTA, the text is 'Not yet confirmed', 'Partially confirmed' or 'All sched. lines confirmed'.

6. Question: What is the importance of the open quantity in the status overview?

Answer: In the status overview of the document flow, a quantity is displayed as open for a third-party item or individual purchase order item only if only a partial quantity was confirmed in a relevant purchase order item. The details of this issue are relatively complicated. SAP Note 377981 describes the issue in more detail using an example.

7. Question: I cannot find an entry 'Purch.confirm.status' in the status overview of the document flow of the order item. Why?

Answer: For a status item or individual purchase order item, you find no 'Purch.confirm.status' entry if the item has been rejected. Check this in your system. If it is not rejected, there is an error.

8. Question: How does the order confirmation status affect redetermination of third-party purchase order items or individual purchase order items?

Answer: When you trigger rescheduling in the sales order (by choosing 'Check availability' or by changing the quantity or date), the system carries out rescheduling only if none of the purchase order items belonging to this order item has been confirmed yet (VBUP-COSTA = 'A'). See SAP Note 401058 for more details. SAP Note 849074 explains an exception to this rule.

550192 - FAQ: Changing third-party items and individual purchase order items

1. Question: Can I subsequently change the quantity for a third-party item or individual purchase order item?

Answer: Yes, you can subsequently change the quantity of a third-party item or individual purchase order item. If that item has not been ordered yet, the change does not cause any problems because the quantity in the purchase requisition is updated as well. If a purchase order item already exists, it is absolutely necessary that you consider several issues that are covered in the following FAQs. For this reason, please continue reading.

2. Question: I want to decrease the quantity for a third-party item or individual purchase order item that has already been ordered. What do I have to consider in this case?

Answer: If you decrease the quantity in the sales order, the system issues a warning message that this item was already ordered, but the system does not prevent the change. However, you should remember that the original quantity has already been ordered and that you must therefore maintain the purchase order in a system-conform manner. There is no automatic function here except for the ALE scenario because the maintenance is connected to an activity. This is the case because you generally have to inform your vendor about this change in quantity. This topic is also explained in SAP Note 210942.

3. Question: If I decrease the quantity for a third-party item or individual purchase order item that has already been ordered, the system confirms the original, higher quantity. Why does this happen?

Answer: The system confirms the original quantity if the respective purchase order item has been confirmed. If it has not been confirmed, the system confirms the new quantity in the order item (also refer to FAQ 549583 regarding the question: 'When is a purchase order item confirmed?'). In both cases, you must maintain the purchase order item manually as described in the previous answer.

4. Question: How can I increase the quantity for a third-party item or individual purchase order item that has already been ordered and do this in a system-conform manner?

Answer: You should not increase the quantity directly in the item overview but rather create a new request schedule line in the scheduling screen. Then the system generates a new PReq item from which a new purchase order item can be generated (within the same purchase order or in a new one). This is the only way if the purchase order item was already confirmed. If the purchase order item was not confirmed, you can increase the quantity in the order item and in the purchase order item as explained for the quantity decrease. For more information, see SAP Note 445451.

5. Question: What do I have to consider when I change the quantity for a third-party item or individual purchase order item with an automatically generated purchase order (ALE scenario)?

Answer: In the ALE scenario, the change in quantity (increase or decrease) is transferred automatically to the respective purchase order item, and the latter is updated. In the sales order item, the system carries out a rescheduling if the respective purchase order item was not confirmed. You must be careful if the respective purchase order item was already confirmed; in this case, the system does not carry out a rescheduling. Instead, it copies the date confirmed by the purchase order, which you may need to discuss with your vendor. For detailed information, see SAP Note 449592.

6. Question: Can I change a third-party item into an individual purchase order item after saving the sales order?

Answer: Yes, you can change the item category from third-party to individual purchase order (TAS => TAB in the standard system). However, if a purchase order item already exists, you must delete it beforehand. This topic is also explained in SAP Note 210989.

7. Question: Can I change an individual purchase order item into a third-party item after saving the sales order?

Answer: No, you cannot change the item category from individual purchase order to third-party (TAB => TAS in the standard system) because an individual purchase order item generates a CO object in the background that does not allow this change. Depending on whether a purchase order item was generated, you must delete it first. Then you must reject or delete the individual purchase order item, and finally you have to create the third-party item again. This topic is also explained in SAP Note 210989.

8. Question: What do I have to consider when I change the ship-to party for the entire sales order or for a third-party item?

Answer: In the third-party scenario, the ship-to party of the third-party item in the sales order is identical with the delivery address of the respective purchase order item. Up to and including Release 4.5, there is no automatic function for a synchronous change, so this must be done manually in both documents. As of Release 4.6, the system automatically updates the delivery addresses from the purchase order items if the ship-to party of the third-party item changes. The change of the delivery address in the purchase order is therefore no longer possible; thus the tab 'Delivery address' is displayed only in display mode in the purchase order transaction.

2361640 - It is not possible to remove a third-party sales order line item in VA02

The deletion indicator (EKPO-LOEKZ) should be set in the purchase order line item.
If there are already goods or invoice receipts for this purchase order, these documents should be cancelled before the order line is rejected.

816842 - Individual purchase order: WEBAZ from material master is used

In the case of a sales order of the type "Individual Customer Purchase Order" (item category TAB), you overwrite the goods receipt processing time (WEBAZ) manually (field EKPO-WEBAZ) during the creation of the corresponding purchase order. During the update in this sales order, this manual value is taken into account. However, in the following situations, this is no longer the case.

You execute rescheduling in the sales order (by changing the sales order or choosing the "Availability Check" button in the sales order or automatically by means of a scheduled overnight job, for example). Here, the WEBAZ from the material master is used for all order items of the type "Individual Purchase Order".
The sales order item is part of a delivery group or the "Complete Delivery" indicator is set for the sales order. In addition, you have implemented modification SAP Note 650247.
If you now change one or more purchase order items, the WEBAZ from the material master is used during the redetermination of the order items that are connected by correlation but not currently changed.

This is not desired. If a manual value for WEBAZ exists in the purchase order item, this should also be used for every scheduling in the sales order.

2772842 - Customer Connection: Overwriting of EBAN and EBK data in third-party process and individual purchase order process

A solution is required for the two scenarios "Third-Party Process" (item category TAS in the SAP standard system) and "Individual Customer Purchase Order" (item category TAB in the SAP standard system).

In both scenarios, corresponding purchase requisition items are created or changed during the creation or changing of the sales order in the background. There should be a way to influence the content of various standard fields in the two central purchase requisition tables EBAN and EBKN by means of customer programming in exits of the sales order code and to add customer-defined (ZZ_) fields to these tables.

2885734 - Profit center changeable for purchase order with account assignment

There are several reasons, why the field "Profit center" is still editable by standard design in a third party sales order with a purchase order with account assignment:

1. A customer deliberately wants to change the profit center (that is, knowing what he does), and this option is removed from the customer.

2. When a customer opens a sales order with an existing purchase order, the system issues an information message informing the customer that a follow-up document exists. The customer is already pre-warned that he/she should be careful with the data. Even if the profit center is changed in the sales order, there should be no critical inconsistencies occuring, but usually some deviations in the statistics data. However, if the "Profit Center" field is not ready for input by standard design, it could cause a large number of problems (for example, an IDOC cannot be imported due to the missing changeability of the field or similar). Until today no other customer has reported that he/she received a problem due to the different profit center values in the sales order and in the purchase order. Therefore, SAP thinks the statistics inconsistencies which may arise from different profit centers in the sales order and in the purchase order are not particularly critical.

SAP still offers every customer the option of controlling the changeability of fields according to specific criteria or using specific process criteria. Especially, the customer user-exit USEREXIT_FIELD_MODIFICATION (include MV45AFZZ, SAP note: 208245 - Availability of fields in sales orders) is available.

(If the field "Profit center" (VBAP-PRCTR) is not ready for input in a third party sales order with an existing purchase order, the above described scenario does not occur.)

Please always initiate changes or modifications in the standard coding with the consideration of consequences described in SAP note 170183.

2847899 - Reason of rejection value is not copied from VBAP-ABGRP to EKPO-SPE_ABGRU

The field 'EKPO-SPE_ABGRU' is not updated in a third party sales scenario by design. When the sales order is rejected, the corresponding purchase requisition and purchase order are deleted.

(The field EKPO-SPE_ABGRU is actually defined in standard function module 'BAPI_PO_CREATE1', but it is only used in a so called 'TPOP CRM sales order' process only.)

2945744 - One purchase requisition generated for line items with multiple schedule line category

For a sales order with multiple third-party items, the standard logic generates only one PR number for all these items, even though the line items may have different item categories and schedule line categories, and the corresponding PR items may have different document types (EBAN-BSART).

This design does not affect the correct classification of subsequent documents. The two most important PR tables EBAN and EBKN both have key fields BANFN and BNFPO. As long as the PR items can be correctly differentiated, the subsequent documents can be so as well. For example, different purchase orders (PO) for different PR items by PR document type can be created.

However, the MM function ME_CREATE_REQUISITION_EXT does provide a custom-exit function. Since the exit function is called right before the standard function to generate the new PR number, it may be checked if an own logic can be implemented here to assign different PR numbers to the third-party line items. Please always consider SAP note 170183 before applying any modifications.

2950523 - Confirmation hierarchy in schedule line updates for SD individual purchase order items

For an individual purchase order item, the confirmed delivery date in the schedule line is initially set by the scheduling date in the purchase requisition item, and later updated with the delivery date of the purchase order item or with the confirmed delivery date in the AB confirmation.

We can draw a confirmation path to represent this design.

Update from AB in Purchase Order > Update from delivery date in Purchase Order > Scheduling date in Purchase Requisition

There is a hierarchy of precedence from left to right down the path. If an AB-confirmed date exists, it will be used to update the confirmed delivery date in the schedule line. Otherwise, the PO delivery date will be used. If no active PO exists, the PR scheduling date will be taken.

With SAP Note 1774447, SAP has extended this path and hierarchy by allowing automatic updating of sales order confirmed delivery dates from shipping notifications and/or goods receipts. Now the complete path may look like this.

Update from Goods Receipt > Update from Shipping Notification or Inbound Delivery > Update from AB in Purchase Order > Update from delivery date in Purchase Order > Scheduling date in Purchase Requisition.

An update from GR has the highest precedence in the hierarchy, followed by shipping notification or inbound delivery, AB confirmation, and so on. A higher-level update supersedes all previous lower-level updates and preempts all further lower-level updates. For example, an AB-confirmed schedule line can be first updated by shipping notification or inbound delivery, and later again by GR. On the other hand, a GR-confirmed schedule line cannot be updated by AB confirmation, shipping notification or inbound delivery.

This rule holds true even in situations that involve the confirmation of partial order quantities. Once a partial GR is posted, for example, the system replaces all schedule lines confirmed by lower-level updates with one new schedule line confirmed by the GR. From now on, the schedule line(s) can only be updated further by additional GRs but not by additional shipping notifications or AB confirmations. This design prevents a mix-up of confirmed schedule lines from different update levels from appearing in the same item at the same time. As a matter of fact, the standard design for third-party and individual purchase order processing has never supported simultaneous schedule line updates across multiple hierarchical levels. This simplistic approach ensures the correctness and consistency of update results in general.

Any custom-specific solution that departs from the standard design must be realized through custom development (See SAP Note 83020). As a starting point, you may look into the possibility of implementing USEREXIT_CHANGE_SALES_ORDER in include FV45EFZ1. It is called by FORM EBAN_VBEP_UPDATE (SAPFV45E), which is in turn called by the function module SD_PURCHASE_CHANGE_ORDER. Please work with your own SAP consultants to match your particular business requirements.

2314836 - Third Party Returns Process

Open trx VA01 - Create a 'RE' order document.
A Purchase Requisition is created in the background
Open ME21N - Create a PO document using the Purchase Requisition from step 2.
Open transaction MIGO - Post the Goods Receipt.

The functionality for returns processing within a Third Party scenario is not available through the standard SAP system.

All documents must be canceled individually in both SD and MM. The returns process functionality within a Third Party scenario is not a planned enhancement

751609 - Returns for third-party process (cancellation)

There are several documents for a third-party process or individual purchase order process that is, a purchase order was created for a sales order (via a purchase requisition) and in addition, goods and/or invoice receipts may exist for this.

You cannot cancel this process by creating a cancellation third-party order or a cancellation individual purchase order with reference to the original sales order.
You also cannot set up a return process that links customer and vendor return documents (for example: returns order and corresponding credit memos) with each other.

751385 - Third-party order processing for consignment fill-up

1. A consignment fill-up should take place by means of third-party order processing (item category TAS in the SAP standard system), so the goods are ordered externally and the vendor delivers directly to the consignment stock.

It is not possible to customize a logical goods issue so that the goods can be posted directly to the customer special stock.

2. A consignment fill-up should take place by means of an individual customer purchase order (item category TAB in the SAP standard system), so the goods are ordered externally.

A dump occurs during the creation of the purchase order assigned to the sales order. This is caused by a data inconsistency between the tables VBAP (item table of SD document) and EBKN (account assignment table of MM purchase order requisition) with regard to the field PAOBJNR.

Missing functionality. The scenario described above, so a consignment in conjunction with external procurement, is not a feature of the SAP standard system.

2871175 - Third party sales order item's confirmation

As per standard config, third party sales order item delivery date/quantity is only updated after the purchase order is confirmed through AB confirmation.
However, if the purchase order has multiple AB confirmations, multiple schedule lines are added to the sales order. The sales order schedule line should be updated with the latest AB confirmation instead of adding multiple schedule lines per AB.

As per standard design, third party sales order items get their confirmations from purchase order items only, if the purchase order is created. The confirmations of category AB are used to update the confirmations of the sales order items. Also if the purchase order has multiple AB confirmations, then multiple confirmed schedule lines are added to the sales order item.

Scenario 1: Purchase order has multiple AB confirmations

From the business point of view it means that the vendor will deliver the goods in multiple parts (partial deliveries) and the sales department end has no influence on vendor deliveries. Vendor data will be taken over as they are entered in the purchase order.

Scenario 2: The sales order schedule line should be updated with the the latest AB confirmation instead of adding multiple schedule lines per AB

This expectation is not correct, because sales has no influence on the vendor deliveries. Sales department simply has to document the confirmations entered in the purchase order with the aim, e.g. to be able to inform the customer about real partial deliveries which he will receive (in particular, to send him an ORDRSP IDOC having realistic and correct delivery data).

Procurement

Subcontracting

196684 - Requirement dates of components in subcontract POs

The following problems occur with the calculation of the requirement dates for the components of a subcontract order or subcontracting scheduling agreement:

1. In scheduling agreements, the requirement date is calculated in different ways. This depends on whether the scheduling agreement delivery schedule line is created manually or by the MRP run.

The MRP run calculates the requirement date on the basis of the delivery date as follows:

first, the planned delivery time (in calendar days) is deducted from the delivery date, this is then converted to the last workday before it (if neccesary) and the purchasing processing time (in workdays) is deducted.
If a schedule line is entered manually, the purchasing processing time is not taken into account.

2. If when you create a subcontract order the delivery date minus planned delivery time date is in the past (to be more precise: before the purchase order date), the requirement date is set to the purchase order date. As a result, information as to which delay the provision of components has is lost.

3. When you convert a PReq into a purchase order, the requirement date can "jump" to a later date if the purchasing processing time is greater than 0. (The requirement date in the PReq is the release date of the PReq, which includes the purchasing processing time.) This is confusing for the user and also causes problems with the availability check of the components.

4. A subcontract purchase requisition is generated from a production order that has the operation components assigned to it as components to be provided. When you convert this purchase requisition into a purchase order, the requirement date of the components and the release date are determined differently for the dates specifed in the subcontract purchase requisition.

2027986 - The way of requirement date calculated in T-code ME2ON

The requirement date (release date) of the components is always calculated as follows:

the planned delivery time (in calendar days) taken from the info record is deducted from the delivery date, the resulting date is converted (if necessary) to the last workday before it and then the purchasing processing time (in workdays) is deducted.

So the requirement date = delivery data in the PO - planned delivery time - Purchasing processing time in working days (T-Code OPPQ).

1170805 - Requirement dates of components for subcontract order VI

A production order contains a subcontracting type operation.

When you save (or release) the order, a subcontracting purchase requisition is created.

When this purchase requisition is converted into a subcontract order, the requirement date is determined using the release date of the purchase requisition, and when the subcontract order is created, it can only be redetermined if the delivery date changes.

The release date is redetermined when the subcontract order is created using transaction ME21N.

1920439 - How are the subcontracting requirements displayed in transaction codes MD04 and MD05?

In subcontracting process, the necessary materials of making subcontracting assembly need to be purchased by ordering company, then transfer to subcontracting vendor. But it is often not so clear how the requirements of those subcontracting materials are displayed in transaction codes MD04 and MD05. E.g. some subcontracting requirements appear in both plant segment and subcontracting vendor segment but some others are only in subcontracting vendor segment.

The subcontracting requirements of transaction codes MD04 and MD05 are displayed as following example in 2 segments generally, one is plant segment which represent the ordering company, another one is subcontracting segment for subcontracting vendor. The requirements can appear in both segments or only in subcontracting segment according to stock situation of subcontracting vendor.

Here is an exmaple of transaction code MD04 of a model.

Component material M is purchased by plant P which belongs ordering company, then transfers it to subcontracting vendor V.

Date MRP Element. Requir/Recive Avail. Qty.

**************Plant segment**************************

Today Stock 500

Date3 Subreq3 220- 280

Date4 Subreq4 400- 120-

**************Subcontracting segment*****************

Today Subcont.Stock of Vendor V 380

Date1 Subreq1 100- 280

Date2 Subreq2 200- 80

Date3 Subreq3 300- 220- >>> Shortage occurs.

Date4 Subreq4 400- 620-

In principle, the system consumes the subcontracting stock first, then takes the plant segment stock of ordering company into account.

As we see above, the shortage occurs in subcontracting vendor segment at date 3 by subreq 3 and quantity 220, so this requirement and its next requirement subreq 4 also appear in the plant segment to consume the plant stock. The requirements of subreq 1 and 2 can be covered by the stock of subcontracting vendor, so they don't need to be appeared in plant segment. This is reasonalbe in business and it is the cause why some sub requirements are in plant segments but some others are not.

And, only the ones appearing in plant segment are considered to create new procurement proposals to purchase from outside by the plant of ordering company.

The above case is for the situation when no MRP Area is created for the subcontracting vendor and assigned to the material master.

If the MRP area is created, the proposals are created in the MRP area segment and doesn't transfer the requirements to plant.

2176766 - Requirement date (re)calculation logic in subcontracting during conversion of requisition to PO

The system behavior concerning the scheduling of subcontracting Preqs and POs has been standardized/stabilized via SAP note 196684. The only exception are Preqs and POs from PP orders as part of an operation without a material number.

If you create a PR out of a planned order or a production order, the scheduling is already performed in these documents via the operation data and should not be changed anymore during the creation of the PO. There has been an error regarding this which was fixed with Notes 366843, 523604 and 1170805 in the include MM06EFLB_MDPM_MAINTAIN. For this reason SAP decided to create the exception for the case of ESTKZ “F” and “U”.

This rule is not valid for POs created out of Preqs from MRP or directly in dialog, as here you have to take the planned delivery time and the info record into account to have an accurate requirement situation and to calculate the requirement dates of the components accordingly.

Before note 366843, the system behavior was as follows:

When you converted such a Preqs into a PO, the system considered the planned delivery time. Consequently the release date/requirement date of the components in the Preq and in the PO were calculated completely differently. This was wrong in case of the scenario with ESTKZ “F” and “U” due to the fact that scheduling already took place.

Therefore the current system design is correct and is not changeable. A change here could result that the scheduling will not consider agreements with the vendor concerning delivery times and GR processing times for material POs.

Additional information

2513980 - Intercompany billing - posting to vendor account using EDI in SAP S/4HANA

Automatic posting to vendor account is done by EDI. In our case where both companies are processers in the same system (& client), it is sufficient to create Idoc. This process requires several steps:

1. Creating a Customer to represent the receiving company

2. Creating a Vendor to represent the supplying company

3. Creating a Port

4. Maintain an Output Type - you need to use RD00 as dummy type for IDOC!

5. Creating a Logical Address

6. Creating a Partner Profile for both Customer and Vendor

7. The relevant FI customizing is maintained.

See details with screenshoots to the steps in the attached pdf file.

338922 - Analysis information for cross-company transactions (delivery)

Refer also to the related SAP Note 308989 "Consulting note for cross company transactions".

1. Creating the intercompany billing (ICB) document

When you create the customer billing document, the billing index for the internal billing document is set up (exception: SAP Note 38501 (Release 22A - 46C) is implemented). When the ICB is created, the index is reduced again.

If the delivery document is not displayed or displayed in error in the billing due list for ICB, first refer to SAP Note 301254 (release-independent). If the delivery contains some items that are relevant to ICB and some items that are not relevant to ICB, see SAP Note 22771 (Release 22A-22E).

You cannot create the internal billing document.

Symptom: The fields of the delivery that are relevant to ICB

- LIKP-VKOIV

- LIKP-VTWIV

- LIKP-SPAIV

- LIKP-FKAIV

- LIKP-PIOIV

- LIKP-FKDIV

- LIKP-KUNIV

are not filled.

Consequence: the status VBUP-FKIVP is not set.

As of Release 4.0, the system issues error message VF 162:

"Please check Customizing for cross-company".

Cause: Customizing is incorrect or there is incorrect master data.

The copying control is also not maintained correctly.

Solution: Create the correct copying requirement from delivery to ICB:

"014" (header) and "015" (item).

Check Customizing and the master data.

For more information, see SAP Note 158721 (Release 40A-46A).

You may create the internal billing document several times.

Cause: The delivery has an incorrect billing status.

Solution: If the ICB document was canceled, and the delivery now has an incorrect billing status, implement SAP Note 132821 (Release 30A-45A).

In addition, you must set up the billing index again

(report RVV05IV) - SAP Note 128947 (release-independent).

2. Incorrect status

When you create the ICB document, the goods movement status (field VBUK-WBSTK) is reset from "C" to "A" if the order is a cross-company stock transport order. Implement the corrections from SAP Note 121191 (Release 31H-45A).

To correct the incorrect status in the delivery document, use the correction report ZZDELSTA from SAP Note 137011 (Release 30A-46C).

3. Cancellation

If you cancel an internal credit memo for a returns delivery, the goods movement status (field VBUK-WBSTK) is reset incorrectly.

To correct this, implement SAP Note 164074 (Release 31H-46A).

If a goods receipt is canceled for a cross-company-code stock transfer, the goods movement status (field VBUK-WBSTK) is changed from "C" to "A".

Corrected with SAP Note 204435 (Rel. 31H - 46C).

Error message VF034: "Delivery & does not exist"

You can delete a delivery item even though the internal billing document for this item exists already. That is, no check is carried out on the ICB document when you delete the delivery item.

Corrected with SAP Note 165344 (Release 300-46A).

Error message F5702: "Balance in transaction currency"

Corrected with SAP Note 112562 (Rel. 30C-45A).

If the results analysis (CO) is incorrect when you cancel the ICB document, see SAP Note 105603 (Release 30C-40B).

4 Additional error messages

VF 084: "Material data not fully maintained for sales org.& & language &"

When you create the ICB document, the material data is read with the sales organization (VKOIV) and the distribution channel (VTWIV) of the delivering company code. Therefore, the sales view of the material must also be maintained for the delivering organizational data. This strict handling method was implemented with SAP Note 189639 (Release 300-46B). If you have not implemented this SAP Note, you can also create the ICB document without the material master for the supplying sales organization.

To repeat the process consistently, maintain the organizational data.

VF 091: "Material & has not been maintained"

An item with a material that is flagged for deletion cannot be billed, because the system reads the material data for an item without an order reference during billing. To correct this, implement SAP Note 315175 (Release 30A-46A).

5. Cost condition

Duplication of cost

If during the cross-company code stock transport order, goods issue and goods receipt take place before the ICB is created, the cost is determined with the duplicate condition value. SAP Note 85745 (Release 30A-31l) corrects the determination of the condition value. However, it CANNOT be used if you have implemented SAP Note 127139 (Release 300-40B). In this case, see SAP Note 163348 (Release 300-31l).

If internal credit memos for stock transfer returns are created, implement SAP Note 164074 (Release 31H-46A) to correct the duplicated cost.

Incorrect cost

If the billing document was created after the changeover to the euro, an incorrect cost may be determined. To correct this problem, implement SAP Note 128172 (Release 30F-45A). If you have implemented SAP Note 128172, you must refer to SAP Note 141778 (Release 30F-45B).

If the goods issue is canceled during the cross-company code stock transfer, implement SAP Note 204435 (Release 31H-46C) to correct the incorrect cost.

6. Conditions PI01/PI02/IV01/IV02

In the standard system, the ICB prices in the ICB document are determined from the relevant condition master record. If you manually change the conditions, the changes are not transferred to the ICB document. However, if you want to transfer price changes, see consulting SAP Note 195094.

If you want to prevent the redetermination of a condition, use the user exit FORM USEREXIT_PRICING_RULE, FORM USEREXIT_PRICING_COPY. See SAP Note 24832 for more information (release-independent).

In this case, note that not only the taxes but also the conditions for the pricing type "G" are redetermined with condition category = "l". Therefore, it makes sense to define a separate pricing type.

In the stock transfer process, you may want the value in the ICB document to correspond to the value in the stock transport order. As of Release 4.0, you can copy conditions from the stock transport order. For this, you must go to Customizing for the copying control (delivery after billing document) and select "A" (conditions from the purchase order) in the price source field. It also makes sense to select the pricing type "G" here.

If the condition PI02 is used as a transfer price for the ICB document, you must also execute a normal pricing for free-of-charge items. SAP Note 33258 (Release 30A-40B) contains a solution for this.

For more information, see SAP Note 33382 (release-independent).

7. Currency change

If the document currency is changed in the ICB document, or if another currency that does not correspond to the document currency of the order is assigned to the internal customer, foreign currency translation errors may occur. This is because the exchange rate (from condition currency to local currency) is also redetermined, which should not be the case.

When you implement SAP Note 135220 (Release 40A-46A), the translation (from condition currency to local currency) is only executed while a document is being copied if the local currency of the billing document differs from the local currency of the preceding document. For this, the local currency of the related order is defined in the billing document.

8. Tax

You can access the tax condition records using country of departure and destination country. You can access customer master and material master to determine the tax classification using the country of the plant. The country of the company code of the delivering plant is used as the country of departure. The delivering sales organization defines the destination country (customer master record of the ICB customer).

If you want a different system response, see SAP Note 10560 (Release 22A-46B).

If the tax conditions are determined with errors for the ICB document, refer to the following SAP Note: SAP Note 151941 (Release 40A-45B).

If a billing document cannot be transferred to accounting due to an incorrect value-added tax indicator, implement the corrections contained in SAP Note 68092 (Release 30A-40B).

For the ICB document, the "Country of destination of sales order" field (VBRP-LLAND_AUFT) is filled with the country of the ship-to party from the ICB customer, and not the land of the ship-to party from the order.

If you do not want this, implement the program correction contained in SAP Note 99745 (Release 30A-31l).

The "Region of sales order" field (VBRP-REGIO_AUFT) is filled in the same way. Implement the corrections contained in SAP Note 159115 (Release 30A-46A) and SAP Note 204996 (Release 30A-46B) here.

If there is a consignment issue for a plant abroad, implement the correction contained in SAP Note 213500 (Release 40A-46C). As a result, the tax departure country is set the same as the country of the plant (or company code).

9. Setting reason for rejection

In the returns request, a reason for rejection is set. This reason for rejection is set in Customizing so that the item is no longer relevant for billing. Despite this, you can create the internal credit memo with reference to the returns delivery for returns handling. This is because the reason for rejection ensures that this item is billable only during order-related billing. The billing status for the ICB (VBUK-FKIVK and VBUP-FKIVP) is created when the delivery is created. The billing status is no longer affected when you enter a reason for rejection in the order document. You can complete this item by flagging the item as statistical (VBRP-KOWRR = "X") and, as a result, billing the item with the value zero. For more information, see SAP Note 209934 (Release 30F-46B).

VF 087: "No exchange rate found for & / &"

If the purchase order item is rejected during a stock transfer process, the system displays this error message while the internal credit memo is being created.

Corrected by SAP Note 174600 (Release 31l-46A).

10. Billing block

No billing blocks can be set for internal billing documents.

Corrected by SAP Note 163788 (Release 300-46A).

11. Partner determination

In the standard system, the (header) partner functions sold-to party (AG), bill-to party (RE), and payer (RG), and the (item) partner function WE for the ICB document are equated with the internal customer.

For more information, see SAP Note 141676 (release-independent).

Exception: For the partner function ship-to party (WE) (at item level), the actual physical ship-to party can be used.

For the stock transfer process, you should refer to the Customizing specifications for partner determination from SAP Note 106821 (release-independent).

If the partner RE or RG in the internal billing document contains an incorrect name, implement the corrections for this in SAP Note 172583 (30A-46A).

For information with regard to manual address changes, see SAP Note 33112 (Release 22E-40B).

If an invoice split occurs when you create the ICB document, even though all VBRK fields are identical, the cause of the split may be the customer hierarchy.

In this case, SAP Note 40299 (Release 22A-45B) provides a solution.

12. Business area determination

KI 188: "&2 &1 belong to business area &3 not &4"

To correct this, implement SAP Note 134386 (Release 30C-45A). For more information, see SAP Note 175681 (Release 30D-46A).

13. CO account assignment

For incoming orders, the CO object is created in the company code of the plant (activity output). Two account assignments are required for billing: the customer billing document is updated with the organizational data of the selling company code and the ICB document is updated with the organizational data of the delivering plant. The account assignment is generally dependent on the control of the controlling area (transaction OKKP). In particular, it is dependent on the type of profitability analysis (costing-based or account-based profitability analysis).

For account assignment logic, see SAP Note 83702 (release-independent).

SAP Note 138221 is a composite note for account assignment and cross company sales. The account assignment from Sales and Distribution (SD) also depends on whether the process is a direct sale or repetitive manufacturing, or whether it is a make-to-order production.

The system may issue the following error messages: - KI 100: "The CO account assignment object belongs to company code &3, not &4"

- KI 162: "No account assignment to customer order (not active in COArea &, year &)."

If it is a make-to-order production, the customer billing document cannot be transferred to financial accounting due to these error messages. To correct this, implement SAP Note 76911 (Release 300-45A).

For returns, see SAP Note 141224 (Release 300-31I) if the goods are returned to a plant that belongs to the company code of the order and not the company code of the delivery.

If during the stock transfer process, the ICB document is not transferred to financial accounting, implement SAP Note 202765 (Release 40A-45B).

For creating with reference, see SAP Note 121599 (Release 30C-45A).

If individual conditions or complete billing items are missing from the profitability analysis, see SAP Note 20254 (release-independent).

If the system issues error message KI 203 "Company code & is not assigned to CO area &" during cross-controlling area sales, implement SAP Note 105258 (Release 30C-40B).

If there are incorrect values or currencies for the planned revenues, implement SAP Note 178999 (Release 30D-46B) and SAP Note 158998 (Release 30D-46A).

Profitability segment VRBP-PAOBJNR

The profitability segment in the ICB document is determined with the customer data of the internal customer and the organizational data of the company code of the plant. The delivering sales organization or distribution channel is therefore transferred to the profitability analysis (this is correct). Refer to the source code in SAP Note 98570 (Release 30C-40B).

For make-to-order productions, this function is only available in the standard system as of Release 4.0. For earlier releases, implement SAP Note 78544 (Release 30C-31I) for each case. To implement a different program logic as of Release 4.0, you must make a modification.

If it is not a make-to-order production, see SAP Note 114958 (Release 30C-45A). For more information, see SAP Note 166803 (Release 30D-40B).

For more information, see SAP Notes:

- 70159 (Release 300-31I)

- 102049 (Release 30C-40B)

- 117981 (Release 31G-45A)

- 102049 (Release 30C-40B)

Special feature for automatic posting to vendor account:

If the invoice receipt is not posted manually but instead directly to financial accounting using SAP Electronic Data Interchange (EDI), an automatic posting to the vendor account takes place. If the account-based profitability analysis is active, the costs are posted to CO-PA (profitability analysis) using this posting to the vendor account. If you want a different system response, you must implement a modification. If the costs have already been transferred to CO-PA in the customer billing document using the condition type PI01/PI02, a duplicate entry occurs. To avoid this, do not assign a value field to the condition type PI01/PI02.

Profit center (VBRP-PRCTR)

SAP Note 39254 (Release 30D-40B) describes how the profit center is determined for the cross-company code sales.

KM 026: "Profit center does not exist for &"

To correct this, implement SAP Note 180795 (Release 45B-46B).

If no intercompany billing is involved and you want the account assignment to be made in the customer billing document, the following may occur: the sales order is posted to the company code of the producing plant, which means the profit center is the plant. When the customer billing document is released to accounting, the system displays error message KI 100. SAP Note 69314 (Release 30A-40B) removes the account assignments when the customer billing document is created, and the profit center of the selling company code is determined. This may cause the system to issue error message KI 235. To avoid KI 235, post to a different account or find a dummy account assignment that is then reassigned to CO.

For more information, see SAP Note 112974 (Release 30C-45A).

Work breakdown structure (WBS) element VBRP-PS_PSP_PNR

The WBS element is entered at item level. SAP Note 190103 (Release 30C-40B) ensures that the WBS element belongs to the company code of the sales order item. That is, the system checks whether the WBS element belongs to the company code of the delivering plant. However, in the customer billing document, the system posts to the WBS element of the selling company code and not to that of the delivering company code. This is the standard system function. When the internal billing document is created, the costs and revenue are allocated, which completes the cross-accounting sales.

VF 155: "Revenue of leading WBS element & determined by substitution from &"

To correct this, implement SAP Note 135449 (Release 40A-45B).

For more information, see SAP Note 165267 (Release 30D-46A).

Cost center VBRP-KOSTL

You use an order reason to determine the cost center in the sales document.

This cost center is used only for the posting in the selling company code (that is, for the customer billing document), not for goods issue and ICB.

If the cost center is not posted to in the company code of the plant, see SAP Note 76466 (Release 30E-46B).

14. Correction reports

Use the report RVV05IVB from SAP Note 128947 (release-independent) to reorganize the billing index.

Use the report ZZDELSTA from SAP Note 137011 (Release 30A-46C) to redetermine the status in the delivery.

To correct existing deliveries that are incorrect due to incorrect Customizing settings, contact SAP Support or your SAP consultant.

39254 - Profit center, cross-company code sales

1. Sales order (in the selling company code)

The profit center in the sales order item belongs to the supplying company code. The profit center is proposed from the material master for the supplying plant but can be replaced by another profit center of the supplying company code (manually, actual account assignment, PCA substitution). This profit center is used as the profit center in goods issue posting and for internal billing documents.

When a profit center is entered manually, a check is performed to see whether the profit center entered belongs to the controlling area of the supplying company code. With profit center substitution (transactions 0KEL and 0KEM), both the 'Profit Center' field (PRCTR) and the 'Profit Center for Billing' field (PCTRF) are filled when you create the sales order.

The functions of profit center substitution are described in SAP Note 167912.

Please see also SAP Notes 815972 ('PCA substitution for cross-company-code sale') and 916973 ('Incorr partner PC in intercompany billing before ext billing') for the determination of the field for the billing document profit center (PCTRF).

History:

In the case of cross-company sales, profit center substitution is not active when the system creates sales orders (in Release 3.0C - 4.0B). Substitution can derive a profit center from sales order data. This data belongs to the selling company code (for example, the customer number), and not to the supplying company code. Therefore, a substitution is not useful. Furthermore, when the system creates sales orders in the case of cross-company sales (in Releases 3.0C - 4.5A), profit center substitution does NOT contain internal billing document data (internal customer number, internal sales area) in addition to the data for external sales. These two functions can be implemented in the aforementioned releases using SAP Note 112974.

2. Goods issue (in the supplying company code)

The goods issue copies the profit center from the sales order.

History:

Up to Release 3.0B, see also SAP Note 37800.

3. Customer billing document (in the selling company code)

During the creation of the customer billing document in the cross-company-code scenario, the profit center (PRCTR) is always deleted and redetermined. The reason for this is that the profit center transferred from the sales order is the profit center of the supplying view, not the selling view. This means that it cannot be used for the billing document.

To redetermine the profit center, maintain and activate a substitution rule in Customizing for Profit Center Accounting (transactions 0KEL and 0KEM). If this has already been done at the event 'Create Sales Order' and the field for the billing document profit center (VBAP-PCTRF) has therefore been filled, this profit center is copied to the external billing document item.

However, you may want the profit center to be copied from the order item. Please see SAP Notes 106875 and 713228 in this regard. See also SD note 1532865 - FAQ: Profit center in billing document

4. Intercompany billing (in the supplying company code)

The intercompany billing copies the profit center from the sales order.

To correctly determine the partner profit center for intercompany billing up to and including Release 4.6C, you need to create a customer billing document (or a customer credit memo) before intercompany billing. With Release 4.7, the 'Profit Center for Billing' field was added again to the table for order items (VBAP-PCTRF). Therefore, you no longer need to adhere to the time-based sequence of creating an external customer billing document before an internal customer billing document if the "Profit Center for Billing" field is already filled when you create the sales order. See Notes 815972 and 916973.

To read the partner profit center for the intercompany billing, the preparations for consolidation must be maintained (OCCL, OCCI - see SAP Note 161277, too). If CRM is active, the R/3 routines for determining the partner profit center (transaction OCCL) do not work. For more information, see SAP Note 570567 as well.

When the intracompany billing is saved, an IDoc is created. This is used as the basis for the posting of the invoice receipt in the selling company code. When the IDoc is created, transaction VOFC (change view 'Billing document: Switch for acc. elements of IV to CO') is executed. As a result, if the IDoc type INVOIC02 is used, the following account assignments are copied from the billing document:

Cost center = KOSTL (segment E1EDP30 with qualifier 045)

Profitability segment = PAOBJNR (segment E1EDP30 with qualifier 046)

Work breakdown structure = PSPNR (segment E1EDP30 with qualifier 047)

Profit center = PRCTR (segment E1EDP30 with qualifier 048)

Business area = GSBER (segment E1EDP30 with qualifier 049)

Partner profit center = PPRCTR (segment E1EDP30 with qualifier 078)

In the customizing for intercompany billing under "Automatic Posting to Vendor Account (SAP-EDI)" (transaction VOFC), activate the process for copying account assignments from the external billing document. You must activate the billing type for the intracompany billing and the billing type for the reversal for the intracompany billing.

History:

If the external billing document is created before the internal billing document, the partner profit center is determined by reading the selling profit center from the customer billing document data (or the customer credit memo in the case of a return). However, the system does not read the table VBRP of the billing document items. Instead, it reads the PrintView table VBDPR that exists in SD.

To read the partner profit center for the intercompany billing, the preparations for consolidation must be maintained (transactions OCCL and OCCI - see SAP Note 161277, too).

Up to and including Release 4.6C, the external billing document must be created before the internal billing document. Up to Release 4.5B, please refer to the program corrections contained in SAP Note 114954.

To handle cross-company sales without intercompany billing, please refer to SAP Note 69314 up to and including Release 4.0B.

5. EDI invoice receipt (in selling company code)

Profit center: As of Release 4.0, you can use transaction VOFC to make a setting so that account assignments are copied from the customer billing document for the automatic EDI invoice receipt. Transaction VOFC is executed when the intracompany billing is saved and is reflected in the IDoc, which is used to post the automatic EDI invoice receipt. (See also point 4 - 'Intercompany Billing'). For this, the customer billing document must be available before the internal billing document.

In the case of the posting of an invoice receipt with EDI where the intercompany billing has already been posted (document type IV) but the customer billing document has not (document type F2), please see SAP Note 607799.

To set the partner profit center for EDI invoice receipt, note the following:

If you have maintained the preparations for consolidation (transaction OCCL, see also SAP Note 161277), the partner profit center is read from the customer sales order profit center (VBAP-PRCTR = supplying view).

In addition, note that the field for the partner profit center in the field status variant of the accounts concerned must be ready for input (transactions OB14 and OB41).

History:

SAP Note 166462.

If, in the case of cross-company processing, the profit center is not copied from the customer billing document for the automatic EDI invoice receipt, refer to SAP Note 134656 (Releases 3.0D - 3.1I).

Information about IDoc types 'INVOIC01' and 'INVOIC02'

As of Release 4.0B, a new IDoc type INVOIC02 is available in addition to the IDoc type INVOIC01. The difference between the IDoc types INVOIC02 and INVOIC01 is that the type INVOIC02 also contains the E1EDP30 segment for additional account assignments during intercompany billing.

If you use the IDoc type INVOIC02 (definition in the partner profiles of the sender), at present the account assignments for the project, profit center, cost center, profitability segment, business area, and partner profit center are automatically copied to the FI document from the customer billing document by transaction VOFC. Therefore, the advantage of this IDoc type in comparison with the IDoc type INVOIC01 is that the account assignments are already contained in the IDoc (and therefore in every process). Consequently, the standard customizing for the derivation of an additional account assignment in the table T076K (transaction OBCC) or the user EXIT_SAPLIEDI_002 may no longer be required at all if the six account assignments from the customer billing document (or the E1EDP30 segment) are sufficient.

We recommend using the IDoc type INVOIC02 with the message INVOIC when you post intercompany billings with EDI or EDI invoices in FI. For account assignments in INVOIC02, see also SAP Note 170809.

The account assignment options of INVOIC01 and INVOIC02 are compared below:

INVOIC02

1. TC OBCC - Table T076K (with SAP Note 170809)

2. TC VOFC (additional account assignments INVOIC02, segment E1EDP30)

3. EXIT_SAPLIEDI_002 (with SAP Note 170809)

INVOIC01

1. TC OBCC - Table T076K

2. EXIT_SAPLIEDI_002

If you do not use the user exit and if both account assignments from segment E1EDP30 (only for INVOIC02) and Customizing account assignments from the table T076K exist, the relevant account assignment from the E1EDP30 segment has priority over the customizing account assignment. However, if no account assignment exists in the E1EDP30 segment but is defined in customizing in the table T076K, the customizing entry is transferred to the FI document.

Additional information

Internal billing

IC billing type determination

it is set in the referenced document type (V0V8), and for a new item from the default sales document type ( V0V8. 0VLK ). The billing types must be the same, if it is not then it will be an error:

FV50XFLP_LIPS_MATNR_PRUEFEN
Delivery item 90001 HUM
call function 'LE_SHP_AUART_DETERMINE'

Outb -> Inbound INVOIC with/wout ref. to a pur.document

INVL when we have real reference to a purchasing document, otherwise INVF.

137686 - ALE_INVOIC01: Internal allocatn Customizing in FI

Check the settings in Customizing described below and make the required changes, if necessary.

1. An internal vendor which represents the delivering company code must be created in the selling company code.

2. A partner function must be created for the internal vendor via the maintenance of purchasing organization data.

3. Using Transaction WE20 create a partner profile with partner type LI in which you maintain the inbound parameters for the message type INVOIC and the message variant for FI. Enter the process code INVF for the inbound options.

4. Specify if necessary how the vendor is to be determined from the EDI invoice.

a) With this in mind you can define a logical destination in table EDILOGADR for each delivering company code and customer. The logical destination specifies to which company code and which vendor account is to be posted with the incoming invoice.

- Logical address = supplying company code (four-digit) followed by the 10-character customer number (for example, if company code = 0001 and internal customer = 4711, then EDILOGADR-LOGADR = 00010000004711 is entered)

- Application (EDILOGADR-EDI_APPLIC) = V3

- Destination (EDILOGADR-EDI_DESTIN) = selling company code and vendor (the format is similar to that of the logical address)

b) The vendor number is entered directly in the IDoc or determined by the EDI converter. In this case it is found in field PARTN of the first E1EDKA1 segment with partner function RS (invoicing party) or LF (Vendor).

c) The 3rd option would only be relevant for EDI invoices from external vendors. In the IDoc, you can enter the account number under which the receiver is managed for the sender.The account number must in this case be transferred in the segment E1EDKA1 in the field LIFNR. Furthermore, field LFB1-EIKTO (Our account number with the vendor) must be filled in the vendor master record.

5. Using Transaction OBCE maintain the program parameters for the partner type LI, your internal vendor (and its number as partner, for which the partner profile was maintained) and also the company code in which the internal invoice is to be posted.

Minimum details: Posting keys and document types

If you set the flag 'Calculate tax' to recalculate the tax of FI based on the tax information transferred in the IDOC, the flag 'Calculate taxes on net amount' must be set in the user options (Transaction FB00) of the user processing the IDocs.

6. In Transaction OBCA maintain the assignment of the company code which is in the internal billing document, for the company code to be posted for the receiver.

7. In Transaction OBCB, maintain the G/L accounts which should be posted to according to the goods/service number from the IDoc.

Minimum entry: Standard entry * with G/L account and company code

8. In Transaction OBCC maintain the additional account assignments for the CO account assignment objects which correspond to account assignment ID in the IDoc.

Minimum entry:Account assignment ID * without specifying account assignments

9. In Transaction OBCD maintain the assignment of the tax code in the tax segments of the IDoc to the corresponding tax code for the receiver. To do this refer also to the F1 help for the input fields.In field 'Tax type' enter 'VAT'.In field 'Tax rate' you must enter the tax rate that is transferred in the IDoc.In doing this, it is important that the entries match character for character.

If you use Release 4.5A or higher, you must also maintain the entry for the country of the partner.

A program error may be the cause if errors occur in processing of the IDoc after checking these settings.In this case you should consult Note 142642. If you need further assistance, contact SAP R/3 Support.

2460512 - Error FD150 during INVOIC IDoc processing

This error is caused by a missing customizing in OBCB.
A G/L account could not be determined from the invoice specifications for the specified item.
The goods/service number as per the G/L account is determined is not entered in Financial Accounting customizing (transaction code OBCB).

The goods/service number is taken from the intermediate document type field
- INVOIC01: E1EDP19-IDTNR (for E1EDP19-QUALF = "002 - Vendor's material number").

Please check and enhance your customizing in transaction code OBCB.

You can use the sign "+" or "-" for surcharge or discount (E1EDP05).
Otherwise, for every other line item (E1EDP19) you are supposed to use “*”, or an explicit value.

946072 - EDI: Error message 06 019 during invoice entry

You enter an incoming invoice by EDI with the 'INVOIC' IDOC type and the 'IDOC_INPUT_INVOIC_MRM' function module. The 'Goods-receipt-based invoice verification' indicator is set for the corresponding purchase order item.
If the delivery note number specified in the IDOC is incorrect (E1EDP02/ qualifier segment 16), the system issues error message M8 183 ' Delivery note/service entry sheet & & does not exist'.

31126 - Intercompany billing - posting to vendor account with EDI

1. Create a vendor master record that represents the delivering company code. This vendor master record must be created in the selling company code.

2. Output type:

Output type RD04 is set up for posting to vendor account in ICB (transaction V/40).

3. Output determination procedure:

Output determination procedure V40000 applies for billing type IV.

4. Creating an output condition record (transaction VV31):

Output type "RD04" and the customer for ICB.

5. Output control:

In the administration for EDI processing, a partner profile must be maintained for the output control for inbound and outbound processing since the sender data and the recipient data is required. The outbound process code is used to trigger a Version 5 function module (Version 3.0 function module to trigger inbound processing).

Outbound process code: SD08.

For further information about the output configuration, refer to the "Output" section in the IMG.

6. Outbound processing:

Important: The field KNVV-EIKTO (account number at the customer) must be maintained in the customer master data (transaction VD02 -> sales view).

a) Partner profile (transaction: WE20)

Partner No.: Specify customer number IV

Partner type: KU

b) Message control:

Partner No.: Customer number IV

Partner type: KU

Partner role: RE

Application: V3

Output type: RD04

Output :

Output type : INVOIC

Output code: FI

Outbound Options:

Outbound code: SD08 : INVOIC: Internal allocation

c) Outbound parameters:

Outbound Options:

Receiver port: for example SAPP30 EDI MM Development

IDoc type: INVOIC02

Basic IDoc type: INVOIC02

7. Inbound processing (transaction SBPT) for the customer:

a) Input parameters:

Partner No.: Specify vendor number

Partner type: LI

Partner role:

Output type : INVOIC Invoice/Billing document

Output code: FI

Process code: INVF

8. Check the process code and processing function module assignment.

Transaction: WE42 -> Basis -> Control -> Inbound process code -> Processing by function module -> Processing with or without ALE

Code: INVF

Identification: IDOC_INPUT_INVOICE_FI (INVOIC FI Invoice receipt)

Code FI03 to 3.0E

Identification: IDOC_INPUT_INVOICE_FI

9. Vendor:

A vendor must be assigned for each company code and ICB customer.

You can make this assignment in Customizing.

Choose the following IMG path:"Sales and Distribution -> Billing -> Intercompany Billing

-> Automatic Posting To Vendor Account (SAP-EDI)"

Example:

Data:

Delivering company code: 0001

Customer: 0000000001, created in delivering company code

Selling company code: 0099

Vendor: ALECRED01, created in selling company code

Settings:

Application: V3

Logical address 00010000000001

This consists of:

a) Delivering company code consisting of four digits: 0001

b) Customer number consisting of ten digits: 0000000001

Target:

Company code: 0099

Vendor: ALECRED01

Important:

The logical address must have 14 digits. If the customer number has less than ten digits, add leading zeros.

The system may issue the following error message if the logical address is maintained incorrectly in the table EDILOGADR:

"Company code could not be determined for intermediate document XXXXX".

Proceed in the same way for the internal credit memo.

Different system settings for the logistics invoice verification:

6. Output control:

Output code 'MM'

7. Inbound processing

Output code 'MM'

Process code 'INVM'

as of Release 4.0 'INVL'

8. Check the process code and processing function module assignment.

Transaction: WE42 -> Basis -> Control -> Inbound process code ->

Processing by function module -> Processing with or without ALE

Code 'INVM'

Identification: 'IDOC_INPUT_INVOICE_MM'

Code 'INVL' (as of Release 4.0)

Identification: 'IDOC_INPUT_INVOICE_MRM'

How to set up intercompany billing - vendor invoice via EDI scenario at SD side

Create a vendor master record that represents the delivering company code. This vendor master record must be created in the selling company code.
For billing type IV, procedure V40000 is assigned(T-code: VOFA)
In the customer master of internal customer, vendor should be maintained in field “Acct at cust.”(T-code: XD02)
Create partner profiles for internal customer

Add outbound parameters for KU partner
Partner role should be BP, Message Type: INOVIC, Message code: FI, Basic type: INVOIC02, Receiver port also need to be entered

Application: V3/Message type: RD04/Process code: SD08 ( SD08 points to idoc_output_invoic_iv_mm - intercompany billing )

Create partner profile for vendor

Message type: INVOIC / Message code: FI / Process code: INVF

A vendor must be assigned for each company code and ICB customer.
Maintain output condition records for output type RD04
Run VF31 to process this output

Different system settings for the logistics invoice verification, in case that you need to get MM invoice verification to be created:

Partner profiles - Settings for outbound parameters/ Message code: MM
Process code: INVL
MM customizing : Materials Management - Logistics Invoice Verification - EDI - Enter Program Parameters

Fills organizational data used for internal billing

Two cases are possible:

The delivery is already relevant for internal billing. In this case the IB data of the current plant must match with the existing data
The delivery is not yet relevant for internal billing. The IB data of the current plant are copied to the delivery header if they are filled

TVAK-FKAIV

LIKP-FKAIV..