#177 feature/Invoice: init, added Invoice related structs, implemented met…

[akshayDev17]

feature/Invoice: init, added Invoice related structs, implemented methods:GenerateInvoiceNumber,GetInvoiceDetails(by ID)

What does this PR do?

1. implements the Invoice related structures that takes care of the endpoints: "/v2/invoicing/generate-next-invoice-number" and "/v2/invoicing/invoices/{invoice_id}", thus addresses this issue.

Where should the reviewer start?

1. Main-code: types.go; from the structure InvoiceNumber to the structure Invoice
2. invoicing.go: implements the methods for the endpoints mentioned above.
3. invoicing_test.go: implements unit-testing functions for the above mentioned methods.

How should this be manually tested?

1. By running the test functions TestGenerateInvoiceNumber() and TestGetInvoice() in invoicing_test.go using the commands go test -timeout 60s -cover -v -run ^TestGenerateInvoiceNumber and go test -timeout 60s -cover -v -run ^TestGetInvoice respectively.

Any background context you want to provide?

1. Other Invoicing endpoints will also be addressed in the future commits.
2. Currently there seems to be no way to implement a generalized function(across different types/structs) for comparing two slices of the same type of struct, where the ordering of the elements within the slices should not be a factor in determining their equality.
   1. l = [1,2,3](data returned by API) and v = [2,3,1](explicitly declared data in a Testing function) is the same(because it might be that the API returns data in a different order).
   2. sorting by one of the fields would be helpful:
      1. but since the field value can be empty(nil), would've to sort across all fields.
      2. currently exploring whether this can be done regardless of the knowledge of the struct(in a programmatical manner), because explicit implementation across all structs would be too cumbersome.

[plutov]

Ideally we don't have any keys in tests, where did you get them? Should we move them to env vars?

[akshayDev17]

I obtained these from the integration_test.go file. They seem to be used in order_test.go as well. Should we ideally be importing them as env vars?

[plutov]

Please also add that to README to the list of supported enspoints.

[akshayDev17]

Added in this commit, please review.