Cannot change part number on inventory transfer without clearing screen

Yes, they are not planning on fixing this.

From what I understand there was a different bug where the on hand quantity was not being calculated properly in the inventory transfer screen so when development fixed that, they made us start having to clear the screen. This then affected all of us who do multiple transfers of the same part…

Such a bummer.

I’ve tried escalating this with Epicor to no avail. To me it’s like having a problem with a car that means it stalls sometimes, so they make it so you have to turn the ignition off and back on again every time you stop at traffic lights. Fix the problem but make it a total pain to use. I wish there was a way of getting this feedback into the guys who actually made this stupid decision but there doesn’t seem to be unless anyone has any ideas!

1 Like

Yeah this isn’t getting fixed.

The silver lining is that this is a UI design disagreement - and one in the soon to be legacy Smart Client. With the availability of REST, users are no longer limited to these UI design constraints. It is now possible to create your own web-based Transfer screen that is most efficient for your business needs and available on devices like tablets and phones.

1 Like

Yes, I started fooling around in visual studio yesterday with this.

I got stuck on the GetNewTransferOrder Method which is the very first method I see in a trace.

The rest call is expecting a body of JSON filled out… I don’t understand where they are getting all of those values. I also don’t know if the method call is truly needed, but I know that the dataset it returns is used in many subsequent calls so maybe it is?

Very flexible though if you are adept at programming.

I recommend taking a page from the @Aaron_Moreng school of integration and make up your own API and just use the trace to create your Epicor Function library. One function might return the part information and another to do the transfer. Play around with it. Just keep the logic in the functions and simplify the API for the client. You’ll have to do the validations/error handling on your own but even those show up in the trace.

1 Like

Is there documentation on functions in the ice tools tech ref guide?

1 Like

You don’t need “workarounds” for properly functioning software. If the intent is that the user must clear it between entries, then that’s just how it works. And isn’t a “workaround”.

[ gets off soapbox ]

1 Like

I agree I guess.

Just sucks they took away functionality. Didn’t really think it through in my opinion. And if this is the way they intended it to be used they did a horrible job with the UI.

It shouldn’t let you do anything with the previous transactions, there shouldn’t be a “new” button available if you have already made one transaction.

“This is how it works,” is not cool when it clearly isn’t working as it should. Fine if they take away the functionality, but change the UI and form to work the way you say it should.

1 Like

You betcha. ICE Guide.

Some forms (like the Inventory transfer) should be viewed as “one time use”. Because they create transactions, not records. Yes, the transactions are records. But you can’t pull up an in inventory transfer like you can a packer or order.

When you save an Order, it doesn’t clear the screen and expect you to make a new order from scratch.

Inventory Transfer used to create the partran records, clear some fields on the form(like: Transfer Qty, To and From Bins, Reference, Reason code, etc…), and update others (like the grid of Bins with QOH). But it would also leave some pre populated (like the PartNum). This was handy if you had to do multiple transfers for the same part. Not so much if a different part needed transfers.

If you needed to do a different part transfer you could click new and it added to the tree. You could process it and then click new again and transfer a different part number and it would save that one in the tree as well.

Then if you wanted to go back and transfer the same part you did three transactions ago, you could click that part in the tree, change the source (if needed), then click process. It would create another sub-entry in the tree under the original part.

This functionality no longer works.

You have to do a transaction, click process, then clear. Then type the part all over again if you want to make another transfer. It saves time to use the tree as a template, much like it does to use a job as a template or a quote as a template.

They took this away and now it is working as intended.

2 Likes

Ahhhhh … And the transaction log that can be printed is gone when you clear the form? So if you did 10 transfers, you’d have to print the log in between each of them, no?

Or am I confusing it with Qty Adj (which we definitely need the log to be printed, as we have a sign off procedure for Qty Adj’s)

Not sure, we aren’t really looking at the inventory transfer screen to see what happened. We are trying to use it to do transactions. And they used to make it easy to transfer parts over and over again by not having to click new, fill out the part number, the locations, etc… You could just select the part in the tree from a previous transaction and then use that again.

I know it’s not ideal, but maybe you can just pull in a bunch of parts at a time (using a BAQ search) or even just pull in all parts. That will at least give you multiple parts in the nav tree. I do this with BAQ Search that gives me a list of parts by part group. I usually haven’t had any issues jumping back and forth between parts by clicking on the part in the tree.

I feel your pain, though. We’ve been frustrated by the same sort of UI/UX inconsistencies for a long time. Last year I ended up just making my own inventory transfer web app and it’s worked out pretty well. It was a good crash course in Angular and wasn’t without its challenges. But now we have an inventory transfer app that works on the ipads and looks/behaves exactly how we want it to, so it definitely was worth it. +1 for the REST api

2 Likes

Yep, this was a huge bummer at my last job. We had an otherwise very successful upgrade to 10.2.700, but this got missed in the testing, and it left a large faction of the warehouse feeling like they were much worse off after the upgrade…

1 Like

I’m a bit confused - did they fix this prior to 10.2.700.9?

We just upgraded from 9.05.702a to 10.2.700.9 and I can see that the part number box and button are now greyed-out after doing a transfer so we can’t just key in or search for a new part. But we can click the new button, enter a new part, transfer it and it saves in the tree as well. If we want to do another transfer of the same part, we don’t even have to hit “new”, we just key in new quantities and bins and hit “transfer” again and it adds the transaction to the existing part. If we want to do another transfer for a part that we already did previously, just select it in the tree and do another transfer. Basically it sounds like its now working “as its supposed to”, aside from the change from E9 that we can no longer key in a different part number after completing a transaction (we have to use the “new” button). But aside from that small difference it actually seems to work pretty well.

Interesting, thanks for adding your own experience. Glad to see they allow the re-entering now. Interesting that if you would like to add a new part you have to use the new option, but at least it is working.

I’m pretty sure the part field is not cleared out, with the Kinetic UI in 2021.2… Just not the ‘classic modern’ UI. At least that’s one step back, and finally a step forward again. :slight_smile:

1 Like

Did anyone find a customization as a workaround to this? I’m trying to override the ReadOnly property, but its not sticking. This is still an issue in Kinetic 2021.2.21

1 Like