-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Design) Fiscal Year #279
Comments
/# 2 above limits you to one project/enterprise - "The previous fiscal year will be automatically calculated via the auto-increment index. The user will not be able to specify a previous fiscal year - whatever the last fiscal year created was will become the previous fiscal year." Form above with name, date created, number of months, .... do you want date created or beginning month? or both. Opening balances modal needs CR/DR columns, your balance can be on one side or the other AND DRs must = CRs or you stay in the modal. Close the FY needs to be a button on each FY along with X and Edit. You close a year when ready, often months after beginning a new one. Rarely, you could go back and fix a closed year (if not audited or reported to the govt) and then recalculate the closing ... which require recalculating the following year's period 0. |
For point 1, you are right, you would have to explicitly set the enterprise. The idea would be to do something like: SET @prev = (SELECT MAX(id) FROM fiscal_year WHERE enterprise_id = {{ id }});
INSERT INTO fiscal_year (..., previous_fiscal_year_id) VALUES (...., @prev); I'm hoping we only have to specify a single start date, in the form of a DATETIME. It would be beginning of the month. The mockup above uses "Set Date" to emphasize that we will use the same Alright, will do! I wondered if DR/CR fields should exist on the view, and ended up not displaying them. They exist in the backend though. Perhaps the edit button shouldn't exist if the previous year is closed... Should you be allowed to reopen a closed year? We could easily have a series of "close/reopen", "edit", and "X" buttons if needed. It might be better to put this on the edit form. @imawh, thanks for the feedback! I'll adjust the mockups based on this discussion. After some discussion with @sfount, I'll also add the "Set Beginning Balances" directly in the "Create Form" for the initial fiscal year, in the same location as "Close Previous Fiscal Year" is on the other page. I'll also remove the "Close Previous Year", and move that functionality onto the list view. |
This commit updates the fiscal year schema as requested by #279 in preparation for creating the client-side fiscal year module. It also updates the posting journal's core checks to ensure that integration tests continue to behave appropriately. Specifically, here is what changed: 1) `period.period_start` --> `period.start_date` 2) `period.period_stop` --> `period.end_date` 3) `fiscal_year.previous_fiscal_year` --> `fiscal_year.previous_fiscal_year_id`. 4) REMOVED `fiscal_year.transaction_start_number` 5) REMOVED `fiscal_year.transaction_stop_number` 6) REMOVED `fiscal_year.start_year` 7) REMOVED `fiscal_year.start_month` 8) ADDED `fiscal_year.start_date` DATE 9) ADDED `fiscal_year.created_at` 10) ADDED `fiscal_year.updated_at` 11) `fiscal_year.fiscal_year_txt` --> `fiscal_year.label`
This commit updates the fiscal year schema as requested by #279 in preparation for creating the client-side fiscal year module. It also updates the posting journal's core checks to ensure that integration tests continue to behave appropriately. Specifically, here is what changed: 1) `period.period_start` --> `period.start_date` 2) `period.period_stop` --> `period.end_date` 3) `fiscal_year.previous_fiscal_year` --> `fiscal_year.previous_fiscal_year_id`. 4) REMOVED `fiscal_year.transaction_start_number` 5) REMOVED `fiscal_year.transaction_stop_number` 6) REMOVED `fiscal_year.start_year` 7) REMOVED `fiscal_year.start_month` 8) ADDED `fiscal_year.start_date` DATE 9) ADDED `fiscal_year.created_at` 10) ADDED `fiscal_year.updated_at` 11) `fiscal_year.fiscal_year_txt` --> `fiscal_year.label`
This commit updates the fiscal year schema as requested by #279 in preparation for creating the client-side fiscal year module. It also updates the posting journal's core checks to ensure that integration tests continue to behave appropriately. Specifically, here is what changed: 1) `period.period_start` --> `period.start_date` 2) `period.period_stop` --> `period.end_date` 3) `fiscal_year.previous_fiscal_year` --> `fiscal_year.previous_fiscal_year_id`. 4) REMOVED `fiscal_year.transaction_start_number` 5) REMOVED `fiscal_year.transaction_stop_number` 6) REMOVED `fiscal_year.start_year` 7) REMOVED `fiscal_year.start_month` 8) ADDED `fiscal_year.start_date` DATE 9) ADDED `fiscal_year.created_at` 10) ADDED `fiscal_year.updated_at` 11) `fiscal_year.fiscal_year_txt` --> `fiscal_year.label`
3379: Update snyk to the latest version 🚀 r=jniles a=greenkeeper[bot] ## The dependency [snyk](https://github.com/snyk/snyk) was updated from `1.110.1` to `1.110.2`. This version is **not covered** by your **current version range**. If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update. --- <details> <summary>Release Notes for v1.110.2</summary> <h2><a href="https://urls.greenkeeper.io/snyk/snyk/compare/v1.110.1...v1.110.2">1.110.2</a> (2018-11-22)</h2> <h3>Bug Fixes</h3> <ul> <li>when package-lock.json file is present, snyk wizard included devDepepndencies in vulnerability count (<a href="https://urls.greenkeeper.io/snyk/snyk/commit/df876c6">df876c6</a>)</li> </ul> </details> <details> <summary>Commits</summary> <p>The new version differs by 2 commits.</p> <ul> <li><a href="https://urls.greenkeeper.io/snyk/snyk/commit/e96ad625e9138a1ebdad91acf714b88709dcfc68"><code>e96ad62</code></a> <code>Merge pull request #279 from snyk/fix/wizard_uses_devDeps_when_lockFile_present</code></li> <li><a href="https://urls.greenkeeper.io/snyk/snyk/commit/df876c6717ce6cd687c21fb3afa991e6eaaba39a"><code>df876c6</code></a> <code>fix: when package-lock.json file is present, snyk wizard included devDepepndencies in vulnerability count</code></li> </ul> <p>See the <a href="https://urls.greenkeeper.io/snyk/snyk/compare/7adcca08348e6a76eb17165075fc8df3691731d8...e96ad625e9138a1ebdad91acf714b88709dcfc68">full diff</a></p> </details> <details> <summary>FAQ and help</summary> There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html). If those don’t help, you can always [ask the humans behind Greenkeeper](https://github.com/greenkeeperio/greenkeeper/issues/new). </details> --- Your [Greenkeeper](https://greenkeeper.io) bot 🌴 Co-authored-by: greenkeeper[bot] <greenkeeper[bot]@users.noreply.github.com>
This issue proposes a design for the fiscal year module. It mostly presents a user interface based off the ideas in #270.
Changes From 1.x
Our previous 1.x implementation of fiscal years went through many iterations, mostly due to a lack of a formal design. Here are some things 2.x's fiscal year module will change:
period === month
.transaction_start_number
,transaction_stop_number
,start_month
,start_year
,fiscal_year_txt
-->label
Fiscal Year Database Schema
The new database schema for the table
fiscal_year
looks like this:Mockups
The fiscal year page draws heavy inspiration from #270, but includes only details that make sense to a fiscal year. Figure 1 shows a list of the fiscal years created on the main fiscal year page.
Fig 1 Fiscal Year List
The user is only able to delete a fiscal year if there are no transactions created against it. This is done in a confirm modal like #150 (not shown here).
Fiscal year creation behaves different between the first year created and any subsequent years created after that. If the user is creating the very first fiscal year, there is no previous fiscal year, and the user has the option to set the opening balances (stored in period 0 of the
period_total
s). See Fig 3.Fig 2 Fiscal Year Creation - First Year
Fig 3 Fiscal Year Creation - Opening Balances
If a previous fiscal year exists, it is automatically linked based on the
max(id)
of the fiscal year table. The user is also presented the option to close the previous year automatically importing the balances from the last year.Fig 4 Fiscal Year Creation - Close Previous Fiscal Year
Finally, on the edit page, the user is given the opportunity to see the opening balances (uneditable) in a modal, or close the fiscal year (locking it).
Fig 5 Edit a Fiscal Year
The text was updated successfully, but these errors were encountered: