SAP Business One

Integration with

Radley iCARaS EDI

Mascidon, LLC

March, 2011

Dr. Don Maes

248-568-0418

Table of Contents SAP B1 Integration to iCARaS ........................................................................................................................ 4

Figure 1.1 SAP Integration Points ............................................................................................................. 4

Figure 1.2 Flow of EDI Information into SAP ............................................................................................. 5

Figure 1.3 Flow of Integration Information into iCARaS ........................................................................... 6

Incoming Data – Demand for Shipment ....................................................................................................... 7

Shipments to Customers ............................................................................................................................... 8

Handling of Consignment Inventory ............................................................................................................. 9

Handling of Invoices .................................................................................................................................... 10

Figure 1.4 Create 810 Invoices ................................................................................................................ 11

Master File Creation .................................................................................................................................... 11

Figure 1.5 Customer EDI Fields ............................................................................................................... 12

Figure 1.6 Customer / Supplier Trading Partner Setup ........................................................................... 13

Figure 1.7 Flag for Creating a Single Sales Order for Incoming Requirements ....................................... 14

Figure 1.8 Item Master File EDI Parameters ........................................................................................... 15

Figure 1.9 Returnable Container ............................................................................................................. 16

Figure 1.10 Item Cross Reference to Trading Partner Information ........................................................ 16

Figure 1.11 EDI Items by Trading Partner Report ................................................................................... 17

Figure 1.12 Inventory Consumption Warehouse .................................................................................... 18

Blanket POs ................................................................................................................................................. 18

Figure 1.13 Blanket PO Maintenance ..................................................................................................... 19

Figure 1.14 Blanket PO Header Information ........................................................................................... 20

Figure 1.15 Blanket PO Items .................................................................................................................. 21

Supplier Setup ............................................................................................................................................. 21

Splitting Demand Between Suppliers ......................................................................................................... 21

MRP Processing ........................................................................................................................................... 22

Processing 862 Transactions ....................................................................................................................... 22

Figure 1.16 View MRP - Blanket PO Requirements ................................................................................ 23

Figure 1.17 View EDI Material Requirements ......................................................................................... 23

Figure 1.18 Create 862 EDI Transactions ................................................................................................ 24

Processing 830 Transactions ....................................................................................................................... 24

Figure 1.19 Import Incoming Documents From iCARaS .......................................................................... 25

Figure 1.20 Retrieving the PO Goods Receipt Draft (ASN) ...................................................................... 26

Processing 850 Supplier POs ....................................................................................................................... 27

Figure 1.21 EDI 850 – Purchase Order .................................................................................................... 27

Combining MRP Forecasts .......................................................................................................................... 27

Figure 1.22 Combine MRP Forecasts ...................................................................................................... 28

Figure 1.23 Selecting Forecasts to Combine ........................................................................................... 29

Figure 1.24 Combined Forecast is Included ............................................................................................ 29

Processing ASNs from SAP B1 ..................................................................................................................... 29

Figure 1.25 Delivery Order with Trucking Tab ........................................................................................ 30

Figure 1.26 In Transit Define by Ship To ................................................................................................. 31

Figure 1.27 Transportation Modes ......................................................................................................... 31

Figure 1.28 Equipment Codes ................................................................................................................. 32

SAP B1 Integration to iCARaS

The integration of SAP Business One to the iCARaS EDI software marries the capabilities of SAP with the

EDI experience and certifications provided by Radley. By making the Radley iCARaS system the ‘master’

for shipping purposes and using its release accounting functionality, the integration utilizes the

strengths of the EDI solution. The strong integration tools available with SAP B1 have been used to add

fields to screens and to force procedures on the data that is integrated with the EDI.

Figure 1.1 SAP Integration Points

Export out of

SAP to XML

Parts Master Invoices Purchase Orders

to Vendors

Import Into SAP

from XML

Requirements –

into Sales Order

Shippers – into

Delivery Orders

Vendor ASN’s into

Draft PO Goods

Receipts

Requirements –

into Forecast

Import Into SAP

from XML

Shipper containers -

into Inventory

Issues

Shippers for

consigned items –

into Inventory

Transfer

Inventory

Consumption – Into

Delivery Order

830’s and 862’s

to Vendors

Figure 1.1 shows the integration points between SAP B1 and Radley iCARaS. Figures 1.2 and 1.3 show

