Similarly to the application, a record can also be copied via the REST API. During import, instead of a regular creation, you can create a new record as a copy of an already existing record. This is done using the sourceId attribute, in which you specify the identifier of the record to be copied.
Example
Copying an inventory movement, where we set a different issue date for the newly created record:
<winstrom version="1.0">
<skladovy-pohyb sourceId="1179">
<datVyst>2022-09-11</datVyst>
</skladovy-pohyb>
</winstrom>
The specified attributes (here datVyst) are assigned to the newly created record, while the rest are taken over from the copied record.
You can also copy by code, and the same works in JSON format:
<winstrom version="1.0">
<ucet sourceId="code:132001">
<id>code:132002</id>
<nazev>Zboží na hlavním skladě</nazev>
</ucet>
</winstrom>
{
"winstrom": {
"@version": "1.0",
"faktura-vydana": [{
"@sourceId": "123",
"firma": "code:JINY_ODBERATEL"
}]
}
}
Idempotence
If the identifier of the new record is specified, the call is idempotent. Repeated submission of the request will only result in a regular update of the already existing record.
If the identifier is not specified, or such a record does not yet exist, a copy of the record referenced by the sourceId attribute will be created.
ℹ️ How to recognize this in the response: a copy will return the ID of the new record, whereas calling it again with an already existing <id> will return the ID of the original record — no new copy will be created.
What to Watch Out For
When creating a copy of a record, you usually need to make sure that properties remain unique (e.g., the Code field in code lists), but in some cases this is already ensured automatically (e.g., when copying documents).
A reference to a non-existent
sourceIdwill result in a400error with the codeNOT-FOUND.Before sending the copy for real, verify the result with a test save (
?dry-run=true) — in the<content />tag, you will see what would actually be saved.