======Acquisitions/Serials Module======

FIXME 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.

====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

====Vendor Record Maintenance====

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//. 

{{:acq:pmanager1.jpg|OFBiz Party Manager}}

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

{{:acq:pmanager2.jpg|OFBiz Party Manager}}

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

{{:acq:pmanager3.jpg|OFBiz Party Manager}}

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.

{{:acq:pmanager4.jpg|OFBiz Party Manager}}

OFBiz allows for an enormous amount of detail to be associated with parties, and has mechanisms for checking for things like fraud ([[http://en.wikipedia.org/wiki/Address_Verification_System|AVS checking]]), and multiple [[http://en.wikipedia.org/wiki/Electronic_funds_transfer|EFT options]], including credit cards. There is also a general mechanism for adding metadata to vendor records (via //Party Attribute(s)//).

{{:acq:pmanager5.jpg|OFBiz Party Manager}}

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:

{{:acq:pmanager6.jpg|OFBiz Party Manager}}

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.

{{:acq:pmanager7.jpg|OFBiz Party Manager}}

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

{{:acq:pmanager8.jpg|OFBiz Party Manager}}

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

====Accounting Principles: Accounts, Ledgers and Funds====

The [[http://www.netmba.com/accounting/fin/process/|Accounting cycle]] is a well established process of ordering materials and tracking financial information. OFBiz uses a [[http://en.wikipedia.org/wiki/Chart_of_accounts|Chart of Accounts]] (COA) as part of its financials, and it is what classifies postings to the [[http://en.wikipedia.org/wiki/General_ledger|general ledger]]. In North America, a COA will usually have these top level categories.

  * [[http://en.wikipedia.org/wiki/Asset|Assets]]

  * [[http://en.wikipedia.org/wiki/Ownership_equity|Equity]]

  * [[http://en.wikipedia.org/wiki/Liability|Liabilities]]

  * [[http://en.wikipedia.org/wiki/Income|Income]]

  * [[http://en.wikipedia.org/wiki/Expense|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 [[http://www.georgialibraries.org/lib/publications/COA_0507.pdf|Georgia Public Libraries]] and many universities prescribe a COA for departments, for example, [[http://www.mcgill.ca/accounting/handbook/chartaccounts/|McGill]].

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

{{:acq:coa.jpg|Default Chart of Accounts}}

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 //[[http://en.wikipedia.org/wiki/Accounts_payable|Accounts Payable]]//.

{{:acq:payment_method.jpg|Payment Method}}

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.

{{:acq:payment_method_type_edit.jpg|Payment Method Type Edit}}

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.

{{:acq:method_to_gl.jpg|Payment Method Assignment}}

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.

{{:acq:payment_po.jpg|Direct Payment Option}}

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.

{{:acq:payment_search.jpg|Payment Search}}

====Creating the Purchase Order====

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. 

{{:acq:po1.jpg|PO Opening Screen}}

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.

{{:acq:po2.jpg|PO Agreement Screen}} 

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

{{:acq:po3.jpg|PO Main Screen}} 

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

{{:acq:osrf1.jpg|Search Screen for Evergreen from within PO}} 

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.

{{:acq:osrf2.jpg|Results display from Evergreen Search}} 

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

{{:acq:prod1.jpg|Prices screen for Product Entry}}

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.

{{:acq:po4.jpg|Payment Search Screen}} 

====Invoicing====

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.

{{:acq:po5.jpg|Receiving a Shipment}}

Shipments can also be further subdivided, or rejected.

{{:acq:po6.jpg|Receiving Item(s)}}

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.

{{:acq:fin_home.jpg|Receiving Item(s)}}

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".

{{:acq:fin_inv.jpg|Invoice display}}

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

{{:acq:payment_inv.jpg|Applying payment to Invoice}}

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.

{{:acq:payment_ledger.jpg|Applying payment to Invoice}}

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

{{:acq:report1.jpg|Transaction report}}

Other report mechanisms are available, such as //Balances by Vendor//, and  //opentaps// has also bundled the [[http://en.wikipedia.org/wiki/Pentaho|Pentaho]] application (see [[http://open-ils.org/dokuwiki/doku.php?id=acq:functions|opentaps wiki entry]]).

{{:acq:report2.jpg|Balances by Vendor report}}


====Serials====

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.

{{:acq:sub1.jpg|Subscription Screen}}

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 [[acq:serials:sketches|Serials Checkin and Pattern Maintenance]].

====EDI====

[[http://edireader.sourceforge.net/|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.