Hi,
Anyone have this issue or is this the standard behavior?
I’m using R script to post the receipt to Manager.io, I have actually set the AutomaticReference to true when posted thru API.
However, when i check on Manager.io, it showing blank, i will need to manually edit the receipt and click on Update only the reference will be update. is this the standard behavior or it is a bug?
Can anyone help on this?
This is normal behavior.
meaning to say by using Post Feature, there is no way that manager.io will auto generate the reference number? even we already set the automatic reference as true?
Yes, this has always been the case. The auto reference is only evaluated once you press the “Create” or “Update” buttons in the UI form.
Recently, the auto reference is also evaluated on “Batch Create” function but it restarts numbering back from 1 for every batch.
I think the reference counters aren’t exposed to batch operations or the API yet. It would be a nice addition though.
@Ealfardan, thanks for the answer. appreciate the help.
@lubos hope that this feature can be take into consideration that automatic reference can be auto generate instead of click “Create” or Update" button manually.
Imo supporting unique reference numbers via the API is a reasonable feature.
However the API provides low level access for programmers, so for that environment it makes more sense to supporting a method to determine
Rather than adding “user data entry automatic facilities”. Particularly given multiple users want different numbering schemes.
That’s the right direction more or less. Even better would be the largest number used, which should be readily available.
Somewhere inside of Manager there’s a list of counters/incrementors that are compared and incremented everytime a new reference number is introduced. These aren’t exposed to the API, so exposing just those incrementors is the way to go since it avoids expensive queries like this:
…which is already available in the API in the /{object type}.json file but it requires the user to retrieve the full list of numbers everytime.
Not necessarily. The list of transactions of a specific type could be searched each time for the highest reference number. That is how it has always been described in the Guides.
I didn’t know that. But that seems like too much work.
From the UI, this is quite straightforward to do as we can sort by that column.
However, via the API it would require loading every single record individually, looping through them all to check what the highest is.
Which is why I suspect Ealfardan wrote:
I, too, would love to see the auto-increment functionality work through the API in the same way that it does with the interface. If set to true on an API create/update, and the reference field is empty, it should create a new reference number automatically.
The functionality already exists, it just doesn’t seem to work via the API. It feels more like a bug with the API, or an oversight, rather than a missing feature.
I think you are looking past an important distinction. When you create a transaction manually, you are using the features and processes built into the program to create a record in the database. So the program can interject a variety of tests, conditions, and active steps as it builds the record. But when you use the API, you are bypassing all that and injecting data directly into the database, data that is analogous to the result of all those tests, conditions, and steps. You get the result, but not the actions that would have been used to produce the result.
This is like batch operations, where you can create or update records with sequential reference numbers, but you cannot choose automatic sequencing. The automatic reference feature is an option in the creation/editing process, not a variable in the record.
I understand your analogy.
With that in mind – all REST APIs provide basic validation to prevent invalid data from being entered, and this is no different with Manager. If I was to put a completely wrong value into a field, it’d come back at me with an error. So it’s unlikely to be “injecting data directly into the database”.
Expanding on that… a REST API can include different fields to the form in the standard UI. And fields that it does provide, should be fully supported. Any that are not supported, shouldn’t be included.
I’ve just had a look at the documentation for a POST request to the SalesInvoice object.
This is what it suggests in the API example when loading the API in a web browser:
{
"IssueDate": "0001-01-01",
"DueDate": "By",
"DueDateDate": null,
"DueDateDays": null,
"Reference": null,
"QuoteNumber": null,
"OrderNumber": null,
"Customer": null,
"SalesQuote": null,
"SalesOrder": null,
"BillingAddress": null,
"Description": null,
"Lines": null,
"SalesInventoryLocation": null,
"LineDescription": false,
"Discount": false,
"DiscountType": "Percentage",
"AmountsIncludeTax": false,
"Rounding": false,
"RoundingMethod": "None",
"WithholdingTax": false,
"WithholdingTaxType": "Rate",
"WithholdingTaxPercentage": 0.0,
"WithholdingTaxAmount": 0.0,
"EarlyPaymentDiscount": false,
"EarlyPaymentDiscountType": "Percentage",
"EarlyPaymentDiscountRate": 0.0,
"EarlyPaymentDiscountAmount": 0.0,
"EarlyPaymentDiscountDays": null,
"LatePaymentFees": false,
"LatePaymentFeesPercentage": 0.0,
"TotalAmountInWords": false,
"TotalAmountInBaseCurrency": false,
"Bilingual": false,
"HideDueDate": false,
"CustomTitle": false,
"SalesInvoiceCustomTitle": null,
"HasSalesInvoiceCustomTheme": false,
"SalesInvoiceCustomTheme": null,
"AutomaticReference": false,
"ClosedInvoice": false,
"CustomFields": null
}
AutomaticReference is present in that list (3rd from the bottom). Therefore, it should either be fully supported – or removed from Manager’s API documentation for the SalesInvoice object.
If it is to be removed, so be it, but since it is in the documentation, it is natural for an API user to assume that it works. Would you agree? 
I just noticed that this thread is specifically about Receipts. So I just had a look and confirmed that AutomaticReference is also present in the API documentation for the Receipt object (4th from bottom).
{
"Date": "0001-01-01",
"Reference": null,
"PaidBy": "Other",
"Customer": null,
"Supplier": null,
"Contact": null,
"ReceivedIn": null,
"Status": "Pending",
"BankClearDate": null,
"Description": null,
"Lines": null,
"InventoryLocation": null,
"LineDescription": false,
"QuantityColumn": false,
"UnitPriceColumn": false,
"AmountsAreTaxExclusive": false,
"FixedTotal": false,
"FixedTotalAmount": 0.0,
"BalancingAmount": null,
"CustomTheme": false,
"ReceiptCustomTheme": null,
"AutomaticReference": false,
"CustomTitle": false,
"ReceiptCustomTitle": null,
"CustomFields": null
}
Not if my analogy is valid. But my expertise and understanding extends only as far as the analogy, so I’m really not qualified to express any further opinion.
In that case, it would be good to get @lubos’ opinion on this:
SalesInvoice, Receipt, and other objects have an AutomaticReference column in the API documentation generated by Manager itself. However, it doesn’t do anything.
Should it:
@DnD_IT_Solution, @Ealfardan, @Patch and I have all indicated above that we would prefer No 1.
In my personal opinion, if No 1 will not happen, then at least No 2 should be considered (removing it from the API documentation, to avoid confusing people that are using the docs as a point of reference for what the API is capable of doing).
I would be very surprised it than is not exactly what Manager does during user data entry.
That sounds logical to me.
Personally I think there are many other higher priority tasks (such as localisations communication with various jurisdictions and the ability to report exact values reported to tax authorities not approximate {without accumulated rounding}). So I would not support extensive programming input at this time.
Lubos may have some other grand design for the “API” however I have the impression it is very much a work in progress.
Ultimately, the order and importance of tasks comes down to the developer, and lubos is also the only one that can properly determine how much work may be involved. So I won’t comment on either of those.
Sounds like you’re in favour of No 1 (fixing it) only if it doesn’t delay other things that you personally believe to be a higher priority. Which is logical
That is my understanding as well. It has progressed a lot in the past few years, I recall when it did not have any built-in documentation at all.
This is correct as it would accept a reference number through API but it would not generate an automated one because that requires the internal programming actions of Manager. If you want auto-reference numbers then you should develop such code as part of the data entry side that links via API to Manager.
No
The API is a low level interface supporting implementation of functionality not in the basic Manager code. I see less value in replicating the existing user functionality.
As such option 2 or 3 make more sense to me.
The underlying issue is the API enables a programer to increase Managers functionality for a single company. In contrast localisations enable a programmer to increase Managers functionality for a jurisdiction. The later is thus an order of magnitude more powerful feature.
Oh, I’ve already got it working via my own code
But since it was raised by the OP, just thought I’d lend my support to it either working in Manager or having the documentation updated.