.. additional_data documentation master file, created by sphinx-quickstart on Sun Jul 8 22:06:29 2018. You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. Welcome to additional_data's documentation! (v |release|) ========================================================= .. toctree:: :maxdepth: 2 :caption: Contents: usage/installation usage/quickstart cli/additional_data_util usage/define_an_additional_data_model api_reference/additional_data usage/tips_and_tricks adcollection/index changelog/changelog changelog/roadmap impressum/impressum Motivation ---------- Standards in data exchange between enterprises are defined with regards to the participants. Focussing on including all essential data and leaving out all superfluous. The bigger the number of interested parties in said definition, the harder it is to combine the two goals. A standard trying to satisfy a great number of users will have to die the one (include and support many data elements that nearly nobody needs) or the other (exclude data elements that are not used every time or by every one) death. In practice this leads to either bilaterally or in small circles defined standards, that exactly fit the needs of all participants, but are unknown or unused outside the defining group. Or there are abstract jacks of all trades that are not completely implemented by anyone, because the costs of said implementation would be uneconomical. There exists a well known arsenal of methods to trim a big standard down to manageable size, e.g. user recommendations, association restrictions or inhouse formats. These restrained formats can often times preserve compatibility with the basic format. Using the herewith presented procedure of data extension, a reciprocal method for extending a given data format is laid out, that should achieve or at least allow for the same conservation of the underlying format. In the following a standardized procedure to derive such a data extension set is introduced. Identifying the needs --------------------- The first step should be to determine whether you do indeed have an unsatisfied need and/or whether there already exist solutions for your problem. Identifying your need normally isn‘t too difficult, normally your co-workers, partners or other business associates will signal insufficiencies time and time again, like a wound tends to signal you pain over and over again telling you to do or stop doing something specific. Nonetheless you should invest the time to write down the specific needs your organization faces and condense what you truly require and sort out needs that only appear to be beneficial or whose benefits are far too little to advocate a time consuming investment like the definition of a data extension. Be not mislead by the ease of the procedure and the tools supplied to you by this publication: Sitting down with others at a table and agreeing on a standard that afterwards is indeed used – meaning it faces not only your commitment but commitment of others, too – is a time consuming endeavor. But let‘s say you did all that and identified what your business process or your partner‘s are missing in the currently used data environment. Then you should look again, if your problem isn‘t already solved. Since, if you have a problem and you are not a monopolist with a very special business, chances are good others have and have had the same problem. Thus, chances are, you might be lucky and others already solved your problem. If you happen to be of the unlucky kind, do not despair, instead follow our :ref:`formalDefinitionAnchor` or jump into our :ref:`ImplementationExampleAnchor`. Indices and tables ================== * :ref:`genindex` * :ref:`modindex` * :ref:`search` .. _additional data definition: