Please note that this page outlines requirements for the old XUL Client Acq and Serials models. This does not reflect current use (as of 2019) or current Angular Acq Requirements.

The Acquisitions/Serials module will have the ability to add/manage:

• Currencies

• Funds

• Vendors

• Ledgers

• Purchase Orders

• Invoices

• Locations/shipping information

• Publication Patterns

• EDI Profiles

• Rollover rules

• Tax rules

• Routing lists

The Acquisitions/Serials module will have the ability to search:

• All of the above

• Line Items

Library acquisitions systems typically define vendor types, such as Domestic Monographs, addresses associated with a vendor/supplier, and relationship rules, such as claim intervals.

In OFBiz, vendors are defined through the Party Manager Application.

For most vendors, a Party Group will be created, and OFBiz's classification function will be used to indicate vendor type.

OFBiz allows for a classification hierarchy, but in this example, we will place vendor type under a generic level.

We will use a vendor called Renfrew Books. OFBiz has options for associating logos with vendors, but we will go with a spartan entry for now.

OFBiz allows for an enormous amount of detail to be associated with parties, and has mechanisms for checking for things like fraud (AVS checking), and multiple EFT options, including credit cards. There is also a general mechanism for adding metadata to vendor records (via Party Attribute(s)).

Every vendor needs at least one address for purchase orders, and OFBiz is preset for multiple address types (which can also be expanded) to be associated with contact(s) for the vendor. The default options for contacts are shown below:

We will start with a shipping address. There is no limit to the number of addresses that can be added, and these, in turn, can be assigned multiple purposes.

In OFBiz, any kind of party is a clearinghouse for many actions. For example, contacting a vendor with a general information request.

Requests have unlimited items associated with them, and are date-stamped and tracked.

The Accounting cycle is a well established process of ordering materials and tracking financial information. OFBiz uses a Chart of Accounts (COA) as part of its financials, and it is what classifies postings to the general ledger. In North America, a COA will usually have these top level categories.

• Assets

• Equity

• Liabilities

• Income

• Expenses

Some libraries use their organization's COA, and all, a subset, or none of the COA can be reflected in Woodchip. You can think of a COA as a sort of Dewey Decimal system for accounting. Many COAs are publicly available, including the COA used by Georgia Public Libraries and many universities prescribe a COA for departments, for example, McGill.

By default, the COA here assigns library funds to Expenses, but this is arbitrary.

The COA intersects with the ledger through a Payment Method Type, but this also requires a Payment Type since payments can be defined to have different actions on the ledger. We can use a pre-existing Vendor Payment, and the ledger type of Accounts Payable.

At this point, we can assign specific Ledger IDs (which come from the COA) to the Payment Method Type. This allows multiple methods to be assigned to a single ID. There are a couple of different ways to create a method, but one of the easiest is to use Web Tools and in particular, the Data Entity Tool. In this case, we create a type called GEN_MON for general monograph ordering.

We can assign the the ledger here, or use the Accounting Manager. It probably makes a lot of sense to work with the XML files when configuring woodchip from the start if there are a lot of funds to be mapped rather than working through them one by one in the web interface, but for now, we will use the drop-down box in the defaults section of the manager application.

Most libraries probably use funds but it is important to note that Purchase Orders can also be issued directly against a credit card or bank account, which is controlled and displayed in the Payment Information section of the a PO.

Payments are a standalone entity, they can be issued without an Purchase Order or Invoice, but they can't be expended without further action. There are options to change this behavior so that, for example, a Purchase Order can not be issued without a payment. Generally speaking, the expected workflow is to create a PO, issue a payment, and expend the amount based on the invoice, which would normally be automatically created when an order is received.

The tracking and monitoring of activities will usually take place in Financials, for example, payments for outstanding POs.

A purchase order (PO) starts with identifying the organization doing the ordering (Internal Organization), the source/vendor for the order (Supplier), and the option to change the login id if a different account is to be used.

Each vendor can have one or more agreements defined that specify conditions on the order, such as discounts, or the PO can be assigned a default currency and be created with no pre-existing agreement.

The main PO screen has hooks to both Evergreen and the Desiderata application, and payments can be assigned at the time of the order.

The Quick Evergreen Lookup searches the Evergreen database. Evergreen has many options for access points but a subset are used at this point:

The results set is used as the entry point for the record that will become the line item. Selecting the record number pulls fields from Evergreen into the Desiderata catalog record editor.

Saving a record will add it automatically to Desiderata, and a price is then associated with the record.

The Search Desiderata box in the PO screen is the hook for records from sources outside of Evergreen, or records that have already been transferred.

Payments can be assigned to multiple accounts. OFBiz creates an invoice automatically when a shipment is received or partially received, and payments are normally expended to an invoice. Payments are a distinct entity in OFBiz, and PO numbers are used for the Reference No associated with a payment.

When an order is received, an invoice can be created in a number of different ways, but the most straightforward is to search for the PO, and then choose to receive the order from it. Because it is possible to request that different parts of an order go to different locations in shipping, an option is presented for individual shipments and the entire PO.

Shipments can also be further subdivided, or rejected.

The Financials application keeps a running overview of activities. Here, we have already ordered and received an item for $20, and have a newly created invoice from the shipment that has just been processed for $24.99. The result is that the value of the inventory is now considered to be $44.99. The invoice has been created, but not processed.

The invoice itself may be subject to further refinement, or may even need to be printed and sent elsewhere in the organization. Normally, however, the invoice will be marked as "ready".

Payments can be applied in total or combined with others (if the library was combining funds to make a purchase).

Since we had made the payment method type for Vendor Payment associated with Accounts Payable, this ledger line credits the GEN_MON line for the amount.

It is possible to use the Transaction Report to get a quick view of the status of accounts.

Other report mechanisms are available, such as Balances by Vendor, and opentaps has also bundled the Pentaho application (see opentaps wiki entry).

For a resource that has to be paid on a schedule, the record is assigned a subscription. This value defines the period of availability for the resource, and is used for notification that a renewal is due.

Publication patterns are associated with a cycle and one serial title may represent more than one cycle (for example, a title with a monthly publication pattern, which also includes a yearly pattern for an annual index publication).

More detail is available in the notes for Serials Checkin and Pattern Maintenance.

EDIReader is well positioned to be integrated into OFBiz, placing an order via EDI does not represent a substantial addition but invoicing will require some hooks to the general shipment mechanism.