Function similar to Owner

Hi,

I have two catalogs Items and ItemTypes. An Item can have many ItemTypes and an ItemType can be assigned to many Items. Thus, I added a TabularSection in Item including an attribute ItemType which is of type CatalogRef.ItemTypes. Creating an Item I can assign several ItemTypes in the table to the current Item that I created before.

Now, I want to select an Item within a document and, afterwards, select one of its ItemTypes that I assigned to that Item. However, instead of displaying only ItemTypes that are actually assigned to the selected Item, all ItemTypes created are shown when I click on "Show all". What do I need to do so that only ItemTypes are displayed that are connected to the currently selected Item.

I need something like the owner functionality, but realizing a many to many relationship. An Item can have many ItemTypes and an ItemType can be assigned to many Items.

Example:

1. Creating ItemTypes: Type1, Type2, and Type3
2. Creating ItemA and assigning ItemTypes Type1 and Type2 to it.
3. Creating ItemB and assigning ItemTypes Type2 and Type3 to it.
4. Creating the document. Selecting ItemB. Then I want to select one of its ItemTypes which are Type2 or Type3, but clicking on "Show all" all ItemTypes (Type1, Type2, and Type3) are shown and selectable.

Best,
Saman

Hi Saman,

1. To be able to answer that I need more information about the Document's nature and structure. How the Document, Item and ItemTypes are connected? What is the structure of the Document? If you select Item to fill out the Document why do you need to select ItemType?

2. Could you, please, explain me the use case you are trying to implement here? What exactly does a user do and see here? Would be great if you could give me a step-by-step description of this scenario. Like:
- User clicks "Create New" in the Document's list
- A new Document form is opened
- Then what?

Ok, I will try to explain my use case in more detail. I start in the Designer with creating the
Catalogs and the Document:

Step 1: Create a catalog named ItemTypes
->Attributes: none (attributes are not needed right now)

Step 2: Create a catalog named Items
-> Attributes:

• Unit (this is of type String)
  

• ItemType (the Type of this is CatalogRef.ItemTypes)
  
• Price (the type of this is Number)
  

• TotalPrice (this is of type Number)
  

• Item (the type of this is CatalogRef.Items)
  
• ItemType (the type of this is CatalogRef.ItemTypes)
  
• Price (the type is a Number)
  

• TotalPrice (this is of type Number)
  
• Items (the tabular section):
  
• - Item (the type of this is Object.Items.Item)
  
• - ItemType (the type of this is Object.ItemTypes.ItemType)
  
• - Price (the type is a Number)
  

• Unit: Each
  
• Tabular section Row 1:
  
• ItemType: Type1
  
• Price: 3.99
  
• Tabular section Row 2:
  
• ItemType: Type2
  
• Price: 8.99
  

• Unit: Each
  
• Tabular section Row 1:
  
• ItemType: Type2
  
• Price: 10.99
  
• Tabular section Row 2:
  
• ItemType: Type3
  
• Price: 12.99
  

• Select Item: ItemB
  
• Select ItemType: ItemType3 <--- PROBLEM HERE ---
  
• Add Price: 12.99
  

Concerning the specific task (filtering the drop-down list basing on the selection made in another field). What you are looking for is called Choice Parameter Links (Developer Guide, 5.6.14) and Choice Parameters (5.6.15). Please, take a look at this topics and try to apply these properties to your case.

That said, I am not sure if your current solution is good enough. Making many-to-many relation with Catalog tabular part might be not the best idea. But it's really hard for me to say, because I don't understand what the ItemType is. What does it refer to in real life (in physical world)? Can you give me a few examples of Items and correspondent ItemTypes?

Hello Saman,

I am not sure if I understand your use cases correctly. But if you need just a discount for certain type of customers, you can have products as owner of the catalog PriceCategory.A customer (as regular customer) has a category PriceCategory (with discount 5%), you should create an attribut PriceCategory in the catalog Customers  with a type CatalogsRef.PriceCategory.
You can make then a Query with some JOIN, and only Products with the PriceCategory (5% discount) will be available at creating of document (Customer is as attribut in the document).

It is just an idea, but please let me know if I understood the task correctly.

I guess even JOIN is not necessary. You would need only query parameters and then Selection.Next().
I have to say I am not so good in writing queries.

@Konstantin

Saman,

I really think that your current issue is completely wrong data structure, so it's crucial for us to focus on this single topic. I really need you to answer this question: "What exactly do you store in the PriceCategories tabular section? If you have one price for one Product why you need a list of PriceCategories INSIDE this single Product? What does it mean? ".

Could you please give me one specific example of one particular product with all its attributes and tabular section lines?

Saman,

I have another idea. You can create an Information Register with Dimensions Product (Type CatalogRef.Products) and PriceCategory (Type CatalogRef.PriceCategory). And set the dimension Product to Master and Main Filter. Then a query should work.

But I still do not understand. Do you need to see a dropdown list in the tabular section of the sales invoice or it is enough if you have a customer in your Sales Invoice who has ONLY ONE type of discount, let's say 2% (in this case it can be okay if you get a price from your information register)?

Sorry for wrong advice! It can not work this way.
I am interested in this solution because maybe one of my customers will have a very similar wish.

The advice was not soooo wrong.

I created an information register PriceCategories with periodicity "Whithin a second".
In every Product I created a PriceCategory with different discounts (in Enterprise mode).

In Common Modules I wrote GeneralFunctions and there

