We are using DMT to migrate our open sales orders. We are using the Sales Order Combined template (add new and update). We are populating both OrderDtl#UnitPrice and OrderDtl#DocUnitPrice. And OrderDtl#LockPrice
= TRUE.
Despite our efforts, what gets pulled into the Epicor sales order is the price from the Part table to which the price would default if you opened a new order and added a line.
I assume there is some flag or other that we are missing. We were not sending up OrderDtl#OverridePriceList (it defaults to FALSE), but we tried to update one of the lines with OrderDtl#OverridePriceList set to TRUE and that did not do anything, either.
Please advise the column order that you’re using in your template. DMT will be calling business logic on the back of the fields it is inserting/updating in the database. If you’ve got the UnitPrice before some other column that is calling a method that changes unit price, it’ll get overwritten.
I would try moving UnitPrice to be the last column in your import.
Thanks for the info. We just use the field order as it comes out of the template. I did try moving unit price to the end with no luck. But will now go look at all the fields…
We are using Sales Order Combined. Is it better to put up the order header and then the detail? Someone here though that might help, but I have not yet tried it…
Sam,
I have not used the Sales order combined. All of my imports have been done Header, Details, Release. That said I have experienced the behavior you are seeing in the system if you go and change a ship to on a sales order and you do not have customer price lists. It will default the sales order price to the part price.
We do have customer price lists, but some of our items have no price in the Part table because they are custom product which get priced per customer. So there is no list price.
We are not using a release, though. We use different line numbers with different dates instead of multiple releases per line.
just a thought for a reasonably quick experiment. Null out the part master prices (retain them for reimport after) then test with no price, apart from those you are bringing in in sales order.
We’ve found that there’s definitely a standard sequence/order of bring in tables but omitting non mandatory fields and doing catch-up after the fact with DMT or standard entry for those pesky fields is an option to get the desired results apart from standard entry sequence and behavior. Same issues with supplier prices on an earlier version. For that matter, make sure you are using the newest version of DMT for your version of Epicor.
Best,
Henry Burke
Sorry, Jumped in at the middle. I also did header, line, release when I was migrating and the price held after I added the lock. I looked at the DMT labs and templates and the detail example used DocUnitPrice and SellingQuantity which is what I used.
I’m not sure what is causing your issue, just the fields that I used worked for my situation.
Another tactic you can use is to put the price in a UD field in your spreadsheet and use a bpm to copy the UD field to the price after Epicor has read the price list.
Sam,
Go back thru your import fields and check the lock price. I think Greg hit it on the head with that being the factor of holding the price.
I have both the Unit Price and Doc Unit Price on my imports and do not have any problem with the price resetting on import.
Again I am importing separately Header, Details, Releases
Hi Sam,
DMT aims to use the field that you fill in on the Epicor screen. In this case, the Unit Price field on the Epicor Sales Order Entry screen is associated with the OrderDtl.DocDspUnitPrice field (See Help > Field Help > Technical Details). If you replace the OrderDtl#DocUnitPrice & OrderDtl#UnitPrice fields in your DMT import file with the OrderDtl#DocDspUnitPrice field then you should get the result you want. (I also had to remove the OrderDtl#OrderNum field from the import file).
Thanks for the idea of removing the OrderDtl#OrderNum.
I think my IT guy is going to split apart the Combined into two parts. He had some tests that work. Once we figure it out for certain, I will post the field order that works for us so someone else can benefit from our pain…