Navision standard W1 code

NavStudent

Navision code is written so that a user actually performing on the screen the task.
For example If you are creating a customer, and your Post code table is populated, you get list of cities if the zip code is in two cities.

If you are creating customers through code, how would you be able to create customers without getting run modal? My solution has been to not validate the field, but shouldn’t Navision code provide or be smarter and not open the dialog?

What about web service in next version, which comes by default with new version, if an external developer, consumes a web service, how much do I have to explain, or change code in navision for the web service to actually work?
On sales order credit limit window pops up, I know I can call sethidevalidation, but again I have to tell the outside developer?

By providing web service, the development is moved out Navision and third party will do all the work.

What if you want post orders through web service? What will happen to dialog boxes?

As Navision databases get bigger and bigger, a lot of processes need to be batched posted at night, and having this feature as default would lower the modification numbers.
They have created job queue, and it would be nice to schedule some process out of the box.

DenSter

Check out the GUIALLOWED property. I've used it to handle that sort of thing for NAS a number of times.

NavStudent

DenSter wrote:

Check out the GUIALLOWED property. I've used it to handle that sort of thing for NAS a number of times.

I know of GUIALLOWED function.
The question I have is, why isn't part of standard Navision?

DenSter

It IS part of standard NAV, you can use it whenever you want. Most of the code is written with the regular client usage in mind, which is a design decision that you obviously don't agree with.

It is the way it is, I don't really spend too much time questioning it, and when I need to make it NAS-friendly, it usually doesn't take a lot of time to do it.

NavStudent

If NAV is moving to provide web services by default, shouldn't they take into consideration to make the product work by default?
I see so many areas that are left uncompleted, and No I don't want to hear another joke about business opportunity.
Just recently in 5.0 sp1 that they added option to default to zero for qty to ship, invoice. Or add line comment. They are moving slower than the pace of snail.
They are marketing RIM this RIM that. Maybe MS should RIM themselves up.

It's that polished touch that is missing.

They should be eating their own dog food.

kine

Now in code I see this line (Table 36):

  IF HideValidationDialog OR NOT GUIALLOWED THEN

It means that it is disabling the validation dialog by default if running under NAS (or as a WebService etc.).

And for checking the credit limit there is condition

IF GUIALLOWED AND (CurrFieldNo <> 0) AND ("Document Type" <= "Document Type"::Invoice) THEN BEGIN

It means that it is not working under NAS, and if the validation is called from code, not by user (which means e.g. from your code for creating the order header etc.). I like the CurrFeldNo right because this possibility to distinguish cases when the validation is triggered by user or by code...

By providing web service, the development is moved out Navision and third party will do all the work.

This is not true. That there will be WebServices doesn't mean that they will develop in NAV will do all outside NAV. It means that you will prepare some easy interface for them and they will just use them. Everything in NAV will be still work of NAV developer...

DenSter

NavStudent wrote:

If NAV is moving to provide web services by default, shouldn't they take into consideration to make the product work by default?

NAV will not be working with sebservices by default, there will be functionality so that you can choose to publish NAV functionality as webservices, in which case you will need to make sure that it works. Seriously, you can't expect them to be responsible for your customizations.

If only everything came in such a state that you'd only look at it and it did what you were thinking, but the real world just doesn't work that way. Every software product has flaws, deal with it.

NavStudent

DenSter wrote:

NavStudent wrote:

If NAV is moving to provide web services by default, shouldn't they take into consideration to make the product work by default?

NAV will not be working with sebservices by default, there will be functionality so that you can choose to publish NAV functionality as webservices, in which case you will need to make sure that it works. Seriously, you can't expect them to be responsible for your customizations.

If only everything came in such a state that you'd only look at it and it did what you were thinking, but the real world just doesn't work that way. Every software product has flaws, deal with it.

They can change this in standard product faster then the length of this thread. There is no reason for everybody else to deal with it.

NavStudent

kine wrote:

Now in code I see this line (Table 36):
This is not true. That there will be WebServices doesn't mean that they will develop in NAV will do all outside NAV. It means that you will prepare some easy interface for them and they will just use them. Everything in NAV will be still work of NAV developer...

Lets say you are doing an integration. to create orders in Navision with a web system. All you would do in NAV is enable the sales Order webservice and all code would be done by the web developers to consume the webservice. Where is the NAV work?

