1.8 introduces two features that make it important that the Practice Location is set appropriately:  the practice location set in the customer information screen (which defaults to the current location when the customer is created), and the service ratio pricing facility (where the pricing of items is dependent of the practice location set when the invoice is created).

This project will enable the OpenVPMS logo shown at the top left of the screen to be a function of the currently selected practice location.  This graphic is 27x128 - but can have a larger width to accomodate practice location information.  In the example below it has been extended to 384 pixels wide. Here the practice location is indicated by both the text and its background colour. Note that although consideration was given to altering the screen's background colour as a function of the current practice location, it was decided that it was best to reserve the background colour to allow its use for distinguishing production and test systems.

The graphics will be stored in the database (so as to simplify migration) and specified via the Administration|Organisation|Practice Location screen. 

It is up to the user to specify an appropriately sized graphic (27 high and up to 512 wide). The image format can be gif, png or jpg.  The standard graphic to use as a start-point can be found at <TOMCAT-HOME>\webapps\openvpms\images\openvpms.gif

JIRA: OVPMS-1646

When crediting a customer, the only approach supported at present is to use a separate Customer Credit transaction.

This is cumbersome, as it means stopping the current workflow, performing a Credit, then resuming the workflow.

This project will:

• enable Credit Items to be added to Invoices
• change Pharmacy Returns to use Credit Items in invoices where possible

This will streamline pharmacy return processing. Currently, these either:

• adjust the quantity on the existing invoice; or if the invoice is finalised
• create a new Customer Credit

In the former case, if the return takes the quantity to zero, any fixed price must manually be removed.

In the latter case, this must be done from the Customer Orders workspace. This is inconvenient, as it means breaking out of the workflow.

• remove the need to use negative prices to support discounting

Overview

There is currently no way to determine:

• who last edited an object
• who created an object (with the exception of acts)

This project will add support to track the who created and updated an object and when. This information can be:

• displayed in the user interface
• included in reports

Creation and update information will be added to:

• Acts (includes financial acts, document acts)
• Entities
• Parties
• Users
• Products
• Product Prices
• Lookups
• Documents
• Archetypes
• Roles
• Authorities

This will be done by adding four new columns to the underlying database tables:

• create_time
• create_user
• update_time
• update_user

These will be exposed on the archetypes as the following nodes:

• createTime
• createUser
• updateTime
• updateUser

These nodes will be hidden and read-only.

This change will also:

• remove the need for participation.author on acts
• remove the need for createdDate on party.patientpet

User Interface Changes

Editors and viewers will be updated to display the create and update information on the top right of the view.

Database changes

The following tables will be updated to include the create_time, create_user, update_time and update_user columns.

• acts
• archetype_descriptors
• assertion_type_descriptors
• documents
• entities
• lookups
• product_prices
• security_roles

To aid reporting, indexes will be placed on the create_time and update_time columns.

Migration

• for acts that provide an author node, the createUser will set to the author, and the author participation will be deleted
• party.patientpet instances with a non-null createdDate will have a change record created, with the timestamp set to createdDate. The createdDate will be removed.
• document templates that reference author nodes need to be updated to use

openvpms:get(., "createUser.name")

Exclusions

This project will not provide create/update information for:

• contacts
• relationships
• identities
• links

The information can be obtained from the parent objects e.g. for a phone number contact, the party.customerperson object will track who created or updated it.

This project will extend the display of the Items table in charges and estimates to:

• display a Template column

This will indicate the product template that the item came from.

If the item isn't associated with a template, it will be blank.

• display a Product Type column

This will indicate the product type of the item's product.

If the product isn't associated with a product type, it will be blank.

• allow the new columns to be shown/hidden

The Items table is already very wide, so the display of the columns may be suppressed.

Check boxes for Show Template and Show Product Type will be displayed above the Items table to show or hide the respective column.

By default, the columns will be hidden.

• enable sorting on these columns

If both columns are displayed, then selecting the Template column will sort on Template, then Product Type, then Date. This is the default behaviour if both columns are displayed.

If one column is displayed, then the default sort will be the column and then Date.
 

• include Practice options:
  • Show Template during Charging and Estimating
  • Show Product Type during Charging and Estimating

