Purch. Req. Worksheet no longer creating 1 PO for same vend

bspencer

Hello.

Something has changed in our system that I have been unable to identify. No modifications have been made since this problem started. The purchase requisition worksheet is no longer creating a single PO from a drop ship sales order for multiple items from the same vendor. Steps:

1) Sales Order created with multiple items marked as drop ship.
2) Get Drop Ship Sales Order function run through the Purch. Req. Worksheet.
3) We verified that the vendor in the worksheet was the same for all lines.
4) Carry out action messages creates multiple purchase orders instead of one.

It would have created a single purchase order in this situation a few days ago, now it does not. I have noticed that if I have the location as our MAIN location (directed pick and putaway), the purch req. worksheet will create a single purchase order. If it is any other location (non directed pick and putaway), it creates multiple purchase orders (which it did not use to do). It shouldn't matter what the location is since drop ship is true.

Any ideas? I do not know of any setting that might be creating this problem and our provider is scratching their head.

thanks ](*,)

Savatage

No modifications have been made since this problem started.

How about Just before the problem started

Well if you know that location fixes your problem then set the location to the same value.!?

I do see in CU333 - it looking at the location code for "Special Orders" are you sure it's setup as drop ship or special orders

InsertHeader(VAR ReqLine2 : Record "Requisition Line")
WITH ReqLine2 DO BEGIN
  OrderCounter := OrderCounter + 1;
  Window.UPDATE(3,OrderCounter);

  PurchSetup.GET;
  PurchSetup.TESTFIELD("Order Nos.");
  PurchOrderHeader.INIT;
  PurchOrderHeader."Document Type" := PurchOrderHeader."Document Type"::Order;
  PurchOrderHeader."No." := '';
  PurchOrderHeader."Posting Date" := PostingDateReq;
  PurchOrderHeader.INSERT(TRUE);
  PurchOrderHeader."Your Reference" := ReferenceReq;
  PurchOrderHeader."Order Date" := OrderDateReq;
  PurchOrderHeader."Expected Receipt Date" := ReceiveDateReq;
  PurchOrderHeader.VALIDATE("Buy-from Vendor No.","Vendor No.");
  IF "Order Address Code" <> '' THEN
    PurchOrderHeader.VALIDATE("Order Address Code","Order Address Code");

  IF "Sell-to Customer No." <> '' THEN
    PurchOrderHeader.VALIDATE("Sell-to Customer No.","Sell-to Customer No.");

  PurchOrderHeader.VALIDATE("Currency Code","Currency Code");
  IF "Ship-to Code" <> '' THEN
    PurchOrderHeader.VALIDATE("Ship-to Code","Ship-to Code");

  PurchOrderHeader.VALIDATE("Location Code",ReqLine2."Location Code");
  IF PurchasingCode.GET("Purchasing Code") THEN
    IF PurchasingCode."Special Order" THEN
      IF Location.GET(ReqLine2."Location Code") THEN BEGIN;
        PurchOrderHeader."Ship-to Code" := '';
        PurchOrderHeader."Ship-to Name" := Location.Name;
        PurchOrderHeader."Ship-to Name 2" := Location."Name 2";
        PurchOrderHeader."Ship-to Address" := Location.Address;
        PurchOrderHeader."Ship-to Address 2" := Location."Address 2";
        PurchOrderHeader."Ship-to City" := Location.City;
        PurchOrderHeader."Ship-to ZIP Code" := Location."ZIP Code";
        PurchOrderHeader."Ship-to State" := Location.State;
        PurchOrderHeader."Ship-to Country Code" := Location."Country Code";
        PurchOrderHeader."Ship-to Contact" := Location.Contact;
        PurchOrderHeader."Location Code" := Location.Code;
      END ELSE BEGIN
        CompanyInfo.GET;
        PurchOrderHeader."Sell-to Customer No." := '';
        PurchOrderHeader."Ship-to Code" := '';
        PurchOrderHeader."Ship-to Name" := CompanyInfo.Name;
        PurchOrderHeader."Ship-to Name 2" := CompanyInfo."Name 2";
        PurchOrderHeader."Ship-to Address" := CompanyInfo.Address;
        PurchOrderHeader."Ship-to Address 2" := CompanyInfo."Address 2";
        PurchOrderHeader."Ship-to City" := CompanyInfo.City;
        PurchOrderHeader."Ship-to ZIP Code" := CompanyInfo."ZIP Code";
        PurchOrderHeader."Ship-to State" := CompanyInfo.State;
        PurchOrderHeader."Ship-to Country Code" := CompanyInfo."Country Code";
        PurchOrderHeader."Ship-to Contact" := '';
        PurchOrderHeader."Location Code" := '';
      END;

