## Introduction The document describes a general workflow from start to end and describes all available options for each step of the workflow. It's important to understand, for each step in this workflow, the ZeeBORN system allows to define and strictly control who will be able to execute which step in the workflow. In some cases users may be even blocked from certain steps if they do not reach or exceed given approval levels (e.g. total value of a purchase order). While this document concentrates primarily on a typical purchasing process initiated on board, executed in office and finished with handling all transaction details like delivery, invoicing and payment, the same workflow can also be initiated in the office as well as representative for a vessel or even for ordering office supply and services. If not separately mentioned, a purchasing process can contain the following items: 1. spare parts 2. consumables 3. catalog articles (ISSA, IMPA, internal company catalogues) 4. components 5. services (internal=to be done by customers fleet-wide service crew and external=3rd parties); usually resulting from planned or unplanned maintenance tasks 6. work orders, parts and service orders for dry docking projects 7. free line items 8. additional fees (packaging, transportation, insurance etc.) ## Requisition (RQ) A RQ for requesting the purchasing and delivery of items can be created on board or in the office and may have different causes for its creation: 1. on demand by user on board or in office 2. if remaining quantity on board falls below a given minimum quantity 3. for ordering services for execution of maintenance tasks 4. replenishment of expiring articles 5. requesting audits/reviews (e.g. for renewing essential certificates) All of the above can also be initiated by starting the planning of a dry docking project. The RQ process ends on board with closing the RQ on board and opening it up for further processing in the office. BTW: The RQ creating process can be transparently followed in the office, even if the office can take over further execution only after approval and closing on board. After closing the RQ on board, the following options exist for further processing: 1. After the RQ is received by the office, it's turned directly into a PO and is sent to a supplier 2. A request for quotation (RfQ) process will be started for requesting quotations from potential suppliers ## Request for Quotation (RfQ) After receiving a RQ in office for further processing, the office can initiate an optional Request for Quotation process. This process can use different optional workflows: 1. Manually sending RfQs to potential suppliers. 2. Using dedicated 3rd party services like ShipServ, ProcureShip etc. via suitable online interfaces. 3. Just skipping the RfQ stage entirely and creating a PO directly from the received RQ. If the manual process is used, the office user can select per quotation (complete offer) or per line item what line items of the initial RQ should be ordered from what supplier. If 3rd party service is used, the detailed process of supplier selection depends on the scope of contract with the related service providers. This ranges from receiving a prepared purchase order (PO) for the best/cheapest supplier to a report about what supplier may suite best for each line item. After selecting the supplier(s) and final approval, the RfQ process will be closed and purchase orders will be created for further processing. ### Supplier Rating The selection of a supplier is assisted by a supplier rating process. That can permanently run in parallel to the daily operation. A supplier rating can be requested from any involved party (department managers, inspectors, crew on board) and results can be used for defining preferred suppliers, but also suppliers not to be used. ## Purchase Order (PO) After reviewing the created PO, the PO can be approved by authorized users and can be sent to the supplier(s). The transmission of the PO can use different options. 1. print and send as letter 2. send via e-mail 3. send via dedicated service providers via suitable online interfaces ## Delivery, Invoicing, Payment, Exception Handling Form here the next processes can happen at the same time in parallel. ### Delivery The monitoring of the delivery of ordered items can be monitored by integrating several 3rd party tracking systems but also with the features available within the system. The following delivery types are supported: 1. direct delivery to vessel 2. delivery via shipping company's warehouse 3. delivery via 3rd party warehouse 4. execution of service jobs At the end, the vessel will confirm if the ordered items have been delivered and if they have been delivered in the contracted quantity and quality. If any deficiency is detected, this can be reported by the vessel for further follow up in the office. In case of service orders, the execution of a service order will be reported in the PMS module. In case of spare parts and an used stock module, the received quantities will increase the corresponding stock quantity. ### Invoicing *Invoice handling can also be done by integrating an existing 3rd party solution.* Received invoices can be processed directly in the system - including the storage of scanned or original invoicing documents. Invoices will be registered against the matching sent purchase orders. Any difference in contracted costs and invoiced costs can be handled by a dedicated exception handling (e.g. accepting minor differences caused by currency exchange differences). There are different optional workflows for accepting and approving a received invoice: 1. approval if contracted and invoiced costs match 2. approval if difference and invoiced costs do not exceed a predefined limit (automatic handling of currency differences) 3. general review and approval by inspectors 4. request of manual approval by authorized users for invoices that exceed defined limits 5. approval of payment by authorized users ### Payment The payment process is fully handled outside the ZeeBORN system - fully separated from the ZeeBORN system or by implementing suitable interfaces for exchanging information about the payment process. That's the part with the most optional workflows possible, where the basic variants are the following: 1. Processing is forwarded to the accounting department right after sending a purchase order. Purchase order details can be exchanged between ZeeBORN and the accounting system for easier processing. 2. Process is forwarded to the accounting department after an invoice has been received, registered and approved in the ZeeBORN system. In any case an interface between the ZeeBORN system and accounting system should be established for exchanging invoicing and payment information for marking them visible within the ZeeBORN Purchase module as part of the transaction details. ### Exception Handling As the process from initial RQ creation to closing the process with delivery and final payment offers many possibilities of things that could go wrong, the ZeeBORN system tries to provide as much as possible assistance with proper exception handling. While the basic assistance consists of providing as much as possible details about the affected transaction including providing history information about what happened where and why, it also provides dedicated features for exception handling. Possible causes for necessary exception handling: 1. RfQ: Supplier can't deliver requested item in required quantity, quality or not within agreed delivery timeframe. 2. PO: Items are not delivered in ordered quantity or quality 3. PO: Items are not delivered at all or not on time (e.g. missing port stay of vessel). 4. PO: Wrong items delivered and need to be sent back. 5. Invoice: general problems with received invoice (wrong format, missing essential details, wrong info etc.) 6. Invoice: prices don't match contracted values Beside giving access to transaction details, the ZeeBORN system provides assistance with dedicated features: 1. Sending of PO cancellations. 2. Reissuing POs for different supplier. 3. Splitting POs for getting partial delivery from different supplier. 4. Returning to RfQ state if ordered items were not delivered. 5. Providing immediate access to communication details of each involved party. 6. Creating E-Mails for requesting clarification (incl. adding related documents as attachment etc.). 7. Handling of invoices already received prior delivery and handling partial delivery 8. Registering cancellation invoices or partial invoices ## Budgeting ### Limits During each step of the purchasing process, the integrated budgeting module allows a fine-grained monitoring of the given budget limits and the impact of purchasing transactions on the budget limits. Budget limits can be defined by setting the limits for a given period - e.g. sharing an annual budget to each month of the year or even using a daily budget. For expected exceptional non-regular purchases, additional budgets can be assigned for limited periods (e.g. extended budget limits for dry docking projects). Those limits are assigned by vessel, cost account and additional accounting related structure elements. ### Monitoring For each PO the system shows in the upper right corner in realtime the impact on the budget of the currently handled PO. It provides information if the planned PO is still within the given limit or if and how far it may exceed the given limit. As some exceptional or unexpected orders may exceed the given budget limit, it can also be defined by authorized users, that the selected POs should be handled as exceptional orders. By marking an exceptional order as such, it can still be checked if regular POs for the same cost accounts or cost categories may still be within the given limit - that's basically done by ignoring exceptional POs while monitoring the budget impact. That special handling is of course a matter of separate authorization for this special handling - but can also be fully disabled on demand. ### Integration with Accounting Systems The ZeeBORN budget module can exchange all relevant data with a 3rd party accounting system. This includes 1. line item details and prices of purchase orders/service orders 2. status of delivery incl. exception handling (wrong quality, quantity etc.) 3. status of invoicing (partial invoicing, cancellation, approval) 4. status of payment ## Special Case: Service Order A service order (SO) results from assigning a planned or unplanned maintenance task to an external service provider for execution. This can be done in a planned way (maintenance task will always be executed by external service) or will be individually decided (e.g. depending on the responsible technician's qualification and skills). Compared to a regular purchasing transaction, a service order has the following additional properties: 1. Service order line items are internally linked to the related maintenance task in the PMS module. The monitoring of the transaction can be done additionally in the PMS module at the related maintenance tasks. 2. Service orders can contain additional spare part line items and/or component orders for replacement components. 3. The execution of a service will be reported in the PMS module and will be automatically reported back to the Purchase module as "delivery". Beside this, a service order is a normal purchase order and can be processed like any purchase order incl. RfQ process. ## Special Case: Dry Docking Projects Dry Docking projects are created and managed in a separate module. While the Dry Docking module concentrates on the documentation of a planned dry docking, it is deeply integrated with the PMS and Purchasing module. Related to the integration of PMS and Purchasing module it includes the following tasks: 1. Managing of maintenance jobs that could be preferably executed during the dry docking and should be postponed from regular execution even if those jobs might become overdue - making sure, the postponing of the overdue job is reasonable and documented due to the planned dry docking period. 2. Bundling of maintenance jobs and service orders to be done during a dry docking period 3. Bundling of dry docking specific maintenance jobs and services 4. Bundling of component replacements 5. Bundling of spare part/consumable restocking tasks 6. Bundling of related purchase orders, service orders. 7. Initiating and monitoring a RfQ process for selecting a suitable shipyard and suppliers/services. 8. Monitoring the execution of each maintenance task of the dry docking project. 9. Monitoring of all related deliveries. 10. Budget monitoring. Most of those tasks rely on using the already existing features of the other related ZeeBORN modules and the Dry Docking module provides an "umbrella" on top of those tasks for a better project management. *[PO]: Purchase Order *[AZA]: local folder *[(PO]: Purchase Order *[RQ]: Requisition *[(RQ]: Requisition *[RfQ]: Request for Quotation *[(RfQ]: Request for Quotation *[SO]: Service Order *[(SO]: Service Order *[SQ]: Service Requisition *[(SQ]: Service Requisition *[SRfQ]: Service Request for Quotation *[OoB]: Open on Board *[(OoB]: Open on Board *[ART]: Average Running Time (operation hours per day) *[MC]: Master Contract *[ADS]: Advantage Database Server (database engine used in previous versions of the ZeeBORN software) *[.replic]: file extension for replication files (aka data transfer files)