Parameters by sales organization or company code

[daphnash]

Hi Gurus,

We are a global company with many sales organizations\company codes (sales organization = company code==> 1:1).

I need to maintain several parameters by sales organization\company code , that will be used for reporting and printing programs.

For example: whether to print authorized signature, should I use logo or stationary, whether to print "INVOICE" or "TAX INVOICE" at invoice layout header, and a few more...

Do I have a standard location for maintaining such parameters or do I need a "Z" table for that?

I had an idea to use classification like customer classification, so I have tried to create a "Z" class type for on TVKO or T001, but it didn't create a search help in CL20N and the users do not know the numbers by heart (there are more than a hundred of them...)

Please help me -- I don't want to create another "Z" table

There are too many of those in this project...

Thanks,

Daphna

[daphnash]

Thanks you all !!

I try to avoid Z tables as much as possible.

I eventually managed to create the required new class type with the proper search help with standard tools according to "How to" I found on the net.

I created the classes and characteristics in DEV and used SAP distribution model (using IDOCs set up) to distribute it to all systems.

The value maintenance can be maintained easily in CL20N or massively in CL24N.

I used characteristic dependencies for several validations and dependencies.

The solution eventually fitted other implementers from FI and MM as well that needed additional parameters for company codes.

[Jelena]

Since this is the whole rainbow of requirements you'd be better off with a Z table. Many SAP customers have some kind of a "catch all" table for all kinds of odd requirements. We have one that consists of the Object name (can be ABAP report, form name, any unique ID), Org ID (can be SOrg, Company, etc.), Parameter ID (usually technical field name), Value and Comment. This table is used instead of hardcoding in many places - user exits, forms, etc. I've heard many others using similar tables.

Classification is pain in the back to read and how would the programs know what characteristic applies to them? It's not in any way better than a Z table. Small table that rarely changes can also be buffered for better performance.

P.S. You might not want to open with "hi gurus" on SCN. Anyone is free to post or respond here.

[VeselinaPeykova]

I have encountered both cases for z-tables: a few generic ones vs. multiple process-specific/module-oriented tables.

Generic z-tables are nice and convenient to use, but there can be some disadvantages.

When you use generic z-tables, nobody is the 'owner', so maintenance, understanding the logic, review, cleanup, proper documentation can become a challenge (I have seen such z-customizing tables used by several teams with tens of thousands entries). I am not sure about the complexity of restricting maintenance access between departments, I think that it could be tricky sometimes, especially if you use external resources.

With multiple multiple process-specific/module-oriented tables you have the risk of duplicating similar things in several small tables, so probably it is up to the solution architects to review and challenge new z-table creation, so that things don't spin out of control.

