When standard functionality does meet the client requirment as role of functional consultant , you need to prepare the FDD , in that FDD you need to mention what are all the standard tables need to modify ,what should be field types and when the value should update in the modified tables
For example : Client required some fields in the sales order form ,same fields open order details should flow to as received by posting packing slip after posting the packing slip i need get Print of the packing slip , invoice also the same fields need to flow .
what my question as functional consultant what is the best way to know where the intial data will store , when post what are all the tables will effect and what would be concern reports . As FC when update in the FDD , the same will follow by technical consultant.
Here i am requesting your help how to know about the structure and any suggestions, tips for FC .
As per your example let’s take the technical design document , As a functional consultant if we dont know what tables need to modfiy and which tables need to give relation , then how can we explain to a technical consultant that the list of tables need to modified , where and when need to modified.
As a FC , if we dont know , then how can we prepare the design document .
For example : in NAV when user posted a document , click on the NAVIGATE button , system will show the effected tables . the same way in AX how to find out in easy way.
As an FC you define the functional specification, you define in this document, with screen shots, the process flow and changes. The developer then takes this and develops a technical design - they define the tables and classes as per the functional requirement. If an FC starts defining tables they are telling the developer how to develop, which should not be the case because the standard FC does not know the underlying and related tables, processes and classes. It is the job of the develop to define the technical solution to meet the needs of the functional requirement. When you get FC’s defining programmatical appraoches to solutions you will run into issues because the developer will not necessarily approach it in this manner due to development best practices and requirements.
Where I will draw a caveat is that this is an opinion, some partners do not produce technical documents, some partners have programmers and not developers which leads to a different approach. In essence it depends upon your approach, I am answering how Microsoft view SureStep, but one thing is irrelevant of all of this, if you have a functional consultant that is not technically aware they cannot define a technical document for a programmer.
You can right mouse click on a field in AX an look at the setup, the table referenced is stated on this form, but this is field by field, because one form is not from one table, and some fields displayed are not on the table, they are populated and the opening of the form. AX does not have the same table lookup, it is a completely different database structure and development environment.
let me explain you one scenerio . As you written above to prepare the functional specification and screen shots on what basis FC will prepare. Let us say customer asked one field as per their business requirement and mentioned that when he take the reports , that field value should display in that reports.
As you said prepare the screen shots , Screen shots means the screen should contain the new fields and how it has to flow . As FC if we dont know tables and forms , then how will you prepare the screen shots. ?
The report is not relevant, the SSRS cube would need to contain it and is a separate argument. Even if specifically requested you would put it on the source table, but if they want it to be transactional based the functional specification would need to state that the field is added to the posting routines to write to the ledger entries, perhaps even the invoice journal, but it maybe stated that it posts through to the invoice stage.
As for the screen shot you take a screen shot of the existing screen, then add the field to the screen and highlight it. How you add this is up to you - some people open the screen in paint/photoshop/whatever and add the field in the position where it is required. Knowing the table is irrelevant to adding it to form.
There is no document or manual about the AX main tables and flow - there are some table schemas, but the last I saw published was version 4 and it was incomplete - it is on this site. Due to the configuration of AX tables may or may not get hit. The structure and understanding of it can be obtained by experience, knowledge and willing, but on the whole the technical consultants define this, and primarily because even if you understand the table structure and flow this may NOT be the way the solution is developed. In my opinion for AX if the average functional consultant stated in a specification the tables and classes to modify a developer would reject it.
The solution does work for you, Yet it is how Microsoft propose it is undertaken - the functional consultant defines the functional nature of the modifcation, the developer the technical - these are two separate documents in Surestep. It may not work for you, but it works for many many partners. You can put your own interpretation on this but you need to up skill your consultants by givign them technical exposure, something very difficult to do.
No, I am a functional consultant and anything I tell you could be misleading.
This is the data model for version 4 http://dynamicsuser.net/media/p/141708.aspx which will give you an idea and many of the fundamental structures remain, but there have also been significant re-designed in AX2009 and AX2012.