Topic overview

This article describes procedures for using the Import data application in relation to inventory postings. These procedures contain general instructions, e.g. which special features need to be taken into account.

The description of the Import data application, which also includes field and button descriptions, can be found in the Import data article.

Definitions of terms

Voucherless demand
The pseudo-voucher voucherless demand is available in order to be able to reserve a demand without having to create a voucher beforehand. A voucherless demand has an identification number and counts towards the demand origins (element).

General information

The import of inventory postings is to be understood as an option for submitting inventory postings via the import interface, which can be used primarily for transferring legacy data from inventories and for electronic confirmation of inventory postings.

Importing inventory postings results in the inventory records, availability records and/or the inventory valuation being updated in the imported inventory postings, depending on the posting key used. If a special process is specified, the import can also lead to the updating of a voucher status or the updating of a voucherless demand.

To be able to send inventory postings via the import interface, you must define at least one filter for importing inventory postings.

When submitting inventory postings via the import interface, the same validations are performed as when submitting a inventory posting via the Inventory postings application. For example, you cannot import an inventory posting for a warehouse for which you do not have authorization. In this case, an error message is displayed and an entry is created in the data exchange log.

Procedure

1. Open the Import data application
2. Display a filter for the business object com.cisag.app.inventory.obj.InventoryTransaction

• The filter for importing inventory postings is displayed.
  (If required, you can also create a new filter for this business object part).

3. The selected attributes of the filter are already highlighted. If necessary, you can still adjust the attributes.
4. Select the [Import data] button in the standard toolbar

• The Import data dialog window opens

5. You can make settings for the import file in this dialog box. A detailed description of the fields can be found in the Import data article in the corresponding section.
6. You can carry out the import by selecting the [In background] or [Immediately] button

Detailed information and examples

Please read the following information on the following topics:

• Submitting an inventory posting via the import interface

In this section you will also find examples of import files:

• Special features when importing inventory postings
• Importing historical inventory postings

Submitting an inventory posting via the import interface

The attributes that need to be imported in order to obtain a correct inventory posting depend on the item, loading unit, posting key and warehouse used. A list of the supported attributes can be found under Overview: Supported attributes during import.

 <?xml version="1.0" encoding="UTF-8"?>
<semiramis xmlns="com.cisag.app.inventory.obj.InventoryTransaction" xsi:schemaLocation="com.cisag.app.inventory.obj.InventoryTransaction InventoryTransaction.xsd" locale="en-US-XMLSchemaCompliant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <InventoryTransaction xmlns="com.cisag.app.inventory.obj.InventoryTransaction">
   <Type>02</Type>
   <date>2015-04-07T23:00:00.000Z</date>
     <Item>10010</Item>
   <Identifier></Identifier>
    <ReferenceItem></ReferenceItem>
   <ReferenceIdentifier></ReferenceIdentifier>
   <Storage>
     <warehouse>HAN1</warehouse>
     <zone></zone>
     <location></location>
   </Storage>
    <ReferenceStorage>
     <warehouse></warehouse>
     <zone></zone>
     <location></location>
  </ReferenceStorage>
   <StorageUnit></StorageUnit>
   <storageUnitCount></storageUnitCount>
   <UnitLoad></UnitLoad>
  <referenceText>Importierte Materialbuchung</referenceText>
  <Partner></Partner>
  <quantity index="0">
    <amount>100</amount>
    <Uom>Stk</Uom>
  </quantity>
   <quantity index="1">
    <amount>99</amount>
    <Uom>kg</Uom>
  </quantity>
  <orderQuantity>
    <amount>1</amount>
    <Uom>Ktng</Uom>
  </orderQuantity>
  <value>
    <amount1>10</amount1>
    <amount2></amount2>
    <amount3></amount3>
  </value>
  <valueDimension>PER_UNIT</valueDimension>
  <info>
    <CostCentre></CostCentre>
    <CostObjective></CostObjective>
  </info>
  <TargetOwner>00000</TargetOwner>
  <SourceOwner>00000</SourceOwner>
  <extendedPostingOrder>
    <type></type>
    <orderType></orderType>
    <orderNumber></orderNumber>
    <detailNumber></detailNumber>
    <subDetailNumber></subDetailNumber>
  </extendedPostingOrder>
  <extendedOriginalOrder>
    <type></type>
    <orderType></orderType>
    <orderNumber></orderNumber>
    <detailNumber></detailNumber>
    <subDetailNumber></subDetailNumber>
  </extendedOriginalOrder>
  <OriginalDemand></OriginalDemand>
   <OffsetAccount></OffsetAccount>
 </InventoryTransaction>
