I am trying to figure out if I can get Epicor to update multiple rows if I have to do these manually…
We have two warehouses, A and B. Most of what we do is in A.
We have a group of parts that is managed out of B. When the parts were created, no warehouse was specified and so the primary warehouse was set to A and the cost adjustments were done in A.
We would like to both change the primary warehouse to B and to remove a link to A from the part.
The plan is this:
DMT update to change the value of PartPlant.PrimWhse from A to B.
UBAQ (?) to PartTran to change change the warehouse on the cost adjustments from A to B.
DMT delete the PartWarhouse records for A.
My understanding of UBAQs is that while the UBAQ itself supports changing multiple rows, each of those rows is updated individually. At two CostAdj transactions per part, that is a lot of clicking that I would prefer to avoid, if possible.
Is there a way (UBAQ, widget-only BPM, DMT?) to update the value in all the selected records in one shot? I am better at BAQs than BPMs, but it seems like this is something that should be doable. The semi-English language equivalent would be something like:
Set WarehouseCode = 'B"
Where PartNumber in
(query to select affected part numbers)
I did not see a DMT template for PartTran, but that would be the easiest if if actually exists.
You shouldn’t mess with existing PartTran records.
Why do you need to change them? So you can remove the part plant? Have you tried just removing it?
Yes, the goal in removing them is that the Part Warehouse record can be deleted.
We did try just deleting it, but cannot because it has transactions (the cost adjustments) against it.
In general, we don’t mess with PartTran records. However, since these are only cost adjustments (and really only the one adjustment to set the initial cost; it just has two lines), it didn’t seem harmful.
Thanks for the advice.
The only way to edit the PartTran records would be via SQL.
AND I REALLY WOULD ADVISE AGAINST THAT.
What you can do is to “inactivate” that warehouse for that part. Simplest way would be to ad a UD field to PartWhse to indicate “Inactive”, and then add a DD to halt any transactions that would try to use that warehouse.
To hide the “inactive” warehouse, add a MD BPM to PartWhseSearch
Thanks again for your advice.
I think that I am going to suggest that they live with the automatically created records. It appears that as long as Warehouse B is identified as the default warehouse for the part, the system works as they want it to.
Here’s what I have learned in looking at all this, just in case it is useful to someone else:
When a part is created, a Part Warehouse (PartWhse) record is created for the warehouse identified in Site Configuration as the General warehouse (PlantConfCtrl.DefaultWhse). The records is flagged as the default warehouse for the part.
Sometimes that warehouse record can be if another PartWhse record is created with another warehouse identified as the default.
It is possible to have more than one PartWhse record per part.
If a cost adjustment is made, it will be made in all warehouses with a PartWhse record, not only in the default warehouse.
The first PartWhse record, (A, in this case) cannot be deleted if there is a transaction (e.g., a cost adjustment) against it.
The parts we are dealing with are loaded in batches and it takes about 7-10 DMT uploads to load all the info. Until now, there was no Part Warehouse record loaded and the last file loaded was a Cost Adjustment file. So the new plan is this:
Load the files EXCEPT FOR the cost adjustment file.
Create a PartWhse DMT upload to add a record for B and identify B as the default warehouse.
Create a PartWhse DMT upload to delete the PartWhse record for A.
Load the cost adjustment file.