These determine if Show Template and Show Product Type are initially selected  or not.

• keep the settings for the lifetime of the session

If the columns are shown or hidden, these settings will be stored while the user remains logged in so that the same changes don't need to be re-done each time the user performs charging/estimating

JIRA: OVPMS-1648

New customers are currently given a default phone and location contact.

This project will:

• include a default email contact
• automatically remove the email contact if it is not populated

JIRA: OVPMS-1675

This project will provide a new administration workspace that will provide fine-grained control over ESCI inboxes.

It will:

• list ESCI suppliers
• allow the inbox of a given ESCI supplier to be browsed
• allow messages to be selected and processed individually
• allow an inbox message to be administratively deleted
• allow the content of an inbox message to be viewed as text

Processing Messages

By default, ESCI processes messages for all supplier inboxes, in the order that they are received. If a message is invalid, processing of the supplier inbox stops until the problem is rectified.

A frequent cause of errors is invoice messages having incorrect order references.

This project will enable:

• messages to be selectively processed

Messages may be processed out-of-order. If the message is not the first message in the inbox, a warning will be displayed.

• messages to be processed with invalid order reference errors suppressed

A dialog will be displayed with a "Ignore invalid order references" check box.

This will be off by default. If ticked, any invalid order references will be ignored, but displayed in a popup when the order is processed.

Message Deletion

This project will support message deletion by acknowledging the selected message. This will prevent a message being processed by OpenVPMS, and can be used to remove malformed or incorrect messages.

A confirmation dialog will be displayed prior to deletion

User Interface

A new ESCI screen will be added to Administration. This will:

• list suppliers and the corresponding stock locations that use ESCI for ordering
• provide a filter on supplier and/or stock location

Double clicking on a supplier/stock location, or clicking the Inbox button, will display the Inbox for that supplier and stock location.

Inbox

The inbox displays:

• the supplier and stock location that it pertains to
• a table containing:
  • Id - the message identifier
  • Date - the message date
  • Type - the type of the message

Selecting a message in the table enables the following buttons:

• Process - processes the message
• Delete - deletes the message
• View - displays the message as text

Exclusions

Malformed messages (i.e. those that don't conform to the ESCI or UBL schemas) will not be able to be:

• displayed as text. An error message will be displayed instead.
• processed. Messages from suppliers must be well-formed in order to be accepted

JIRA: OVPMS-2347

In countries that have a low-value currency, it is standard practice to set the product's price (i.e. selling price) in round dollars.  For these environments, one needs the system to round any automatically calculated prices.

This project will add a 'Round Product Price to' field to the Currency screen. This will round prices to the specified amount. By default this will be set to $0.01. 

If this is set to say $1.00 then automatically calculated prices will be rounded to the nearest dollar. If it was set to $0.20 they would be rounded to the nearest 20 cents.

The Product Price Rounding will apply to both fixed and unit prices.

Prices will only be rounded when:

a) editing a product, and the product's markup or cost price are updated and the product's price is recalculated; or

b) Auto Price Update is set and a delivery is finalised which contains an updated Supplier List Price. [This will update the cost price to the list price, and calculate a new rounded unit price.]

Rounding will not occur if:

• the Import facility is used to update a price
• the price is entered during charging or estimating

JIRA: OVPMS-1649

Overview

OpenVPMS supports ad-hoc emails of:

• customer charges and estimates
• customer, patient and supplier documents
• reports

E.g., to email a patient document, the Print button is selected in Patients - Medical Records - Documents. The displayed Print window has a Mail button. Selecting this displays a Write window with:

• the Subject set to the document template name
• the document attached

This project will extend this functionality so that emails are pre-filled with text defined in the associated Document Template.

The text may optionally contain macros, to enable text to be generated based on what is being mailed.

This will save time and ensure consistency when sending emails.

This project will allow a service ratio to be applied to fixed and unit prices when charging and estimating.

The service ratio is determined by:

• the Practice Location; and
• a product's type

This can be used by practices that provide an out-of-hours clinic to charge a premium for products.

Overview

This project will allow discounts to be enabled or disabled on a Practice Location basis.

This is primarily designed for practices that provide out-of-hours services where discounting is not used. For these practices, a separate Practice Location will be configured that disables discounts.