Idea and discussion portal for the bulk materials product line. Users may submit, view and vote on ideas submitted by all users.
The current data replication process for deletes creates a sydatrep distribution record for every active location for every detail record when something like a price list for example is deleted. It would be nice to see a method where perhaps just the header could replicate and that would trigger the POS to clean up the rest of the data on its own, or for deletes to be handled in such a way that they can respect the distribution filters (i.e. if you distribute out inprclst by locationid then only send the deletes to those locationids as well). I'm sure by using a delete staging table to then feed the data rep distribution something like that could be achieved. Example the other day a couple of price lists were deleted, each had about 570 rows in the inprclst table for each pricelistid. This caused 570 X 2 rows to send to about 150 active DR locations which created over 17,000 rows in sydatrep in the middle of the day and backed up our replication of more important data (like dispatch vehicle assignments) by an hour. We also run into this in a lesser extent with dispatch order deletes when all the dsload records go out to all the distribution locations.
This idea has been accepted. We will now begin prioritizing and planning the work required to implement your idea. You will be notified when the planning process is started.
Justin,
We have already created a solution in v6 for the Dispatch Order/Dispatch Loads problem. The problem with Dispatch Loads was that when maintenance is run every purged loads goes to every location. We basically, stopped replicated these 'Maintenance' deletes because Maintenance will purge at the location. The solution was to modify the code within the 'Maintenance' process to behave differently. Note: A delete within the Dispatch Order program will still replicate to every location (while not optimal).
This modification is available in the latest release.
'Price List' has a different architecture, so we may have to rethink a solution for those sets of tables.
Definitely something to think about.
Regards,