acq:functions
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
acq:functions [2007/12/09 22:32] – art | acq:functions [2019/06/12 15:29] – aneiman | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ======Acquisitions/ | ||
+ | FIXME Please note that this page outlines requirements for the old XUL Client Acq and Serials models. | ||
+ | |||
+ | ====Requirements==== | ||
+ | The Acquisitions/ | ||
+ | |||
+ | * Currencies | ||
+ | |||
+ | * Funds | ||
+ | |||
+ | * Vendors | ||
+ | |||
+ | * Ledgers | ||
+ | |||
+ | * Purchase Orders | ||
+ | |||
+ | * Invoices | ||
+ | |||
+ | * Locations/ | ||
+ | |||
+ | * Publication Patterns | ||
+ | |||
+ | * EDI Profiles | ||
+ | |||
+ | * Rollover rules | ||
+ | |||
+ | * Tax rules | ||
+ | |||
+ | * Routing lists | ||
+ | |||
+ | The Acquisitions/ | ||
+ | |||
+ | * All of the above | ||
+ | |||
+ | * Line Items | ||
+ | |||
+ | ====Vendor Record Maintenance==== | ||
+ | |||
+ | Library acquisitions systems typically define //vendor types//, such as //Domestic Monographs//, | ||
+ | |||
+ | In OFBiz, vendors are defined through the //Party Manager Application// | ||
+ | |||
+ | {{: | ||
+ | |||
+ | For most vendors, a //Party Group// will be created, and OFBiz' | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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 ([[http:// | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ====Accounting Principles: Accounts, Ledgers and Funds==== | ||
+ | |||
+ | The [[http:// | ||
+ | |||
+ | * [[http:// | ||
+ | |||
+ | * [[http:// | ||
+ | |||
+ | * [[http:// | ||
+ | |||
+ | * [[http:// | ||
+ | |||
+ | * [[http:// | ||
+ | |||
+ | Some libraries use their organization' | ||
+ | |||
+ | By default, the COA here assigns library funds to // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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 | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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// | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ====Creating the Purchase Order==== | ||
+ | |||
+ | A purchase order (PO) starts with identifying the organization doing the ordering (//Internal Organization// | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Each vendor can have one or more // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | The main PO screen has hooks to both // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Saving a record will add it automatically to // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | The //Search Desiderata// | ||
+ | |||
+ | 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. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ====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. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Shipments can also be further subdivided, or rejected. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | The // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Other report mechanisms are available, such as //Balances by Vendor//, and // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | |||
+ | ====Serials==== | ||
+ | |||
+ | For a resource that has to be paid on a schedule, the record is assigned a // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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: | ||
+ | |||
+ | ====EDI==== | ||
+ | |||
+ | [[http:// |
acq/functions.txt · Last modified: 2024/08/25 12:56 by sleary