Module history for Sage X3
Sage X3 fixes
The package did not contain the components of the YB2E5EAD electronic addressing screen extension.
The delivery did not provide all processing associated with this screen's events.
The missing extension components have been added to the Sage X3 V18.1 package.
The package includes the extension required for checks and data refreshes in the electronic addressing screen.
Some older CDAR 212 lines retained an empty status and remained blocked even though their other information allowed recovery.
The existing XML file could not be reused for these lines.
Recovery is permitted only for lines meeting the specified eligibility states, without a remote identifier or HTTP response, and with an existing, readable XML file. It retains the same identity and file; other states remain protected.
Eligible older CDAR 212 lines can be recovered without creating a new identity or re-enabling lines whose transmission has already started or remains uncertain.
The supplier selection list for CDAR addressing was effectively limited to 200 results.
An eligible supplier beyond this limit could not be found in the list.
Selection has been adapted to native Sage X3 pagination. It retains filters for country, environment, activation, electronic address, and issuer or buyer role.
browse eligible suppliers in CDAR addressing selection without a practical limit.
Processing applied unsuitable conversions to line numbers that were already character values.
This incompatibility could cause a Sage X3 error in e-reporting processing.
The relevant conversions have been removed from sales, purchase, payment, and mapping processing. Date conversions remain unchanged.
Line numbers are handled using their original type, without causing the error related to the unsuitable conversion.
The value “Unexpected” could be used as a document identifier during status lookup.
A status call was then launched without a usable remote identifier.
This value is now recognised regardless of case, and lookup stops before any network call. The previously saved identifier and status are preserved.
do not call the middleware when the persisted Unexpected value is not a usable remote identifier.
HTTP transport used in batch mode was not adapted consistently across Sage X3 versions. Purchase retrieval errors could also be reported with a severity unsuitable for scheduled processing.
A call could fail depending on the version or disrupt batch execution without the situation being correctly distinguished from an interactive error.
Transport selection takes version and context into account: Java first for V9/V11 batch mode, native transport for V12 and interactive mode. No fallback is initiated after a Java sending attempt. Error HTTP responses during retrieval are reported as warnings in batch mode, without hiding the failure or triggering a retry.
select HTTP transport according to version and context, and report purchase errors as warnings in batch mode without changing the flow.
An empty, unknown, or malformed environment value could lead to implicit or inconsistent routing between processing routines.
Flows and electronic addresses risked using different environments.
Recognition of Production and Sandbox has been harmonised. Case differences and leading or trailing spaces are normalised; ambiguous values are rejected. Electronic addresses must match one of the two authorised environments.
the same environment parameter produces consistent routing across all Sage X3 processing, or an explicit rejection if ambiguous.
Recovery after an uncertain network result or concurrent execution could restart invoice transmission.
The same invoice risked being transmitted multiple times while the outcome of the first attempt was unknown.
An attempt is now reserved before the network call. An existing send, a remote identifier, or an uncertain outcome blocks retransmission until status reconciliation. If a transaction is still in progress, sending is deferred to the next run.
avoid duplicate sending after a lost network acknowledgement or concurrent recovery, while allowing explicit reconciliation.
Data containing reserved characters could produce invalid XML. Tag and amount inconsistencies also affected the France and Poland templates.
The generated document could be unreadable or rejected during processing.
Variable data and attachment labels are now properly escaped without changing their binary content. The relevant tags and the tax-exclusive amount in the Poland template have been corrected. If escaping fails, the document is not sent.
produce well-formed XML for data containing reserved characters and correct confirmed structural inconsistencies.
Reading the XML file for transmission could truncate content that was large or compacted onto a long line.
The platform could receive an incomplete document, different from the generated file.
Reading now retrieves the entire document, including the last content read at the end of the file, without adding separators. An empty file or read error blocks transmission. The full content is used regardless of HTTP transport.
transmit an entire large or minified XML document without truncation or added separators.
The severity of business-rule rejections was not always determined from the actual execution context on the batch server.
A data rejection affecting one invoice could block scheduled processing instead of being reported while allowing the batch to continue.
Business-rule rejections are now reported as warnings on the batch server and remain errors in interactive mode. Unexpected technical errors retain their error severity.
on the server, a business-rule rejection is logged as a warning and the next invoice is processed; in interactive mode, the same rejection remains a visible error.
A data error on one invoice could disrupt continued processing of subsequent invoices.
The batch did not process other invoices independent of the rejected one normally.
The result and error messages are now isolated for each invoice. A rejected invoice is counted and reported, then processing continues through the batch; an ineligible invoice is skipped. Technical errors remain explicitly reported.
an invalid invoice is counted and logged without preventing subsequent invoices from being processed; an unexpected technical error remains reported at level 1.
Reads performed during XML generation could move the cursors used to iterate through the batch's sites and invoices.
Processing could fail to resume iteration correctly at the next invoice.
Batch iterations are isolated from XML-generation reads, and the current invoice is saved before generation and transmission calls.
Generating a document no longer disrupts iteration through the batch, which can continue processing subsequent invoices.
CDAR 210 XML generation could fail when the output directory or file could not be used.
The document was not produced, and the error did not always identify the obstacle precisely.
Directory preparation, write permissions, file opening, and name collisions are now checked. Each failure returns a distinct reason.
CDAR generation writes its XML to a verified location and returns an actionable error when a directory or file cannot be used.
The status-call log could contain sensitive HTTP data.
Connection information or raw response content could be exposed in the technical log.
Secrets, headers, and raw HTTP bodies are no longer logged. The log retains the information needed to understand the call result without exposing this data.
Status lookup provides an actionable log without disclosing connection secrets or raw HTTP content.
The context used for CDAR 210 connection parameters needed correction to match the recipient's company.
An inconsistent company or site context could cause the wrong parameters to be used for the buyer.
The company is now resolved from the recipient's electronic address, of company or site type, then checked before parameters are loaded. When an invoice is found, its consistency with that company and site is still checked.
CDAR 210 uses the parameters of the company actually associated with the recipient and rejects an inconsistent buyer context.
The legal identifier scheme was not determined appropriately for the partner's geographical area.
E-reporting XML could contain a scheme that did not match the partner's country.
Determination now distinguishes France, other European Union countries, and third countries. If the country or identifier does not allow the scheme to be determined, an explicit error is returned instead of producing an arbitrary value.
the France e-reporting flow emits an identifier scheme consistent with the partner's geographical area.
The cockpit could continue looking for a non-final France CDAR long after Avalara tracking had ended.
Status calls that had become unnecessary were repeated for old transmissions.
When the Avalara status is final, automatic lookup of a non-final France CDAR is limited to 30 calendar days after transmission, including day J-30. Still-active Avalara tracking, Poland KSeF tracking, and manual calls remain unchanged.
the cockpit limits France GetStatus calls that have become unnecessary without interrupting active Avalara tracking or KSeF tracking.
A final Avalara status could stop lookup before the France national CDAR status or Poland KSeF number was available.
The cockpit could retain incomplete national tracking despite subsequent availability of that information.
Lookup continues while the expected national information remains incomplete. This enrichment does not downgrade an Avalara status that is already final.
a final Avalara status no longer prevents subsequent population of the France CDAR or Poland KSeF number.
Parsing large or escaped status responses and selecting the latest national event could leave CDAR or KSeF tracking incomplete or inconsistent.
The cockpit could fail to show the latest usable national state or risk incorrectly changing a final Avalara status.
Response parsing has been made more reliable and retains the latest relevant national event. A French rejection is matched to the corresponding CDAR status, and the KSeF number is saved for Poland. An invalid response does not change the status already stored.
GetStatus populates the latest usable national state while preserving an Avalara status that is already terminal.
A missing CDAR value could appear in the cockpit with a menu label.
Users could interpret that label as a status that had actually been populated.
CDAR cells now remain empty when the value is absent, in all three cockpit grids. CDAR styling is applied only when a status is displayed.
a missing CDAR value in YB2E5V remains visually empty in the cockpit and displays no misleading label.
Resolution of the company whose licence was to be checked needed alignment with the company and site criteria of outbound processing.
An inconsistent combination of criteria could fail to result in checking the expected legal scope.
Processing now resolves the legal company from the entered site or company and rejects any inconsistency between them. When these criteria are absent, each legal company in the selected scope is checked once. The check takes place at submission and execution.
outbound processing validates the licence for the legal scope actually covered by the Sage X3 criteria and rejects inconsistent company/site combinations.
Purchase retrieval could be launched without a sufficiently defined context for determining company-level parameters.
Retrieval parameter loading did not have an explicitly resolved company.
Entering a company or site is now mandatory. The site identifies its legal company, and an inconsistency between the two criteria blocks launch. Parameters are then read for the company determined in this way.
Purchase retrieval uses the parameters of the company explicitly determined by the launch criteria.
Try another term or remove a filter.
