The manner in which layers were used in the old Ax was pretty clear, we had
SYS, SYP Used by the core system
GLS, GLP Used by the initial added modules which were bought in ( CRM from Hands Norway, Product builder from Aston (now Tectura) HRM from Circle Capital, Shop Floor from Thy Data Center ).
LOS, LOP Used by some countries to add functionality ( US EDI connector, Germany Cost Accounting from Circon )
DIS, DIP Used by most countries for localisation
BUS,BUP Used initially by partners freely then only by invitation in an early version of IBI (Industry Builder Initiative)
VAR,VAP Used by the partners to put their code in
CUS,CUP Reserved for the customer
USR,USP Reserved for the customers
Today in V4, the first 4 are all now in SYS and I am told discussions are ongoing right now as we speak as to where to put what as regards corrections.
I would say do not be greedy:
You have freed up 3 Layers
How about designating one GLS GLP as still for internal use
and freeing UP LOS LOP for IBI use
Leaving DIS DIP empty (replace it later to add another level of user layer )
Give back both BUS and VAR to the dealers freely as it was in 2.5 and V3 initially.
And in a future version give the freed layer to the customers who also need in many cases another layer for their use.
Be a great X-Mas present a clear IBI Layer and an added Dealer layer as well as an added Customer layer
Of course it will not be easy to move things around, as the whole object numbering scheme depends upon this and moving them around is not that easy.
Renumbering the objects has some dreadfull consequences all sorts of places, as those who forgot to export with numbers from their dev system have found out to their cost :-).
But hey the clean up has given the opportunity, and I always though Erik Damgaard when he designed it was being greedy taking 4 of the layers for the systems out of the 8 available ( not counting the patch layers ).
So rebalancing is now a possibility, perhaps.
/Sven
Saturday, 23 December 2006
Friday, 22 December 2006
The concept of Warehouse and extensions
In Dynamics Ax two inventory dimensions which in most other cases are more or less similair stand out a bit or rather stick out like a sore thumb.
One is the warehouse, it has attached to it a lot of functionality, such as quarantine handling or the Warehouse management functionality plus some other basic hookups such as the ability to define a default warehouse by item on Sales / Item / Purchase levels.
However because the warehouse is often confused between a logical warehouse and a physical warehouse and in implementations one often makes use of one or the other and has to stick them both into one field it sometimes becomes difficult to visualise and control ones stock.
What would be nice is to have a sort of sub warehouse level which could be configured everywhere as well as the warehouse, the sub warehouse could be the logical warehouse and should be uniquely linked to its parent which should map to the physical warehouse.
What I am speaking of is sort of like the physical stock locations used in the warehouse module except they should be independent of the locations. The sub warehouse should be availeable all the places where today only the warehouse is present, that is in BOMS in the Quarantine flow, in the SO PO etc etc etc. This allows it to be used as a logical warehouse so that one can have non QC stock and it can still be in the physical warehouse in physical Location but have a statust that disallows it's use.
The reason for adding the sub warehouse or logical warehouse everywhere is to allow the users / dealers to configure legal flows.
One could debate whether it should act as a flag that is we need a new transaction type to control the transfer of it from one status to another (one sub warehouse to another) that does not generate a new inventory transaction or whether a transfer should be required. In an ideal world both should be possible as many businesses would prefer the ability to just change the flage where as audited companies such as medecinal / pharamaceutical companies will want a full track and accounting for any changes made.
I have made such changes but only partially, I have also seen many half botched attempts at making such changes, and I would love to see something like this added as a part of the standard package to allow the product to contain such functionality out of the box.
It would support most industries and allow a much more logical configuration of the system, where the warehouse is really a warehouse and not some beast with many names as is often the case on implementations today.
/Sven
One is the warehouse, it has attached to it a lot of functionality, such as quarantine handling or the Warehouse management functionality plus some other basic hookups such as the ability to define a default warehouse by item on Sales / Item / Purchase levels.
However because the warehouse is often confused between a logical warehouse and a physical warehouse and in implementations one often makes use of one or the other and has to stick them both into one field it sometimes becomes difficult to visualise and control ones stock.
What would be nice is to have a sort of sub warehouse level which could be configured everywhere as well as the warehouse, the sub warehouse could be the logical warehouse and should be uniquely linked to its parent which should map to the physical warehouse.
What I am speaking of is sort of like the physical stock locations used in the warehouse module except they should be independent of the locations. The sub warehouse should be availeable all the places where today only the warehouse is present, that is in BOMS in the Quarantine flow, in the SO PO etc etc etc. This allows it to be used as a logical warehouse so that one can have non QC stock and it can still be in the physical warehouse in physical Location but have a statust that disallows it's use.
The reason for adding the sub warehouse or logical warehouse everywhere is to allow the users / dealers to configure legal flows.
One could debate whether it should act as a flag that is we need a new transaction type to control the transfer of it from one status to another (one sub warehouse to another) that does not generate a new inventory transaction or whether a transfer should be required. In an ideal world both should be possible as many businesses would prefer the ability to just change the flage where as audited companies such as medecinal / pharamaceutical companies will want a full track and accounting for any changes made.
I have made such changes but only partially, I have also seen many half botched attempts at making such changes, and I would love to see something like this added as a part of the standard package to allow the product to contain such functionality out of the box.
It would support most industries and allow a much more logical configuration of the system, where the warehouse is really a warehouse and not some beast with many names as is often the case on implementations today.
/Sven
Friday, 15 December 2006
Back order treatment
Back orders in Dynamics Ax, and their treatment leaves a lot to be desired, basically the most advanced functionality availeable is to allow good to be reserved before arrival in order that the system automatically places a physical reservation against the stock that has arrived when it arrives.
There is nothing intelligent to allow the treatment of a complete shipment of goods that is arriving to see which orders could best be fulfilled from the newly arrived shipment, there is even no function to allow one to automatically plan some shipment actions aside from the above mentioned one.
What would I propose is needed, well basically a linkup with the proposed allocation system that I have discussed earlier where it would be possible to allocate whole sales orders and treat them as units, that is reserve all the items or none. Conversely I see the need to be able to take whole purchase orders or even multiple purchase orders treat them, that is recieve the goods count QC check etc then when a pool has reached a certain size to allow allocation to happen against the pool.
Of course by judicious usage of a dedicated warehouse and Ax transfer functionality one could argue that one could acheive something along these lines. However the inconvenient thing is that one would have to create several new warehouses and the consequences of having stock in several "virtual" warehouses and also leaving traces everywhere is that not only is it harder to visualize where your stock at any one time is but also it is creating a trail of new inventsum records which means all stock and inventory checking reports become slower etc etc.
It would not be complicated to add some more stati in the inventory model and conversely to add some more inventmovement steps that could be configured, actually both on the incoming side as well as the outgoing side this could be of interest.
And these could then be configured by the user to be skipped or they could represent QC steps and or allocating, free for allocation steps.
It would cost very little to maintain if done by MS centrally rather than having to be added by a dealer or a customer.
What do you think.
/Sven
There is nothing intelligent to allow the treatment of a complete shipment of goods that is arriving to see which orders could best be fulfilled from the newly arrived shipment, there is even no function to allow one to automatically plan some shipment actions aside from the above mentioned one.
What would I propose is needed, well basically a linkup with the proposed allocation system that I have discussed earlier where it would be possible to allocate whole sales orders and treat them as units, that is reserve all the items or none. Conversely I see the need to be able to take whole purchase orders or even multiple purchase orders treat them, that is recieve the goods count QC check etc then when a pool has reached a certain size to allow allocation to happen against the pool.
Of course by judicious usage of a dedicated warehouse and Ax transfer functionality one could argue that one could acheive something along these lines. However the inconvenient thing is that one would have to create several new warehouses and the consequences of having stock in several "virtual" warehouses and also leaving traces everywhere is that not only is it harder to visualize where your stock at any one time is but also it is creating a trail of new inventsum records which means all stock and inventory checking reports become slower etc etc.
It would not be complicated to add some more stati in the inventory model and conversely to add some more inventmovement steps that could be configured, actually both on the incoming side as well as the outgoing side this could be of interest.
And these could then be configured by the user to be skipped or they could represent QC steps and or allocating, free for allocation steps.
It would cost very little to maintain if done by MS centrally rather than having to be added by a dealer or a customer.
What do you think.
/Sven
Tuesday, 5 December 2006
Product and other hierarchies
One of the things that most customers wish for when confronted with the reality of the datamodel in Dynamics Ax is some means of attaching meaningfull default values at various levels of a hierarchy to which they attach information.
An example could be the wish to dictate that a certain field f'ex the item group is set to a certain value for all items that belong to the category Oranges, as well as being sold in Belgium.
It is not easy to do in the standard Ax structures, what would be nice is a standard hierarchy builder type of feature as that found in f'ex the Demand planner add on where you are able to conceive your own hierarchy on top of any existing field in the system and for Ax basically to recognize the relationship so that reporting and other features could be built using this variable hierarchy.
Thereafter the next step would be to give the hierarchies an active role in the product, that is to allow the definition of certain fields to be tied to a hierarchy structure.
F'ex to say that the item group is deduced from somewhere in a given hierarchy meaning we can setup a default group at high level and then down the branches define exceptions, allowing the user to work top down and do less work and the system to work bottom up in order to use the first value found.
If we applied this principle to the groups used in the pricing matrix then we could really make some neat price matrices with pricing, discounts, etc at all sorts of levels.
What do you think ?
/Sven
An example could be the wish to dictate that a certain field f'ex the item group is set to a certain value for all items that belong to the category Oranges, as well as being sold in Belgium.
It is not easy to do in the standard Ax structures, what would be nice is a standard hierarchy builder type of feature as that found in f'ex the Demand planner add on where you are able to conceive your own hierarchy on top of any existing field in the system and for Ax basically to recognize the relationship so that reporting and other features could be built using this variable hierarchy.
Thereafter the next step would be to give the hierarchies an active role in the product, that is to allow the definition of certain fields to be tied to a hierarchy structure.
F'ex to say that the item group is deduced from somewhere in a given hierarchy meaning we can setup a default group at high level and then down the branches define exceptions, allowing the user to work top down and do less work and the system to work bottom up in order to use the first value found.
If we applied this principle to the groups used in the pricing matrix then we could really make some neat price matrices with pricing, discounts, etc at all sorts of levels.
What do you think ?
/Sven
Monday, 4 December 2006
Busy
I am currently working myself into a new job and obviously as with all new beginnings there is a period when you are required more than 150% of the time by your current job and I am therefore finding it less easy to work on the blog expect me back in usual frequence next month, right now I am working up a back log of subjects that I want to address.
If you have any subjects that you find are of interest then please feel free to suggest or even if you wish to add a topic contact me and I will add your blog as a feed here if you wish.
/Sven
If you have any subjects that you find are of interest then please feel free to suggest or even if you wish to add a topic contact me and I will add your blog as a feed here if you wish.
/Sven
Saturday, 2 December 2006
Dynamics Ax Base Data model Part I
I often get asked by customers for a basic data model of the Dynamics Ax system and I always have to answer a bit shamefacedly that it does not as of yet exist.
But then I manage to show the Visual Morphx explorer or the Visio tool in version 4 and explain that with 1,500+ tables a chart would not be a chart but a panoramic wall chart requiring the deforestation of Finland to create.
Nevertheless it is instructive when getting introduced to Ax to start by considering some basic elements of the data model.
Before starting one should consider that Ax is a fully integrated ERP system, that is transactions actually cross module boundaries. This implies that the data-model very quickly grows quite complicated, or rather perhaps rather than saying complicated I should say it is quickly heavily populated with tables.
As with most ERP’s one can view Dynamics Ax as being about controlling the flow of goods through the company, the stock control view or approach, or one can view the product as being about controlling the financial information in the company, the nominal/general ledger view or approach.
In my book both are correct, sooner or later most of the modules in Ax will have an effect on the inventory, and or the ledgers.
So let us take a look at the basic data-model surrounding these modules :
I choose to take the more complicated inventory model first J
The main table here is the InventTable which contains the basic information about products in Ax and which notably of course contains the ItemId field which is the identifier by which the product is known.
The list of items controlled in a company when presented to a user also includes 3 instances of a table called InventTableModule all linked through the ItemId to InventTable, and at least one instance of InventItemLocation.
Why are the above elements stored in separate tables ?
In order to allow more flexibility as to configuring in multi company scenarios where the information concerned is held, F’ex the default warehouse for inflow, outflow, and stocking is held in the InventTableModule, this allows us to configure the system in such a manner that 2 or more companies can share the InventTable whilst at the same time having separate configurations of default warehouses, tax codes, unit sizes etc all of which are found in the InventTableModule.
InventItemLocation is another story as it has been split in order to accommodate being able to based on a users configuration needs have different stock flows in the replenishment planning area or net requirement calculation. Of course this also means that we can have a different setup in a multi company situation as well.
Enough about the base table to which everything is tied there are a large number of further tables to explore in this area to do with the configuration of the behaviour of the item but we will get back to that later.
Let us look at the basic transactional model as regards inventory, the information about stock inflows and outflows in Ax are stored in a table called InventTrans, this table contains some key fields, the first basic one is the ItemId field of course which ties the transactions to an item ;-).
Thereafter not in order of importance the InventTransId or what one could call the internal lot number, which identifies the source of this / these transactions as the model permits the existence of multiple InventTrans with a common InventTransId.
Then the StatusInflow, and StatusOutflow fields which are used to identify that the transaction is an inflow or outflow transaction and to state at what stage the transaction is currently, that is if f’ex StatusInflow is 1 (Purchased) it means this item is considered as a fully purchased or costed inflow depending upon it’s provenance, if it is 2 it means it has been delivered but not invoice updated.
The model so far is exactly the same as the one that Concorde XAL had which was created by mostly Benny Olesen who is linked / referenced on the side together with Bjorn Moeller Pedersen, Erik Damgaard, Jesper Theil Hansen and the rest of the core developers at the time.
The next key field is new / a departure from the XAL model, it is the inventdimid field which contains a reference to a combination of inventory dimension fields ( The Warehouse, Lot number of an item as well as it's configurationId ). This Innovation in the data model does make it easier to add new / more dimension fields however it also renders all direct lookups impossible and with heavy data traffic in the inventory transactions renders the system hard to use.
I will carry on from here later as I have been busy these last few days.
/Sven
But then I manage to show the Visual Morphx explorer or the Visio tool in version 4 and explain that with 1,500+ tables a chart would not be a chart but a panoramic wall chart requiring the deforestation of Finland to create.
Nevertheless it is instructive when getting introduced to Ax to start by considering some basic elements of the data model.
Before starting one should consider that Ax is a fully integrated ERP system, that is transactions actually cross module boundaries. This implies that the data-model very quickly grows quite complicated, or rather perhaps rather than saying complicated I should say it is quickly heavily populated with tables.
As with most ERP’s one can view Dynamics Ax as being about controlling the flow of goods through the company, the stock control view or approach, or one can view the product as being about controlling the financial information in the company, the nominal/general ledger view or approach.
In my book both are correct, sooner or later most of the modules in Ax will have an effect on the inventory, and or the ledgers.
So let us take a look at the basic data-model surrounding these modules :
I choose to take the more complicated inventory model first J
The main table here is the InventTable which contains the basic information about products in Ax and which notably of course contains the ItemId field which is the identifier by which the product is known.
The list of items controlled in a company when presented to a user also includes 3 instances of a table called InventTableModule all linked through the ItemId to InventTable, and at least one instance of InventItemLocation.
Why are the above elements stored in separate tables ?
In order to allow more flexibility as to configuring in multi company scenarios where the information concerned is held, F’ex the default warehouse for inflow, outflow, and stocking is held in the InventTableModule, this allows us to configure the system in such a manner that 2 or more companies can share the InventTable whilst at the same time having separate configurations of default warehouses, tax codes, unit sizes etc all of which are found in the InventTableModule.
InventItemLocation is another story as it has been split in order to accommodate being able to based on a users configuration needs have different stock flows in the replenishment planning area or net requirement calculation. Of course this also means that we can have a different setup in a multi company situation as well.
Enough about the base table to which everything is tied there are a large number of further tables to explore in this area to do with the configuration of the behaviour of the item but we will get back to that later.
Let us look at the basic transactional model as regards inventory, the information about stock inflows and outflows in Ax are stored in a table called InventTrans, this table contains some key fields, the first basic one is the ItemId field of course which ties the transactions to an item ;-).
Thereafter not in order of importance the InventTransId or what one could call the internal lot number, which identifies the source of this / these transactions as the model permits the existence of multiple InventTrans with a common InventTransId.
Then the StatusInflow, and StatusOutflow fields which are used to identify that the transaction is an inflow or outflow transaction and to state at what stage the transaction is currently, that is if f’ex StatusInflow is 1 (Purchased) it means this item is considered as a fully purchased or costed inflow depending upon it’s provenance, if it is 2 it means it has been delivered but not invoice updated.
The model so far is exactly the same as the one that Concorde XAL had which was created by mostly Benny Olesen who is linked / referenced on the side together with Bjorn Moeller Pedersen, Erik Damgaard, Jesper Theil Hansen and the rest of the core developers at the time.
The next key field is new / a departure from the XAL model, it is the inventdimid field which contains a reference to a combination of inventory dimension fields ( The Warehouse, Lot number of an item as well as it's configurationId ). This Innovation in the data model does make it easier to add new / more dimension fields however it also renders all direct lookups impossible and with heavy data traffic in the inventory transactions renders the system hard to use.
I will carry on from here later as I have been busy these last few days.
/Sven
Subscribe to:
Posts (Atom)