the process flows for the integrated solution.

Figure 1.2 Flow of EDI Information into SAP

CUSTOMERS

Demand

850,830,862

iCARaS

Translates

to XML

XML

Demand

Sales Orders MRP Forecast a. Shipper, b. Transfer PO Goods Receipts Draft

c. Issue of Stock

SAP Reformats XML

SAP SDK Import From XML

XML

Forecast

iCARaS

Prepares

Shippers

EDI ASN

856

XML

Shipper

iCARaS

Translates

Vendor

ASN

XML ASN

SAP B1 Files

Figure 1.3 Flow of Integration Information into iCARaS

As you review Figures 1.2 and 1.3 it becomes apparent that there are two critical functions in the

integration. The first is the use of XML data structures to pass data from iCARaS to SAP B1 or from SAP

B1 to iCARaS. The accurate translation of these XML files is crucial to the integration. The second is

the programs used to process the data from XML files into the SAP B1 or iCARaS file structures. From

CUSTOMERS / VENDORS

Parts

XML

Parts Master Invoices POs, 830s, 862s

iCARaS Imports XML to Files

PO XML Invoice

XML

SAP B1 Files

Create Parts XML Create Invoice XML Create PO XML

iCARaS

Files

iCARaS EDI Processing

the SAP B1 view, once the XML files are in SAP B1 format, the Software Development Kit (SDK) has the

capability of writing that format XML file to the appropriate business object within SAP B1. Similarly,

iCARaS expects a common format XML file for mapping to the iCARaS data structures. iCARaS has been

integrated with other ERP systems using the same process and XML file formats, so this is a known,

accurate means of populating the files.

Incoming Data – Demand for Shipment

The flow of information proceeds as follows:

• Within SAP B1, customers and vendors (trading partners) can be flagged as using EDI or not

• iCARaS receives EDI incoming documents from trading partners

• iCARaS translates the EDI and calculates the demand for shipping

o 830

o DelFor

o 862

o DelJit

o 850

• iCARaS maintains all of the information for the EDI transactions and processes any turnaround

documents required

• iCARaS exports the sales demand to SAP B1 as an XML file. The file is placed in the directory

determined by DCMSetup.U_XMLImport – as defined in SAP B1. There is a similar configuration

file within iCARaS that indicates where data is to be located.

o An SAP SQL process finds the XML files placed in the directory by iCARaS and depending

on the file name processes that file as an incoming sales order (SALESxxxxxx.xml), an

incoming MRP Forecast (FORECASTxxxxxx.xml), or a Payment Remittance

(REMITxxxxx.xml). The processing:

� Creates a backup copy of the file being made in a separate directory

� Passes or fails the file based on data requirements (i.e. customer not found

would result in a failure)

� Files that fail the tests are written to an ‘unprocessed’ directory for error review

and correction. In most instances, the corrections involve setups of parts and

customers. Then the file is copied back to the normal processing directory and

re-run.

� Files that pass the tests are rewritten to a new directory as SAP B1 XML files.

� The SAP B1 SDK program is called.

� The SDK program reads the XML file and :

• Sales orders – uses an XML file to cancels / close specific Sales orders on

file for the part – destination – PO in sales demand.

• Sales orders – reads a second XML file to create new sales order

demand within SAP B1. The SAP B1 SDK creates new sales orders for

each part – destination – PO in sales demand. This is normally done

once per day. The ‘Requirement ID’ in iCARaS is linked to

‘U_DCMReqID’ in SAP B1.

• Forecasts – creates a new MRP Forecast using the XML file. Normally

MRP forecasts are imported upon demand. The non EDI demand from

the sales orders for non-EDI trading partners is included in the MRP

Forecast as additional information read directly from the SAP file

structures. It is included in the current forecast XML file created. The

MRP forecast itself is trading partner independent – it does not track

where it needs to ship, just the part, date and quantity.

• Remittances – creates incoming payment documents using the XML file.

Notes:

The ‘Requirement ID’ created by iCARaS is the logical link used to determine the

line items to cancel / close.

All demand placed in the XML file is imported. Any other demand in SAP sales

orders for any of the trading partners being imported results in cancel / close of

the sales order. Partners not included in the XML demand file have no changes

made to the sales orders on file.

• This implies that if a trading partner has EDI demand and it is unfulfilled

