If the BAQ is filtered, is it still bringing down the whole dataset?
Is it possible then to do it with a function to avoid the UBAQ?
or custom BPM to avoid UpdateExt in UBAQ update.
I don’t know SalesOrder functionality to tell anything specifically
1 Like
I think you may be on the right track there. Filtering the [U]BAQ to only return the relevant results (Releases attached to the selected line) would filter it on the server side, only sending the relevant results to the client. That would dramatically speed up the process (loading 400 releases instead of 12,000 releases).
Okay - this might be something I can get behind. That is, if I can find time to work on it.
1 Like
That’s the cool thing about the Kinetic panel cards with grids, you can get rid of the default one and then replace it with your own, bound to a trans view of your UBAQ and they made it so much more approachable IMO as a novice developer.
Update: This issue has been passed along to and accepted by the Development Team as Problem ID: PB0279399
nice!
Oh @jgiese.wci look… I know this is related to SO, but the same applied to Customer FKV
We worked with EBiz to speed up their CreditCard layers and they had same, similar bugs. Most our Customers have 500-3000 ShipTos.
We just eliminated FKV from our Order Entry and every Customer.GetByID call has been replaced with either Customer.GetCustomer or a BAQ DataView called XYZ-CustomerDataView we mimicked the same behaviour that FKV has.
But doing lazy-loading in the Classic client would be tough at this point. Especially if you are in Sales Order and you want to change how SO loads, as far as FKV there are options.
how did you snag the memory usagE?
.NET Profiler by Redgate or JetBrains, also Resource Monitor on your PC. Also it wasnt so much the Memory in the client as much as SQL fetching everything.
Customer.GetByID does in a nutshell fetch all ShipTos, Attachments, Contacts, etc… so if you just want to read the Addresss1 field or CreditHold, you are getting it all.
Customer.GetCustomer just gets the Customer Head row.
2 Likes
That is disappointing. Understandable, but disappointing nonetheless.
Haso,
When sending updates, do you get “Record Updated by Another User” messages or do you do last one wins?
There was another ERP system that would look at the area the user changed and if that area (group of fields) didn’t change, it did a refresh of the record then the update instead of having to the user re-enter the change. For example, if one user changed the releases on line 7 but another user previously printed the document (updating last print date on the header), it didn’t force the second user to re-enter their changes. It did a get then updated the second change. Of course, the devil is in the details about which areas can be changed simultaneously… 
1 Like
They have eluded to this a few days ago, but now they just flat out said it…And I don’t know if I should be insulted, irritated, or impressed with this response 
:
To be honest, even if they do fix it, I think I would rethink how you do this as a business process. You may come to the same conclusion and process in the end, but on it’s face, 12,000 releases for one sales order sounds absurd.
Not saying you should change it, but at least game it out.
1 Like
I agree 100% - It is our customer that does not agree. They have been using the same PO for years (like 5+ years) and they just keep adding more and more releases to it. I have told the CSR team here that this same issue is going to happen again and again, and they (the CSR’s) are going to have to continually split things off into a new SO once the number of releases starts to grow again.
We have asked the Customer to help us out a little and start things on a new PO, but they refuse.
If these were manually keyed into the system it would be one thing. But this specific order is EDI and the system just pushes it right through unless we manually stop (using the Demand tab for the customer) and then split off the EDI into a new SO and then bring in the existing open demand from the old SO. It really is a pain on the CSR’s, but for now it is what we have.
Does EDI push it through to the same SO because it recognizes the PO number on the SO?
Can you modify the PO on the old SO then close it? Change PO 1234 to PO 1234-CLOSED?
There is an option in Demand Entry of “Create New Sales Order”.
This will close the associated Sales Order, Lines, and Releases and open a new Sales Order using the same Customer PO Number as the initial Sales Order. The only downfall is that any existing demand that was in the old Sales Order will need to be entered into the new Sales Order. This can be done via DMT or by creating an EDI app file and importing that using the “Import EDI Process” screen.
When I split off this Sales Order into a new one a few weeks ago, we had to be sure that the new Sales Order had all of the lines in it that the original sales order had, plus any releases that were due to ship out in the next 2 days. So we opted to take the route of creating our own .app file and importing it into the system.
All of the stress was worth it though. Once that new Sales Order was created using Demand Entry, everything started to work smoothly. There are still the occasional warnings for that PO (shipping dates and such) but nothing that is considered out of the norm.
I am NOT volunteering, but that sounds like something that can be semi-automated…
You’re right, this is a job for you.
@jhecker what we implemented in the past was Blanket Orders, so we created some customization to have a Parent Order (Blanket) and then other orders were children. You would still ship them seperately, but the Blanket was the real one with PO. It took some time to customize, but its used by a 12 billion dollar company with large customers that have 10,000 ShipTo’s for Walmart and Releases.
1 Like