Question

Customer Orders with Duplicate Customer Order POs error - ORA-20110

  • 28 November 2022
  • 8 replies
  • 340 views
B
Rank
Badge +1

Our EDI customer re-use the same PO references on different incoming orders (they aren’t able to change this). IFS can accept this, but when an order with the same PO reference is received, IFS rejects this order at the 'incoming customer order' screen (see below). The only way to work around it is to amend the PO ref, create the order, then change the PO ref back on the order that's created, but this is resource intensive. Does anyone know if there’s any configuration to allow duplicate Customer PO Numbers on incoming customer orders?

 

8 replies

M
Rank
Userlevel 5
Badge +10

Hi,

 

We are in a similar situation. I’m going to look at an event - I’ll let you know how I get on.

It should be something that is natively supported by IFS though

P
Rank
Userlevel 5
Badge +13

Hi,

As far as I know, this validation is made on purpose, to keep a single link between your customer’s PO number and IFS customer order. Remember that this Customer PO Number is also used in the documents provided to your customer, so it can be confusing for them to have several documents with the same Customer PO number and different order numbers and invoices from your side.

Is it feasible to use instead a change order, so new demands for the same Customer PO Number are added to your existing customer order?. In this case, then new customer order lines would be created for your existing order and customer could differentiate between different demands with the Line No identifier.

Regards,

Pilar

M
Rank
Userlevel 5
Badge +10

This is where IFS lets itself down in its fabled ‘Moment of Service’ - not all Customers of IFS’ Customer’s are Enterprise Level operations. It is up to the end customer to decide what is confusing for them - not IFS. 

A good chunk will be SME’s where ‘my word is my bond’ still stands. It maybe that at the customer the invoice needs to go directly to an individual for them to arrange cost allocation / payment so the same name is used as an order number. Or it may be that they use the same PO reference on their system for all orders for a Period.

Who are we to dictate what is a confusing business practice for customers that pay us money and ultimately means we can afford the licensing for IFS.

It represents a separate demand IFS so should be entered as a separate order within IFS. What IFS should be doing is listening to requests to help improve the revenue generating abilities of their customers. I can see no reason why it should be a hard stop on an incoming order - but only a warning message if the order is created manually.

There could be a toggle switch on the incoming customer order settings, or the customer file entitled ‘allow Duplicate PO numbers’ which if ticked would skip the validation logic in the API call for creating the customer orders.

P
Rank
Userlevel 5
Badge +13

Hi,

Understand your position, I was only trying to help.

Anyway, if you agree, I can create a new Idea in Community, so RnD can consider this request for future releases

Contribution from customers is highly valuated, so any request of enhancement is usually welcome.

Regards,

Pilar

M
Rank
Userlevel 5
Badge +10

Hi,

 

Yes please can you raise this as an Idea in the Community. Hopefully RnD will see the benefit as well!

 

Thanks,

 

Matt

P
Rank
Userlevel 5
Badge +13

Hi Matthew,

New idea created:

Please, upvote it so RnD considers this in future enhancements.

Regards,

Pilar

M
Rank
Userlevel 5
Badge +10

Thanks - much appreciated and also the comments above were not personal, more a vent at the cumulative issues I’ve faced recently

M
Rank
Userlevel 5
Badge +10

Hi @BEYANTHONYB - I now have an event that is running as a scheduled database task execution of a pl/sql block.

I force all orders to error (via adding text to a field and an event action looking at incoming customer order) as I want to make these have a specific order type and coordinator (which is different to customer default) - then when the creation errors it will add X-123||Message_ID||PO, then create customer order and finally remove the X-123||Message_ID| from the customer order.

I have included the relevant section of the code - apologies for not putting all in, but to ‘sanities’ for the Internet would take too long! I am sure you will be able to add variables and syntax in. It is curranty in TEST, so you may run into scalability problems

 

cursor ext_Cust_Order is
SELECT ECO.OBJID, ECO.OBJVERSION, 'X-123-'||ECO.MESSAGE_ID||ECO.CUSTOMER_PO_NO NEW_PO 
from external_customer_order ECO, IN_MESSAGE IM 
where 
ECO.MESSAGE_ID = IM.MESSAGE_ID
AND
IM.sender = 'DEF' 
AND ECO.ERROR_MESSAGE LIKE 'ORA-20110: ExternalCustomerOrder.CUST_ORD_FOUND_EXT%' ;

CURSOR ORDER_DEL_CON IS
SELECT
OBJID, OBJVERSION, TRIM(LEADING'X' FROM CUSTOMER_PO_NO) OLD_PO
from customer_order
where order_id = 'ABC'
AND CONFIRM_DELIVERIES_DB = 'TRUE'
AND STATE NOT IN ('Invoiced/Closed', 'Cancelled', 'Delivered', 'Partially Delivered')
;

CURSOR ORDER_NO_SORT IS
SELECT
OBJID, OBJVERSION, SUBSTR( CUSTOMER_PO_NO, 13 ) OLD_PO
from customer_order
where order_id = 'ABC'
AND STATE NOT IN ('Invoiced/Closed', 'Cancelled', 'Delivered', 'Partially Delivered')
AND CUSTOMER_PO_NO LIKE 'X-123-%';

FOR D_ IN  ext_Cust_Order LOOP

objid_ := D_.OBJID ;
objversion_  := D_.OBJVERSION ;
NEW_PO_ := D_.NEW_PO ;
 Client_SYS.Clear_Attr(attr4_);
            Client_SYS.Add_To_Attr('CUSTOMER_PO_NO', NEW_PO_, attr4_);
            

EXTERNAL_CUSTOMER_ORDER_API.MODIFY__(P04_,objid_, objversion_ ,attr4_, 'DO' );
end loop ;

FOR E_ IN MESSAGES_APPROVE LOOP
objid5_  := E_.objid ;
objversion5_  := E_.objversion ;
  Client_SYS.Clear_Attr(attr5_);
            Client_SYS.Add_To_Attr('AUTHORIZE_CODE', 'DEF', attr5_);
            Client_SYS.Add_To_Attr('ORDER_ID', 'ABC', attr5_);
            Client_SYS.Add_To_Attr('LIMIT_SALES_TO_ASSORTMENTS', 'FALSE', attr5_);
External_Customer_Order_API.Approve__(p0_,objid5_,objversion5_,attr5_, 'DO');
END LOOP ;

FOR F_ IN ORDER_NO_SORT LOOP
objid6_  := F_.objid ;
objversion6_  := F_.objversion ;
OLD_PO_ := F_.OLD_PO;
  Client_SYS.Clear_Attr(attr6_);
            Client_SYS.Add_To_Attr('CUSTOMER_PO_NO', OLD_PO_, attr6_);

CUSTOMER_ORDER_API.MODIFY__(p0_,objid6_,objversion6_,attr6_, 'DO');

END LOOP ;

Reply


Terms & ConditionsCookie settings