and the customer is no longer a trading partner, any outstanding sales

orders need to be either shipped or cancelled manually.

Shipments to Customers

All EDI outgoing shipping functions are handled using iCARaS. The shipping papers are iCARaS papers.

The customer labels are provided by iCARaS. Sending and resending ASNs is handled by iCARaS. All of

the quantity demand calculations are handled by iCARaS. The user has the option of using SAP to

process non EDI shippers. If this option is chosen, then shipping papers need to be defined in both

iCARaS and SAP.

Upon completion of the shipper, iCARaS sends the ASN to the customer and an XML file to SAP B1 file

directory (the file directory is defined by DCMSetup.U_XMLImport). The shipper XML file is handled as

follows:

• The presence of an XML file is detected in the Import directory.

• A backup of this file is written to the backup directory.

• The XML file is read and checked for errors. The part number is verified as a valid, active SAP B1

item. The customer and shipping addresses are verified. If there are any reasons this file cannot

be processed by SAP B1, the file is written to an ‘unprocessed’ directory.

• The XML file is translated into an XML file in the format required for an SAP B1 shipper. If the

shipper is for an item that is ‘consumed’ , then the XML file is translated into an XML file in the

format required for an SAP B1 inventory transfer.

• The SDK program is called to process the shipper XML file(s). The shipper created references the

sales order using the requirement id field.

• Miscellaneous charges included on a shipper are written to the delivery order expense detail file

(DLN3).

• Line items on a shipper that are containers result in a third XML file passed on to SAP B1. This

XML file contains container inventory issues transactions. These transactions are not directly

associated with the shipper.

o The business partner can require or not require a returnable container. If the business

partner flag OCRD.U_DCMCtn <> ‘N’, then the items sold will require a returnable

container. This means that each item sold to this customer must have a returnable

container defined in the item master screen. The definition of which items are sold is

based on the business partner catalog setup – all items sold to a customer are included

in this file.

o If the container is serial controlled, then the XML file includes serialized details for the

container. Multiple serial numbers for container are supported.

o A returnable container must be set up as an inventory item, but is not required to be an

item with on hand tracking (Inventory flag on the item master is not checked).

Handling of Consignment Inventory

Inventory that is transferred to a customer site and later relieved and billed when an inventory

consumption 846 EDI transaction is received is processed as follows:

• When iCARaS is used to ship the product, the ‘shipment’ triggers the creation of an inventory

transfer within SAP

o All shipping paperwork is handled by iCARaS

o Shipper XML is received from iCARaS

o A flag in the SAP B1 item master is checked (OITM.U_DCM846) and if it is Y, this triggers

the creation of an inventory transfer from the default inventory warehouse location to

the first warehouse location that is flagged as ‘Consumable consigned inventory’.

(There should only be one such warehouse).

• When 846 transaction (consumption) is received by iCARaS

o The EDI transaction is translated by iCARaS and an XML file is created

o The XML file is read and translated into an SAP B1 shipper XML file.

o The SAP B1 SDK is used to create a Delivery order in SAP

� The Delivery order warehouse is the consumable consigned inventory

warehouse

� The price is defaulted based on the customer’s default price list

• Following this logic, users can determine the quantities of any item on hand at the customer by

viewing the on hand of an item in the consumable consigned inventory warehouse. The

inventory posting audit trail within SAP B1 can track the inputs and removal of stock from this

warehouse.

Handling of Invoices

The business partner has a flag set to indicate whether or not they are to be sent EDI invoices

(OCRD.U_DCMInvoice). If EDI invoices are to be sent, this is the process followed:

• The user utilizes SAP B1 functionality to create invoices from Delivery Orders (normal process).

• After invoicing has been completed for the day, the user accesses Administration � Data

Import / Export � EDI � Create Invoice XML. This creates the interface to iCARaS in an XML

file in the ‘Export’ directory as defined in the initial setup of EDI. Only the business partners

with the flag U_DCMEDI set to Y, and the flag U_DCMInvoice is set to Y, have EDI invoices

created.

• Alternatively, the user can create each EDI invoice one at a time by clicking the button ‘Create

810’ after a completed invoice has been saved. Any invoices created in this manner would be

excluded during the day-end batch run by virtue of the ‘EDI Created’ flag being set.

• The XML file created is in a format acceptable to iCARaS for processing.