Another approach, which I have seen, is using parameters/selection options maintained in transaction STVARV for custom reports. Maybe for some high-level/global stuff it can be useful (if you don't have too many entries and if you can establish control on who/when/why manages what). There must be a good reason why this is not a very popular and common approach, it could be because z-tables give more flexibility and it is easier to come up with good logic compared to TVARVC, or something else.

In all cases - if you get one hundred of possible values for a specific process (and several others to combine with), then it seems to me that either the rules are too complex (then it is a good idea to discuss with the business to standardize and streamline the processes before introducing changes in the system) or the selected criteria for differentiating needs to be challenged.

Most probably there are different printforms used for invoices in different countries, so I would prefer to keep the logic for "INVOICE" or "TAX INVOICE" etc. text in the smartform anyway in a FM per country with more complex logic... sometimes z tables just cannot cover well all possible cases per country.

Message was edited by: Veselina Peykova

[former_member182378]

Veselina,

In past projects, I have seen clients using z-tables, module specific z-tables and TVARVC.

You have mentioned some disadvantages of using TVARVC, please elaborate with some examples.

- why only some high-level/global stuff?

- how z-tables give more flexibility?

- why it wont work for too many entries? we can input several values, range etc. in the a selection option Tab

Another approach, which I have seen, is using parameters/selection options maintained in transaction STVARV for custom reports. Maybe for some high-level/global stuff it can be useful (if you don't have too many entries and if you can establish control on who/when/why manages what). There must be a good reason why this is not a very popular and common approach, it could be because z-tables give more flexibility and it is easier to come up with good logic compared to TVARVC, or something else.

What text do you refer to below

Most probably there are different printforms used for invoices in different countries, so I would prefer to keep the logic for "INVOICE" or "TAX INVOICE" etc. text 

thanks!

TW

[VeselinaPeykova]

I have seen TVARVC used only in 2-3 cases during projects, to be precise, so it is hard to provide examples . I was hoping that Jelena could share her views from techno-functional perspective. For my stuff, I used this just once - to maintain the wait time per system for executing a certain set of instructions (to write the result of multiple document modification and creation in a z-log table, it was not 'worth it' to create and maintain another table for something of that sort). 

For z-tables you can choose the set of fields that you need for the custom logic, table structure and settings, usually only one team is responsible for maintaining it or at least is controlling what is maintained there. In a previous company I worked in, people insisted not to give authorization to externals for everything in SPRO, only what is really needed for their roles and responsibilities.

Imagine when you have a mixture of internal and external consultants from different teams maintaining some values in the same place ... and usually there is not a single person in the company with a good understanding what all these values influence.

This is why I would go for such option only for very few things with high impact instead of using it for just anything.

Z-tables in addition allow more complex logic, combinations of values from different fields, I believe that it is generally easier to configure and write complex custom logic with z-tables than with variables. I cannot comment on performance impact, since my case was kind of 'special'.

As to the different invoice smartforms - for example countries such as Russia, Belarus, Ukraine have completely different requirements for invoice layouts, not to mention how you fill the data - compared to many EU countries, so they would not use the same forms as, say, Austria. Hellenization is another notable case, where things are not really simple when it comes to document types, printing cancellations and so on.

It is a good approach to avoid excessive hard-coding in printforms, but to expect that you can capture all possible scenarios and influence printout logic for many countries with values from a single z-table, is probably too optimistic. If it is for some relatively simple stuff in the same form (if you can reuse the invoice form in credit/debit memo printout for example), then there are conditions in SMARTFORMS, you can also determine different standard texts based on certain prerequisites. If it is some really complicated logic, which can be reused in other forms, then I would prefer to call a z-FM per country that reads also the country-specific customizing, not just query a generic z-table, which is maintained in addition to it and which everybody forgets about.

I have used z-tables for one logistics form, for example, because we had a requirement to print document items in a special sort order and grouping per product type, packaging, quantity etc., which the logistics key users wanted to define on their own in PRD without modifying the existing master data. In my case z-tables were unavoidable, so the FM read the settings and modified the items for printing purposes.

In all cases, if a country redefines the way it treats a document as tax invoice or invoice or changes the source for determining VAT registration numbers, this implies significant changes in the system setup and master data, so adjusting the smartform text would be the least of my worries.

[Jelena]

Selection Variables (TVARVC table) are meant to be used as, well, selection variables for the report variants. For example, we follow a special fiscal calendar and month start/end dates don't match with the actual 1st / last of the month. But these are parameters in many programs. Unfortunately, in the report selection variant, there are only the actual calendar date options, not the fiscal one. So we created several selection variables and there is a daily program that updates them based on the fiscal calendar.

I've seen once someone used TVARVC just to store some values for the program. This is not a great idea and does not offer much visibility as to what those variables are for (much easier to run "where used" for a Z table). It's better to use TVARVC only for what it's intended. Z tables (global or by module, depends on the organization's needs) are fine for all other scenarios. Veselina already pointed out some advantages, including more manageable access and possible value validations.

Also, as correctly pointed out, the forms are a different beast and in many cases some conditions can be simply added to the forms. E.g. if something is based on the document type it's unlikely to change frequently. And if it does you'd need a transport anyway.

After some trial and error we actually arrived to one function module that we now use in all SD forms for the company address / phone / logo. The FM is called by all the forms and provides the object names (bitmap or standard text) by Sales Org. New Sales Orgs are rarely added, but the text/logo itself is easily changeable. We also have some conditions coded directly in the forms.

Volume and nature of such "parameters" would be the determining factor for how to implement them in the specific organization. There is no "cookie cutter" solution for everyone IMHO.

P.S. Wow, this turned into a major [free] consulting session.

[former_member182378]

Daphna,

To confirm the business - (taking an example) Invoice printout should contain a particular logo, if there is a particular sales organization in the billing document. To achieve this need, you want to update information in the sales organization or maintain a custom table, so that the logic knows logo is needed.

Please confirm.

TW