...
In InforLN, Sales Credit Notes follow the same logic as per Sales Invoices. The only difference is the minus sign on the amounts that the Connector then ignores when transferring the Credit Note to Xero (Xero automatically assigns the negative amount thanks to the fact that the entity is a Credit Note).
Xero Voiding a Sales Invoice exists but not in InforLN
In Xero there is "InvoiceNumber = INV-00049" but in Infor this does not exist.
By Design, the Connector does not send back Sales Invoices to InforLN. InforLN is the source of truth of the Sales Invoices, all the Sales Invoices should be created in there. This does not give any problem in terms of Invoice synchronisation, but it will in terms of Payments: indeed the Connector is designed to collect all the recently-changed payments in Xero and trying to sync them back to InforLN. In this case InforLN will fail, raising an exception in the Stellarise Connector Audit Table.
Purchase Invoices (InforLN to Xero) and Credit Notes
Purchase Invoices from InforLN to Xero use cases can be mostly covered by the test cases for the Sales Invoices, since they share moslty the same communication logic. The following use cases In addition to the :
InforLN Purchase Invoice: "source" field different from empty
In InforLN, there are some purchase invoices modified in a given period of time. Some of them are legitimate and some aren't because they were created by Stellarise Connector in the previous run.
When Stellarise Connector runs the next time, it must discard the ones that it has previously generated. To do this, the InforLN API provides an extra "Source" field, reporting the origin of the invoice. If it is empty, then InforLN the Sales Invoice "303-SI1-20001" needs to be removed because it's wrong.
This is a manual activity. After having removed the Sales Invoice from InforLN and its potentially related Payment, the end user needs to search in Xero for the invoice "303-SI1-20001" and remove it. In Xero, the "removal" on approved invoices is a virtual action called VOID: meaning that behind the scenes, the Voided invoice will always be archived somewhere, it is just not counted in the financial reports. In Xero, like in InforLN, in order to Void a paid invoice the User needs to remove the payment against the invoice first.
Xero Sales Invoice exists but not in InforLN
In Xero there is "InvoiceNumber = INV-00049" but in Infor this does not exist.
By Design, the Connector does not send back Sales Invoices to InforLN. InforLN is the source of truth of the Sales Invoices, all the Sales Invoices should be created in there. This does not give any problem in terms of Invoice synchronisation, but it will in terms of Payments: indeed the Connector is designed to collect all the recently-changed payments in Xero and trying to sync them back to InforLN. In this case InforLN will fail, raising an exception in the Stellarise Connector Audit Table.
Purchase Invoices (InforLN to Xero) and Credit Notes
Purchase Invoices from InforLN to Xero use cases can be mostly covered by the test cases for the Sales Invoices, since they share moslty the same communication logic. The following use cases In addition to the :
InforLN Purchase Invoice: "source" field different from empty
In InforLN, there are some purchase invoices modified in a given period of time. Some of them are legitimate and some aren't because they were created by Stellarise Connector in the previous run.
When Stellarise Connector runs the next time, it must discard the ones that it has previously generated. To do this, the InforLN API provides an extra "Source" field, reporting the origin of the invoice. If it is empty, then it has been originated by InfoLN so it can be sent to Xero, otherwise the invoice is simply ignored.
...
In InforLN, Purchase Credit Notes follow the same logic as per Purchase Invoices. The only difference is the minus sign on the amounts that the Connector then ignores when transferring the Credit Note to Xero (Xero automatically assigns the negative amount thanks to the fact that the entity is a Credit Note).
Service Purchase Invoices (Xero to InforLN) and Credit Notes
The use case Xero Purchase Invoice Collection: InvoiceNumber format check can be reused for Service Purchase Invoices from InforLN to Xero. In addition:
Xero Purchase Invoice addressed to a Xero Contact that has a related InforLN Business Partner HAVING Supplier role
This Invoice "2020 JAN electricity" was manually generated in Xero through Receipt Bank, it does not exists in InforLN. Its Contact is set to a Xero Contact called "EDF Energy group".
The connector picks the Xero Bill "2020 JAN electricity" up and analyses if the Contact "EDF Energy group" has the InforLN Business Partner Code attached to it. There is, its "30000024", this means "EDF Energy group" is considered as a recurring supplier by Desgn. Once this invoice is sent back to InforLN, it is then created as Purchase Invoice assigned to the Business Partner "30000024".
Xero Purchase Invoice addressed to a Xero Contact that has a related InforLN Business Partner NOT HAVING Supplier role
This Invoice "2020 Feb Voiding a Purchase Invoice
In InforLN the Purchase Invoice "abcd-303-PI1-30001" needs to be removed because it's wrong.
This is a manual activity. After having removed the Purchase Invoice from InforLN and its potentially related Payment, the end user needs to search in Xero for the invoice "abcd-303-PI1-20001" and remove it. In Xero, the "removal" on approved invoices is a virtual action called VOID: meaning that behind the scenes, the Voided invoice will always be archived somewhere, it is just not counted in the financial reports. In Xero, like in InforLN, in order to Void a paid invoice the User needs to remove the payment against the invoice first. ASK MARCELLO
Service Purchase Invoices (Xero to InforLN) and Credit Notes
The use case Xero Purchase Invoice Collection: InvoiceNumber format check can be reused for Service Purchase Invoices from InforLN to Xero. In addition:
Xero Purchase Invoice addressed to a Xero Contact that has a related InforLN Business Partner HAVING Supplier role
This Invoice "2020 JAN electricity" was manually generated in Xero through Receipt Bank, it does not exists in InforLN. Its Contact is set to a Xero Contact called "Enel EDF Energy group". "Enel Energy group" does exist in InforLN, but it is only tagged as Customer, not as Supplier.
The connector picks the Xero Bill "2020 Feb JAN electricity" up and analyses if the Contact "Enel EDF Energy group" has the InforLN Business Partner Code attached to it. There is, its "3000002530000024", this means "Enel EDF Energy group" should be is considered as a recurring supplier by DesignDesgn. Once this invoice is sent back to InforLN, it is then created as Purchase Invoice and... ASK MARCELLO
Xero Purchase Credit Notes
The Purchase Credit Note "CN-0002assigned to the Business Partner "30000024".
Xero Purchase Invoice addressed to a Xero Contact that has a related InforLN Business Partner NOT HAVING Supplier role
This Invoice "2020 Feb electricity" was manually generated in Xero through Receipt Bank, it does not exists in InforLN. Its Contact is set to "ABC Customer ltd", existing in InforLN as Business Partnera Xero Contact called "Enel Energy group". "Enel Energy group" does exist in InforLN, but it is only tagged as Customer, not as Supplier.
The connector picks this Credit Note up and tries to transfer it to InforLN. "ABC Customer ltd" is correctly found as Business Partner; this credit note will then be created as a Purchase Invoice against the "ABC Customer ltd" .
Other Purchase Invoices (Xero to InforLN) and Credit Notes
Xero Purchase Invoice Collection: InvoiceNumber format check
In Xero there is a Bill (Purchase Invoice) named "INV-001". This Invoice was manually generated in Xero through Receipt Bank, it does not exists in InforLN.
The connector picks it up, analyses it and realises that its Invoice Name is not in the InforLN format (e.g. "303-PI1-123456789"), so it will process it as an Other or Service purchase invoice.
Xero Purchase Invoice addressed to Xero Contact not having a related InforLN Business Partner
This Invoice "2020-07 Expenses" was manually generated in Xero, it does not exists in InforLN. Its Contact is set to a fictional Xero Contact called "Mario Rossi expenses"the Xero Bill "2020 Feb electricity" up and analyses if the Contact "Enel Energy group" has the InforLN Business Partner Code attached to it. There is, its "30000025", this means "Enel Energy group" should be considered as a recurring supplier by Design.
The Invoice is then sent back to InforLN, but this will answer with a meaningful Exception in the Audit Table.
Xero Purchase Credit Notes
The Purchase Credit Note "CN-0002" was manually generated in Xero, it does not exists in InforLN. Its Contact is set to "ABC Customer ltd", existing in InforLN as Business Partner.
The connector picks this Credit Note up and tries to transfer it to InforLN. "ABC Customer ltd" is correctly found as Business Partner; this credit note will then be created as a Purchase Invoice against the "ABC Customer ltd" .
Voiding a Purchase Invoice
This is a manual activity. After having removed the Purchase Invoice from Xero and its potentially related Payment, the end user needs to search and manually remove in InforLN. ASK MARCELLO
Other Purchase Invoices (Xero to InforLN) and Credit Notes
Xero Purchase Invoice Collection: InvoiceNumber format check
In Xero there is a Bill (Purchase Invoice) named "INV-001". This Invoice was manually generated in Xero through Receipt Bank, it does not exists in InforLN.
The connector picks it up and analyses if the Contact "Mario Rossi expenses" has the InforLN Business Partner Code attached to it. It does not, this means "Mario Rossi expenses" is considered as a non-recurring supplier. Once this invoice is sent back to InforLN, it is then created as an Expense Item, reporting "Mario Rossi expenses" as a reference.
Xero Purchase Credit Notes
The Purchase Credit Note "CN-0001, analyses it and realises that its Invoice Name is not in the InforLN format (e.g. "303-PI1-123456789"), so it will process it as an Other or Service purchase invoice.
Xero Purchase Invoice addressed to Xero Contact not having a related InforLN Business Partner
This Invoice "2020-07 Expenses" was manually generated in Xero, it does not exists in InforLN. Its Contact is set to a fictional Xero Contact called "Mario Rossi expenses".
The connector picks this up and tries to transfer it to InforLN. Since in InforLN there is no Business Partner called it up and analyses if the Contact "Mario Rossi expenses" , this credit note will be has the InforLN Business Partner Code attached to it. It does not, this means "Mario Rossi expenses" is considered as a non-recurring supplier. Once this invoice is sent back to InforLN, it is then created as an "Expense Record" with a negative sign, related to the Expense Item, reporting "Mario Rossi expenses" employee
Payments
| Info |
|---|
During the description of the following use cases:
|
Xero Payment received from Client
There is a straight Xero Payment having ID 1234-1234-1234-1234 against a Sales invoice, the related Customer exists in InforLN and the amount IS NOT related to any pre-payment.
The connector picks the Xero Payment "1234-1234-1234-1234" up and checks for the Customer InforLN Code. When this preliminary check is done, then the connector sends the payment to InforLN.
Particularly, paying attention to the following field:
...
as a reference.
Xero Purchase Credit Notes
The Purchase Credit Note "CN-0001" was manually generated in Xero, it does not exists in InforLN. Its Contact is set to a fictional Xero Contact called "Mario Rossi expenses".
The connector picks this up and tries to transfer it to InforLN. Since in InforLN there is no Business Partner called "Mario Rossi expenses", this credit note will be created as an "Expense Record" with a negative sign, related to the "Mario Rossi" employee
Voiding a Purchase Invoice
This is a manual activity. After having removed the Purchase Invoice from Xero and its potentially related Payment, the end user needs to search and manually remove in InforLN. ASK MARCELLO
Payments
| Info |
|---|
During the description of the following use cases:
|
Xero Payment received from Client
There is a straight Xero Payment having ID 1234-1234-1234-1234 against a Sales invoice, the related Customer exists in InforLN and the amount IS NOT related to any pre-payment.
The connector picks the Xero Payment "1234-1234-1234-1234" up and checks for the Customer InforLN Code. When this preliminary check is done, then the connector sends the payment to InforLN.
Particularly, paying attention to the following field:
DocumentType: 1, In InforLN means "Allocated Sales Payment"
BusinessPartner: 300000366, InforLN customer code to allocate the payment against.
InvoiceNumber: 303-SI1-1234567890, the Invoice to allocate the payment against.
XeroPaymentID: 1234-1234-1234-1234, The unique identifier of the Payment ID.
XeroPprepaymentID: "", no Prepayment are defined.
XeroContactName: "ABC Customer ltd", the String name of the Customer
...
DocumentType: 2, In InforLN means "Allocated Purchase Payment"
BusinessPartner: "", no InforLN Business Partner specified, this means that in InforLN this payment will be recorded as an "Expense Record".
InvoiceNumber: abcdefg-303-PI1-1234567890, the Invoice to allocate the payment against.
XeroPaymentID: 6453-6453-6453-6453, The unique identifier of the Payment ID.
XeroPprepaymentID: "", the Prepayment ID is always empty for Purchase Payments related to Non-recurring-Suppliers.
XeroContactName: "Federico Rossi Expenses", the String name of the non-recurring Supplier
...
the non-recurring SupplierWhat to expect in InforLN: regardless the fact that DocumentType == 2 means "Allocated Purchase Payment" in InforLN, the simple fact that the BusinessPartner is empty will be interpreted by InforLN as a simple "Expense Record" rather then a real Payment.
Xero Payment to remove
In Xero there is a payment that needs to be removed.
This is a manual action that needs intervention on both Xero and InforLN. When removing a payment from Xero, the end user also needs to go in InforLN and remove the same payment from there - in InforLN "Payment" is called Bank Transaction having type 1 or 2. ASK MARCELLO
Prepayments
Xero Prepayment received from Client
...
The connector picks the Xero Prepayment "0003-0003-0003-0003" up and tries to extract the Supplier InforLN Code. The Connector does not find it, so it will block itself immediately, creating a warning message in the Audit Table, reporting the suggestion to manually deal with this case.up and tries to extract the Supplier InforLN Code. The Connector does not find it, so it will block itself immediately, creating a warning message in the Audit Table, reporting the suggestion to manually deal with this case.
Xero Prepayment to remove
In Xero there is a Prepayment that needs to be removed.
This is a manual action that needs intervention on both Xero and InforLN. When removing a Prepayment from Xero, the end user also needs to go in InforLN and remove the same Prepayment from there - in InforLN "Prepayment" is called Bank Transaction having type 3 or 4. ASK MARCELLO