Create a SO with a Web Service

chrisdfchrisdf Member Posts: 82
edited 2009-07-03 in NAV Three Tier
Hi,

There is a useful blog on this subject by Freddy:

http://blogs.msdn.com/freddyk/archive/2 ... d-rtm.aspx

However, the assumption is the creation of the Sales Order using the NAV number series for the sales order.

If we try and create a sales order using the Page method and specify the sales order number (No.) we continually get an error message that you cannot re-name a sales order.

I can get around this by writing a codeunit web service to create the SO but can anyone confirm if it is possible to create a SO with a Page web service and specify the order number?

Thanks.

Comments

  • thetallblokethetallbloke Member Posts: 66
    G'day Chris,

    Why do you want to change the SO number...??
    Isn't that the point of using the number series...???
    If you go and manually change the SO number, you could potentially have the system return a duplicate number when using the "normal" method by pressing F3 on a card or by using the RTC pages.
    .
    I'm not crazy !!! Just ask my toaster...
    .
  • chrisdfchrisdf Member Posts: 82
    Because the web application is taking orders and assigning a unique order number.
  • thetallblokethetallbloke Member Posts: 66
    I'm currently building a Sales Order entry application that uses both Nav webservices and Microsoft Mobile Document Services... later there will be a website for customers, probably much the same as what you're doing...

    In Nav I have a "CreateDocument" webservice that takes a docment type (0-quote, 1-order, 5-return order) and creates the document with the correct type and returns the new document number from the number series (eg SO12332)
    In Nav I then have an "UpdateDocument" webservice that takes doc type, doc number, and a whole heap of other parameters and updates the Sales Header records created by the CreateDocument WS... This gets around your renaming issue.

    Anyway, getting back to your question...
    If you have a number series defined, you can't manually assign your own number to it.. I believe you have to untick the "Default Nos." column first.
    You either use manual numbers or a number series...

    Having said that, I've just been told that you can have number series relationships setup so you could use two different number series for Sales Orders... you could have one that spits out: SO1001..SO1002..SO1003..etc
    and a second one that spits out a different number format : WEB1001..WEB1002..WEB1003..etc

    Someone correct me if I'm wrong with that..

    A simpler way would be just to add a flag to your Sales Header table that you set to define if a record is from the web or from within Nav directly. Make it read-only on the form in Nav. Thats what we're doing with our system... due to the application being dsconnected at times on our mobile devices, ours will also have an "InUse" flag, and if that is set, the Nav Classic form or RTC page will be read-only until that flag is cleared by the mobile device that is using it.

    I hope this helps..
    .
    I'm not crazy !!! Just ask my toaster...
    .
  • chrisdfchrisdf Member Posts: 82
    Hi,

    I really appreciate the time you have taken to reply - thanks for that.

    Like you I have had to write a function in a codeunit web service to create the SO header .... the parameters are Order Number and Sell-To Customer number. The web application then manages the rest of the header using the exposed page web service. So I do have a workaround.

    I just wanted to know if anyone has managed to write the SO with a specified "No." field. It seems odd to me that it doesn't seem possible - maybe it is fixed in SP1??

    Thanks anyway.
  • freddy.dkfreddy.dk Member, Microsoft Employee Posts: 360
    Just tried to set the Manual Nos. in the number series and do this:

    // Create the Order header
    var newOrder = new SalesOrder();
    newOrder.No = "SO10000";
    service.Create(ref newOrder);

    which works fine (this would be the right place to assign the number).

    Maybe I didn't understand the problem though.
    Freddy Kristiansen
    Group Program Manager, Client
    Microsoft Dynamics NAV
    http://blogs.msdn.com/freddyk

    The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
  • TroyMcCLureTroyMcCLure Member Posts: 1
    Hi,
    That does work, however when trying to assign further values to the sales order header and update, I get a 'The date is not valid' error. I'm only explicitly setting the Order_Date and Document_Date, and I can see valid dates being assigned to them when breakpointing. The error message is quite vague as it doesn't even reveal which date it's having the issue with.

    However our workaround, though inelegant, does work: first I call a codeunit that creates the order and returns a ref to the created order. Then I can set the values on the ref and update it. This does NOT cause the 'date' error from above, so my assumption is that when creating a Sales Order using web services, some essential trigger code is not being executed.


    Here's an excerpt of non-working code:

    SalesOrders so = new SalesOrders(); //sales order header obj
    so.No = navOrderNumber;
    orderHeaderService.Create(ref so);
    ...
    so.Order_Date =DateTime.Now;
    so.Document_Date = so.Order_Date;
    orderHeaderService.Update(ref so); //date error here


    Here's what we are doing that works:

    SalesOrders so = new SalesOrders();
    customIntegrationService.CreateSalesOrder(navOrderNumber, customerNumber);
    so = FindSalesOrder(navOrderNumber);
    ...
    so.Order_Date =DateTime.Now;
    so.Document_Date = so.Order_Date;
    orderHeaderService.Update(ref so);
  • chrisdfchrisdf Member Posts: 82
    Thanks Troy,

    We had the exact same problem with "Date Error" and we came to the same conclusion with the same workaround.
  • freddy.dkfreddy.dk Member, Microsoft Employee Posts: 360
    I am pretty sure this problem has to do with some of the date fields not being assigned a value (but the <field>specified for that field is true). If this is the case, this problem will be solved in SP1.
    Freddy Kristiansen
    Group Program Manager, Client
    Microsoft Dynamics NAV
    http://blogs.msdn.com/freddyk

    The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
Sign In or Register to comment.