kine

Not exactly. In your case it will mean that you will publish the Page for the order with all functionality to browse and modify the orders, but this is not what you want, isn't it? You just need to create Webservice which will receive base data fro creating the order and do it yourselfs, because you cannot give full access to all orders in your system to the external developer... ;-)

NavStudent

kine wrote:

Not exactly. In your case it will mean that you will publish the Page for the order with all functionality to browse and modify the orders, but this is not what you want, isn't it? You just need to create Webservice which will receive base data fro creating the order and do it yourselfs, because you cannot give full access to all orders in your system to the external developer... ;-)

You can control this through security if you wanted too.
The customer can add filters, change the page property or display one order.
This is realy isn't an issue, a nav developer or navision developer, from customer point of view both are developers, if there is a trust issue, then why would the customer trust a Nav developer.

As long as customer test it and it works and secured properly, nav dev doesn't really need to be involved, even if invovled, we are talking hours not days.

kine

This is not a question of trust,this is question of security. WebService is mainly used to publish some data to e-shop or another external application. And this aplication (e-shop) can be attacked. And if you do just minimal interface, you will have minimal breach. If you publish whole tables and functionality, you have big potential hole into system. Yes, it is easy, just tick the check box... but you need to think about all the consequences which can happen than... [-X

And because responsibility for the NAV DB is on me (as a partner) and the interface is used by another company which has own responsibility just for their product, I need to minimize possible problems caused by bugs and bad work of this external company. Once again, minimal needed interface is best interface for me from security point of view...

But it is on you how you will use the WebService and how you are doing your job... 8)

NavStudent

For companies that deal with outside, it makes sense, for majority of work though, the company has it's own dev or web people who they trust and will can do it all outside of NAV.

DenSter

NavStudent wrote:

They can change this in standard product faster then the length of this thread. There is no reason for everybody else to deal with it.

There is absolutely no way that you can tell how much work it is to change something like that, and in my opinion you're being a little unreasonable. It would certainly make certain things easier, and it might be that it is on their list, but way down with a low priority.

Dakkon

DenSter wrote:

NavStudent wrote:

They can change this in standard product faster then the length of this thread. There is no reason for everybody else to deal with it.

There is absolutely no way that you can tell how much work it is to change something like that, and in my opinion you're being a little unreasonable. It would certainly make certain things easier, and it might be that it is on their list, but way down with a low priority.

I don't know I don't think it's that unreasonable for Navision to make some key common processes Nas/WebService friendly. I'm sure it's not a priority for them and that doesn't surprise, but come on ... let's be honest here, the developers have been getting a big fat shaft for a long time. Almost all product changes seem to be user minded and not developer oriented. Also, before anyone starts talking about good business sense and how users are the business, I think better support for developers leads to better third party support and adoption of the product, which translates to bigger user base and profit.

David_Singleton

Dakkon wrote:

DenSter wrote:

NavStudent wrote:

They can change this in standard product faster then the length of this thread. There is no reason for everybody else to deal with it.

There is absolutely no way that you can tell how much work it is to change something like that, and in my opinion you're being a little unreasonable. It would certainly make certain things easier, and it might be that it is on their list, but way down with a low priority.

I don't know I don't think it's that unreasonable for Navision to make some key common processes Nas/WebService friendly. I'm sure it's not a priority for them and that doesn't surprise, but come on ... let's be honest here, the developers have been getting a big fat shaft for a long time. Almost all product changes seem to be user minded and not developer oriented. Also, before anyone starts talking about good business sense and how users are the business, I think better support for developers leads to better third party support and adoption of the product, which translates to bigger user base and profit.

To paraphrase an old saying about marriage,

"Programming makes up 10% of a good NAV implementation, and 90% of a bad one."

think about it.

djswim

I can think of a thousand things to replace "Programming" and "NAV implementation" with in that sentence (many inappropriate).... but out of curiosity (if it's not inappropriate) what's the original?

David_Singleton

djswim wrote:

I can think of a thousand things to replace "Programming" and "NAV implementation" with in that sentence (many inappropriate).... but out of curiosity (if it's not inappropriate) what's the original?

Its exactly what you think it is , a three leter word begining with "S"