Currently, all product prices are stored inclusive of tax. This makes it difficult to update prices if a tax rate changes. All prices must be manually updated to incorporate the rate change

This project will:

• store all product prices tax-exclusive
• calculate tax-inc prices when a product is charged
• display products with both tax-inc and tax-ex prices

A new flag "Display Prices Tax-Inclusive", set at the Practice level, will determine how prices are displayed.

In the Product browser, this will determine if fixed and unit prices are displayed tax-inclusive or tax-exclusive.

When viewing products, both tax-inclusive and tax-exclusive prices will be displayed.

Price Editing

When editing products, both tax-inclusive and tax-exclusive prices will be editable.

If the tax-inclusive price is changed, the tax-exclusive price will be derived, and vice-versa. Only the tax-exclusive price will be stored.

Where Display Prices Tax-Inclusive is true, this allows tax-inc prices to be assigned a round amount.

Report Changes

The following reports need to be updated to display prices based on the Display Prices Tax-Inclusive flag:

• Product List
• Product Price List

These will need:

• new JXPath extension functions that calculate the tax-inclusive price
• support to invoke JXPath extension functions from within an SQL report.

Data Migration

Product fixed and unit prices must be updated to remove the tax component.

Prices are currently calculated using:

price = (cost * (1 + markup/100) ) * (1 + tax/100)

and then rounded to the no. of decimal places specified by the currency.

The migration script will recalculate the price using

price = round(price/(1 + tax/100),3)

This is required for practices that loaded historical price data without the cost information.

The migration script cannot determine the number of decimal places to use, so will default to 3 decimal places.

NOTE: due to rounding, the calculated tax-inc price may be different to that prior to migration. The difference will be a fraction of a cent.

Related project: http://www.openvpms.org/project/add-support-invoice-level-taxation

Price Description

The productPrice.unitPrice and productPrice.fixedPrice archetypes have derived description nodes:

concat('$ ',/price, ' ',openvpms:lookup(.,'uom'),' (',date:formatDate(/fromDate), ' - ',date:formatDate(/toDate),')')

i.e. they contain text like:

$ 8.37 Ampoules(13/07/2006 - )

These will be migrated to contain the tax exclusive price. This description will not be displayed in the user interface, as it won't necessarily reflect the current practice configuration.

This project will add the following xpath extension functions to be used in macros and reports:

Currently, Scheduling and Work-List workspaces must be manually refreshed to see changes by other users.

This can be done by:

• clicking Find
• switching views
• changing workspaces

This project will provide support to periodically refresh the display automatically.

As this change will cause additional server load, the refresh interval should be configurable. It should default to 30 seconds.

JIRA: OVPMS-2064

At present, all mails sent via the mail dialog can only be addressed to a single address.

When emailing customers, users may select from a list containing the customer's email addresses, and those of any referring vets for the current patient.

When emailing suppliers, users may select from a list containing the supplier's email addresses.

This project will allow support for:

• multiple To addresses to be entered
• multiple CC addresses to be entered
• multiple BCC addresses to be entered
• staff email addresses

JIRA:  OVPMS-1555

This feature provides support for managing and using prescriptions. The following describes the proposed specification for this project:

• A new prescription tab will be available in the Patient Medical Records workspace.  This will allow users to create, edit and delete prescription information.
• The prescription tab will also be available in the Check In and Consult workflows allowing prescriptions to be managed and dispensed during these work flows.
• Prescription information will include the medication(product) to dispense, dispensing qty, number of repeats, expiry date, qty dispensed (read only), clinician who created the prescription and label information.  
• When creating a new Prescription the label information will default to the label information for the selected product.  This can be edited and will be stored with the prescription and used for subsequent dispensing.
• The Practice can set a default Prescription expiry period. 
• Prescriptions that have a non zero qty dispensed amount cannot be deleted.
• A Print button will allow printing of a prescription specific template defined in Administration -> Templates with a new Type of "Prescription".
• A Dispense button will display the standard label dialog with the quantity field defaulted to the prescription default quantity (or the quantity remaining if less), the label text to the prescription default label text and the clinician to the current clinician. The amount, expiry, clinician and label can be modified.  The amount entered cannot be greater than the amount remaining to be dispensed which is  ((no of repeats+1) X dispensing qty) -  qty dispensed.   On confirming the dialogue the prescription qty dispensed is updated and a new invoice line item and associated visit medication are added to the appropriate invoice and visit.
• Users cannot dispense from a prescription who's expiry date has lapsed or the qty dispensed is equal to ((no of repeats+1) X dispensing qty).
• During invoicing if a product is selected that has a valid (non expired and greater than zero available qty) prescription defined the user will be prompted if they want to dispense using the selected prescription or not.  If selected the process above is invoked otherwsie the standard medication dispensing process is used.

JIRA: https://openvpms.atlassian.net/browse/OVPMS-1307

This project will add an "Estimates" tab to the visit editor to manage estimates during visits.

The tab will:

• display all estimates for the current patient
• add buttons to:
  • create new estimates
  • edit estimates
  • invoice estimates
  • delete the selected estimate

Estimates will apply to the visit patient only i.e. if an estimate exists that contains both the visit patient and other patients that the customer owns, it will not be displayed.

When invoicing an estimate, the items will be added to the visit invoice.

JIRA: OVPMS-1346

At present, archetypes and reports can format dates using the following xpath functions:

• date:formatDate(value) - formats a date using the locale's MEDIUM format
• date:formatDate(value, style) - formats a date using the style - one of "short", "medium", "long"
• date:formatTime(value) - formats a time using the locale's MEDIUM format
• date:formatTime(value, style) - formats a time using the style - one of "short", "medium", "long"
• date:formatDateTime(value) - formats a date/time using the locale's MEDIUM format
• date:formatDateTime(value, style) - formats a date/time using the style - one of "short", "medium", "long"
• date:formatDateTime(value, dateStyle, timeStyle) - formats a date/time using the specified styles

This project will add an xpath function to that specifies a pattern for the format, to provide fine-grain control over how dates and times are presented. This will use the pattern from the SimpleDateFormat class.

E.g.:

• date:format(value, "dd/MM/yyyy h:mm a")  - "21/03/2013 9:32 AM"
• date:format(value,  "EEE, MMM d") - "Fri, Mar 23"

JIRA: https://openvpms.atlassian.net/browse/OBF-223

This project will enable Jasper Reports to be evaluated as macros, to enable complex macro processing.

This project will make the current application context available to macros using variables.

The variables will be available to macros:

• during editing
• when sending mail
• when sending SMSes
• when editing report parameters

This project will add support to export reminders that need mailing to a CSV file, instead of printing them.

This can be sent to a third party to perform the reminder mail-out.

The CSV file will contain:

• customer identifier
• customer title
• customer first name
• customer surname
• customer street address
• customer suburb
• customer state
• customer postcode
• customer phone number (SMS phone number, or preferred phone if not available)
• patient identifier
• patient name
• patient species
• patient breed
• patient sex
• patient colour
• patient date of birth
• reminder type id
• reminder type name
• due date
• reminder count
• reminder last sent date

To determine if a reminder should be printed or exported, the entityRelationship.reminderTypeTemplate archetype will have a new boolean "export" node. If true, and the reminder is to be mailed, it will be exported instead of printed.

The CSV file will be downloaded to the browser for the user to save on completion of reminder generation.

Tab separated files will also be supported, to avoid the need to escape fields containing commas.

The type of export will be configurable at the practice level.

JIRA: https://openvpms.atlassian.net/browse/OVPMS-1308