• iCARaS reads this XML file and creates the EDI Invoice transactions and sends this to the

customer.

• In the event an invoice must be resent to a trading partner, the user must access the invoice

and change the flag OINV.U_DCMEDI from ‘Y’ to ‘N’. The next time the invoices are exported,

this flag is checked and the resend occurs.

Figure 1.4 Create 810 Invoices

Master File Creation

Business Partner Master File

New customers (trading partners), ship to destinations, parts, and cross references to customer parts

are maintained in SAP B1 and also in iCARaS. In phase 1 of the EDI integration, the user will need to set

up the customers and destinations in both SAP and iCARaS. A future phase may integrate these. The

EDI fields required for the customers are shown in Figure 1.5. The trading partner for the customer is

defined in a separate customer master file tab as shown in Figure 1.6. For suppliers, only the fields ‘EDI

Used?’ and the trading partner id are required.

The normal process for imported sales orders from EDI is to create new sales orders for each part – ship

to destination. This works well when 862 and 830 transactions are imported. However, in other

instances, such as automotive aftermarket, an 850 purchase order should be imported with all items for

a specific destination on a single sales order. A flag in the ship to address as shown in Figure 1.7 controls

whether a single sales order is created for incoming requirements.

Figure 1.5 Customer EDI Fields

Several checks are made on data entered for the customer:

1. The trading partner must exist if the flag ‘EDI Used?’ is set.

2. The address codes for each of the ship to destinations are limited to 5 characters to match the

destination codes used for EDI.

Figure 1.6 Customer / Supplier Trading Partner Setup

Figure 1.7 Flag for Creating a Single Sales Order for Incoming Requirements

Part Master Files (OITM, OSCN)

Parts are maintained within SAP B1 and exported to iCARaS as needed. Only inventory items requiring

EDI are exported. When a new part is created, the flag OITM.U_DCMEDI is checked to see how this part

is managed.

o If the flag is set to ‘Y’, then this part requires management within iCARaS as an EDI part. In

general, only items being shipped to customers would be flagged as managed by EDI. In a

future phase, when vendor EDI integration is included, then some items purchased via EDI

would also have this flag set.

o To set up the item, the basic SAP information required is:

� Item master file maintenance – including setting the ‘managed by EDI’ flag. The EDI

fields are on the ‘Planning’ tab of the item master.

� Business partner cross reference information is maintained in the Business Partner

Catalog Numbers file within the inventory system. This is required information for

EDI managed parts.

o The item and all associated cross references (by trading partner) are exported to iCARaS in

an XML file. This is done by accessing Administration � Data Import and Export � EDI and

then clicking on the ‘Create Parts Master XML’ option. The name of the XML file created

when this task is performed is updated on the item master screen. It includes the date and

the time for reference.

The EDI fields required for the item master setup are shown in Figure 1.8.

Figure 1.8 Item Master File EDI Parameters

The returnable container information is shown in Figure 1.9.

There are several EDI fields required in the BP Catalog file, as shown in Figure 1.10.

Figure 1.9 Returnable Container

Figure 1.10 Item Cross Reference to Trading Partner Information

Several inventory fields need to be ‘forced’ to conform to EDI standards if the EDI flag for the item is set:

• The item description can be no longer than 80 characters.

• The unit of measure and sales unit of measure must be 2 or 3 characters (depending on the X12

or EDIfact standard selected).

• The engineering drawing field (OITM.U_DCMEngrDrawing) is limited to 30 characters.

Upon completion of the entry of the EDI customer, ship to addresses, items and cross references to the

trading partner item files, a report of the EDI information for a trading partner is available. This is shown

in Figure 1.11. Access this report via Inventory � Item Management � EDI Items by trading Partner.

Figure 1.11 EDI Items by Trading Partner Report

If consumable inventory transactions are being processed, a warehouse file must be set up. Figure 1.12

shows the setup of the warehouse.

Figure 1.12 Inventory Consumption Warehouse

Blanket POs

Blanket POs are required in order to manage the supplier EDI integration. Shipping schedules and

forecasts are only prepared for items that have active blanket purchase orders on file. In addition, the

blanket PO sets the prices for the items.

Within SAP B1, blanket PO’s are ‘normal’ purchase orders. There are additional flags on the PO to

indicate that this is a blanket PO and that it is an active blanket PO. When PO’s with the flag ‘blanket

