To have an overview of what Stellarise Connector for InforLN and Xero does, this is a list of the different use cases that may happen during the integration process and the description of the expected outcome.
Contacts
InforLN Contact does not exist in Xero - Xero Name does not exist, Xero Contact Number does not exist
In Infor LN there is "Foreign Customèr S.R.L" having Business Partner ID set to "30000010" but in Xero this does not exist.
After the connector has searched in Xero for the "Contact Number = 30000010" and the "(small case, numbers and letters only , ignoring accents)Name = foreigncustomersrl", the Connector then creates "Foreign Customèr S.R.L" in Xero, having Contact Number set to 30000010 and all the InforLN information described by Design.
InforLN Contact does partially exist in Xero - Xero Name does exist, Xero Contact Number does not exist
In InforLN there is "Foreign Customèr S.R.L" having Business Partner ID set to "30000010" and in Xero you have "foreign customer s.r.l" but without Contact Number.
After the connector has searched and found in Xero the "(small case, numbers and letters only , ignoring accents)Name = foreigncustomersrl", the Connector then updates the existing Xero Contact reporting all the InforLN information described by Design and assigning the Xero Contact Number to "30000010".
InforLN Contact already exists in Xero and they are both the same
In InforLN there is "Foreign Customèr S.R.L" having Business Partner ID set to "30000010" and in Xero you have the same.
The Connector realises the match by ContactNumber or Name and checks for differences (e.g. tax number, bank account, primary contact, address, etc.): both Infor and Xero give the same checksum, the Connector does nothing and moves on.
InforLN Contact already exists in Xero and they differ for one or more details
In InforLN there is "Foreign Customèr S.R.L" having Business Partner ID set to "30000010" and Tax Number "1234567890". In Xero you have the same but the Tax Number is "0987654321".
The Connector realises the match by ContactNumber or Name and checks for differences (e.g. tax number, bank account, primary contact, address, etc.): Infor and Xero differ. The Connector updates the Xero Contact updating its information with the details reported in Infor.
Sales Invoices and Credit Notes
InforLN Sales invoice serie "2xxx" but does not exist in Xero.
In InforLN there is an invoice having Invoice Name "303-SI1-2000001" but in Xero there is not such invoice.
Stellarise Connector does not find the Xero invoice by "InvoiceNumber = 303-SI1-2000001" so it creates it with "InvoiceNumber = 303-SI1-2000001" and all the InforLN information defined by Design.
InforLN Sales invoice serie "2xxx" and it does exist in Xero.
In InforLN there is an invoice having Invoice Name "303-SI1-2000001" and in Xero it exists as well.
Stellarise Connector finds the Xero invoice by "InvoiceNumber = 303-SI1-2000001" so it goes into Xero and to update it with the InforLN information defined by Design.
InforLN Sales invoice serie "4xxx" (from prepaid orders)
In InforLN there is an invoice having Invoice Name "303-SI1-4000001" and in Xero it may exist or not.
In Xero there is not such distiction between a normal invoice or a LineaLight invoice from pro-forma order. The invoice will be created following the serie "2xxx" logic.
InforLN Sales invoice single line
In InforLN there is an invoice having Invoice Name "303-SI1-2000003" having one invoice line that has a ledger code and a tax rate correctly mapped in the Stellarise Connector settings.
Stellarise Connector creates or updates the Xero invoice by "InvoiceNumber = 303-SI1-2000003". It will only have one invoice line, having unit price, discount, tax amount and total amount matching with the InforLN invoice. Invoice Line Description just reports "RTF" if the InforLN Invoice "RelatedPurchaseInvoice" field is empty, the content of the InforLN Invoice "RelatedPurchaseInvoice" field if it is assigned and if the invoice is not paid or partially paid.
InforLN Sales invoice multiple lines
In InforLN there is an invoice having Invoice Name "303-SI1-2000004" having multiple invoice lines that have a ledger code and a tax rate correctly mapped in the Stellarise Connector settings.
Stellarise Connector creates or updates the Xero invoice by "InvoiceNumber = 303-SI1-2000004". It will only have one invoice line, having unit price, discount, tax amount and total amount calculated as the sum of all the the InforLN invoice lines. Invoice Line Description just reports "RTF" if the InforLN Invoice "RelatedPurchaseInvoice" field is empty, the content of the InforLN Invoice "RelatedPurchaseInvoice" field if it is assigned and if the invoice is not paid or partially paid.
InforLN Sales invoice Ledger Code / Tax rates not mapped in Stellarise Connector
In InforLN there is an invoice with Invoice Name "303-SI1-2000004" and having one invoice line that has the ledger code "60004001" not mapped in the Stellarise Connector settings. No defaults behavior is also set in the Stellarise Connector Ledger settings.
Stellarise Connector collects the InforLN Invoice "InvoiceName = 303-SI1-2000004" and realises that the Ledger code or the Tax Rate that should be present in the InforLN-Xero ledgercodes/taxrates map (Connector Settings) but it is not. In addition there is not any deafult specified. At this point, Stellarise Connector tries to transfer it anyway to Xero but since the invoice status is set by Design to "approved" and Xero does not allow approved invoices without explicitly specified ledger, Stellarise will record the exception in the audit table, reporting that the invoice cannot be created because there is no ledger code defined against it.
InforLN Sales invoice correct Ledger Code / Tax rates, not mapped but with default
In InforLN there is an invoice with Invoice Name "303-SI1-2000005" and having one invoice line that has a ledger code and a tax rate not correctly mapped in the Stellarise Connector settings. But a default is set for Ledger codes and tax rates.
Stellarise Connector collects the InforLN Invoice "InvoiceName = 303-SI1-2000005" and realises that the Ledger code or the Tax Rate that should be present in the InforLN-Xero ledgercodes/taxrates map (Connector Settings) but it is not. Anyway, there is a default Ledger Code / Tax rate defined against it: Stellarise Connector will then assign this default values to the Xero invoice, that will then be successfully created in Xero.
InforLN Sales invoice created now, but the "Process until" setting in Stellarise Connector is set to "Until yesterday"
In InforLN there is an invoice with Invoice Name "303-SI1-2000006" which has literally been created now, while you are reading this document. In the Connector settings, the property "Process Data Until:" is set to "yesterday".
Stellarise Connector exploits the capability of InforLN to retrieve entities between a certain period of time. Typically, the starting point of the considered time period is the last DateTime the Connector has run. the Upper limit of the time period is calculated instead using the formula "Now minus number of days specified in the 'Process Data Until' field": in the example, using "Yesterday" means that the upper limit of the timeframe is "Now - one day", resulting in a request to InforLN that literally is "give me all the Sales Invoices modified since the last time I have requested to you and Today minus the number of days specified in the 'Process Data Until' field"".
Stellarise Connector collects then all the timeframe matching InforLN Invoices, but "InvoiceName = 303-SI1-2000006" is one of them. and realises that the Ledger code or the Tax Rate that should be present in the InforLN-Xero ledgercodes/taxrates map (Connector Settings) but it is not. Anyway, there is a default Ledger Code / Tax rate defined against it: Stellarise Connector will then assign this default values to the Xero invoice, that will then be successfully created in Xero.
InforLN Sales Credit Notes
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).
Voiding a Sales Invoice
In 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.
Purchase Invoices with Attachments
In InforLN there is a purchase invoice 303-PI1-600001 that needs to be created in Xero. In InforLN, this invoice has a PDF attachment as well.
After the Connector has transferred the details of the Purchase Invoice to Xero, creating the Xero Purchase Invoice "303-PI1-600001", the following task that the connector performs is to check if there is a file attachment for the given Purchase Name in InforLN. InforLN reponse reports that there is a file called "600001.pdf" alongisde with its binary content. Preserving the filename, the Connector then attach it to the "303-PI1-600001" Xero Purchase Invoice.
Invoice Line description from "RTF" to "Related to:"
In Xero there is the invoice "303-SI1-200001", initially produced by the Connector. The Invoice has the designed single invoice line having the "Description" field filled with the string "RTF", suggesting that this invoice is waiting for a related purchase invoice to appear.
When the Connector runs, it picks up from InforLN the Purchase "303-PI1-600001", which has the field "RelatedSalesInvoice" set to "303-SI1-200001". The Connector creates then the Purchase Invoice "303-PI1-600001" in Xero, updating the invoice line Description field of the previously created Xero Sales Invoice "303-SI1-200001", from the existing "RTF" string to the string: "related to: 303-PI1-600001" if the invoice is not paid or partially paid.
InforLN Purchase Credit Notes
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).
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 "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 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 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 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, 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 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" 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
During the description of the following use cases:
- The Bank Account Number will be always sent from Xero to InforLN as the "Account Number", i.e. excluding the sort-code part. This assumption is due to InforLN limitations and has been taken during the Design phase.
- The Contact Name is always passed from Xero, even if there is no InforLN correspondence. This because this string can then be used as a reference.
- At least the Payment or Prepayment ID is passed. These will then be used by InforLN to check on already processed payments or prepayments.
- Due to InforLN otherwise impossibility for financial matching, Non-Recurring suppliers that refer to employee expenses must be set up in Xero as Contacts following the format "FirstName LastName expenses"
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
Xero Payment received from Client and related to Prepayment
There is a straight Xero Payment having ID 5678-5678-5678-5678 against a Sales invoice, the related Customer exists in InforLN and the amount IS related to a previously made pre-payment.
The connector picks the Xero Payment "5678-5678-5678-5678" 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: 5678-5678-5678-5678, The unique identifier of the Payment ID.
XeroPprepaymentID: "abcde-abcde-abcde-abcde", the Prepayment ID that this payment is relating to.
XeroContactName: "ABC Customer ltd", the String name of the Customer
Xero Payment sent to recurring Supplier
There is a straight Xero Payment having ID 4321-4321-4321-4321 against a Purchase Invoice, the related Supplier exists in InforLN. By Design definition, this means that the Supplier IS a recurring supplier.
The connector picks the Xero Payment "4321-4321-4321-4321" up and checks for the Supplier InforLN Code. When this preliminary check is done, then the connector sends the payment to InforLN.
Particularly, paying attention to the following field:
DocumentType: 2, In InforLN means "Allocated Purchase Payment"
BusinessPartner: BP00000001, InforLN supplier code to allocate the payment against.
InvoiceNumber: abcdefg-303-PI1-1234567890, the Invoice to allocate the payment against.
XeroPaymentID: 4321-4321-4321-4321, The unique identifier of the Payment ID.
XeroPprepaymentID: "", the Prepayment ID is empty because the payment is not referring to any purchase prepayments.
XeroContactName: "Linea Ligth srl", the String name of the recurring Supplier
Xero Payment sent to non recurring Supplier
There is a straight Xero Payment having ID 6453-6453-6453-6453 against a Purchase Invoice, the related Supplier DOES NOT exists in InforLN. By Design definition, this means that the Supplier IS NOT a recurring supplier. In this Use Case, Xero Preprayment ID will alwys be empty. By Design indeed, Prepayments to non recurring suppliers are practically impossible, meaning that it is not happening in the real life. If it should happen in future, they will be manually addressed in InforLN.
The connector picks the Xero Payment "6453-6453-6453-6453" up and checks for the Supplier InforLN Code; it does not exist, so pass the information to InforLN as a normal Payment, but without specifying the Supplier Code.
Particularly, the following fields will be sent:
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
What 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
There is a Xero Prepayment having ID 0001-0001-0001-0001 against the "ABC Customer ltd" Customer. The Customer has indeed just paid an upfront amount of money to cover up the next Invoices' payments.
The connector picks the Xero Prepayment "0001-0001-0001-0001" up and extracts the Customer InforLN Code, then it sends the Prepayment to InforLN.
Particularly, the following fields will be sent:
DocumentType: 4, In InforLN means "Non-allocated Sales Prepayment"
BusinessPartner: "300000066", InforLN Business Partner Code.
InvoiceNumber: "", This is a prepayment, there is no Invoice Number related to it.
XeroPaymentID: "", This is a Prepayment, furthermore PaymentID is empty.
XeroPprepaymentID: "0001-0001-0001-0001", the Prepayment Unique Identifier.
XeroContactName: "ABC Customer ltd", the String name of the Customer
Xero Prepayment made for recurring Supplier (Xero supplier does exist in Infor)
There is a Xero Prepayment having ID 0002-0002-0002-0002 against the "The Big Supplier ltd" supplier. Supplier exists in InforLN, this means that the Supplier IS a recurring supplier by Design definition.
The connector picks the Xero Prepayment "0002-0002-0002-0002" up and extracts the Supplier InforLN Code, then it sends the Prepayment to InforLN.
Particularly, the following fields will be sent:
DocumentType: 3, In InforLN means "Non-allocated Purchase Prepayment"
BusinessPartner: "300000099", InforLN Supplier Code.
InvoiceNumber: "", This is a prepayment, there is no Invoice Number related to it.
XeroPaymentID: "", This is a Prepayment, furthermore PaymentID is empty.
XeroPprepaymentID: "0002-0002-0002-0002", the Prepayment Unique Identifier.
XeroContactName: "The Big Supplier ltd", the String name of the Customer
Xero Prepayment non recurring Supplier (Xero supplier does not exist in Infor)
There is a Xero Prepayment having ID 0003-0003-0003-0003 against the "McDonalds" supplier. Supplier DOES NOT exist in InforLN, this means that the Supplier IS NOT a recurring supplier by Design definition.
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.
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