Putting functionality into data

Shenpen

It is possible to put functionality into data, instead of developing them.

Examples:

1) A company has 5 hierarchical levels of product groups. Instead of adding fields to Item Card, you could put into Item No. Any Item-related report and transaction has Item No. so users can filter for it. Of course, be very cautious to map new Item Nos. to old ones during inventory import. Maybe you want to use No 2 to store the old ones.

2) Implementing business hierarchy in reports. Simply creating dimensions like 2, 27, 271 and filtering like 2*, 27* etc. Same for Security Filters.

3) Locations and physical locations. If you have multiple locations in a physical warehouse, how do you check inventory for the physical location? By coding locations like 11,12, 21,22 where the first number is the physical location. Or maybe a more readable way is A_MATERIAL, A_PRODUCT, B_MATERIAL, B_PRODUCT.

4) Having some kind of zones without implementing Directed Pick and Put-Away. Simply name Bins like A_1223, A_1332 for zone A.

DenSter

That might work, but you're relying on meanings to values of fields instead of fields with purposes. So you'd have to hardcode your filters, or create custom functionality to dynamically set up those values.

Hard coding filters is a bad idea all around, so you'd come to custom functionality, in which case you might as well create proper hierarchy fields after all.

You'd also rely on people interpreting values the same way, and that's harder to do the more people use your system.

It would certainly save money, but it would also add risk to the consistency of your data. The choice is yours I guess. Good luck

Shenpen

It is very amusing, how people are afraid of hardcoding Yes, hardcoding is definitely wrong in a compiled program, but in an interpreted program as easy to modify as Navision the only important thing is to document it. If there is clear paper saying f.e. you shall always have 3-letter hierarchical Cost Places dimensions and this data is hardcoded into this and this object, and this and this could go wrong if you do it otherwise, I think it"s okay. Flexibility is less important IMHO than simplicity, minimum footprint, ease of use etc. Customers are more than willing to comply with clearly written "you MUST do it this way" rules as long as these rules are practical and fit to their way of thinking. Alll e-mail address is hardcoded to name@domain.xx format and no oen complains, because it is well documented.

It is also a custom in the world of the Big Software: f.e. all Purchase Orders numbers in SAP start with 4. Why not? As long everbody knows it, no problem.

DenSter

All I'm saying is you need to modify the system anyway, why not spend a little extra time and come up with something that works without hard coding.

Nobody's afraid of hardcoding anything, you will just be maintaining the hardcoded bits ad nauseum when a user decides to do it differently.

HalMdy

Also remember that not all customers have payed for a dev Licence. They prefer change some parameters in place of asking an NSC everytime they want to change something in the "hardcoding" part...

Shenpen

This is true, but I never saw users who would be able to change parameters on their own f.e. creating a New Location without forgetting the Inventory Posting Setup, so it is almost the same...

DenSter

Alright.... So you would hard code a value 'PG1' in OnAfterInsert, or enter that value as the initvalue or something. Perfectly legitimate solution that will work like a charm... as long as the value 'PG1' is a valid posting group.

I would think for instance about adding a default posting group to a setup table that the user can change, and have OnAfterInsert get that value dynamically.

Both methods are about the same amount of development, but the customer would have a lot more value out of a generic solution that will never need any maintenance.

Shenpen

For these kind of developments, surely - as long as are talking about tables, not forms. For forms, I think even such kind of stuff is OK, because not the development times is important, but service pack installation (merging) time. Development time is usually paid - service pack installation time is usually not, especially when it is law update. And as for forms we can say "save as" and then we don't have a service pack problem. But for tables, cannot. So I would go to any length to avoid modifying tables.

But actually I am talking about different kinds of developments. The topic is called "putting functionality into data". It means that for example you could create a cost place dimension like 2 for Sales, 27 for Spare Part Sales and 279 for J. Random Salesman, add a field "Cost Place filter" to table User Setup 2* for Sales Manager, 27* for Spare Parts Sales Manager and 279 for J. Random Salesman then simply add a filter to a custom - developed report to use this filter on records.

This is the real meaning of putting functionality into data - lesser footprint that adding "Divison Code", "Subdivision Code" and "Employee Code" to all Ledger tables.

DenSter

I hear you, and I agree that is a very smart way of using dimensions, and you can apply that idea to many areas.

There's only one catch to this, and that is it only works as long as the values mean the same thing.

I don't agree with you at all about your remark on development. Putting data functionality in forms is asking for problems, you should always put as much of it in tables, so it works the same on all forms by developing it in one place. As long as you mark the code correctly, you should be fine in any upgrade.

Custom development usually takes a LOT more time than service pack merging. I can get any service pack in any database in a matter of a few days, because our custom code is usually very clearly marked.

By the way, service pack merging is a paid engagement where I come from, I guess that's a matter of the contract you have with the customer.