PO’ set are added or saved, the procedure ‘dbo_sp_transactionnotification’ captures this transaction

and automatically sets the PO flag ‘docstatus’ = ‘C’ � Closed. Pulling up the PO will show that it is

closed. The blanket PO status flag indicates whether it is an Active blanket PO or not. The delivery date

of the PO indicates the ending valid date for the blanket PO. The dates on the 830 or 862 transactions

will be not include any requirements beyond this date – even if there is demand. Note: care must be

taken when creating a blanket PO because when you exit the PO, it closes automatically. This is done so

that the blanket PO’s do not influence the MRP calculations.

Figure 1.13 Blanket PO Maintenance

Blanket PO’s are not maintained as normal PO’s are maintained. Since blanket PO’s are SAP B1 ‘closed’

PO’s, the blanket cannot be changed. The blanket PO number is not actually the ‘PO’ number displayed

on the screen, it is the Blanket PO / Reference number. By copying the existing closed PO and making

changes, the same Blanket PO can be modified. It will get a new PO number, but the blanket PO number

remains the same. After duplicating the first blanket PO, the original blanket PO must be set to inactive

so that it is no longer in effect. Figure 1.13 shows this process.

Blanket PO’s are checked to see that the same item is not on the blanket PO more than once. Allowing

the same item would create many complexities that this release will not address: a. Cost changes built

into the contract; b. Engineering revision changes scheduled; c. Expiration dates differing for each item

on the blanket PO. This implies the following: a. A new or revised blanket PO must be activated when

parts costs change; b. engineering change control is not being considered in the release of 862 and

830’s, except to note the current engineering revision; c. if purchasing lots of parts from a single vendor

and the expiration dates of the parts varies for each, using unique blanket PO’s for each part should be

considered.

Create PO

Flag as blanket &

active

Items have flags

for 862 / 830

Upon Add,

TransactNotify

closes the PO

Change Blanket PO

Duplicate current

blanket PO

Change or Add

Lines to Blanket

PO

Upon Add,

TransactNotify

closes the PO

Inactivate the

original blanket PO

The ‘Indicator’ flag on the Accounting tab for the PO has been renamed to the ‘Contract’. In many

instances a single blanket PO may be part of a broader contract. In those cases, the contract id can be

defined and displayed in this field. Refer to Figure 1.14 for the blanket PO header information changes.

Figure 1.14 Blanket PO Header Information

The line items on the blanket PO have several flags as shown in Figure 1.15:

1. 862 – Y/N flag for 862 transactions. Not all vendors will receive 862 transactions and this flag is

used to flag which do and which do not.

2. 862 - ‘mask’ which determines the days this part is sent as an 862. For instance, the mask ‘246’

indicates that an 862 is sent Monday – Wednesday and Friday (days 2, 4 and 6).

3. 830 – numeric flag determines the day of week to use for 830 EDI transactions. 830 transactions

will be weekly transactions starting on this date each week. 1 = Sunday, 2 = Monday, etc.

4. Fabrication days – this is the number of days on the 830 for which the fabrication of parts is

authorized. Leave this unassigned if the 830 should not include a fabrication authorization.

5. Material days – this is the number of days on the 830 for which the purchase of parts is

authorized. Leave this unassigned if the 830 should not include a material authorization.

6. Engineering revision – this is defaulted from the item master record (formatted search using the

query ‘Assign engr rev level to PO item’) .

Figure 1.15 Blanket PO Items

Note that on the blanket PO, the quantities are set to 1. Purchasing agents often do not want to commit

to high volumes so they negotiate a price based on projected volumes. If possible, leaving these

volumes off the blanket PO is their goal – just in case they do not meet those volumes. Our

implementation is neutral – key in whatever quantity is your normal policy.

The unit of measure is defined on the blanket PO. In some cases parts will not be purchased in the

inventory unit of measure. The 862 and 830 transactions issued will convert to standard pack quantities

(purchasing unit of measure) if the blanket PO is not set up in inventory units of measure.

Supplier Setup

See the settings in Figures 1.5, 1.6 and 1.7 for the setup of suppliers. The suppliers must be flagged as

an EDI partner and have a 2 digit trading partner id. The other EDI flags apply only to customer trading

partners.

Splitting Demand Between Suppliers

Splitting demand between multiple suppliers will not be supported in phase 1.

