Today, we only have 1 contract we use for any shop order / selling documents / purchase documents and such.
In our developements (events / CF read only type / schedule tasks / lobbys ), the most of the time, SQL queries don’t use the contract to filter data, but generally we only use the ORDER_NO field for selling and purchase documents, and ORDER_NO + RELEASE_NO + SEQUENCE_NO fields for shop orders.
We have planed to create a new contract : what would be the consequences on our developements ? Would they need to be re-worked?
Page 1 / 1
@romsar every supply/demand transaction (Purchase Order/Customer Order/Shop Order) is always linked to a Site (contract field in the DB). These tables don’t have the order_no as primary key, instead they use a unique key which is the combination of site (contract) and order_no.
Since CO numbering is managed via Coordinator/Coordinator Groups, I’m pretti sure you can’t have the same CO number across different sites, but when it comes to Shop Order I’m not sure.
Of course, all CRIM development should be done considering these unique keys for each LU. I believe it would be safer to refactor your CRIMs.
@Marcel.Ausan
I guess that CO means “customer order”, but what’s CRIM?
About lobbys, I suppose the problem can easily be solved either by using the #USER_DEFAULT_SITE# variable to filter the site or by adding a variable on the lobby page.
About sheduled tasks, it’s possible to add a parameter to filter on the site and then, running again the same script but with another site.
In my end, I took the habbit to consider the OBJKEY of the object of the view to get every information I need, but still, I would still need to make sure there would have no conflict on objects because of the lack of the filter on the site. In my case, I met some issues on an event about INVENTORY_PART, as queries were filtering only the PART_NO field...
@romsar - CRIM is IFS speak for Configuration, Report, Integration or Modification - effectively including all the “developments” you refer to in your original post.
As site/contract is pretty fundamental within lots of the IFS functionality, I would suspect that you would need to add the contract into most of your events/tasks/lobbies/lobby elements as a variable to ensure that you are pulling back / actioning the correct data.
@romsar CRIM is the IFS abbreviation for Configurations Reports Interfaces Modifications. It’s a widely used term in IFS world which comprises on enhancements done to the system.
For example, custom fields / custom events are considered Configurations (C in CRIM), whereas custom PL/SQL packages that you created and run as Scheduled Tasks would be Modifications (M in CRIM).
For sure you will have issues in INVENTORY_PART / SALES_PART / PURCHASE_PART / PROD_STRUCTURE / ROUTING_HEAD as all of these tables use the part_no in conjunction with the site (contract).
