SAP Business One Integration with Radley icaras EDI. Mascidon, LLC March, 2011 Dr. Don Maes

Transcription

1 SAP Business One Integration with Radley icaras EDI Mascidon, LLC March, 2011 Dr. Don Maes

2 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 Figure 1.4 Create 810 Invoices Master File Creation Figure 1.5 Customer EDI Fields Figure 1.6 Customer / Supplier Trading Partner Setup Figure 1.7 Flag for Creating a Single Sales Order for Incoming Requirements Figure 1.8 Item Master File EDI Parameters Figure 1.9 Returnable Container Figure 1.10 Item Cross Reference to Trading Partner Information Figure 1.11 EDI Items by Trading Partner Report Figure 1.12 Inventory Consumption Warehouse Blanket POs Figure 1.13 Blanket PO Maintenance Figure 1.14 Blanket PO Header Information Figure 1.15 Blanket PO Items Supplier Setup Splitting Demand Between Suppliers MRP Processing Processing 862 Transactions Figure 1.16 View MRP - Blanket PO Requirements Figure 1.17 View EDI Material Requirements Figure 1.18 Create 862 EDI Transactions Processing 830 Transactions Figure 1.19 Import Incoming Documents From icaras... 25

3 Figure 1.20 Retrieving the PO Goods Receipt Draft (ASN) Processing 850 Supplier POs Figure 1.21 EDI 850 Purchase Order Combining MRP Forecasts Figure 1.22 Combine MRP Forecasts Figure 1.23 Selecting Forecasts to Combine Figure 1.24 Combined Forecast is Included Processing ASNs from SAP B Figure 1.25 Delivery Order with Trucking Tab Figure 1.26 In Transit Define by Ship To Figure 1.27 Transportation Modes Figure 1.28 Equipment Codes... 32

4 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. Import Into SAP from XML Requirements into Sales Order Requirements into Forecast Shippers into Delivery Orders Vendor ASN s into Draft PO Goods Receipts Import Into SAP from XML Shipper containers - into Inventory Issues Shippers for consigned items into Inventory Transfer Inventory Consumption Into Delivery Order Export out of SAP to XML Parts Master Invoices Purchase Orders to Vendors 830 s and 862 s to Vendors Figure 1.1 SAP Integration Points

5 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. CUSTOMERS Demand 850,830,862 EDI ASN 856 Vendor ASN icaras Translates to XML icaras Prepares Shippers icaras Translates XML Demand XML Forecast XML Shipper XML ASN Sales Orders MRP Forecast a. Shipper, b. Transfer PO Goods Receipts Draft c. Issue of Stock SAP Reformats XML SAP SDK Import From XML SAP B1 Files Figure 1.2 Flow of EDI Information into SAP

6 SAP B1 Files Create Parts XML Create Invoice XML Create PO XML Parts XML Invoice XML PO XML Parts Master Invoices POs, 830s, 862s icaras Imports XML to Files icaras Files icaras EDI Processing CUSTOMERS / VENDORS 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

7 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.

8 Notes: 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. 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.

9 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.

10 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.

11 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.

12 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.

13 Figure 1.6 Customer / Supplier Trading Partner Setup

14 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.

15 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.

16 Figure 1.9 Returnable Container Figure 1.10 Item Cross Reference to Trading Partner Information

17 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 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.

18 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.

19 Create PO Flag as blanket & active Change Blanket PO Duplicate current blanket PO Items have flags for 862 / 830 Change or Add Lines to Blanket PO Upon Add, TransactNotify closes the PO Upon Add, TransactNotify closes the PO Inactivate the original blanket PO 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.

20 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: 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 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) 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 ).

21 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

22 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.

23 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 This produces the report shown in Figure 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.

24 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.

25 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 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 Figure 1.19 Import Incoming Documents From icaras

26 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.

27 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.

28 Figure 1.22 Combine MRP Forecasts This accesses the screen shown in Figure 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.

29 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

30 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 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 The equipment codes are also stored in a table as shown in Figure When the truck leaves the plant, the delivery order can be retrieved and the Time Left Plant can be added (see Figure 1.25).

31 Figure 1.26 In Transit Define by Ship To Figure 1.27 Transportation Modes

32 Figure 1.28 Equipment Codes