In order to split demand between suppliers, there would need to be 2 active blanket POs on file for the

same item. When this occurs, the system looks to the field OSCN.u_dcmsplit to get the percentage split

by supplier. The 862 or 830 is then split between the two suppliers on a percentage basis – with the

higher percentage supplier processed first. If the blanket PO is set up to use standard pack containers,

then the first standard pack required would be assigned to the first supplier.

MRP Processing

The quantity of every purchased material required for manufacturing must be determined. This is done

utilizing the Material Requirements Planning module from SAP. For an accurate MRP this is required:

1. An accurate bill of material

1. Reasonably accurate inventory on hand

2. Forecasted demand from customer forecasted requirements and open sales orders

If any of these three are not correct, the MRP results are not correct and there is no point in sending 830

or 862 transactions to suppliers because the data is inaccurate.

What does MRP do? Using the demand for product based on sales orders, minimum inventory

requirements and forecasted demand, the MRP system calculates the requirements for receipts of raw

materials and purchased components. MRP’s end result is essentially a spreadsheet with dates across

the top, items in column ‘A’, and each cell containing the quantity required for that item – date. This

data is used to create 862 and 830 transactions to send to your suppliers.

Processing 862 Transactions

The purpose of sending 862 transactions to suppliers is to provide them with a short term view of parts

that are required in your manufacturing processes. An 862 is a shipping schedule. The first step in this

process is to make certain that an active blanket PO exists for every item that is to be included in an 862

processing run. Refer to the setup of a blanket PO for more details. The next step in this process is to

run the MRP. In this instance, the time ‘horizon’ for the MRP run should be short – 5 to 10 days is the

norm for shipping schedules. In the automotive world, your customers would send you 862 ship

schedules and you would use these same schedules as the basis for the MRP forecast. If using the

iCARaS integration to SAP B1, the incoming 862 documents from customers would generate sales orders

within SAP. These are all ‘firm’ commitments. If there were sales orders for aftermarket parts, these

would be added in iCARaS and imported into SAP B1 as well.

Let’s say you create an MRP scenario with 14 days of requirements, no forecast, but all sales orders.

Running the MRP wizard creates an order recommendation report for all of the raw materials and

purchased components. Do not use the SAP B1 recommendation report to create purchase orders to

suppliers for those parts that are to be managed using 862 transactions. Review the items and quantity

requirements and make changes to the quantities if required.

Prior to actually creating the 862 EDI documents, it is recommended that the ‘View Requirements’

report be run. To view this report, access the MRP Recommendations screen and click on the ‘View

Reqd’ button as shown in Figure 1.16. This produces the report shown in Figure 1.17. The only material

requirements shown on this report are the requirements for this MRP Scenario that have an associated

blanket PO and are within the blanket PO end date limitation.

Figure 1.16 View MRP - Blanket PO Requirements

Figure 1.17 View EDI Material Requirements

To actually create the 862 EDI transaction, click on the ‘Create 862’ button as shown in Figure 1.18.

Figure 1.18 Create 862 EDI Transactions

Processing 830 Transactions

The purpose of 830 transactions being sent to suppliers is to provide your suppliers with a long term

view of parts that are required in your manufacturing processes. They would use this information to

plan their purchase of raw materials and purchased components. The first step in this process is to

make certain that an active blanket PO exists for every item that is to be included in an 830 processing

run. Refer to the setup of a blanket PO for more details. The next step in this process is to run the MRP.

In this instance, the time ‘horizon’ for the MRP run can be lengthy and is normally by week. The length

should correspond to the MRP Forecast length provided by your customers. In the automotive world,

your customers would send you 830 forecasts and you would use these same schedules as the basis for

the MRP forecast. Normally, sales orders are included in the long range MRP run.

Let’s say you create an MRP scenario with 14 weeks of requirements. Running the MRP wizard creates

an order recommendation report for all of the raw materials and purchased components. Do not use

the recommendation report to create purchase orders to suppliers for those parts that are to be

managed using 830 transactions. Review the items and quantity requirements and make changes to the

quantities if required.

In a manner similar to processing 862 transactions, 830 EDI transactions can be created by clicking on

the ‘Create 830’ button. The MRP scenario should be the MRP run for the extended forecast. The same

report as shown in Figure 1.17 is available for the 830 EDI review.

