Sales Office Processing

EDI Processing from the Sales Office Perspective

The sales office is the intermediary of most CID transactions.  To the end customer, the sales office is a vendor; to the remote site it is considered a customer.  From this location, seven EDI transactions are supported; they are sequenced in a list below.  Note that outbound shipment/BOL processing is available at the sales office.  However, because this process occurs at the remote site for direct distribution orders, it is shown in the graphic explaining processing at the remote site.

1.   Inbound Sales Orders

2.   Outbound Purchase Orders

3.   Inbound PO Acknowledgments

4.   Outbound SO Acknowledgments

5.   Inbound Receipts

6.   Outbound Shipments/BOLs

7.   Outbound Invoices

Inbound Sales Orders

As the customer sends you an EDI purchase order transaction, it is converted (via ED140E) into a sales order on your MAC-PAC system.  On the resulting sales order, "Customer PO" fields exist from which you can cross-reference the original customer's purchase order.

Orders can be created asynchronously or in batch.  You can also place an automatic EDI customer hold on incoming sales orders until the EDI transactions are approved and the hold is removed.  This can prevent credit checking and/or inventory reservation, depending on the way the flags are set up on Reference File category 402, Sales Order Hold Codes.  The process of converting a customer's purchase order into a sales order on your system also produces several reports.

A report is generated for all sales orders created by this program.  The report shows key fields from the sales order header, detail, and comment lines.  Error messages related to availability checking are also printed.  A summary report is printed indicating the number of lines processed, the number of sales orders created, and the number of transactions rejected.  Lastly, an error report is created to identify transactions that could not be processed.  These reports can be used to verify transactions.

To process an inbound sales order, the information received from the customer's purchase order must be valid.  If the transaction is not valid, an online exception correction facility is provided to facilitate adjustments.  Once corrections have been made, you can resubmit the transactions for processing.  If correcting the transaction is not possible, you can delete the transaction using function key F14-Delete.  If you choose this option, you must either enter the transaction manually through the Sales Order Maintenance conversation or request that the customer retransmit the data.  Also, note that a sales order will not be created unless all information received for that transaction is valid (including the header, all lines, and associated comments).  If you use F14 to delete any part of a transaction, the customer's entire purchase order transaction will be deleted.

When a sales office processes an inbound sales order it must choose to source the order from its warehouse location or from a remote site.

Outbound Purchase Orders

If the sales office decides to source the sales order remotely, MAC-PAC automatically generates a purchase order requisition which triggers the creation (via PO185E) of an outbound purchase order to send to the remote site.

Outbound purchase order transactions can be generated asynchronously (via PO630E) or in batch, depending on the release code of the purchase order.  They may also be reprinted if necessary.  When sending outbound purchase orders, the Purchase Order Document Format field must allow EDI transmission (the value must be "E"-electronic transmission only or "B"-both paper copy and electronic transmission).

The "External" fields passed with the EDI transaction data will specify the trading partners of this EDI transaction.  They will identify you as a unique customer on the remote site's system.  The EDI transaction data also includes shipment type information.  This is used to tell the remote site whether to return the shipment to your sales office or whether to ship the goods directly to an end customer.  Furthermore, comments relating to an inbound sales order can be transferred via purchase order requisition to the purchase order created to cover the original sales order.

Outbound purchase order transactions are sent from the sales office to a vendor (remote site).  If the vendor has MAC-PAC, the purchase order can be converted into an inbound sales order on the vendor's system (via ED140E).  You can also use EDI processing without computer integrated distribution.  This is done by creating a manual purchase order and "reprinting" that order using a document format that generates EDI transaction files.

Inbound Purchase Order Acknowledgments

When you send an outbound purchase order to be sourced at a remote site, regardless of whether the order is to be shipped back to you or sent directly to the end customer (a direct distribution order), you will want to know that it has been received and follow its processing status.  This is done through a series of acknowledgment transactions.

Once your order is received, the sourcing warehouse will generate an outbound sales order acknowledgment indicating that it received the purchase order that you sent from the sales office.  If this is done through electronic transmission, the incoming transaction file data can be processed as an inbound purchase order acknowledgment on your system (via ED100E).

In addition to confirming the receipt of your purchase order, the acknowledgment also contains the date when the remote site expects to ship the order.  The information contained in the acknowledgment files updates you of all the processing that has occurred since the end customer initiated the original purchase order transaction.  Follow-up transactions may occur if the sourcing warehouse changes the ship date.  Both types of transactions, the initial acknowledgment and the later status updates, are processed identically.

Inbound purchase order acknowledgment updates can occur asynchronously or in batch.  Three reports are produced for this transaction.  A control report is generated listing the number of transactions processed.  A variance report is generated listing any significant differences between the fields on the acknowledgment and those on the purchase order that you sent to the remote site.  An exception report is generated to list the exceptions that prohibit the updating of the purchase order's promised ship date.

To process an inbound purchase order acknowledgment, the information received from the remote site's transaction files must be valid.  If an acknowledgment line is in error, an online exception conversation is provided to facilitate adjustments.  Once corrections have been made, you can resubmit the transactions for processing.  If it is impossible to correct the transaction, you can delete the transaction using function key F14-Delete.  If you choose this option, you must either enter the promised ship date transaction manually through the Purchase Order Maintenance or request that the remote site retransmit the data.  Also, note that if you delete a purchase order acknowledgment transaction line that is in error, only the current acknowledgment line will be deleted.  This means that if the header record is deleted, all associated lines will also be deleted but if the header record is valid, only the transaction line in error will be deleted.

Note:    You can define the company/warehouse, ship-to customer, and bill-to customer information for each vendor defined on the system.  This information is used by the vendor to identify purchase orders received from this site.  There is no system validation when you enter the field on the EDI Information screen in the Vendor Master Maintenance conversation; however, it is used later to validate vendor information when processing inbound EDI purchase order acknowledgments and receipts.  If these fields are blank, the first vendor with blank external fields is used.

Once processed, the corresponding purchase order lines (on your system) are updated with a new promised ship date.  Furthermore, if the transaction is part of a direct distribution process (the purchase order being updated has a corresponding sales order), the promised ship date on the sales order is also updated.

Outbound Sales Order Acknowledgments

The function of an outbound sales order acknowledgment transaction is to acknowledge receipt of an order (the end customer's purchase order) and, in some cases, to provide the status of an existing order (if you have a corresponding sales order that you sourced from a remote site).  Order acknowledgments can be generated asynchronously or in batch, depending on the sales order acknowledgment's release code; they may also be regenerated, if necessary.

You should process an outbound sales order acknowledgment when you receive an inbound sales order from the end customer.  This will update the customer on the order's status.  Follow-up transactions may also be necessary if the sourcing warehouse changes the ship date.  Both types of transactions, the initial acknowledgment and the later status updates, are processed identically.

To generate an outbound order acknowledgment for the receipt of a customer's purchase order, make sure that the value of the Sales Order Acknowledgment Release code is "I" (immediate) and that the Sales Order Acknowledgment Document Format field allows EDI transmission (values must be either E-electronic transmission only or B-both paper copy and electronic transmission).

If you are working with a direct distribution order and receive an incoming purchase order acknowledgment for a remotely sourced sales order, it will update the corresponding sales order on your system.  Then, if you choose to pass this information on to the end customer, you can re-issue an outbound sales order acknowledgment.  This is done (via OP520E) manually by requesting a reprint of the sales order.  To do this, enter the Sales Order Maintenance conversation and set the Reprint SO flag to "Y", the Sales Order Release code to "I" (immediate) or "N" (process with end-of-day batch jobs), and the Sales Order Acknowledgment Document Format field to allow EDI transmission (the value must be either "E"-electronic transmission only or "B"-both paper copy and electronic transmission).  This will generate the outbound EDI transaction files to be sent to the customer.

Inbound Purchase Order Receipts

When the remote site ships the inventory (either back to you at the sales office or directly to the end customer), you will receive a copy of the bill of lading.  If the shipment is being sent back to your location, the BOL will probably accompany the shipment.  If the remote site is sending the shipment directly to the end customer, they will generate multiple copies of the BOL.  One copy will be sent to you and another will be sent with the shipment to the end customer.

Regardless of whether inventory passes through the sales office, it must process a receipt of the goods.  Note that although they are generated from the same transaction files, inbound receipt transactions differ from an inbound shipment transactions.  The main difference is that the physical goods accompany the shipment (and thus, the inbound shipment transaction cannot be done via EDI transmission).

In order to receive inbound purchase order receipt information you must have remotely sourced the order.  If you requested that the goods be returned to you, the remote site will send an outbound shipment/BOL transaction along with the inventory.  You can use this information to process an inbound receipt.  Furthermore, if you are forwarding the goods to the end customer, you will need to generate an outbound BOL to accompany the shipment.

On the other hand, if the order in question is a direct distribution order, the remote source will send the shipment of goods directly to the end customer, bypassing your office completely.  In this case you will receive a copy of the BOL sent to the end customer so that you can process an inbound receipt transaction.  When processing this transaction, a receipt will be created to update the purchase order that was sent to the sourcing warehouse to obtain the goods.  The order processing shipping process will also be performed to record a shipment against the sales order and generate an outbound invoice to be sent to the end customer.

Once the BOL is received from a vendor, regardless of whether inventory is also received, a purchase order receipt is generated.  This can be done asynchronously or in batch, and may be regenerated, if necessary.  The process also creates three reports.  A control report is generated listing the number of transactions processed.  A variance report is generated listing any significant differences between the remote site's shipment information and the purchase order (on your system).  An error report is generated to list errors that prohibit the creation of the receipt.

To process an inbound purchase order receipt, the shipment information received from the remote site must be valid.  If a shipment transaction is in error, an online error correction facility is provided to facilitate modifications.  Once corrections have been made, you can resubmit the transactions for processing.  If it is impossible to correct the transaction, you can delete it using function key F14-Delete.  If you choose this option, you must either enter the transaction manually through the appropriate Receiving conversation or request that the remote site retransmit the data.  Also, note that if you delete a purchase order receipt transaction in error, all information associated with the purchase order receipt will be deleted (i.e., header and line records).

The Purchase Order Receipt transaction is initiated (via ED120E) when the EDI Receipt Header & Line files are received at the sales office.  Information from the shipment file is used to automatically create receipts, in effect performing the functionality of Receipt Administration automatically.  Because multiple shipments are allowed against a sales order, if the total sales order quantity has not been received for a direct shipped sales order line, a new release is created automatically.  The new release per shipment requirement remains in place for non-direct shipment orders.

With the receipt automatically created, you only have to be concerned with quantity control activities when the shipment is physically received.  Quantity control must be done manually for non-direct distribution orders.  If a direct distribution purchase order is received, the corresponding sales order can be shipped automatically using the shipment functionality of the Electronic Data Collection module.  If either the purchase order line or the sales order line are fully shipped, the they can be closed automatically (for the purchase order line this depends on the setup of Reference File categories 491 and D78).  When all lines are closed, the order is closed.

Note:    You can define the company/warehouse, ship-to customer, and bill-to customer information for each vendor defined on the system.  This information is used by the vendor to identify purchase orders received from this site.  There is no system validation when you enter the field on the EDI Information screen in the Vendor Master Maintenance conversation; however, it is used later to validate vendor information when processing inbound EDI purchase order acknowledgments and receipts.  If these fields are blank, the first vendor with blank external fields is used.

Outbound Shipments/BOLs

Outbound shipment transactions are generated from the location that sends the inventory to the end customer.  This is done (via OP690E) in the form of a Bill of Lading.  This function is performed either asynchronously or in batch mode, depending on the bill of lading release code, and may be regenerated, if necessary.  When EDI processing is used, the Bill of Lading Document Format field must allow EDI transmission (the value must be "E"-electronic transmission only or "B"-both paper copy and electronic transmission).

BOLs can be created for up to four parties:  ship-to customers, direct distribution customers, customs authorities, and carriers.  Each of the four recipients can be sent a paper version, electronic version, or both versions of a bill of lading.  Bills of lading created for customs authorities (customs invoices) are an enhanced version of the regular BOL.  It includes extended price information for each shipped line and price totals (by currency).

For direct ship orders, the BOL that is generated for the PO receipt and the sales order shipment is automatically generated in the sales office when goods are received by the customer from the remote site.

For non-direct ship orders, the sales office initiates an outbound shipment transaction¾whether the order was remotely sourced is irrelevant if the goods are being returned to the sales office before they are forwarded to the end customer.

Outbound Invoices

Invoices are a way of billing the customer for inventory.  In MAC-PAC, invoices are always sent from the location that received the order to the location that sent the order, regardless of where the inventory is shipped.  This means that for direct distribution shipments, invoices cannot be sent from the sourcing site directly to the end customer; they must be routed through the sales office.  Thus, two separate outbound invoice transactions must occur:  one from the remote site to the sales office, and one from the sales office to the end customer.

This function consists of determining which invoices need to be processed, retrieving the invoice information, and printing the invoice document (via OP540E) and/or formatting the EDI Outbound Invoice Transaction files.  Unless the invoice release code is hold indefinitely, an invoice is printed at creation time (either upon being shipped or at invoice consolidation), either asynchronously or during the daily batch process.  Invoices can be sent to customers electronically, in printed form, or both.  When EDI processing is used, the Invoice Document Format field must allow EDI transmission (the values must be "E"-electronic transmission only or "B"-both paper copy and electronic transmission).  Invoices may be regenerated, if necessary.