Requisition Update Transaction - PU

When a user or approver updates information in the order, a "Requisition Update" transaction request is sent to the client's ESM service. The format is almost identical to the "Requisition Insert" transaction request with the exception that the order is already a purchase request in the client's purchasing system. The following is an example of a "Requisition Update" transaction request.

There are more fields that come across in the transaction, but they are not used by the ESM Interface. Therefore, the transaction has been pared down into the mandatory fields for ease in understanding what is used by the BusinessPlus Purchasing subsystem and what is not.

If everything validates and the transaction is sent to the Purchasing Subsystem for processing, the ESM Controller picks up the request and validates it again. However, this time it is with respect to content, not formatting. Information in the request that must exist in the BusinessPlus tables is now validated. This includes information like the vendor ID or Ship To address. If any errors occur during content validation, the response is marked as "Error," along with the inclusion of the error that occurred. The following is an example of a transaction response that validates with an error.

If at any point a validation error occurs, processing terminates, and the error response is returned. If the request was validated successfully, a new Purchase Request is created in the Purchasing Subsystem. The following is an example of a successful Purchase Request created by a "Requisition Insert" transaction.

When errors are returned to the ESM Service, there are several different levels at which a transaction can fail. The error previously displayed in the "Requisition Insert" section is a transaction level error. This means that it took place at a higher level than the processing of an item (i.e., amounts do not match) or account distribution (i.e., undefined Key/Object). The above example is an account distribution level error in which the object is undefined. The granularity allows ESM to pinpoint the exact nature of the error.

If validation is successful, the processing of the Requisition Update continues. The main record for the order is updated. However, instead of trying to figure out what to update and how, the remaining records are deleted, and the transaction request goes through the Insert logic for the remaining tables. This includes the following tables:

• POI-ITEM-DTL – An item detail record is created for each item in the transaction request.
• PON-EN-DTL – An associated purchase request encumbrance detail record is created for each account in an item request.
• POT-TEXT-DTL – Both Purchase Request Text Notes and Item Text Notes are created when either Internal or External notes are found in the transaction request. Item notes will be inserted at the item detail level. Transaction notes are inserted at the purchase request level.
• EN-DTL – Pre-Encumbrance records are inserted into the encumbrance table.

ESM Requisition type transactions such as inserts, and updates result in the pre-encumbering of the requisition unless the client does not perform pre-encumbering. ESM Purchase Order type transactions result in the encumbering of the Purchase Order.
If processing is successful, the transaction response will be marked as "Success." If not, the response will be marked as "Error" and the specific error message is included in the response.

There is no difference in a Purchase Requisition that has been updated and one that has not. With the exception of the master Purchase Request record, all other ESM records are new after the update.

The "Success" response that is sent back to ESM Easy Purchase is identical to the "Purchase Insert" Transaction Request. The only difference is that the Requisition Number is not returned since it is already known to eSchoolMall.

At this point, the ESM (Easy Purchase) system can continue through the approval process defined for the client. As the approval process continues, the creator and/or approver can update the order multiple times or not at all. However, once the final approval takes place, the user can no longer update the order. The Purchase Order Insert transaction takes place upon the final approval.

If the creator decides at any point during the approval process that they do not want the order any more, they can cancel it during the approval phase at ESM, which results in the creation of a Requisition Delete Request.