It is expected that the supplier will send an 856 ASN transaction when they ship parts based on either

830, 862 or 850 EDI transactions that you originally sent to them. Processing of an incoming ASN is

accomplished by accessing the screen: Administration � Data Import / Export � EDI � Import iCARaS

files. This is the same process as used when importing shippers, forecasts and sales requirements. See

Figure 1.19. The import function looks for any incoming EDI documents and processes them. If an 856

ASN is found, it is processed and stored as a PO Goods Receipt Draft. Retrieval of the Draft PO Goods

Receipts is done by accessing: Purchasing – A/P � Purchasing Reports � Document Drafts Report. This

is shown in Figure 1.20.

Figure 1.19 Import Incoming Documents From iCARaS

Figure 1.20 Retrieving the PO Goods Receipt Draft (ASN)

From a user perspective, the incoming ASN’s are retrieved and the PO Goods Receipts Drafts are

created. This can be set up to run in unattended mode. The receiving clerk has the truck at the

receiving dock and gets paperwork from the trucker. The clerk then goes to the appropriate goods

receipt document as shown in Figure 1.20 and double clicks on it. The PO goods receipt can then be

processed normally. The blanket PO stays with the receiving information and is inherited by the A/P

invoice. The goods receipt PO draft is ‘Closed’ by this process. Periodically a manager should look at the

close drafts and delete them from SAP.

Processing 850 Supplier POs

In some instances 862 and 830 management of suppliers is not required. For instance, if purchasing low

volume unique items from a supplier, there is no reason to set up a blanket PO and manage the logistics

supply chain using 830 and 862 EDI transactions. Under these circumstances utilizing traditional

purchase orders is appropriate. To create an EDI 850 purchase order, simply enter a normal purchase

order into SAP B1. Since an EDI document is to be created from the purchase order, the vendor must be

flagged as an EDI vendor (see Figure 1.5).

Figure 1.21 EDI 850 – Purchase Order

After entering and saving the purchase order, simply click on the Create 850 button. This creates the

EDI 850 document and passes it on to iCARaS for processing with the vendor.

Combining MRP Forecasts Companies may import several MRP forecasts independent of each other. For instance, the Ford

internal manager may want their forecast separate from the Chrysler manager. Once they import these

files from iCaras and they are uploaded to SAP, the MRP runs only one forecast at a time. If any

components are used by both customers, the MRP will provide erroneous buy recommendations using a

single Forecast. To alleviate this issue, multiple forecasts can be combined together. Accessing the

Mascidon menus there is a menu item to combine forecasts. Refer to Figure 1.22.

Figure 1.22 Combine MRP Forecasts

This accesses the screen shown in Figure 1.23. The user then clicks on the ‘Set Forecast Name’ to define

the name of the forecast to be created. Then they select the forecasts to combine into a single forecast

by clicking the appropriate check boxes. Clicking on the process button will create the combined

forecast with the Forecast name = ‘Combined’. This screen is refreshed after the new forecast has been

created. This is shown in Figure 1.24.

Figure 1.23 Selecting Forecasts to Combine

Figure 1.24 Combined Forecast is Included

Processing ASNs from SAP B1 If implementing Radley’s iSC web based supply chain product with SAP Business One, the shipping

function reverts to SAP (i.e. when iCARaS is not utilized). In this instance, the delivery order screen

requires additional fields of information in order to enable the creation of an ASN to the customer when

the shipment is made. Refer to Figure 1.25 for the additional tab on the delivery order screen. These

additional fields are included in the ASN. The ‘Shipping Type’ field was moved from the Logistics tab to

the Trucking tab.

Figure 1.25 Delivery Order with Trucking Tab

If necessary, formatted searches can be added to any of the fields on the Trucking tab to ensure that the

codes entered are valid. The in transit time is inherited from the in transit time for this ship to

destination. Refer to the in transit field shown in Figure 1.26. The shipping types are normal SAP B1

ship types and can be maintained using SAP functions. The transportation modes are stored in a user

table as shown in Figure 1.27. The equipment codes are also stored in a table – as shown in Figure 1.28.

When the truck leaves the plant, the delivery order can be retrieved and the ‘Time Left Plant’ can be

added (see Figure 1.25).

Figure 1.26 In Transit Define by Ship To

Figure 1.27 Transportation Modes

Figure 1.28 Equipment Codes