connectingeurope / einvoicing-en16931 Goto Github PK
View Code? Open in Web Editor NEWValidation artefacts for the European eInvoicing standard EN 16931
License: Other
Validation artefacts for the European eInvoicing standard EN 16931
License: Other
within CII-DT-018 (validation/cii/schematron/CII/EN16931-CII-syntax.sch) the following typo needs to be corrected: ram:TypCode -> ram:TypeCode
I was just using the Java mapping from /edifact/validator/1INVOIC2ISOXML(JAVA).zip but the output is different than the checked in example file:
Checked in file EDIFACT_EXAMPLE1.xml (line 75)
<G_SG3>
<S_RFF>
<C_C506>
<D_1153>GN</D_1153>
<D_1154>57151520</D_1154>
</C_C506>
</S_RFF>
</G_SG3>
<G_SG3>
<S_RFF>
<C_C506>
<D_1153>VA</D_1153>
<D_1154>NL8200.98.395.B.01</D_1154>
</C_C506>
</S_RFF>
</G_SG3>
After mapping with the Java tool:
<G_SG3/>
<G_SG3/>
Anyone an idea??
The created XML fails XSD validation:
Starting validation against ERROR - [error] @ file:/D:/Entwicklung/git/validation/edifact/validator/../instance/EDIFACT_
EXAMPLE1.xml(76:12) [SAX] cvc-complex-type.2.4.b: Content des Elements 'G_SG3' ist nicht vollstõndig. '{S_RFF}' wird erw
artet. (org.xml.sax.SAXParseException: cvc-complex-type.2.4.b: Content des Elements 'G_SG3' ist nicht vollstõndig. '{S_R
FF}' wird erwartet.)
ERROR - [error] @ file:/D:/Entwicklung/git/validation/edifact/validator/../instance/EDIFACT_EXAMPLE1.xml(77:12) [SAX] cv
c-complex-type.2.4.b: Content des Elements 'G_SG3' ist nicht vollstõndig. '{S_RFF}' wird erwartet. (org.xml.sax.SAXParse
Exception: cvc-complex-type.2.4.b: Content des Elements 'G_SG3' ist nicht vollstõndig. '{S_RFF}' wird erwartet.)
ERROR - [error] @ file:/D:/Entwicklung/git/validation/edifact/validator/../instance/EDIFACT_EXAMPLE1.xml(95:12) [SAX] cv
c-complex-type.2.4.b: Content des Elements 'G_SG5' ist nicht vollstõndig. '{S_CTA}' wird erwartet. (org.xml.sax.SAXParse
Exception: cvc-complex-type.2.4.b: Content des Elements 'G_SG5' ist nicht vollstõndig. '{S_CTA}' wird erwartet.)
XSD validation done!
E.g. the example instance 1 produces the following errors:
[[SVRLResourceError@0x545de5a4: ErrorLevel=FATAL_ERROR; ErrorFieldName=/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[0]; ErrorLocation=[ResourceID=/test-files/cii/instance/CII_example1.xml]; ErrorText=[Text=[BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-96) is “Standard rated” and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119). ]]; test=ram:BasisAmount = (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement[ram:ApplicableTradeTax/ram:CategoryCode = 'S' and ram:RateApplicablePercent=ram:ApplicableTradeTax/ram:RateApplicablePercent]/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount)1010)div 100) + (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator='true' and ram:CategoryTradeTax/ram:CategoryCode='S' and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent]/ram:ActualAmount)1010) div 100) - (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator='false' and ram:CategoryTradeTax/ram:CategoryCode='S' and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent]/ram:ActualAmount)1010) div 100)],
[[SVRLResourceError@0x61526469: ErrorLevel=FATAL_ERROR; ErrorFieldName=/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[1]; ErrorLocation=[ResourceID=/test-files/cii/instance/CII_example1.xml]; ErrorText=[Text=[BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-96) is “Standard rated” and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119). ]]; test=ram:BasisAmount = (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement[ram:ApplicableTradeTax/ram:CategoryCode = 'S' and ram:RateApplicablePercent=ram:ApplicableTradeTax/ram:RateApplicablePercent]/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount)1010)div 100) + (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator='true' and ram:CategoryTradeTax/ram:CategoryCode='S' and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent]/ram:ActualAmount)1010) div 100) - (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator='false' and ram:CategoryTradeTax/ram:CategoryCode='S' and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent]/ram:ActualAmount)1010) div 100)]]]
Both rules have a check "or not(exists(//cac:ClassifiedTaxCategory[normalize-space(cbc:ID) = 'Z']))"/>" this should be cac:TaxCategory, as ClassifiedTaxCategory does not exist in AllowanceCharge
Why does this check fails? the Account ID is there and if I even add a value for the NAD+SE_C088/3434 (=instition branch identifier) as mentioned in the schematron rule it still fails. B ut even if it would not fail, is the check really correct requiring the 3434?
edited sample string: FII+RB+SE1212341234123412+SEXDABCD:::TEST'
[BR-CO-02]-Account identification shall be present if payment means is credit transfer.This is just one example for an invalid check which as I understood still refers back to an issue with the System function current#0 in EDIFACT\EN16931-EDIFACT-model.sch.
Problem:
When currently checking the EDIFACT_Examples as provided in the instance folders, then e.g. in Example 1 I get this issue:
<error xsi:type="BAR">
<description>[BR-10]-An Invoice shall have the Sum of Invoice line net amount.</description>
<location>xml:1210:0</location>
<test>G_SG28/S_MOA/C_C516[D_5025='79']/D_5004</test>
</error>
1.) I get it 6 times - I think 1 would be sufficient?
2.) the amount is there - so why this is an error?
in EDIFACT: MOA+79:229.6
in XML transformation: <G_SG52>
<S_MOA>
<C_C516>
<D_5025>79</D_5025>
<D_5004>229.6</D_5004>
</C_C516>
</S_MOA>
</G_SG52>
@AndreasPvd please have a look at the following: the example files use e.g. the namespace URL urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100
whereas CII D16B uses to my understanding the namespace URL urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:20
.
Can you please clarify what to use here. Thx.
The rule BR-CO-09 is stating:
"The Seller VAT identifier, Seller tax representative VAT identifier, Buyer VAT identifier shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’. "
However, the validation rule is checking that the prefix is the same as country code for the party, I am not sure that will allways be the case. Suggest to change validation to check only that the prefix is from ISO 3166-1 alpha-2
BR-CO-25 is not firing when Payable amount is negative
I cannot see that the validations done on these rules in any way is checking for what the rules are stating, so my suggestion is to remove these rules. I do not see a need for validation rules, where we cannot validate the "intention" of the corresponding business rule.
Instance files created for ISO 20022 does not comply to scheme as there is something wrong in the instance files. This should be fixed.
Currently none of the existing codes of the UNTDID 1001 code list will be accepted. It seems that the correction which has been done in UBL regarding the document type code needs also to be done for the CII validation artefacts.
I tried to fill the PAI_4461 with several codes (53,58,60), but still get this error. How does this check work?
e.g.: PAI+::53'
Several of the VAT rules are having the following check:
[cac:TaxCategoryCode/cbc:ID='XX']
The element TaxCategoryCode is not existing in the mapping, please check all rules and change all to [cac:TaxCategory/cbc:ID='XX']
BR-CL-13 fires when valid value is used. Codelist check does not seem complete according to latest version of UNCL 4465. Values 98-104 seems missing, in addition to ZZZ
Short question:
Shouldn't the code list checks for BR-CL-17 and BR-CL-18 not also contain e.g. "AA" and "S" according to https://www.unece.org/fileadmin/DAM/trade/untdid/d16b/tred/tred5305.htm ??
Thanks,
Philip
The same error as in OpenPEPPOL/peppol-bis#38 also applies to the UBL Schematrons in here.
Just add <ns prefix="xs" uri="http://www.w3.org/2001/XMLSchema"/>
in the overall XSD to fix the issue.
Rules in CII Schematron are for my understanding not correct. With respect to the EN 16931-1 an INVOICE NOTE group might occure 0..n times.
The following structure (attached you will find a complete document) seems to me conform to the syntax binding but leads to a warning during validation ([CII-SR-029] - IncludedNote should exist maximum once):
<rsm:ExchangedDocument>
<ram:ID>123456</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
<ram:IssueDateTime>
<udt:DateTimeString format="102">20160621</udt:DateTimeString>
</ram:IssueDateTime>
<ram:IncludedNote>
<ram:Content>Bei Fragen zu Ihrer Rechnung wenden Sie sich bitte an unseren Kundenserivce. Sie erreichen uns per Email: […], Tel.: […] oder Fax: […]</ram:Content>
<ram:SubjectCode>ADU</ram:SubjectCode>
</ram:IncludedNote>
<ram:IncludedNote>
<ram:Content>Die Lieferung erfolgt aufgrund der AGB […] erhältlich unter […]. Auf Wunsch senden wir sie auch zu.</ram:Content>
<ram:SubjectCode>ADU</ram:SubjectCode>
</ram:IncludedNote>
<ram:IncludedNote>
<ram:Content>Hinweis gemäß § 33 BDSG: Kundendaten werden gespeichert.</ram:Content>
<ram:SubjectCode>ADU</ram:SubjectCode>
</ram:IncludedNote>
<ram:IncludedNote>
<ram:Content>Beschädigt eingehende Sendungen bitte sofort beim Spediteur bzw. Paketdienstleister reklamieren. Genehmigte Rücksendungen schicken Sie bitte mit den Unterlagen an: […]</ram:Content>
<ram:SubjectCode>ADU</ram:SubjectCode>
</ram:IncludedNote>
</rsm:ExchangedDocument>
It seem that the test for CL-01 is wrong. I used the rule via the kosit-validator and it said that the type code 380 (commercial invoice) ist wrong. But this is an allowed value for an invoice.
It seems that the test
test="((not(contains(normalize-space(.), ' 80 ... 935 ')) and contains(' ', concat(' ', normalize-space(.), ' '))))"
should be
test="((not(contains(normalize-space(.), ' ')) and contains(' 80 ... 935 ', concat(' ', normalize-space(.), ' '))))"
as the other tests, e.g. for CL-03 or CL-04.
Rule does not trigger when Actual delivery date or delivery period is blank
For rule BR-S-08, if there is a line with VAT rate = 25.0, the rule fires when TaxCategory says 25.
The rule should not fire just because the number of decimals is not equal, as the value 25.0 is the same as 25 and 25.00
Please see unit test BR-S-08-1, test no 2, which is not expected to fire, but it does.
I hope I'm not stupid but I looked several times on in the message to find the issue but couldn't find it.
There is just one net amount on line item and should be same as on total level (both 100).
What am I doing wrong? Why I do get:
<failed-assert id="BR-CO-10" location="/M_INVOIC[1]" test="G_SG52/S_MOA/C_C516[D_5025='79']/D_5004 = (round(sum(/M_INVOIC/G_SG27/G_SG28/S_MOA/C_C516[D_5025='203']/D_5004) * 10 * 10)div 100)" flag="fatal">
<text>[BR-CO-10]-Sum of Invoice line net amount =
Σ Invoice line net amount. </text>
</failed-assert>
message:
UNA:+.?*'
UNB+UNOW:4::7+4000001000005:14+4000001000005:14+20150109:1403+87846595'
UNH+1234+INVOIC:D:96A:UN:EAN008'
BGM+380+645643837+9'
DTM+137:20160712:102'
DTM+35:20161012:102'
ALI+++11'
RFF+AAU:2233'
DTM+171:20161011:102'
RFF+ON:4455'
DTM+171:20160610:102'
RFF+VN:8877'
DTM+171:20160712:102'
NAD+BY+5790000000005::9'
RFF+XA:DK10629845'
NAD+DP+5790002330278::9'
RFF+XA:DK23876588'
NAD+SU+5790000000012::9'
RFF+XA:DK10687672'
NAD+IV+5790002330322::9'
RFF+XA:DK98767890'
TAX+7+VAT+++:::25+S'
CUX+2:DKK:4'
PAT+3'
DTM+13:20161112:102'
ALC+C++++ADR'
MOA+8:20'
LIN+1++5776565423456:EN::'
QTY+47:50:KGM'
QTY+46:51:KGM'
QTY+192:1:KGM'
MOA+203:100'
PRI+AAA:20:::10:KGM'
TAX+7+VAT+3010::9DK++:::25+S'
MOA+124:25'
TAX+7+VAT+3010::9DK++:::25+S'
MOA+125:100'
UNS+S'
CNT+2:1'
MOA+79:100'
MOA+86:275'
MOA+125:220'
MOA+131:20'
MOA+176:55'
TAX+7+VAT+3031::9DK++:::25+S'
MOA+124:55'
MOA+125:220'
UNT+49+1234'
UNZ+1+12115118'
The rule states
An Invoice that contains a line, a document level allowance or a document level charge where the Invoiced item VAT category code (BT-151, BT-95 or BT-102) is “Reverse charge” shall contain in the VAT breakdown (BG-23) exactly one VAT category code (BT-118) equal with "Reverse charge".
It does not seem that the validation checks for only one instance in TaxTotal/TaxSubtotal/TaxCategory.
The Business rule error text is misleading because there is an invoice currency, but CUX:3:EUR:18 might be expected and is missing
cen_edifact.EDIFACT_EXAMPLE1.report.xml
</G_SG2> <G_SG7><S_CUX><C_C504>
<D_6347>2</D_6347> <D_6345>EUR</D_6345>
</C_C504>
</S_CUX>
</G_SG7> <G_SG8>
[BR-05]-An Invoice shall have an Invoice currency code.
xml:2:0
G_SG7/S_CUX/C_C504[D_6347='3' and D_6343='18']/D_6345
e.g. Something like….Shall be used in combination with the Total VAT amount in accounting currency when the VAT accounting currency code differs from the Invoice currency code.
The following rules has a context targeting an attribute:
Those rules will not trigger when implementers use the official ISO Schematron stylesheets to generate the XSLT version.
In validation/ubl/schematron/UBL/EN16931-UBL-model.sch there are BR-O-02, BR-O-03, BR-O-04 which forbid the usage of Seller VAT ID or Seller tax representative VAT ID or Buyer VAT ID according to the rules defined in EN 16931-1:2017
"BR-O-2 “An Invoice that contains a line where the Invoiced item VAT category code (BT-151) is “Not subject to VAT” shall not contain the Seller's VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer's VAT identifier (BT-46)”.
Wondering why "shall not". "could not" probably is more appropriate.
This is not an issue of the schematron code. It is just to remember that a discussion about this topic could take place.
Rule BR-S-03 and S-04 are checking if PartyLegalEntity/companyID is existing. But this should not be checked, as the rule is stating that VAT identifier(BT-31), Tax identifier (BT-32) or TaxRepresentative VAT identifier (BT-63) is present. No check against the legal entity should be done
What is wrong here? The VAT rate seems to be greater then zero (=21). Sample string: TAX+7+VAT+++:::21+S'
<fired-rule context="/M_INVOIC/G_SG27[G_SG35/S_TAX/D_5305 = 'S']"/>
<failed-assert id="BR-S-05" location="/M_INVOIC/G_SG27[0]" test="C_C243/D_5278 > 0" flag="fatal">
<text>[BR-S-05]-In an Invoice line where the Invoice
item VAT category code (BT-151) is "Standard rated" the Invoiced item VAT rate (BT-152) shall
be greater than 0 (zero). </text>
</failed-assert>
Hello,
we have found typo in mimeCode list:
<rule context="@mimeCode" flag="fatal"> <assert test="((. = 'application/pdf' or . = 'image/png' or . = 'image/jpeg' or . = 'text/csv' or . = 'application/vnd.openxmlformats-officedocument. spreadsheetml.sheet' or . = 'application/vnd.oasis.opendocument.spreadsheet'))" id="BR-CL-24" flag="fatal">[BR-CL-24]-For Mime code in attribute use MIMEMediaType.</assert> </rule>
There is an extra space in "application/vnd.openxmlformats-officedocument. spreadsheetml.sheet"
Small one, but needs correction
BR
In validation/ubl/schematron/codelist/EN16931-UBL-codes.sch:
[BR-CL-06]-Value added tax point date code MUST be coded using a restriction of UNTDID 2475.Why UNTDID 2475? The EN 16931-1:2017 for BT-8 refers to UNTDID 2005 (probably values could be Invoice document issue date –“3”, Delivery date, actual -“35”, Paid to date – “432”)
For each technical rule an ID is required. Within the EN16931-CII-codes.sch the IDs (/pattern/rule/assert/@id) is missing.
Extend XML Validator with commandline flag to support a pre-compiled XSLT instead.
Rule BR-E-10 is not existing in updated EN. Please remove rule from validation artefacts
Rule does not trigger when deliver to country code is blank/empty element
According to EN 16931-1 BT-18=Invoiced object identifier (An identifier for an object on which the invoice is based, given by the Seller). It may be a subscription number, telephone number, meter point, vehicle, person etc., as applicable.
0..1 Scheme identifier =The identification scheme identifier of the Invoiced object identifierIf it may be not clear for the receiver what scheme is used for the identifier, a conditional scheme identifier should be used that shall be chosen from the UNTDID 1153 code list entries.
How BT-18 is mapped to UBL and which business rules should it respect?
In the EN it is stated that the VAT rate for IGIC and IPSI VAT should be zero or greater than zero. The validation rules for BR-IG-05, 06 and 07 (and the same for corresponding BR-IP rules) only allowes values greater than zero.
Please correct rule to ensure zero values are allowed as VAT rate for these categories.
The final check in these two rules are
or not(exists(//cac:ClassifiedTaxCategory[cbc:ID = 'AE']))
This should be changed to
or not (exists(//cac:AllowanceCharge[cbc:ChargeIndicator='false']/cac:TaxCategory[cbc:ID = 'AE']))
The example files have errors (and I will fix them - just for documentation):
37/302/30168
with DE37/302/30168
<ram:InvoiceCurrencyCode></ram:InvoiceCurrencyCode>
to <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
19
and sometimes as 19.00
which is considered different by the rules. Unifying all to 19.00
<ram:ActualAmount>0.0000</ram:ActualAmount>
to <ram:ActualAmount>0.00</ram:ActualAmount>
<ram:RateApplicablePercent>0.00</ram:RateApplicablePercent>
to <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
<ram:DuePayableAmount>11.90</ram:DuePayableAmount>
<ram:AllowanceTotalAmount>0.00</ram:AllowanceTotalAmount>
currencyID=""
to currencyID="EUR"
sum (...)
we need to use round (sum (...) * 10 * 10) div 100
to ensure exactly 2 decimal digits are present. (see commit below)123456789MVA
with NO123456789MVA
987654321MVA
with NO987654321MVA
967611265MVA
with NO967611265MVA
schemeID="email"
schemeID="email"
<ram:TypeCode>...</ram:TypeCode>
123456789MVA
with DK123456789MVA
O
(which means "services outside of tax") but the rules refer to and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent
- removing the dependence to the applicable percentage solves the issueThe rule for BR-CL-12 should be rewritten I think. As the valid values have / in them, I think they must all be individually wrapped in ''. Example: .='text/csv' or .= 'application/pdf'
Rules are raised if the number of decimals is not the same (example 25.0 and 25.00). Please align these rules with the check done in BR-S-08.
rule BR-O-02 does not fire when expected, assume it is due to the "..or (not(//cac:AccountingCustomerParty...), should be "and" and not "or" I think
The validation rule for BR-CO-15 does not handle the TaxCurrency and DocumentCurrency correctly. Now there is a check if the count of TaxTotal is >1, it uses TaxAmount where @currencyID = EUR.
This will not allways be the case, the check should look for the value in DocumentCurrencyCode, and use the TaxTotal where @currencyID = DocumentCurrencyCode.
I added new unit test for this BR-CO-15-2
According to the latest UN/CEFACT 5305 codelist the correct VAT category codes should be
L = Canary Island Tax
M = Ceuta and Manilla Tax
http://www.unece.org/fileadmin/DAM/trade/untdid/d16b/tred/tred5305.htm
Please correct validation in all BR-IG and BR-IP rules to check for these two values.
According to EN 16931-1 BT-21=Invoice note subject code (The subject of the textual note in BT-22)->
To be chosen from the entries in UNTDID 4451
How is this field mapped to UBL? Is the following example correct?
BT-21 -> <cbc:Note>#AAA#</cbc:Note>
where AAA= Goods item description in UNTDID 4451
It looks like BR-CL-19 is the business rule related to BT-21 but in EN16931-UBL-codes.sch it refers to Code allowance reason and in UBL\EN16931-UBL-model.sch it contains numbers instead of the 3 chars of UNTDID 4451.
Could you please have a check?
Rule BR-CO-17 triggers if TaxableAmount is negative, and tax percent = 0 (zero).
Example file 2 has this issue, and also updated unit test BR-CO-17 to include the same example.
Please correct validation to handle negative numbers multiplied by zero.
In the EN16931-UBL-codes.sch the check to find valid codes is using the normalize-space function. However, when we for the VAT rules perform checks/calculations based on a VAT category, there is no normalize-space function.
This results in that a file with
<cbc:ID> S</cbc:ID>
Will not be handled as standard rate "S". Example in most of the VAT rules (BR-S-09 as one example). Similar issues for PaymentMeans in rule BR-61 and there might be more.
In UBL validation there are [UBL-DT-01]-Amounts shall be decimal up to two fraction digits which raise the error when using more then 2 decimals on Item price discount (BT-147) and Item gross price (BT-148):
<cac:Price>
<cbc:PriceAmount currencyID="HRK">0.1212</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="EA">1</cbc:BaseQuantity>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
[UBL-DT-01]-Amounts shall be decimal up to two fraction digits
<cbc:Amount currencyID="HRK">0.0022</cbc:Amount>
[UBL-DT-01]-Amounts shall be decimal up to two fraction digits
<cbc:BaseAmount currencyID="HRK">0.1234</cbc:BaseAmount>
</cac:AllowanceCharge>
</cac:Price>
According to the EN 16931-1 Semantic data model document, p. 93-94, Table 26 - Allowed number of decimals, there is no restriction on maximum allowed number of decimals for Item net price (BT-146), Item price discount (BT-147) and Item gross price (BT-148). However, in the same table, Invoice line net amount (BT-131), Invoice line allowance amount (BT-136) and base amount (BT-137), Invoice line charge amount (BT-141) and base amount (BT-142) are restricted to two decimal digits which is all right. Item net price can be more than 2 digits, but gross price and discount amount cannot.
The dilemma is if this is a validation issue or way of rounding Item prices and discounts.
In the UBL rule BR-S-02 the TaxScheme ID is verified to be "VA", while it has always been "VAT"
Is it a typo or is it correct? Because now our nvoices with cac:TaxScheme/cbc:ID = 'VAT' are failing validation.
<param name="BR-S-02" value="(exists(//cac:ClassifiedTaxCategory[normalize-space(cbc:ID) = 'S']) and (exists(//cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = ('VA', 'FC')]/cbc:CompanyID) or exists(//cac:TaxRepresentativeParty/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = 'VA']/cbc:CompanyID))) or not(exists(//cac:ClassifiedTaxCategory[normalize-space(cbc:ID) = 'S']))"/>
BR-61 does not fire when Payment means code is 30 or 57, and PayeeFinancialAccount/ID is missing. See unit test BR-61
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.