Skip to content

Latest commit

 

History

History
69 lines (63 loc) · 3.49 KB

todo.org

File metadata and controls

69 lines (63 loc) · 3.49 KB
Raw

Tasks

Add next_paydate() function to invoice

Returns dt for next payday, has to know some previous payday to calculate every second week, or maybe just `if now::week_num % 2` because we started invoicing at the end of week 1 in the new year.

The use of invoice.send() doesen’t really matter

A few tests called send(), but commenting those calls out didn’t affect the outcome of the test. I was thinking each entry could just record some maybe interesting information about its parent invoice, while really trying to defer on making an entry point back to its invoice, something like Entry –> Invoice. Right now its only Invoice –> [Entry, Entry, …]. I was also thinking that an invoice’s ID could be computed from the interesting information, but why not just use a real parent-child relation with formal ids? And this all seems premature anyways. Maybe I don’t care enough about send() to justify its existence, yet.

I found a use for it, it sets the invoiced_datetime property on the invoice, which is used by print_txt().

But I’m still not sure how I even “send” an invoice, beyond the mechanical steps of:

  1. sync phone
  2. copy hour entries from Notes app into notes.txt
  3. run gen_invoice_task, I can specify a variabe in the file to select which company to invoice for
  4. copy-paste line-items from invoice txt file to another Notes app note
  5. sync phone
  6. text Ken

Re-evaluate tests for payment_date in Invoice

Just changed all net_30 date-times to None, and no tests broke. Make tests break, then fix the code.

Move all IO stuff out of TimeEntry, Invoice, and CompanyJobs

Methods or classmethods, like Invoice.write_file(), TimeEntry.parse_note(), or CompanyJobs.get_jobs_from_ini(), belong in a separate IO layer. Maybe something like io/txt_files.

Make it so: invoice == read_invoice(write_invoice(invoice)))

Ended up just going with unpickle(pickle(obj)), but that’s all I really specified, which makes me think I need to rethink how I write these TODOs.

Write invoiced entries to separate file(s) when an invoice is sent(?)

More generally write invoices and entries to files at any time… based on a put(), and then get() or fetch()

Change invoice to persist with only entries IDs

Saving the full entry inside the invoice surely is not a good idea. Store a list of IDs to the entries, and have some mechanism to get entries by their ids.

What’s the flow of entries and invoices? For gen_invoice_task its parse note.txt to entries; the entries are used to create an invoice, attributes of the entries that are used are: hours for an hours_total attribute, company to ensure all the entries are for the same company, and job (id) to create the invoice’s own job_ids dict. The invoice then uses the entries, finally (?), in the send.

Yeah, so, Invoice will use the entries during init and then save only the IDs.

I’m stimmied again by not knowing how invoice.send() gets its entries in test… no way it makes sense to pass the invoice the entries to send, i.e.: invoice.send(entries), when I just made the invoice like invoice = Invoice(entries, …). So maybe invoice does keep the entries for its lifetime. When it’s saved the entries are discarded before pickling (in the case of io_txt) and then after unpickling the invoice… wow, this is so confusing.