</semiramis> 

<?xml version="1.0" encoding="UTF-8"?>
<semiramis xmlns="com.cisag.app.inventory.obj.InventoryTransaction" xsi:schemaLocation="com.cisag.app.inventory.obj.InventoryTransaction InventoryTransaction.xsd" locale="en-US-XMLSchemaCompliant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <InventoryTransaction xmlns="com.cisag.app.inventory.obj.InventoryTransaction">
  <Type>02</Type>
  <date>2015-04-07T23:00:00.000Z</date>
    <Item>10020</Item>
  <Identifier></Identifier>
   <ReferenceItem></ReferenceItem>
  <ReferenceIdentifier></ReferenceIdentifier>
  <Storage>
    <warehouse>HAN2</warehouse>
    <zone>Z1</zone>
    <location>001-001</location>
 </Storage>
  <ReferenceStorage>
    <warehouse></warehouse>
    <zone></zone>
    <location></location>
  </ReferenceStorage>
   <StorageUnit>PAL</StorageUnit>
   <storageUnitCount>1</storageUnitCount>
   <UnitLoad></UnitLoad>
  <referenceText>Importierte Materialbuchung</referenceText>
  <Partner></Partner>
  <quantity index="0">
    <amount>100</amount>
    <Uom>Stk</Uom>
  </quantity>
  <orderQuantity>
    <amount>1</amount>
    <Uom>Ktng</Uom>
  </orderQuantity>
  <value>
     <amount1>10</amount1>
     <amount2></amount2>
     <amount3></amount3>
  </value>
  <valueDimension>PER_UNIT</valueDimension>
  <info>
    <CostCentre></CostCentre>
    <CostObjective></CostObjective>
  </info>
  <TargetOwner>00000</TargetOwner>
  <SourceOwner>00000</SourceOwner>
  <extendedPostingOrder>
    <type></type>
    <orderType></orderType>
    <orderNumber></orderNumber>
    <detailNumber></detailNumber>
    <subDetailNumber></subDetailNumber>
  </extendedPostingOrder>
  <extendedOriginalOrder>
    <type></type>
    <orderType></orderType>
    <orderNumber></orderNumber>
    <detailNumber></detailNumber>
    <subDetailNumber></subDetailNumber>
  </extendedOriginalOrder>
  <OriginalDemand></OriginalDemand>
   <OffsetAccount></OffsetAccount>
 </InventoryTransaction>
</semiramis>

Special features when importing inventory postings

Incorrect inventory postings

If an inventory posting cannot be imported successfully, an entry is created in the data exchange log that can be used for error analysis. The system then continues with the next inventory posting in the import file.

The import of inventory postings leads to a change in inventories if the posting key used provides for a quantity transaction. If the inventory management server responsible for the warehouse does not have the status In operation, inventory postings are generated, but the inventory quantities and inventory values are not updated. In this case, check the status of the inventory management server. Further information on this can be found in the Inventory management server article.

Availability

The import of inventory postings leads to a change in availability if the posting key used provides for a quantity transaction and the quantity transaction occurs at warehouse level. The following scenarios are possible in which the availability is changed by an imported inventory posting:

• If the imported inventory posting is not a special process, an availability is created on the basis of this inventory posting. This availability remains in place until the imported inventory posting has been processed by the inventory management server and the inventory has been updated.
• If the imported inventory posting represents a special process, such as Reserved issue without voucher, the availability of the voucherless demand is completed during import and recreated for the inventory posting at the same time. At no time is the article quantity available as available inventory; the Completed and Generated processes reflect more of a transfer.
  As in the first case, the availability of the inventory posting remains until the inventory posting has been processed by the inventory management server and the inventory has been updated.

Reservation

The import of inventory postings leads to a change in the demand coverage or demand origin data if the posting key used provides for a quantity transaction and the quantity transaction takes place at warehouse level. Just as with availability, several scenarios are possible in which the demand coverage or demand origin data is changed when importing inventory postings:

