This is the 3rd part in a series of posts around exploring the Smart Office SDK to remove an existing modification and how I approach the implementation.
The 1st post (https://potatoit.wordpress.com/2013/02/24/smart-office-sdk-first-project-part-1-testing-the-installation/) discusses testing that we have the SDK installed and validating that we can manipulate Smart Office through the SDK by using the sample code from Infor – launching our own ‘features’, adding controls and subscribing to events.
The 2nd post (https://potatoit.wordpress.com/2013/02/24/smart-office-sdk-first-project-part-2-in-the-beginning-there-was-nothing/) discusses how I validated the core functionality which will drive our feature when creating a project from scratch. The emphasis is on writing code to take small steps and validating each of those steps.
I have some constraints around this project which I haven’t articulated [well] in the previous posts.
- 0 Impact of the user-base – we don’t have the resources to redesign and validate significant changes. If we had the resources, then they would be assigned to other more significant projects.
- We have a few hundred Crystal reports, a portion of these reports touch the Vessel Modification data. We cannot locate these reports and change them without significant risk and time investment.
- Export Documentation – this modification has a major impact when it comes to extracting data for our export documentation system. >85% of our turn-over is derived from exports. We don’t have the resource to invest in major process redesign and validation.
- The current process works, it is hard to justify retraining
- I need to prove that using the SDK and removing our modification has real value to the business
Now that we are comfortable that the SDK is the correct tool for us we will set about exploring the details of our modification. This is rediscovering the modification and its UI interactions with M3 – we need to be able to reproduce these actions in a seamless fashion to the user. We will aim to improve user experience if it represents a high return at low time investment.
Once we have discovered the interactions that we need we will test the interactions. Again, this will be in a scratch program, temporary code. You may question this methodology, but it provides a method for me to focus on specific functionality that I have yet to prove. Having it in its own discrete project will reinforce what I have done in my memory so if I see a similar situation I know that I can solve it in a certain way. Small problems are far easier to deal with than large problems – ever had those times when you have a few lines of code, you know there is a problem with one of them but you can’t quite put your finger on it – you go for a ride, a run or whatever and zone out and you have an epiphany – code clearly visualised in your mind and you just click. Too complex a problem, not breaking it down and I’ve personally found that having those epiphanies just don’t happen, you end up in that dark place with ‘programmers block’.
It also provides some scratch code that I can tinker with for similar situations which don’t work as expected. I like to think of this as making a time investment upfront which will pay for itself many times over.
But I guess I am getting a little side-tracked here – the point being that there are many things that you can do which will aid you in solving problems – don’t complicate things.
Anyways, the balance of this post will be identifying the interactions. The next post will go in to proving that we can address each of these interactions – WebService, API or something else altogether.
So, our Vessel Modification
Our CO no comes from the customer order header – OOHEAD, then we have the customers number and the customers name.
Next we have the Vessel and Voyage fields, they are lookup fields and they go to another modification called ZOI001. PC Vessel and PC Voyage also go to the same modification but have the Pre-Carriage flag set to 1.
Shipping Agent, Shipping Company, PC Shipping Company are look up fields that go to the standard M3 Suppliers (CRS620)
Load Port, Discharge, PC Discar Port and PC Load Port are lookups that go to the standard M3 Places (MMS008)
All the other fields get written to a single table.
ZOI001 – Vessel/Voyage and PC Vessel/Voyage program
Shipping Agent, Shipping Company, PC Shipping Company
Load Port, Discharge, PC Discharge Port, PC Load Port
So, it looks pretty simple, the only gotchya so far is that when we are changing the Vessel/Voyage we should be updating the delivery departure date (currently the mod doesn’t do this consistently).
The next posts will look at proving we can provide similar functionality for the lookups of one of the standard programs, retrieving the CO header information and update the delivery departure date. By that point we should be confident that we have all the pieces of the puzzle and can actually do some real work.
Potato IT 