Function GetCategory(Product) Export
      
   Category = InformationRegisters.PriceCategories;
   ProductFilter = New Structure("Product");
   ProductFilter.Product = Product;
   CategorySelection = Category.Select(,, ProductFilter);
   While CategorySelection.Next() Do
      Message ( CategorySelection.PriceCat);
      
   EndDo;
   
   Return CategorySelection.Product;
   
      
EndFunction

Konstantin,

A Product may have more than one price. That is why I use a tabular section.
Example:

PriceCategories = Category1, Category2, Category3

Products = Monitor, Notebook
Products -> Tabular Section:
Monitor: Category 1 = 3.99 and Category2 = 8.99
Notebook: Category2 = 5.99 and Category3 = 10.50

SalesInvoice:
Monitor => Sel ect Category2 (from the list showing only Category1 and Category2)
Notebook => Select Category3 (fr om the list showing only Category2 and Category3)

Prices are determined by selecting the PriceCategories automatically and totals are calculated afterwards.

Lioudmila,

I think what I want to do is really standard functionality of 1C and I do not want to code
something to keep the application as clean as possible. Using information register may help,
however, I am not sure how to build the right data structure for my issue.

I will try to post an example configuration by next week if I do not have a solution.

Hi again,

so now I prepared a small example configuration.
It includes the submenu Inventory where PriceCategories and Products are located.
I have already created three different PriceCategories numbered 1 to 3 and two
Products numbered 1 and 2. Product1 encompasses PriceCategory1 and PriceCategory2
in its tabular section and Product2 PriceCategory2 and PriceCategory3.

In the second submenu Sales Quotes can be created. This is also where my problem
occurs. So do the following:

1. Go to Quotes in the submenu Sales and click on the Create button. In the form
you will see a tabular section which is supposed to hold the different products
assigned to this Quote.

2.Click on the Add button to add a product to the list. In the Product column select
Product1 and go to the PriceCategory column (by clicking enter, for instance).

3. In the PriceCategory column I want only the PriceCategories of Product1 to be
displayed. But if you click on the "Show all" button every PriceCategory is displayed
and can be selected that have been created in the PriceCategories catalog (in the
submenu Inventory).

How can I fix that by using the right data structure instead of coding it myself (which
I guess is not necessary as it seems to be a standard functionality)?

Thank you Saman. Now the task is perfectly clear. We need some more time to come up with solution. Hopefully it will be ready tomorrow.

Sorry for the delay, Saman. Here is the decision we suggest (please find the DT file for our solution attached to the message).

1. First of all, let's discuss the data structure. In your solution, Price is an attribute of the tabular section of the Products catalog. It means that you can have the only price value - current. You can change it, but you cannot trace the changes. Therefore, you don't know what the price was at any point in past time. Real-world systems usually take the pricing process more seriously and store the complete history of all price changes.

So, we suggest you store the prices in the Information Register with dimensions Product (CatalogRef.Products) and PriceCategory (CatalogRef.PriceCategories) and attribute Price (Number). The register has to periodical. Periodicity depends on the anticipated price change frequency. In my example, I set it to "Within a day". It means that you cannot change the same price more than once a day.

To get the current price you are going to need SliceLast virtual table, so you'd better select "Enable totals for retrieving slice last" option (tab "Other" of the IR properties form.

2. Product categories list is completely dependent on the Product selected (this is why your question has arisen in the first place). Therefore, I cannot see why we divide the selection procedure into two independent actions - user needs to select the Product in one column and then select the Category in another column. This approach makes the connection between Products and PriceCategories unobvious. To avoid confusing a user, I suggest we use one choice form showing two list dependency explicitly.

So, we redefined the ChoiceForm for Products catalog. This form shows two dynamic lists: Products and PriceCategories. PriceCategories dynamic list has a custom query with two parameters - &Product (current product selected in the first list) and &Period (the date of the SalesInvoice document we are creating now).

To open this form, we use ProductsProductStartChoice event handler, which sets StandardProcessing to False to block any Platform default actions and then opens the form. We pass Object.Date to the form as a parameter and then pass is to the query in OnCreateAtServer event of the choice form.

3. Note that the prices shown in the right list of the choice form are dependent on the document date. You can change the date of the document, and you will see different prices in the list.

Please, take a look at the solution. Let me know, if you have any further questions or comments.

Thank you for the detailed answer including the example DT.
I will check your solution closely in the next couple of days and will give you my feedback.

Sorry for the delay in my answer Konstantin.

So I looked at your solution and generally it would help to solve our problem. However,
I am not sure about how user friendly the approach is. I have two concerns with it:

1. Creating products but assigning their prices somewhere else is really inconvenient.
I know the solution you proposed from the developer guide but do not like it much because
I have to switch between different user interfaces (forms) to poplate all necessary
product data. That is most probably unexpected and confusing to users as they have to save
a product that is uncomplete temporarily. Also assigning different prices to one product
forces the user to assign each price subsequently, that is, open the corresponding form,
assign a price, save and close it and then repeat these steps for each following price.

I would rather suggest to put the pricing in the product form as in my example and just
write the data into an information register on post to build the history of a products prices.
That would not bother a user as it is actually invisible for him and do not cause any extra
work steps.

2. The form combining the product and the price category selection in the sales invoice is a
possible solution to my actual question and I may use it as well. However, it somehow breaks
with the general workflow of the other selection fields which may also be a bit confusing to
users. In addition, in your example I cannot use the Select button to confirm and submit the
selected product and price category. Instead, I have to use the enter key. I am not sure if this
is not a bug actually, however, it is unexpected once more.

Nonetheless, your solution would solve my problem and I appreciate your effort. I will try to
combine your ideas with mine. Most important in my opinion is the pricing within the product
creation to avoid context switching.