• If the imported inventory posting does not represent a special process, demand coverage or demand origin data is generated on the basis of this inventory posting. This data remains until the imported inventory posting has been processed by the inventory management server and the inventory has been updated.
• If the imported inventory posting represents a special process, such as Reserved issue without voucher, the demand data of the voucherless demands are completed during import and recreated for the inventory posting at the same time. At no point is the article quantity available as available inventory; the Completed and Generated processes reflect more of a transfer.
  As in the first case, the demand data of the inventory posting remains until the inventory posting has been processed by the inventory management server and the inventory has been updated.

Inventory valuation

The import of inventory postings leads to a change in the inventory value if the posting key used provides for inventory valuation. Here too, the responsible inventory management server must have the status In operation for an inventory valuation to be carried out.

• If the prices are given in all currencies, these will be adopted.
• If only one currency is specified, the other currencies or those with the value zero are calculated automatically. The exchange rate that was valid at the time of the specified posting date is used.
• If no currency is specified (not even with the value zero), the price is determined using the posting key if a price is required.

Status update for referenced orders

An imported inventory posting can be linked to an inventory posting voucher and an original voucher. The inventory posting voucher is the voucher that generated the inventory posting. The source voucher is the voucher at the beginning of the voucher chain. When you import an inventory posting, the status of the source voucher linked to the inventory posting is only updated if you mark the inventory posting to be imported as a special process. The following special processes require a voucher to be specified as the source voucher:

• Supplier returns
  The specification of a purchase order line item is required

• Production receipt
  The specification of a production order is required

• Production issue
  The specification of an inventory item is required

• Co-product receipt
  The specification of a co-product item is required

• Material provided to vendor
  The specification of an item of inventory to be provided is required

In all other cases, the original voucher status is not updated by the inventory posting. The statuses of all other specified vouchers  are never updated.

Import of historical inventory postings

The import of historical inventory postings refers to the transfer of all inventory postings from a source system to a target system. In contrast to importing the current inventory, the moving average price can also be transferred. The following minimum requirements must be met:

• The imported inventory postings can be processed in the target system by an inventory management server
• The inventory postings are processed in the target system in the same order as in the source system
• There are no inventory postings for the possible valuation levels (item and item/warehouse) in the target system before the import.

The order in which inventory postings are processed by an inventory management server is of great importance for the result of the moving average price. For this reason, when importing historical inventory postings, strict care must be taken to ensure that the imported inventory postings are processed in the same order as in the source system. To achieve this, the inventory postings in the import file must be sorted in ascending order according to the internal processing number in the source system.

When importing historical inventory postings, it is also important to ensure that all inventory postings are only processed by a single inventory management server in the target system. This means that all warehouses in the import file must be assigned to the same inventory management server. If processing is carried out by several inventory management servers, compliance with the correct sequence cannot be guaranteed, resulting in an incorrect moving average price at item level.

Restrictions

When importing inventory postings for items that are stored in subdivided warehouses, please note that if the import file contains an inventory posting with storage unit, the same import file must not contain any other inventory postings for this storage location or slot. If, for example, inventories with different identifiers are to be imported, the inventory postings must be split across several import files:

Overview: Supported attributes during import

The attributes that must be imported in order to obtain a correct inventory posting (mandatory attributes) depend on the item used, the loading unit, the posting key and the warehouse.

Mandatory attributes

The following table describes the attributes that must be specified in comlocationation:

Further attributes

The following attributes are supported by the import interface in addition to the mandatory attributes:

Source voucher

The original voucher is typically the voucher at the beginning of the voucher chain. In the Inventory posting query application, the original voucheris called Order. In the original voucher, attributes must be specified down to item or sub-item level. An exception to this is the production order, where it is not always necessary to specify an item. The special processes Production issue, Co-product receipt and Material provided to vendor require the production order to be specified down to item or sub-item level.

The required attributes are described in the following table:

Inventory posting voucher

The inventory posting voucher is the voucher that generated the inventory posting. In the Inventory posting query application, the inventory posting voucher has the desciption Voucher. Attributes must be specified for the inventory posting voucher down to item or sub-item level. An exception to this is the production order, where it is not necessary to specify an item.

The required attributes are described in the following table: