ORDRSP

After the clerk has checked the order, he also sends it in EDIFACT format. The message type used is ORDRSP. The confirmed data is now transmitted in this message. The important data for the confirmation process are: Quantity, price and delivery date. The vendor order number is also transmitted and can thus be automatically entered in the purchase order. The item reference can even be used to assign the corresponding order item on the supplier side to each order item. As already mentioned, this is important for all subsequent processes.

If an order is confirmed by the supplier without any discrepancies, manual intervention by the dealer's clerk is generally no longer necessary. Only in case of deviations, a clarification by a clerk has to take place.

By automating the EDI processes, important document data used in the supply chain areas of the program are processed automatically across the program. These central records are integrated with ongoing business documents to provide information such as document status.

In the acadon_EDI solution, the EDI processes have been adapted to the specific needs of the wood industry. This provides the necessary information, which offers the following advantages:

Cross-program document status
Avoidance of double entries
Automation of the necessary business processes

ORDRSP Import

When importing an EDI ORDRSP message, an EDI purchasing document is created in NAV. This contains all the information agreed between the communication partners that is transmitted in the EDI message. Additional transmitted information will either be ignored or the EDI document will not be imported and the EDI file will be marked as faulty (file extension: .ERR). This can be controlled via a facility on the EDI organization. If EDI documents could be created from the EDI file (independent of the further processing!), the EDI file is provided with an .OK extension.

On the imported EDI document there is a field EDI processing status. This can have the following values:

not processed (default)
to be checked (IT)
to be checked (IDM)
processed (autom.)
processed (manual)
rejected

not processed

This is the default value when creating an EDI document. No further processing or checking has taken place yet.

to be checked (IT)

If an EDI document contains serious errors, EDI logging entries are generated by a check routine before the document is actually processed. Further processing of the EDI document will then not take place. As a rule, the responsibility for checking such documents lies with the IT employee.

Examples of serious errors:

missing article identification
double document import
no corresponding purchase order item / purchase order can be determined.

If the EDI document was imported incorrectly, or if the issue cannot be corrected, the employee can either cancel or reject the EDI document. However, if the error can be corrected, for example, if the article identification is missing, the document can be checked again. (Function: Check document). To do this, all EDI logging entries are deleted and the check routine starts again. Afterwards the status is set to either to be checked (IDM) (in case of relevant deviations) or processed (autom.) (no more check necessary).

However, if serious errors are still present, the status to be checked (IT) is retained and a new manual correction is necessary.

to be checked (IDM)

In case of processing an imported ORDRSP with the status to check (IDM), the clerk has to check if deviations between purchase order and order confirmation can be accepted. This can be, for example, a changed delivery date. To do this, the clerk must check the corresponding EDI order confirmations. Afterwards, this person can accept the ORDRSP (function: Accept document) and the processing status changes to processed (manual). The purchase order is then also updated according to the setup on the EDI organization.

If the clerk does not want to accept the ORDRSP, he can also reject the document (Function: Reject document).

The processing status of the EDI document then changes to rejected and the associated purchase order is not changed.

processed (autom.)

Due to the setup on the EDI organization, it may happen that an EDI document can be processed without user intervention. For example, a purchase order may be confirmed unchanged by the vendor so that no discrepancies occur. Also, a purchase order can be automatically updated based on the setup. This state is optimal because there is no further effort to process here.

processed (manual)

If a changed EDI document is accepted manually by the user, the processing status changes to processed manually. The purchase order is then updated according to the setup.

rejected

If an EDI document is manually rejected by a user, the processing status is set to rejected. Also, an ORDRSP can be automatically rejected if, for example, a duplicate order confirmation was sent. The older unprocessed order confirmation (determined by the EDI message number) is then set to rejected.

EDI checks

On the EDI organization, a number of settings can be made on how to handle discrepancies between the purchase order and the order confirmation. Especially relevant is the check of the following information:

Delivery date
Quantity
Price

Different check methods can be set for all check points.

ignore

The transmitted information (e.g. delivery date) should not be checked. There is also no update of the order. This also applies when the document is accepted manually.

check

The transferred value is compared with the value from the purchase order. If a discrepancy is found, a corresponding EDI logging entry is generated and the processing status is set, for example, from not processed to in process. Here a clerk must check the document.

update, update (always)

The transmitted value is transferred to the purchase order without further checking. There is no notification of the change.

update (tolerance)

If, for example, the transferred purchase price is within a set tolerance, the price is updated in the purchase order if the purchase price reference type is set to purchase price. There will be no further notification. If the value is outside the set tolerance, a corresponding EDI logging entry is generated and no update is made. With the manual acceptance the value is taken over however. If the EK price reference type was set to line amount, the line amount is updated and a corresponding line discount is calculated.

check (Tolerance)

The transferred value is compared with the value from the purchase order. If a deviation outside the tolerance is detected, a corresponding EDI logging entry is generated and the processing status is set from not processed to in process, for example. Here, a clerk must check the document. If the transmitted value is within the tolerance, this deviation is ignored. Also during processing, the value in the purchase order is never changed.

EDI Confirmation Status (Purchase Order)

When evaluating (accepting) EDI purchase order confirmations, the document lines of the purchase order are assigned a corresponding status: **confirmed ** If the purchase order line was confirmed unchanged, or if the change was within the specified tolerance, the EDI confirmation status of the line is set to confirmed.

Note

Depending on the setting on the EDI organization, an automatic transfer of the EDI values may already have taken place here! (update (tolerance)).

changed

This item is currently no longer used

manually accepted

If an EDI document is accepted manually by a clerk, the status of the order line is set to manually accepted. However, this only happens if the status has not already been set to confirmed by the order confirmation.

Rejected

If an order line cannot be delivered by the supplier, the status of the line is set to rejected. Depending on the document lines, the EDI confirmation status is calculated in the order header.

pending

If an order was transmitted via EDI, the confirmation status is set to pending. Here an order confirmation is still expected.

confirmed

If all order lines have the EDI confirmation status confirmed or manually accepted, the header status is set to confirmed.

Partially confirmed

If at least one line has the confirmation status confirmed or manually accepted, but there are other lines with different processing status, the header status is set to partially confirmed.