DynamicsSubs

  Ever come across a situation where you needed to induce validations, in Warehouse Management mobile apps, before letting the user finally submit data?  For example: you need to check if the supplied value for the target license plate, while shipping a transfer order, must be exactly 12 characters long. Or the supplied date of a warehouse Load must be more than or equal to 5 days from today. Or imagine there is a flag in your warehouse, called Stopped for all transactions and while doing GRN from your mobile app, you need to see if it's a stopped warehouse. For all such situations, there is a trusted class (dedicated exclusively for WHMS) called:  WhsControl and you need to wisely put your code there. Essentially WhsControl is a class that has all the variables stacked up in it: the associated WMSLocationId, InventLocationId or ItemId or even the calling menu item. You can simply do a CoC on " processControlUsingDisplay " method, so as to perform these validations and r...

  As a best practice issue, you might have seen this BP deviation warning: The number of fields in <SO_&_So_Table> is more than 18. Consider breaking down the fields into smaller number of fields . This is a standard BP check, that emphasizes to keep the number of fields in a table as low as possible. Factually, keeping the number of fields more than the breakeven of 18 is just not a BP issue, but could lead to various CRUD operations as well as a lot of unforeseen performance impacts (although in standard, you could see a lot many OOB tables that have violated this fact and have over 30+ fields. Standard has safely marked these tables with Cache lookup as: NOTINTTS -- although that might not be a good solution, always). I prefer the following arrangement: The parent table could be kept with a bare minimum number of fields' set, while all the necessary children tables could be mined with the differential number of fields. And make the children-to-parent table relation by ...

  Ever come across a situation where you needed to  a. Using a multi-threaded batch to import a journal header and lines, from a staging table. The table already contains the Journal Ids which you need to assign to the header and allocate the lines under that header. b. You need to continuously check after each line being imported, if the journal with the Id has been created. If not, it will create the header and create the lines under it;  If yes, it will directly create the lines for the header (Find or create). c. As you could rightly guess, this architecture has an inherent sluggishness associated with it -- each time you keep on checking if the header has been created or not, it does mean a lot of performance effects, as a consequence. Also as you can understand it's a multithreaded code, which means each thread has no direct relation with the other -- which does mean there is no way I can talk between the threads/pass on any information. SysGlobalCaches to...