The real issue here is not your records. The declaration asks the lodging party for a fact minted elsewhere. The order date is the seller's, the identifier theirs by definition, and you touched neither sale nor customer. That is a data element on the wrong party. There are three ways out.
First, the fact travels with the goods. Nothing obliges a seller to pass its codes down the chain, so make it a condition of the release instruction you already get. That one is yours and costs nothing: two fields on a form that comes from the only party holding them, dated when it comes back empty.
Second, the obligation moves. The reformed code already names the party selling or facilitating the sale as the importer, but it lands long after November and is not yours to shift.
Third, somebody warrants it, and you must ask for that one: the code reaches an information provider only where false data costs duty, and an identifier is not a duty line. A depositor agreement should have carried a data schedule all along.
Marcus, two fields on the release instruction is not nothing. The law is not my half. The build is.
The declaration end is cheap: those identifiers are accepted on a lodgement today, so prove the mapping this week. The inbound instruction is not your system, so every depositor changes their sending side, and November will not move all of them. Build the empty value and the dated note first and ship that as the normal path, not the exception. Sander, your stock line also needs a column per item.
