admin/raven
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2022-02-09 17:15:27 +00:00
parent 6c57392eea
commit 38f582ee6d
1 changed files with 18 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
docs/8.0/ayanova/docs/ay-start-changes-from-v7.md
View File

@@ -49,6 +49,8 @@ Inventory transactions are required for any change of inventory and the inventor
AyaNova 8 does not permit negative on hand inventory values to exist, every part consumed must have a quantity of on-hand inventory to back it up or it's not allowed to be saved.
In v7 a "Part inventory adjustment" was a separate type of object from the actual inventory itself. In v8 inventory is adjusted by making an inventory transaction entry directly into the inventory blockchain. In v8 serial numbers are updated via the Part object, _not_ the inventory adjustment / transaction as in v7.
#### Suggested quantity
If there is a need to enter parts on a work order as a placeholder so as not to affect inventory for planning purposes the work order item part's "Suggested Quantity" field can be utilized for this purpose.
@@ -67,7 +69,7 @@ AyaNova itself will not automatically set or react to changes to the PO status.
### Part Number / primary identifier fields
In v7 Parts had Part number and Part Name fields. Part Number was always intended as the _primary_ identifier for a part however in v8 we've changed Parts to use the more consistent Part Name as the _primary_ identifier.
In v7 Parts had Part number and Part Name fields. Part Number was always intended as the _primary_ identifier for a part however in v8 we've changed Parts to use the more consistent Part Name as the _primary_ identifier.
Users should use the Part Name field in v8 as the primary and sole identifier for a Part wherever possible. This field like all v8 name fields has no practical length limit and should be the main field used to identify parts both internally and externally.
@@ -80,7 +82,7 @@ In order to accomodate this change, the V8 migration utility offers two ways to
Serial numbers have been separated from inventory for v8.
They now reside in a collection of serials for each Part and you can select from the list or enter alternatives or none at all at any time.
They now reside in a collection of serials for each Part and you can select from the list or enter alternatives or none at all at any time.
This supports the many requests from users for the ability to be more free-form with their serial numbers to allow for mistakes or unique needs but still record them in the system when they are consumed on work orders for warranty purposes etc.
@@ -94,15 +96,15 @@ Similar to how Tax Codes worked in AyaNova 7, rates will now have their price af
#### Flexibility changes
User interface: The user interface for the work order has been designed to reduce the clutter on screen as much as possible while still using the fewest possible clicks to navigate around from section to section.
User interface: The user interface for the work order has been designed to reduce the clutter on screen as much as possible while still using the fewest possible clicks to navigate around from section to section.
In addition we've ensured that a work order can be fully completed using a device as narrow as a 360 pixel wide smart phone if necessary.
##### Conflicting edits reduction
In v7 an entire work order was updated at once in the database during a save meaning only one person at a time could edit *any* part of that entire work order and save without conflict with another user attempting to edit any part of the same work order at the same time.
In v7 an entire work order was updated at once in the database during a save meaning only one person at a time could edit _any_ part of that entire work order and save without conflict with another user attempting to edit any part of the same work order at the same time.
In v8 we have broken out the work order save process into each individual section so the work order Header is one section, a work order Item is another, a work order item part it's own section etc. This means if two (or more) people are working separately in the same work order, as long as they are not working in the same section there is no conflict.
In v8 we have broken out the work order save process into each individual section so the work order Header is one section, a work order Item is another, a work order item part it's own section etc. This means if two (or more) people are working separately in the same work order, as long as they are not working in the same section there is no conflict.
For example two people could be working with two different work order items at the same time and save independently of each other or two or more people could be entering parts separately in the same work order item without conflict. Note that there are still circumstances where a conflict can occur and we still recommend people take steps to avoid working in the same areas at the same time, but conflicts will be greatly reduced. V8 still uses the first save wins method of conflict resolution so that no one can save and lose their changes without knowing it.
@@ -114,17 +116,9 @@ In v7 a Client was tightly connected to a work order and needed to be selected p
In v7 a contract was tightly connected to a particular Client and a work order in turn was tighly coupled to the Contract selected. In v8 the work order structure has been changed to allow a Contract to be changed at any time for a work order. Now, a Contract will be automatically applied to a work order if a Customer, Head Office or Unit is selected for the work order and it has no current contract selected. In addition the Contract selected is exposed as a user selectable item so any contract can be applied at any time to any work order or removed if not appropriate.
##### Work order status improvements
##### Address
In v7 the work order status was a single value stored with the work order selectable by anyone and served only as a flag. In v8 the Work order Status has been greatly expanded into a process control feature and is now a collection that is appended to each time a status changes.
In the work order a single status still shows but can be clicked on to see the entire history of all status changes. In addition Work order status now has options to restrict which security Roles can select a particular status or change out of a currently selected particular status. As well, a status can be flagged as being a "Locked" status which will prevent edits to the work order and can be flagged as a "Completed" type status for triggering notifications etc. The combination of these features makes it easir to control the service process as a work order flows through the service process.
For example it is now easy to make a status for the purpose of a Service Manager or Accounting person to lock a work order at a certain point to inspect it before unlocking it to move on to the next step in the process or to trigger a particular notification at a particular point. (Note that Work order **Item** status is still a feature but is a separate collection now from the main work order status and remains the same as the v7 work order **item** status as a single selectable flag.)
##### Address
Work orders now have their own Address field which is stored *with* the work order itself rather than being linked to the Client / Customer or head office. The Customer address will be used unless Bill head office is in effect in which case the Head office address will be the default. In addition there is now a method to quickly select from any relevant address in the work order itself if the User wants to change the entire Workorder address to (for example) one of the Unit's addresses on that work order or type in an alternative value. This preserves history and makes the Work order more flexible for addressing.
Work orders now have their own Address field which is stored _with_ the work order itself rather than being linked to the Client / Customer or head office. The Customer address will be used unless Bill head office is in effect in which case the Head office address will be the default. In addition there is now a method to quickly select from any relevant address in the work order itself if the User wants to change the entire Workorder address to (for example) one of the Unit's addresses on that work order or type in an alternative value. This preserves history and makes the Work order more flexible for addressing.
#### Work order Templates and Duplicate / copy to
@@ -132,7 +126,7 @@ Work orders can now be duplicated like all other objects in AyaNova 8. In additi
For this reason the v7 templates feature is no longer required and has not been ported to v8.
#### Work order status (Closed / service completed replacement)
#### Work order status
The work order status feature has been greatly expanded into a set of powerful features that can support process control with:
@@ -143,26 +137,26 @@ The work order status feature has been greatly expanded into a set of powerful f
These new features are optional and not necessary to use if just a simple status indicator is desired and it can be used in much the same way as in v7 if there isn't a need for the extra features.
#### Closed and service completed
Closed and Service completed have been replaced by the new [work order status](svc-work-order-status.md) system.
#### Customization
Now nearly all fields and sections on the work order form can be removed or made mandatory for entry. We've made design changes behind the scenes to reduce as much as possible the number of manadatory fields that must be filled in so that users can remove more things from the interface through customization if they don't require them.
Now nearly all fields and sections on the work order form can be removed or made mandatory for entry.
We've made design changes behind the scenes to reduce as much as possible the number of manadatory fields that must be filled in so that users can remove more things from the interface through customization if they don't require them.
#### Custom fields / attachments / wiki
In v7 custom fields, attachments and wiki were supported only in the Work order Item part of the work order. We have now added those to the main Work order itself and the Work order item Unit record in addition to the work order item. So there are now three areas in a work order that support these features. Migrated data from v7 will go to the Work order item record the same as v7.
#### Inventory
##### Serial numbers
#### Work order inventory changes
When a work order has a part added / removed or changed, inventory and serial numbers are updated immediately upon save. There is no longer a "Used in service" checkbox to affect inventory; inventory is now considered immediately affected upon save of a work order item part record. This resolves a number of issues that could arise in the past.
Serial numbers can be edited directly from the Part record and are not tied to inventory in v8.
##### Part inventory adjustments
In v7 a part inventory adjustment was a separate type of object from the actual inventory itself. In v8 inventory is adjusted by making an inventory transaction entry directly into the inventory "blockchain". In v8 serial numbers are updated via the Part object, _not_ the inventory adjustment / transaction as in v7.
#### Work order Items
The work order items now have a "Sequence" field and can be re-ordered as desired so that they are listed in the UI and print on work orders in a specific order. If no order is chosen it defaults to the v7 system of newer items appended to the bottom of the list.