This commit is contained in:
2022-02-09 15:46:00 +00:00
parent 15730c2679
commit 6c57392eea

View File

@@ -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. 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 ### 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: 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. 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. 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 #### 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 #### Work order Templates and Duplicate / copy to