Order Errors when invalid Order reference
Tim,
I wasnt sure whether you read my forwarded email, from Bill McGowan(Provet) the changes they implemented worked but apparently it caused errors from users using unreferenced order's ie the provet order reference (generated from a NON openvpms order) is passed to openvpms which cannot find the reference and causes an error. They have now reverted the updates and gone back to not updating deliveries.
Re: Order Errors when invalid Order reference
Hi Ben,
Yes is disappointing that Provet can't ascertain if an order is from the PMS or another source (web, phone) and filter the order reference. Haven't seen this on other suppliers implementations of ESCI but I assume Provet's internal software systems don't record the source of the order.
I suggest we discuss the option of changing ESCI to ignore order references that don't match OpenVPMS orders but obviously this doesn't solve the immediate issue that everyone is experiencing.
Cheers Tony
Re: Order Errors when invalid Order reference
Hi Ben,
I have been liaising with Bill McGown and the team at provet have managed to implement an interim solution to the problem which looks at the Order Reference format to ascertain if it is OpenVPMS (numeric) or non OpenVPMs (may have alpha) order. They have tested this against quite a number of historical orders and it seems to be very accurat ebut obvioulsy they cannot say it is 100% acurrate.
This is great work by Bill and the Provet team and means we have some time to discuss and implement the changes to ESCI I mentioned. We should try and keep this discussion going and make sure it progresses to development. :-)
Would be great to hear if this new approach is working for you now.
Cheers Tony
Re: Order Errors when invalid Order reference
We must not have sent an order during the period in which they stopped and as most of our orders are placed through openvpms we havent had a mismatch / error occur.
I would be interested to see the error logs that were thrown during that time
I took a look at the ordermatching code. I wonder if we might not be better adding some supplier parameters that are configured on the supplier archetype that provides more information as you how openvpms should match.
Provet for example is using document level order referencing , which I suspect is NOT going to go back and update my backorders....on previous orders....I think I will manually need to do this.
I think a View that openvpms lacks in the order system is some way to view the recorded backorders locally.
However, we need to relaxe the order reference id matching which in my view is relatively simple, perhaps when an order doesnt match we just pop a warning dialog to the end user and log it.
Its possible that we could enable/disable this feature on a supplier basis, so in effect maintain the strict compliance for those suppliers that have implemented comprehensively, and those that have implementedly loosely.
Perhaps there are other areas we need to look at this sort of supplier level implementation?
Another enhancement which I think we should implement ASAP is filtering the GENERATE ORDERS and the new Order dialog to only list party.supplierorganisation rather than the current which is party.supplier*, hence it lists all referral vets and referral practices which is confusing. Ideally, I believe a new supplierLaboratory archetype which just handles external labs v actual suppliers. I recognize that some labs are also suppliers so this may not be required.
Re: Order Errors when invalid Order reference
We want suppliers to implement the spec, not some approximation of it.
The latest Provet implementation provides the order reference per line item. It doesn't include the original order item identifier, but OpenVPMS will match on product and/or quantity. So if Provet supplies the order reference for a back ordered item, it should update the original order.
Regarding the party.supplier* issue, this could be changed for Generate Orders but for the general case, the participation.supplier archetype drives what suppliers may be selected. This is used by all of the act.supplier* archetypes so can't really be changed.
Re: Order Errors when invalid Order reference
While I understand - the bottom line is that the order system has to work for the end user and cant rely on the suppliers implementing exactly how we expect them too. Leaving that hole open allows for third party error, and that is really annoying to end users..
So we need to give the users tools to work around supplier errors.
In the past few weeks since provet started various implementations I have seen those errors first hand
1. I have seen products not match from delivery to orders despite appearing to have the same REORDER codes etc? Openvpms doesnt log these (probably should output some sort of log) and the reason they didnt match.
2. I cant edit an order and record a product as delivered -I can only edit an order and record a product as cancelled....I really should be able to mark it as delivered manually. This might involve some sort of manual order delivery matching for single items. This seems more apparent this week than any other.
3. When a Updated product arrives (currently unlinked to the product database) (does the ESCI spec allow suppliers to let the client know that a code has been updated and/or changed?) I can easily link it, but in some cases I would want to create a new product, meaning I need to exit the Delivery workspace or create a 2nd browser screen and create the product.
4. I know for a fact that my supplier doesnt notify if an order line item cant be processed it just accepts the order....that item will just never appear on the delivery. It will sit in orders pending for ever unless manually cancelled.
These are just some of the issues - none are deal breakers - the system really is very good on the whole.
Sincerely
Ben
Re: Order Errors when invalid Order reference
1. If there was no product in the delivery, then the supplier reorder code in the UBL invoice didn't match that in the Product Supplier relationship.
2. There could be a admin function to manually set a product as delivered. i.e. if you have admin privileges, you would be allowed to override the Received quantity of the order. Alternatively, a button 'Mark All Received'.
3. If there is no match on reorder code, you will end up with an empty Product field in the delivery.
In this case, there could be an administrative function that enables the user to create a new product for a delivery item. E.g,
a. Select delivery item with no product
b. 'New Product' button is displayed
c. Clicking on this displays a popup, prompting for the type of product to create (medication, merchandise)
d. Details are copied to the product
e. On save, a supplier relationship is created with the reorder details
f. The new product is automatically used in the delivery
4. ESCI doesn't specify how a supplier should handle items on back-order. It does allow the supplier to send a subsequent invoice out, but there is no facility to indicate that an item has been cancelled on the supplier side, other than rejecting the whole order, and indicating the reason.