Invoice sub-types disscussion

[asim009]

Hey @wes4m, Just want to discuss few things. So, in this repo are we doing only simplified tax invoice? If yes, please suggest me on how we can post below transactions. ● For Tax Invoice, code is 380 and subtype is 01. ex. 380</cbc:InvoiceTypeCode> ● For Simplified Tax Invoice, code is 380 and subtype is 02. ex. 380</cbc:InvoiceTypeCode> ● For tax invoice debit note, code is 383 and subtype is 01. ex. 383</cbc:InvoiceTypeCode> ● For simplified debit note, code is 383 and subtype is 02. ex. 383</cbc:InvoiceTypeCode> ● For tax invoice credit note, code is 381 and subtype is 01. ex. 381</cbc:InvoiceTypeCode> ● For simplified credit note, code is 381 and subtype is 02. ex. 381</cbc:InvoiceTypeCode> ● For self-billed invoice, code is 389 and subtype is 01. ex. 389</cbc:InvoiceTypeCode>

[adriantoro26]

I have also a question, do you know if Zatca has published the Production URL?

[asim009]

No, not yet! They are like not ready with the sandbox and there is a news from sources that this might extend upto 3-4 months.

[wes4m]

@asim009 I did not implement support for all those different types. I hardcoded invoiceTypeCode name to equal 0211010. While the actual code is set based on this enum

export enum ZATCAInvoiceTypes{
    INVOICE="388",
    DEBIT_NOTE="383",
    CREDIT_NOTE="381"
}

For normal invoice I used 388. For a canceled, or refund invoice you set it to either a DEBIT_NOTE, or CREDIT_NOTE through the cancelation prop.

e.g:

// Sample Invoice
const invoice = new ZATCASimplifiedTaxInvoice({
    props: {
        egs_info: egsunit,
        invoice_counter_number: 2,
        invoice_serial_number: "EGS1-886431145-1",
        issue_date: "2022-03-13",
        issue_time: "14:40:40",
        previous_invoice_hash: "NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiNTdlOQ==",
        line_items: [
            line_item,
            line_item,
            line_item
        ],
        cancelation: {
            canceled_invoice_number: 1,
            cancelation_type: ZATCAInvoiceTypes.CREDIT_NOTE,
            payment_method: ZATCAPaymentMethods.CASH,
            reason: "canceled"
        }
    }
});

[asim009]

Isn't there any validation which checks the invoice number before accepting the credit note

 cancelation: {
            canceled_invoice_number: 1,
            cancelation_type: '381',
            payment_method: ""10"",
            reason: "canceled"
        }

I have passed the above object, the value of key canceled_invoice_number which used, I have never created invoice of that. Still Zatca says it is reported!

Response: for the credit note from zatca for which canceled_invoice_number is wrong and never created invoice.

 {
                "validationResults": {
                    "infoMessages": [
                        {
                            "type": "INFO",
                            "code": "XSD_ZATCA_VALID",
                            "category": "XSD validation",
                            "message": "Complied with UBL 2.1 standards in line with ZATCA specifications",
                            "status": "PASS"
                        }
                    ],
                    "warningMessages": [],
                    "errorMessages": [],
                    "status": "PASS"
                },
                "reportingStatus": "REPORTED",
                "clearanceStatus": null,
                "qrSellertStatus": null,
                "qrBuyertStatus": null
            }
}

@wes4m @adriantoro26 Concern about the validations!!

[wes4m]

@asim009 ZATCA backend does not validate canceled invoice number. For now at least.

[asim009]

@wes4m I am facing unique error while reporting the invoice

{
        "infoMessages": [
            {
                "type": "INFO",
                "code": "XSD_ZATCA_VALID",
                "category": "XSD validation",
                "message": "Complied with UBL 2.1 standards in line with ZATCA specifications",
                "status": "PASS"
            }
        ],
        "warningMessages": [],
        "errorMessages": [
            {
                "type": "ERROR",
                "code": "certificate-permissions",
                "category": "CERTIFICATE_ERRORS",
                "message": "Production CSID does not cover Simplified documents",
                "status": "ERROR"
            },
            {
                "type": "ERROR",
                "code": "certificate-permissions",
                "category": "CERTIFICATE_ERRORS",
                "message": "User only allowed to use the vat number that exists in the authentication certificate",
                "status": "ERROR"
            }
        ],
        "status": "ERROR"
    }

is this because of ZATCA sandbox returns a constant fake production certificate??

[adriantoro26]

@wes4m I am facing unique error while reporting the invoice

{
        "infoMessages": [
            {
                "type": "INFO",
                "code": "XSD_ZATCA_VALID",
                "category": "XSD validation",
                "message": "Complied with UBL 2.1 standards in line with ZATCA specifications",
                "status": "PASS"
            }
        ],
        "warningMessages": [],
        "errorMessages": [
            {
                "type": "ERROR",
                "code": "certificate-permissions",
                "category": "CERTIFICATE_ERRORS",
                "message": "Production CSID does not cover Simplified documents",
                "status": "ERROR"
            },
            {
                "type": "ERROR",
                "code": "certificate-permissions",
                "category": "CERTIFICATE_ERRORS",
                "message": "User only allowed to use the vat number that exists in the authentication certificate",
                "status": "ERROR"
            }
        ],
        "status": "ERROR"
    }

is this because of ZATCA sandbox returns a constant fake production certificate??

Yes the first error when reporting an invoice is because of the expired certificated provided by them, but the second error I've had it too, but not sure why I'm getting it. I'm even using real VAT number and taxpayer data, the only thing that is random/fake is the OTP

[asim009]

I tried with both real and sample VAT number. Still can't able to trace out where is the problem. OTP(123345) is standard for sandbox as per my understanding may be I am wrong. @adriantoro26 how about Tax Invoice(Standard) like are you done with it ? I am failing to understand why there is different API'S for B2B and B2C.

[asim009]

@wes4m @adriantoro26 suggest us to implement Clearance API using the same library !!

[asim009]

0211010

what does the above code indicates

[wes4m]

@asim009 I just copied that value from their simplified tax invoice sample. Here is the explanation.

The invoice transaction code (KSA-2) must exist and respect the following structure:
NN (positions 1 and 2) = invoice
NNPNESB
where
subtype:
- 01 for tax invoice
- 02 for simplified tax invoice
P (position 3) = 3rd Party invoice transaction, 0 for false, 1 for true
N (position 4) = Nominal invoice transaction, 0 for false, 1 for true
E (position 5) = Exports invoice transaction, 0 for false, 1 for true
S (position 6) = Summary invoice transaction, 0 for false, 1 for true
B (position 7) = Self billed invoice

For 0211010: 02 = Simplified 1 = Tax invoice 1 = Nominal (I should change this to 0) 0 = Not Export 1 = Is summary 0 = Not Self billed