aPriori enables you to export part and assembly cost information from one aPriori database and import it into a different aPriori database. The files used for these imports and exports have .ap extensions. This data-sharing capability enables manufacturers to collaborate with their suppliers and other third parties, such as consultants, who are supporting their design and sourcing activities. This functionality also allows users in a location with a slow connection to the primary database server to work with a local database to improve performance and then transmit the costed components to the primary database.
Functional overview
Access import and export options from the File menu.
-
File >Export > Current Scenario & Children exports the current scenario, (the part, assembly or rollup that you see on your screen) plus any children belonging to that scenario, to the .ap file that you specify.
-
File > Export > Select Scenario(s) displays the search menu which you use to select the part, assembly or rollup (group of parts) that you want to export.
-
File > Import enables you to select the.ap file that you want to import.
Basic workflow for sharing data
The following example explains the workflow between two sites of the same manufacturing company or between a manufacturer and their contract engineering firm. For the purposes of this explanation, it is assumed that the Manufacturer is in the US and the Contract Engineering Firm is in India.
-
An engineer in the US initiates a work order for costing a set of parts. This is typically 10 -50 parts but might be up to 100.
-
An engineer in India executes the work order by costing the parts in aPriori.
-
The engineer saves each part as a new scenario, gives the scenario a unique name, and makes the scenario ‘official’.
-
On a periodic basis, or when the work order is completed, the engineer in India creates a rollup and adds all the scenarios in the work order into the rollup.
-
-
The engineer in India exports the rollup from aPriori to create a file on disk.
-
The exported file is shared and made available to users in the US.
-
A user in the US imports the file using aPriori.
Notes about the workflow
-
The naming convention is determined by the aPriori customer so as it does not overwrite data in the US database if the part already exists there (unless that is the desired behavior). The scenario name must not contain a colon (:).
-
The timing of the export is determined by the aPriori customer. When you add parts to the rollup, parts can be added using criteria such as date range, Digital Factory, or the user ID of the person who last saved the part.
-
There is a practical limit to the number of parts that can be placed in a rollup and exported.
-
The exact number depends on the computer being used and the complexity of the parts in the rollup.
-
On a typical 32-bit workstation, it should handle 100 parts without issues.
-
Use a 64-bit workstation and more memory to increase the number of parts you can place in a rollup.
-
-
The file transfer mechanism works in either direction. For example, users in the US makes changes to a part, export it, and the India user can import it.
Data Integrity: Import existing parts in Database
It is important to understand the behavior when importing a part when that part number already exists in the database.
- When you import a part or group of parts and any of the part number/scenario combinations already exist in the database, the list of parts which do already exist are displayed.
- You can cancel the import or proceed.
- If you cancel, nothing is imported.
-
If you proceed, all of the parts are imported and the ones which already exist are overwritten (regardless if they are locked or unlocked).
-
If part 123456.initial exists in the database and is the only scenario for part number 123456, and 123456.India is imported. Scenario 123456.initial remains and 123456.india is added.
-
If part 123456.initial exists in the database and is the only scenario for part number 123456, and 123456.is imported. Scenario 123456.initial remains and 123456.india is added.
-
If 123456.India was official when it was exported, it becomes the official scenario when it is imported.
Therefore, when a user in India costs a sub-assembly, they must export the .initial scenario so that its cost pulled into the higher-level assembly. If that sub-assembly already exists in the US it is overwritten upon import.