SAP Business One Integration with Radley iCARaS EDI Mascidon, LLC March, 2011 Dr. Don Maes 248-568-0418
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