| Q: | Why ERP
mapping has to be performed at all? |
| A: | A small
example shall illustrate the necessity: When performing changes in a
catalog's follow-up version it could be, for example that a project
was split into two. If on customer side, just the new catalog version
would be installed, related ERP numbers could not be assigned anymore,
because the corresponding project is missing. However, if a mapping is
created, this information is available during the installation and the
ERP numbers can be correctly assigned to the new projects
again. |
| Q: | On which
versions the mapping is based? |
| A: | |
| Q: | May an ERP
mapping be performed during LIVE publishing? |
| A: | No. A new
mapping is always created in relation to the last LIVE publication,
however, this is not yet available. |
| Q: | When must an ERP mapping for partial publishing be added (context menu command Add ERP mapping for partial publishing. [Add ERP mapping for partial publication....]..)? |
| A: | For a QA
publication which only contains the locally modified files of the
selected subfolder. All other
files are used from the last successful QA publication. In this way it
is possible just to publish a subset of the locally modified
files. By running
multiple partial publications before running a live publication you
can ‚build‘ a certain desired live version. For example user1 partial
publishes subfolder1, user2 partial publishes subfolder2 … etc. |
| Q: | Modeler has
just confirmed the mappings without actually performing it - how this
can be fixed? |
| A: | This can
lead to problems during the installation of a catalog update. The
LIVE publication will work fine, because mapping exists However, when the customer installs the
update, possibly ERP numbers are mapped to wrong parts. Solution: Create a new LIVE publication
and for this two mappings: Create a mapping as usually (source
version corresponds to the last available LIVE version) Delete the incorrectly confirmed mapping from the mapping file (context menu command Clean up ERP mappings for older versions [Cleanup previous ERP mappings...]...). Create a second mapping to the second
last LIVE version.
|
| Q: | What
happens when a variable used for ERP mapping gets deleted? |
| A: | Mapping is
based on a whole row. So not much happens... The user has to verify
the mapping suggestion. |
| Q: | What to
keep in mind with regard to links? |
| A: | Nothing, as
links do not occur in the mapping. A link points to a real project.
However, if the real project gets modified, this needs a mapping. So
then also for the link project everything is ok. |
| Q: | Which
catalogs require an ERP mapping? |
| A: | Only
catalogs for which a CIP is created during the LIVE publication
(checkbox in dialog). Catalogs without CIP do not have ERP
numbers. In
PARTcommunity or 3dfind.it projects are simply modified. There are no
ERP numbers - the only reason for ERP mapping. |
| Q: | Is running Edit ERP mapping [Edit ERP-Mapping...]... a reliable way to check another person's ERP mapping (also as part of QA checks)? |
| A: | Yes, but
following has to be considered: ERP-Mapping
is created using the local working copy of the catalog. So you should
make sure that the local version of the catalog is the same (watch out
for locally modified files / outdated files etc.) |
| Q: | Some of
problems with ERP mapping are difficult to reproduce - what's the best
way to report them? |
| A: | mapping.json If
possible do not keep on changing files (else it will be harder to
check the problem) What
kind of changes were applied which lead to the problem with the
mapping? Do not
use any workarounds when the publications fails (e.g. publishing
without CIP to make the publishing work. Publishing without CIP
will destroy the server data.
|
| Q: | What role do files uploaded to the SVN trunk (uploading changed files in directories/projects to the server [Upload changed files in directories / projects to the server] ) play in QA publishing? |
| A: | Actually
none, because the files of the local working copy are used. (If it
makes sense to check in the local files is another question.) |
| Q: | Where the
mapping is saved? |
| A: | In the file mapping.json. |
| Q: | Can the file mapping.json be edited by several users at the same time? |
| A: | Yes, the
file is not locked. To have status as current as possible, update your
local file. |
| Q: | How can
conflicts be avoided? |
| A: | Always download the latest version of the mapping.json file. It is best to always perform mappings when checking in and check in the mapping.json. This should ensure that the mappings are always up to date and that publishing is then possible without any problems. Check in
changes in a timely manner (+ perform mapping for it). If e.g. a
big change shall be performed, it could make sense, to process it
in several little steps and to check in the changes after each
partial step (+ create mapping and check in).
|
