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

Browse Source
This commit is contained in:
John Cardinal
2021-05-19 19:45:47 +00:00
parent 24cd6b76d8
commit 1ce5449e51
3 changed files with 52 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
ayanova/devdocs/todo.txt
View File

@@ -341,31 +341,32 @@ todo: many biz objects are not using new PUT methodology
CURRENTLY DOING:
todo: special service rates for contract etc currently just pulls all rates (woitemscheuleduser)
look for notes on this, I wrote them out somewhere about how to handle via variant and pulling contract etc
variant for picklist provide bool check contract and then aytype:id pairs that might have one.
or just pass a variant with contractid in it so the server can just use that contract in addition to other means?
todo: Tax code decoupling from wo so can delete separately (almost there, a bit of testing and decisions first though)
Test what happens when tax code is deleted and removed at back from workorderitemlabor tax id first
want it to be null., can that be automated with an on delete sql constraint?
should I jsut show the taxname separately as a hint *all* the time so no calcs necessary?
that would make shit waaay easier
Pros and cons of removing tax code id from workorder when it's deleted?
Keep tax code id's as are and saving to db as it's convenient for picklist but change schema so that the workorderitem*.tax*id field is not referencing the taxcodes table
so that a tax code can be removed and it's doesn't break the workorder
also, maybe show the taxname if the taxname is nonempty but there is null in the taxcodeid as a failsafe on the form
(small letters underneath picklist if picklist bound to null id but has taxname: "{{taxName}}" not going to add a descriptive thing like "tax previously selected was "blah"" or something)
also todo, if tax code is deleted it *must* be also deleted from all workorderitem* taxcodeid fields it's present on
maybe easiest is a constraint that removes the value when it's removed??
on delete blah blah or handle that at the back end on delete of tax code
todo: once settled needs to flow this back to the po and other tax code items.
todo: tax code ref integrity check should include wo or...
technically I think it should probably just remove them from wo since they are already redundantly storing it, but also it might be good to keep it 50/50 on this one
todo: tax codes, should they just be used to SET a mirror set of fields in other objects thus allowing them to be deleted etc`
currently the workorder stores the tax code id as well as all the data about it that is relevant to teh workorder, but this sets up a link between them
that is technically unnecessary. If the intention is to decouple them, this is a bit of a wasted redundancy, however it does flow like all other things cleanly and displays etc
not sure what to do with this, needs a think.
It *is* important to keep the redundancy, that's a good solid new feature...hmmm...
perhaps the issue is if they delete the tax code it should set the woitem* things that store it's id to null as it will no longer exist, but then the name wouldn't show
I'd like to see it implemented as somethign that is just applied to it and not something that is stored with it and flow that out to PO and global settings etc
then it's less sticky, people can just delete a tax code any time and don't need to rule check all the shit
However it is decoupled now as it stands because it will still have the taxes applied even if the code is deleted separately, just won't display in the UI properly
but that *is* kind of an issue anyway
Circle back to this one
ORDER: Travel, tasks, parts, loans, units, outside service

6
ayanova/src/components/pick-list.vue
View File

@@ -8,6 +8,8 @@
return-object
:items="searchResults"
:label="label"
:hint="hint"
persistent-hint
item-text="name"
item-value="id"
item-disabled="!active"
@@ -87,6 +89,10 @@ export default {
variant: {
type: String,
default: null
},
hint: {
type: String,
default: null
}
},
watch: {

70
ayanova/src/components/work-order-item-labors.vue
View File

@@ -323,6 +323,7 @@
:readonly="formState.readOnly || isDeleted"
:disabled="isDeleted"
:label="$ay.t('WorkOrderItemLaborTaxRateSaleID')"
:hint="laborTaxRateSaleHint"
:ref="
`Items[${activeWoItemIndex}].labors[${activeItemIndex}].taxCodeSaleId`
"
@@ -384,50 +385,6 @@
></gz-currency>
</v-col>
<!-- <v-col
v-if="form().showMe(this, 'WorkOrderItemLaborBasePrice')"
cols="12"
sm="6"
lg="4"
xl="3"
>
<gz-currency
v-model="
value.items[activeWoItemIndex].labors[activeItemIndex].basePrice
"
:readonly="formState.readOnly || isDeleted"
:disabled="isDeleted"
:label="$ay.t('WorkOrderItemLaborBasePrice')"
:ref="
`Items[${activeWoItemIndex}].labors[${activeItemIndex}].basePrice`
"
data-cy="laborbasePrice"
:error-messages="
form().serverErrors(
this,
`Items[${activeWoItemIndex}].labors[${activeItemIndex}].basePrice`
)
"
:rules="[
form().decimalValid(
this,
`Items[${activeWoItemIndex}].labors[${activeItemIndex}].basePrice`
),
form().required(
this,
`Items[${activeWoItemIndex}].labors[${activeItemIndex}].basePrice`
)
]"
@input="
fieldValueChanged(`Items[${activeWoItemIndex}].labors[
${activeItemIndex}
].basePrice`)
"
></gz-currency>
</v-col>
-->
<v-col
v-if="form().showMe(this, 'WorkOrderItemLaborServiceDetails')"
cols="12"
@@ -893,6 +850,31 @@ export default {
this.pvm.rights.change &&
this.pvm.subRights.labors.delete
);
},
laborTaxRateSaleHint: function() {
if (this.activeItemIndex == null || this.activeWoItemIndex == null) {
return null;
}
console.log(
"laborTaxRateSaleHint",
this.value.items[this.activeWoItemIndex].labors[this.activeItemIndex]
.taxCodeSaleId
);
if (
this.value.items[this.activeWoItemIndex].labors[this.activeItemIndex]
.taxCodeSaleId == null &&
this.value.items[this.activeWoItemIndex].labors[this.activeItemIndex]
.taxName != null
) {
return (
'"' +
this.value.items[this.activeWoItemIndex].labors[this.activeItemIndex]
.taxName +
'"'
);
} else {
return null;
}
}
}
};