| D: | Perché è necessario eseguire la mappatura ERP? |
| R: | Un piccolo esempio dovrebbe illustrare la necessità: A causa delle modifiche apportate a una versione successiva del catalogo, è possibile che un progetto sia stato suddiviso in due progetti. Se la nuova versione del catalogo fosse semplicemente installata dal lato del cliente, i numeri ERP esistenti cadrebbero nel vuoto, poiché il progetto originale non esiste più. Tuttavia, se viene creata una mappatura, le informazioni sono disponibili durante l'installazione e i numeri ERP possono essere assegnati correttamente ai due nuovi progetti. |
| D: | Su quali versioni si basa la mappatura? |
| R: | |
| D: | È possibile eseguire una mappatura ERP mentre è in corso una pubblicazione LIVE? |
| R: | No. Viene sempre creata una nuova mappatura in relazione all'ultima pubblicazione LIVE, ma questa non è ancora disponibile. |
| D: | Quando deve essere aggiunta una mappatura ERP per la pubblicazione parziale (comando del menu contestuale Aggiungi mappatura ERP per la pubblicazione parziale [Add ERP mapping for partial publication....]...)? |
| R: | Per una pubblicazione QA che contiene solo i file modificati localmente della sottocartella selezionata. Tutti gli altri file vengono utilizzati dall'ultima pubblicazione QA andata a buon fine. In questo modo, è possibile pubblicare solo un sottoinsieme dei file modificati localmente. Eseguendo diverse pubblicazioni parziali prima di eseguire una pubblicazione live, è possibile compilare la versione live desiderata. Ad esempio: l'Utente1 esegue una pubblicazione parziale per la sottocartella 1, l'Utente2 una pubblicazione parziale per la sottocartella 2, ecc. |
| D: | Il modellatore ha verificato le mappature senza verificarle effettivamente - Come si può risolvere questo problema? |
| R: | Ciò può causare problemi durante l'installazione di un aggiornamento del catalogo. La pubblicazione LIVE funziona perché esistono le mappature. Ma se il cliente installa l'aggiornamento, i numeri ERP potrebbero essere mappati sui pezzi sbagliati. Soluzione: creare una nuova pubblicazione live e due mappature per essa: Creare una mappatura come di consueto (la versione sorgente corrisponde all'ultima versione live disponibile) Eliminare la mappatura confermata in modo errato dal file di mappatura (comando del menu contestuale Pulire le mappature ERP per le versioni precedenti [Cleanup previous ERP mappings...]...). Creare una seconda mappatura della penultima versione live.
|
| D: | Cosa succede se una variabile utilizzata per la mappatura ERP viene cancellata? |
| R: | La mappatura si basa su una linea intera. Pertanto, non succede molto. L'utente deve verificare la proposta di mappatura. |
| D: | Cosa devo tenere a mente con i link? |
| R: | Niente, perché i collegamenti non appaiono nella mappatura. Un collegamento punta a un progetto reale. Tuttavia, se il progetto reale viene modificato, richiede una mappatura. Ciò significa che è tutto a posto anche per il progetto di collegamento. |
| D: | Quali cataloghi richiedono una mappatura ERP? |
| R: | Solo i cataloghi per i quali viene creato un CIP durante la pubblicazione LIVE (casella di controllo nel dialogo). I cataloghi senza CIP non hanno numeri ERP. In PARTcommunity o 3dfind.it, i progetti sono semplicemente aggiornati e non ci sono numeri ERP, che sono l'unica ragione per la mappatura ERP. |
| D: | L'esecuzione di Modifica mappatura ERP [Edit ERP-Mapping...]... è un modo affidabile per verificare la mappatura ERP di un'altra persona (anche come parte dei controlli QA)? |
| R: | Sì, ma si prega di notare quanto segue: La mappatura ERP viene creata sulla base della copia di lavoro locale del catalogo. È quindi necessario assicurarsi che questa sia la stessa (attenzione ai file modificati localmente e non aggiornati). |
| D: | Alcuni problemi con la mappatura ERP sono difficili da riprodurre: qual è il modo migliore per segnalarli? |
| R: | mapping.json Se possibile, non modificate altri file, altrimenti sarà ancora più difficile verificare il problema). Che tipo di modifiche sono state apportate che hanno portato al problema della mappatura? Non utilizzare soluzioni di emergenza in caso di pubblicazione non riuscita, come la pubblicazione senza CIP, per eseguire la pubblicazione. La pubblicazione senza CIP distrugge i dati del server.
|
| D: | Che ruolo hanno i file caricati nel trunk SVN (caricamento dei file modificati nelle directory/progetti sul server [Upload changed files in directories / projects to the server] ) nella pubblicazione QA? |
| R: | In realtà nessuno, perché vengono utilizzati i file della copia di lavoro locale. (Se abbia senso non controllare i file locali è un'altra questione). |
| D: | Dove viene salvata la mappatura? |
| R: | In
del file mapping.json. |
| D: | Il file può essere mapping.json da più utenti
allo stesso tempo? |
| R: | Sì, il file non è bloccato. Aggiornare il file locale per mantenerlo il più possibile aggiornato. |
| D: | Come si possono evitare efficacemente i conflitti? |
| R: | Scarica sempre l'ultima versione del
mapping.json file
giù. Le mappature sono sempre migliori al momento del check-in
e fai il check-in in mapping.json .
Ciò dovrebbe garantire che i mapping siano sempre aggiornati
e la pubblicazione è quindi possibile senza problemi. Verificare le modifiche il prima possibile (+ eseguire la mappatura). Se, ad esempio, si deve apportare una modifica di grandi dimensioni, può essere più sensato effettuare questa modifica in diversi piccoli passaggi e verificare le modifiche dopo ogni sottofase (+ creare e verificare la mappatura).
|