bspencer

Thanks for responding.

Indeed, the sales orders in all examples are boolean flagged for drop ship. Vendor code and location are the same for all lines. Everything pulls into the purch. req. worksheet perfectly. It is just creating a PO for every line in the worksheet.

If we select our directed pick and putaway location code for all lines (which in our case is MAIN), it does create a single PO. However, as I said, it was not until just recently that MAIN has become the only location that allows the purch. req. worksheet to create a single PO. It is almost like a setting was changed some where.

We may have to pull a back up and compare code. We were just hoping for a faster solution.

Savatage

was their any changes to primary key's - like adding a new field to it?

the point is trying to narrow it down - we all know things don't "just happen"

either
1) that's how it always worked and you never noticed
2) you are doing the req worksheet differently than before (missing/adding a step)
3) someone changed something somewhere.

Once you figure out which one it was you'll be able to attack the situation better.

has a new location been added? was MAIN the only location & now there are more?
for how long has it worked the "correct" way for you - weeks, months years?
anything been updated? Service pack, hotfix, upgrade?

bspencer

It is definitely #3. It has worked this way for 2+ years and we have over 100 locations. I am being told there has been no updates to Navision at all since we noticed this problem. However, as you say, something changed some where.

Savatage

are these newer items added to the system? I mean older items that have always worked correctly are they doing the same thing, creating multiple po's - if not perhaps the itemis setup incorrectly??

bspencer

Same old items, nothing new about them. We restored a version of our system (including objects) from 30 days ago and it worked okay back then (1 PO regardless of location code). We are going to have to do an object compare to see where the problem is.

bspencer

There is no difference in the objects. It is a setting issue. If anybody has any ideas, let me know.

Savatage

are you using Purchase Codes on the sales lines??

themave

there is a setup field in purchases and payables,

combine special orders

options are

always combine
never combine

bspencer

Thanks for your information. "Always Combine" is already flagged in the purchase and payables setup.
We do not use Purchase Codes.

I have noticed something else. Certain off-site non-pick and putaway locations are creating single purchase orders, while others are not. Evidently until now, I have been chosing off-site locations that do not by happenstance. In comparing the locations in the location table that create single or multiple purchase orders in the purch req worksheet, I see no significant difference. Perhaps this might provide a clue.

Savatage

run table 14 from object designer. tab over the fields and visually compare the different locations to see which fields are filled * which are not. Test the combining orders for two different ones and see which one warks & whick one doesn't. A few tests should put this to bed, if the location table setup is to culprit.
Perhaps one has require receive or something.

For us other than the code, name & Addess - nothing else is filled in.

bspencer

Harry, thanks for taking the time to respond to these threads.

Regarding Table 14, I made that comparison this morning. There is no signficant difference between the two locations.

It is location related some how. If I have a sales order with 4 lines, two to location PL00001 and two to location PL00004, all things being equal (including the items), the purch req worksheet creates 2 purchase orders for location PL00001 and one purhcase order for location PL00004. Forgive the lame location codes. They have proprietary significance.

bspencer

As a courtesy to everyone, this problem we are experiencing is related to a mod we put in several months back. The conditions required to create the problem were not met until recently.

Thanks for your help on this. Sorry to bring a mod related issue to the forum.

Savatage

Savatage wrote:

No modifications have been made since this problem started.

How about Just before the problem started

At least you found your answer - and that was the goal.

bspencer

In this particular instance, the mod was made in March of 2008. It just so happened that the combination of variables required to manifest the issue were not met until I first posted this thread. But indeed, the problem was created by our changes.