Check the latest version (24.6.2.1613). It will relay linked objects too.
not enough,
this is what I got on the relay
"IssueDate": "2022-09-07T00:00:00",
"DueDateDays": 30,
"Reference": "0001",
"Customer": "962bd1d4-3560-41a2-bd06-9701c46a2449",
"BillingAddress": "صلاح الدين | Salah Al-Din\nالمروج | Al-Murooj\nالرياض | Riyadh\nBuildingNumber : 1111 / PostalZone : 12222",
"Description": "SDK Summary Invoice",
"Lines": [
{
"Item": "7d96f7a3-ac59-41f3-ac62-c4799f0e2ac3",
"LineDescription": "Item with 15% Vat",
"CustomFields2": {},
"Qty": 1.0,
"SalesUnitPrice": 5000.0,
"TaxCode": "1731afd8-40df-484c-8335-81a1451ab8f8"
},
{
"Item": "7d96f7a3-ac59-41f3-ac62-c4799f0e2ac3",
"LineDescription": "Item with 15% Vat",
"CustomFields2": {},
"Qty": 2.0,
"SalesUnitPrice": 800.0,
"TaxCode": "1731afd8-40df-484c-8335-81a1451ab8f8"
},
{
"Item": "7d96f7a3-ac59-41f3-ac62-c4799f0e2ac3",
"LineDescription": "Item with 15% Vat",
"CustomFields2": {},
"Qty": 1.0,
"SalesUnitPrice": 600.0,
"TaxCode": "1731afd8-40df-484c-8335-81a1451ab8f8"
}
],
"HasLineNumber": true,
"HasSalesInvoiceFooters": true,
"SalesInvoiceFooters": [
"e9a08b8d-0c2f-411b-a7f0-76dd4a6d6968"
],
"HasRelay": true,
"Relay": "https://relay.manager.io",
"CustomFields2": {
"Strings": {
"3c4c1fb3-3b0e-4f2e-9eeb-2d466c496e2f": "-",
"df844e4d-2ccc-4e46-9e3b-ac51a80868a2": "10 | In cash"
}
}
}
and this is what I expected
{
"baseCurrency": {
"code": "SAR",
"decimalPlaces": 2
},
"decimalSeparator": ".",
"deliveryNotes": false,
"foreignCurrencies": {
"c37b2a1b-312c-4c79-afc5-78fe5ac3e99a": {
"code": "USD",
"decimalPlaces": 2
}
},
"goodsReceipts": false,
"withholdingTaxPayable": false,
"withholdingTaxReceivable": false,
"billableTime": false,
"data": {
"AmountsIncludeTax": false,
"BillingAddress": "صلاح الدين | Salah Al-Din\nالمروج | Al-Murooj\nالرياض | Riyadh\nBuildingNumber : 1111 / PostalZone : 12222",
"CanBeRealizedCurrencyTransaction": false,
"Customer": {
"BillingAddress": "صلاح الدين | Salah Al-Din\nالمروج | Al-Murooj\nالرياض | Riyadh\nBuildingNumber : 1111 / PostalZone : 12222",
"Code": null,
"Currency": null,
"CustomFields": {
"7de1f605-f0a8-4cae-80a4-664d6dbe70d1": "399999999800003"
},
"CustomFields2": {
"Strings": {
"93f79973-5346-4c6b-b912-90ea9bbf69c2": "\"Party.PostalAddress.StreetName\": \"صلاح الدين | Salah Al-Din\"\n\"Party.PostalAddress.BuildingNumber\": \"1111\"\n\"Party.PostalAddress.CitySubdivisionName\": \"المروج | Al-Murooj\"\n\"Party.PostalAddress.CityName\": \"الرياض | Riyadh\"\n\"Party.PostalAddress.PostalZone\": \"12222\"\n\"Party.PostalAddress.Country.IdentificationCode\": \"SA\"\n\"PartyTaxScheme.CompanyID\": \"399999999800003\"\n\"PartyTaxScheme.TaxScheme.ID\": \"VAT\"\n\"PartyLegalEntity.RegistrationName\": \"شركة نماذج فاتورة المحدودة | Fatoora Samples LTD\""
}
},
"DefaultBillingAddress": "صلاح الدين | Salah Al-Din\nالمروج | Al-Murooj\nالرياض | Riyadh\nBuildingNumber : 1111 / PostalZone : 12222",
"DefaultDeliveryAddress": "صلاح الدين | Salah Al-Din\nالمروج | Al-Murooj\nالرياض | Riyadh\nBuildingNumber : 1111 / PostalZone : 12222",
"DeliveryAddress": "صلاح الدين | Salah Al-Din\nالمروج | Al-Murooj\nالرياض | Riyadh\nBuildingNumber : 1111 / PostalZone : 12222",
"Email": "customer01@customer.net",
"HasDefaultBillingAddress": true,
"HasDefaultDeliveryAddress": true,
"id": "962bd1d4-3560-41a2-bd06-9701c46a2449",
"Key": "962bd1d4-3560-41a2-bd06-9701c46a2449",
"Name": "شركة نماذج فاتورة المحدودة | Fatoora Samples LTD",
"NameWithCode": "شركة نماذج فاتورة المحدودة | Fatoora Samples LTD",
"text": "شركة نماذج فاتورة المحدودة | Fatoora Samples LTD",
"UniqueName": "شركة نماذج فاتورة المحدودة | Fatoora Samples LTD"
},
"CustomFields2": {
"Booleans": {
},
"Dates": {
},
"Decimals": {
},
"StringArrays": {
},
"Strings": {
"3c4c1fb3-3b0e-4f2e-9eeb-2d466c496e2f": "-",
"df844e4d-2ccc-4e46-9e3b-ac51a80868a2": "30 | Credit"
}
},
"Description": "Test Relay",
"Discount": false,
"DueDateDate": null,
"EarlyPaymentDiscount": false,
"EarlyPaymentDiscountAmount": 0.0,
"ExchangeRate": 0.0,
"ExchangeRateIsInverse": false,
"HasLineDescription": false,
"id": "90e520d9-0636-4822-9160-1b22b7a3e1fe",
"IssueDate": "2024-6-1",
"Lines": [
{
"DiscountAmount": 0.0,
"Item": {
"CustomFields2": {
"Booleans": {
},
"Dates": {
},
"Decimals": {
},
"StringArrays": {
},
"Strings": {
"2ef3daa5-c4cf-4cdc-a19c-5a14ea8fcfb5": "",
"6862773d-f847-486e-824b-0b42aaf0cf17": "S",
"88797f0a-d3aa-4de6-8e0c-76ab1131b206": ""
}
},
"ItemCode": null,
"ItemName": "Item 15% Vat",
"Key": "7d96f7a3-ac59-41f3-ac62-c4799f0e2ac3",
"NameWithCode": "Item 15% Vat",
"UnitName": "PCE"
},
"LineNumber": null,
"Qty": 1.0,
"SalesUnitPrice": 100.0,
"TaxCode": {
"Label": "15%",
"Name": "VAT 15%",
"Rate": 15.0,
"text": "VAT 15%",
"UniqueName": "VAT 15%"
}
}
],
"Reference": "2",
"text": "2 — 2024-06-01",
"UniqueName": "2 — 2024-06-01",
"WithholdingTax": false,
"WithholdingTaxAmount": 0.0
}
}
I have a Customfield on Inventory Item, Customer and Supplier that I don’t display on the Invoice and Invoice Printout, but I still need the Customfield to be sent to Relay
@Mabaega Edit field will contain invoice object only. If you want to see data for customer 962bd1d4-3560-41a2-bd06-9701c46a2449, then examine field 962bd1d4-3560-41a2-bd06-9701c46a2449. It’s being sent to relay. The same goes for items, tax codes, footers and custom fields that seem to be linked to your invoice.
Relay your data to https://relay.manager.io/ to see everything that is being received by the relay service.
Excellent.
Now we are addressing the real issues here:
-
A financial viable model for the software developers
-
An interface with Manager (and the external party) stable over years to enable recovery of development cost rather than crippling maintenance costs.
Manager is proprietary software with a relatively small market share in all jurisdictions it is used in. Ex gratis software contribution are sometimes made to open source software projects but I agree it appears it is unrealistic to expect that to happening with proprietary software like Manger. Sure some people will sometimes make helpful suggesting to other user on the forum when browsing for content of interest, or translate some terms for their language, but the time commitment for such task is very different to producing tested code.
Similarly the term “Application Programming Interface” as used in other software environment requires both:
-
It has sufficient functionality to reasonably achieve the service required
-
Once defined is not changed by NG Software for years into the future. Ensuring code written to that interface specification keeps working despite Manager software changes.
-
This underlying issue applies to both Manager extensions, other code run locally, or a web relay.
-
A fixed interface to Manager could be designed to support more that one language if java script is too restrictive or can not be configured for modular programming.
I can’t see Manager achieving the many external interfaces it requires without directly addressing these issues.
A way of ensuring extension are financially supported is to support
- Enabling some extensions only if a licence key is entered.
- NG Software could provide the licence keys to software developers.
- The licence key could be linked to a Manager installation or a Manager Business.
- NG Software & the software developer would need to negotiate who sells the licence keys to customers and what fee (if any) is paid to the other party.
A software solution which required Manager business owner to trust anyone with their bank and tax office login details just because they host a relay is a very weird approach imo. Having that data unencrypted for many business in a relay makes it a high value target. Keeping such data local dramatically reduces the security risk.
Same…
only Sales CustomField exposed to relay
{
"IssueDate": "2024-06-02T00:00:00",
"Reference": "1",
"Customer": "d01823c1-8dc0-4f12-ac9e-ec8ad145cf0a",
"BillingAddress": "Billing address Customer",
"Description": "Description",
"Lines": [
{
"Item": "b2998f91-c9fc-4dfc-b38b-4a25261c54b1",
"LineDescription": "Inventory Item 01 Description",
"CustomFields": {},
"CustomFields2": {
"Strings": {},
"Decimals": {},
"Dates": {},
"Booleans": {},
"StringArrays": {}
},
"Qty": 1.0,
"SalesUnitPrice": 100.0,
"DiscountPercentage": 100.0
}
],
"HasLineNumber": true,
"HasLineDescription": true,
"Discount": true,
"SalesInvoiceFooters": [],
"HasRelay": true,
"Relay": "https://relay.manager.io",
"CustomFields": {},
"CustomFields2": {
"Strings": {
"c142aa3d-68e7-4975-be59-62d0be82d937": "CF Sales"
},
"Decimals": {},
"Dates": {},
"Booleans": {},
"StringArrays": {}
}
}
OK, I misunderstood what is the issue. I thought you couldn’t see any object linked to the invoice (customers, items etc.).
Check the latest version (24.6.3) where all linked custom fields should be included in the POST data now.
Would it be possible to control what information is carried by POST request to relay as right now each and every information is conveyed which might not be even required. And the possibility to make the required fields editable only as opposed to giving full control?
@shahabb what is the concern though? Even if you relay more information than necessary, it’s not really causing performance issues. Whether you are relaying 10 kilobits or 20 kilobits of data, it’s not material when your internet speed is measuring in megabits per second.
If the issue is that your custom fields could contain secrets that you don’t want to be posted to relay because they are not relevant, then that’s a valid concern. When the time comes, I will solve it one way or another. Currently we are just trying to make this concept work so it delivers value. Security will be tightened later once this feature is better understood.
What do you mean by this? Can you give an example?
Need Information linked to Customer Currency.
Or can the Manager send data like that in the edit form?
This data is complete enough to be used.
Why did I choose Edit form for eInvoicing because the data we get from there is more complete, we also need to capture feedback from the server and update the invoice with that data.
Not kind of secrets but they are not relevant.
I get it. it’s in initial stages was just wanting to make sure if thats gonna happen ever.
Here each and every field can be modified. I mean that there is no need to give full control to someone else. Like in our case the Tax authority issue an invoice no when invoice is reported so for that we would want to populate only the Authority Invoice No Field (Custom field).
I am not a developer and don’t know if this suggestion aligns with the whole concept but what if relays are defined individually in settings and for each relay fields or just their values which should be carried are defined (like merged tags) and then just like footers select the desired relay for each invoice.
OK, we will just need to wait and see the scope relays will be used for. Then security can be tightened. Right now, I don’t want to be introducing restrictions becuase they would seem arbitrary.
1 Like
I just see it exposed! Thanks!!
The latest version includes foreign currency in relay.
That JSON is for internal use. It’s subject to change without notice. Relay data model is a lot more stable.
Thank you, the data is complete now. We will need relays for all transactions related to 3rd parties. Purchase, Debit Note, Sales, Credit Note, Payment and Receipt.
I will try to change my project by taking advantage of this feature.
@Mabaega Great. Relays will be extended to all documents eventually. Also, let’s see how it goes at your end. I’m sure there is still a lot to improve at my end to make this really easy for both you and end users.
I am confused about how to handle prepaid amounts from customers.
For eInvoice purposes, I need information about the Advance Receipt Transaction that I have listed in the invoice as prepaid.
I am considering two options. The first option is to use a special account when receiving advance payments from customers, so that I can add the prepaid amount to the Invoice line. Currently, I can include the receipt information in the line description, but this would be inconvenient for users because they need to know the Date, UUID, and Prepaid Document Number that has been reported to the Tax Authority.
The second option is to continue using the special account and make a Prepaid Adjustment to the Invoice using Journal Entry. This method is easier to implement, but I still can’t retrieve information about the Prepaid Transaction Document.
I’m not sure how Manager should treat advance receipts or prepayments.
Perhaps by adding a special line to list advance payments or receipts, so that users only need to select the Transaction Reference, and the transaction data will be linked to the invoice that uses it, allowing us to have a complete reference for eInvoice purposes.
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="PCE">1.00</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="SAR">2000.00</cbc:LineExtensionAmount>
<cac:TaxTotal>
<cbc:TaxAmount currencyID="SAR">300.00</cbc:TaxAmount>
<cbc:RoundingAmount currencyID="SAR">2300.00</cbc:RoundingAmount>
</cac:TaxTotal>
<cac:Item>
<cbc:Name>Laptop | حاسوب محمول</cbc:Name>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>15.00</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price>
<cbc:PriceAmount currencyID="SAR">2000.00</cbc:PriceAmount>
</cac:Price>
</cac:InvoiceLine>
<cac:InvoiceLine>
<cbc:ID>2</cbc:ID>
<cbc:InvoicedQuantity unitCode="PCE">0.000000</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="SAR">0.00</cbc:LineExtensionAmount>
<cac:DocumentReference>
<cbc:ID>46531</cbc:ID>
<cbc:UUID>a79760f7-2f48-4da9-85a5-40459a147c80</cbc:UUID>
<cbc:IssueDate>2022-08-15</cbc:IssueDate>
<cbc:IssueTime>12:28:17</cbc:IssueTime>
<cbc:DocumentTypeCode>386</cbc:DocumentTypeCode>
</cac:DocumentReference>
<cac:TaxTotal>
<cbc:TaxAmount currencyID="SAR">0</cbc:TaxAmount>
<cbc:RoundingAmount currencyID="SAR">0</cbc:RoundingAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="SAR">1000</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="SAR">150</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>15.00</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
<cac:Item>
<cbc:Name>Laptop | حاسوب محمول</cbc:Name>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>15.00</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price>
<cbc:PriceAmount currencyID="SAR">0.00</cbc:PriceAmount>
</cac:Price>
</cac:InvoiceLine>
I need a Document Reference like the 2nd Invoice Line.
This is an example of the data I got from the relay.
{
"IssueDate": "2024-08-11T00:00:00",
"DueDate": 1,
"DueDateDays": 30,
"DueDateDate": "2024-08-31T00:00:00",
"Reference": "18",
"Customer": "962bd1d4-3560-41a2-bd06-9701c46a2449",
"BillingAddress": "صلاح الدين | Salah Al-Din\nالمروج | Al-Murooj\nالرياض | Riyadh\nBuildingNumber : 1111 / PostalZone : 12222",
"Lines": [
{
"Item": "7d96f7a3-ac59-41f3-ac62-c4799f0e2ac3",
"LineDescription": "Item with 15% Vat",
"CustomFields": {},
"CustomFields2": {
"Strings": {},
"Decimals": {},
"Dates": {},
"Booleans": {},
"StringArrays": {}
},
"Qty": 1.0,
"SalesUnitPrice": 2000.0,
"TaxCode": "1731afd8-40df-484c-8335-81a1451ab8f8"
},
{
"Account": "ef49facb-203b-4b45-aebd-99af4645700b",
"SpecialAccount": "86b916fd-3857-47b8-b73b-4540295f466b",
"LineDescription": "Receipt 2024-08-10—1",
"CustomFields": {},
"CustomFields2": {
"Strings": {},
"Decimals": {},
"Dates": {},
"Booleans": {},
"StringArrays": {}
},
"SalesUnitPrice": -1000.0,
"TaxCode": "1731afd8-40df-484c-8335-81a1451ab8f8"
}
],
"HasLineNumber": true,
"HasLineDescription": true,
"ShowTaxAmountColumn": true,
"AlsoActsAsDeliveryNote": true,
"HasSalesInvoiceFooters": true,
"SalesInvoiceFooters": [
"e9a08b8d-0c2f-411b-a7f0-76dd4a6d6968"
],
"HasRelay": true,
"Relay": "https://relay.manager.io",
"CustomFields": {},
"CustomFields2": {
"Strings": {
"df844e4d-2ccc-4e46-9e3b-ac51a80868a2": "30 | Credit",
"e1050215-e02a-4de0-9d55-cf0dba27a0d6": "0200000",
"3c4c1fb3-3b0e-4f2e-9eeb-2d466c496e2f": null
},
"Decimals": {},
"Dates": {},
"Booleans": {},
"StringArrays": {}
}
}
{
"IssueDate": "2024-08-11T00:00:00",
"DueDate": 1,
"DueDateDays": 30,
"DueDateDate": "2024-08-31T00:00:00",
"Reference": "19",
"Customer": "962bd1d4-3560-41a2-bd06-9701c46a2449",
"BillingAddress": "صلاح الدين | Salah Al-Din\nالمروج | Al-Murooj\nالرياض | Riyadh\nBuildingNumber : 1111 / PostalZone : 12222",
"Lines": [
{
"Item": "7d96f7a3-ac59-41f3-ac62-c4799f0e2ac3",
"LineDescription": "Item with 15% Vat",
"CustomFields": {},
"CustomFields2": {
"Strings": {},
"Decimals": {},
"Dates": {},
"Booleans": {},
"StringArrays": {}
},
"Qty": 1.0,
"SalesUnitPrice": 2000.0,
"TaxCode": "1731afd8-40df-484c-8335-81a1451ab8f8"
}
],
"HasLineNumber": true,
"HasLineDescription": true,
"ShowTaxAmountColumn": true,
"AlsoActsAsDeliveryNote": true,
"HasSalesInvoiceFooters": true,
"SalesInvoiceFooters": [
"e9a08b8d-0c2f-411b-a7f0-76dd4a6d6968"
],
"HasRelay": true,
"Relay": "https://relay.manager.io",
"CustomFields": {},
"CustomFields2": {
"Strings": {
"df844e4d-2ccc-4e46-9e3b-ac51a80868a2": "30 | Credit",
"e1050215-e02a-4de0-9d55-cf0dba27a0d6": "0200000",
"3c4c1fb3-3b0e-4f2e-9eeb-2d466c496e2f": null
},
"Decimals": {},
"Dates": {},
"Booleans": {},
"StringArrays": {}
}
}
Why not use Merge Tags?
Advance amount= {{ Invoice Amount }} - {{ Balance due }}
Edit: Didnt know you have to report receipts and payments too and their proper reference in Invoice.
I assume that mostly depends on what the tax authority requires.
If that’s what the tax authority requires then that’s what the Manager solution should provide.
By the way, really knowing what each jurisdiction requires is the difficulty in providing solutions for each jurisdiction (in an author with the computing skills to implement it)
@Mabaega There is a ledger for invoice itself and the way to see whether the invoice has been prepaid is to look whether there is any transaction dated before the invoice date.
The issue with Relays is that there is no way to access this ledger.
I’m going to be heavily working on relays this month. There are some unresolved issues and I’ll keep this in mind.
I think the issue would be that merge tag just gives you the amount. Not details on the transaction that has created that amount. And perhaps there are multiple transactions behind that amount. Also amount would not indicate whether it represents payment in advance or payment after invoice being issued.
But it’s interesting direction to look at. If Footers could embed this kind of data within itself (even if it’s hidden on printed document), Relay could see it and work with it. I will need to think this through.
1 Like
