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

@@ -25,7 +25,7 @@ Clients have been renamed to Customers
 
 Customers in AyaNova 8 now have unlimited Contacts as a seperate collection of User type objects so you can optionally allow them to login to use the Customer interface and subscribe to Customer specific notifications.
 
-Migrating from AyaNova 7 will result in a Customer Contact type User being created for each v7 Customer or HeadOffice type User account and in addition a Contact will be created in v8 if the v7 Client has a name set in the "Contact" text field with the Client phone and email numbers being re-used for the contact created this way. 
+Migrating from AyaNova 7 will result in a Customer Contact type User being created for each v7 Customer or HeadOffice type User account and in addition a Contact will be created in v8 if the v7 Client has a name set in the "Contact" text field with the Client phone and email numbers being re-used for the contact created this way.
 
 The Contact notes text field in v7 that is intended for listing extra contacts will be migrated to the v8 general Customer Notes field as there is no practical way to migrate that text field as additional Contact type users in v8.
 
@@ -43,7 +43,7 @@ There is no longer a "Used in service" checkbox in Work orders, they consume inv
 
 If a work order consumes a quantity of 5 for a part and is saved that amount is _immediately_ removed from inventory. If the work order is subsequently edited to change the 5 to a 3 then a quantity of 2 is immediately returned to inventory upon saving the changed work order.
 
-All inventory changes are tracked in a blockchain inside your AyaNova database and this block chain can be viewed in the Inventory transactions data table. 
+All inventory changes are tracked in a blockchain inside your AyaNova database and this block chain can be viewed in the Inventory transactions data table.
 
 Inventory transactions are required for any change of inventory and the inventory transaction blockchain is the only repository for inventory quantities in AyaNova.
 
@@ -57,13 +57,19 @@ If there is a need to enter parts on a work order as a placeholder so as not to
 
 Purchase orders and receipts have been combined in v8 and are no longer separate objects.
 
-The various rules around Purchase order editing have been eliminated. In v8 purchase order editing ability is no longer controlled by their Status and a PO can be edited anywhere any time. Behind the scenes AyaNova will make the necessary adjustments to inventory to support any edit changes made to purchase orders if they have already affected inventory or work order item part requests. This allows for easy edits when things change post order, for example if a supplier has changed a price or an item has been replaced by another one after being ordered.
+The various rules around Purchase order editing have been eliminated. In v8 purchase order editing ability is no longer controlled by their Status and a PO can be edited anywhere any time.
 
-Status is still available and can be set to any value at any time as users need for displaying in lists and controlling the process. AyaNova itself will not set the PO status automatically at any time.
+Behind the scenes AyaNova will make the necessary adjustments to inventory to support any edit changes made to purchase orders if they have already affected inventory or work order item part requests. This allows for easy edits when things change post order, for example if a supplier has changed a price or an item has been replaced by another one after being ordered.
+
+Status is still available and can be set to any value at any time as users need for reference purposes displaying in lists and controlling the process.
+
+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. 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.
+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.
 
 In order to accomodate this change, the V8 migration utility offers two ways to migrate the existing part fields as an optional choice before migration:
 
@@ -74,7 +80,9 @@ 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. This supports the many cases where users requested 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.
+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.
 
 Migrating from v7 will place any existing serials into the serial number collection automatically.
 
@@ -86,17 +94,37 @@ 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. 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.
+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. 
 
-Decoupling of sections to reduce conflict: In v7 an entire work order was updated at once in the database meaning only one person at a time could edit **any part** of that work order and save without 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 what 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.
+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.
 
-Decoupling of Client: In v7 a Client was tightly connected to a work order and needed to be selected prior to creation of a work order and could not be changed. We've made many behind the scenes structural changes to remove this limitation. In v8 the Customer can be changed at any time for the work order as a whole.
+##### Conflicting edits reduction
 
-Decoupling of Contract: In v7 a contract was tighly 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.
+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. 
 
-Work order status improvements: 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.)
+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. 
 
-Address is now 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.
+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.
+
+##### Decoupling of Client
+
+In v7 a Client was tightly connected to a work order and needed to be selected prior to creation of a work order and could not be changed. We've made many behind the scenes structural changes to remove this limitation. In v8 the work order's Customer can be changed at any time.
+
+##### Decoupling of Contract
+
+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
+
+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 order Templates and Duplicate / copy to