pt/notes
1
0
Fork 0
Code Issues 1 Pull Requests Projects 1 Releases Wiki Activity

move files around and add email options

Browse Source
This commit is contained in:
Trowbridge 2019-01-10 16:24:17 -05:00
parent fc9e9af717
commit dc6439c94b
11 changed files with 186 additions and 241 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

0
Change in Margin Walk.xlsx → analysis/Change in Margin Walk.xlsx
View File

40
price_mix_vol.md → analysis/price_mix_vol.md
View File

@ -1,21 +1,21 @@
Only applies to items that exist in both sets of data
**Change in Price**
( P₂ - P₁ ) Q₂
**Change in Quantity**
( Q₂ - Q₁ ) P₁
_To further break out change in quantity_
Change in Quantity - _Volume Related_
Q₂ ( Q₁ / Σ ( Q₁ ) ) - Q₁
Change in Quantity - _Mix Related_
Only applies to items that exist in both sets of data
**Change in Price**
( P₂ - P₁ ) Q₂
**Change in Quantity**
( Q₂ - Q₁ ) P₁
_To further break out change in quantity_
Change in Quantity - _Volume Related_
Q₂ ( Q₁ / Σ ( Q₁ ) ) - Q₁
Change in Quantity - _Mix Related_
Q₂ - Q₂ ( Q₁ / Σ ( Q₁ ) )

3
email/selfhosted_options.md Normal file
View File

@ -0,0 +1,3 @@
iredmail
mailinabox
mailcow

17
experience.md
View File

@ -1,17 +0,0 @@
what i'm good at
-------------------------
* Modeling historic and forecasted financial & other events
1. Employer - Supply Chain Team - Ground up forecasting of sales, inventory, and operations which feeds financial projections down to cash flow
2. Employer - Sales Team - Build sales database (Postgres) and analytics for the sales team synced with financials & ledger
3. Employer - Ops Team - Develop detailed standard cost transaction ledger for production analytics syned with financials & ledger
4. Employer - Finance Team - Develop Ad-Hoc consolidations and real-time financial statement logic
5. Side Proj- brother Seth & I - Develop basic general ledger application (in-progress) implementing the concept of basic pecuniary record (Goetz, 1939)
6. Side Proj- brother & I - Develop ETL-like tool for quick storage of data from third parties (bank data, competitor products, API results, etc)
* Dealing with limited-value tasks that need to be done
1. State & Local registrations; filings
2. Bank recs, account recs
3. Integrity of balance sheet
4. Audits, formal financial statements

2
marketing.md
View File

@ -1,2 +0,0 @@
new business startup on $1000 and 90 days [blog](https://medium.com/the-mission/seth-godin-new-business-5-step-fdb354988c23)

20
master_data_nodes.md
View File

@ -1,20 +0,0 @@
CREATE TABLE mast.node
(
id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY
,nam text
,sch text
,doc jsonb
)
CREATE TABLE acct.accm
(
id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY
,nam text
--reference to node ids
--should be limited to certain types of nodes, like location, product line, fsline, perhaps an enum?
,nodes bigint[]
--node attributes pooled here
,doc jsonb
)

152
production_scheduling.md → planning/production_scheduling.md
View File

@ -1,77 +1,77 @@
Logic to setup production plan, inventory balances, purchases, and shipments
Starting point
- known balances STKB
- known available BOLH - not posted
- known prod schedule SOFT
- known shipments Sales Forecast
- forecasted orders Sales Forecast
- machines that a part can run on ??
- actual run-time performance Alternates
- actual BOM performance Alternates
- actual scrap performance Alternates
- available machine time ??
Populate
- forecasted prod schedule
- forecasted on-hand (via forecast perpetual transactions)
- forecasted available (via forecast transactions)
- forecasted purchases
Iterate through each calendar day
1. materialize forecasted purchases
1. update on-hand & available
2. materialize production
1. update on-hand & available
3. materialize transfers
1. update on-hand & available
3. materialize shipments
1. update on-hand & available
4. process forecasted order submissions
1. check for inventory available
1. Yes
1. mark unavailable
2. schedule shipment for request date
2. No or partial
1. mark unavailable any partial
2. schedule on next open slot regardless of request date (each part should be mapped to certain set of machines)
1. raw materials available
1. Yes
1. mark unavailable (at begin prod date?)
2. No
1. mark unavailable any partial (at begin prod date?)
2. schedule a purchase net of lead time
2. sub-components available?
1. Yes
1. mark unavialable (at begin prod date?)
2. No
1. (return to 4.1.2.2)
3. schedule transfer of production after completion if necessary
3. schedule shipment for request date, or production date if past request date
snap-shot STKB
snap-shot BOLH
snap-shot SOFT
some notes
-----------------
* shift schedules
* parallel resources
* setup time
* efficiencies
* scrap rates
* blends
* known 'A' item volumes planned regardless of demand
* visibility window for incomming orders
* grouping items to reduce change-overs
* initial start-up: merge with current machine schedule
* limit start date to child item availability
* procurement mix
* purchase lag
* transfer lag
* order priority
* inventory minimums
Logic to setup production plan, inventory balances, purchases, and shipments
Starting point
- known balances STKB
- known available BOLH - not posted
- known prod schedule SOFT
- known shipments Sales Forecast
- forecasted orders Sales Forecast
- machines that a part can run on ??
- actual run-time performance Alternates
- actual BOM performance Alternates
- actual scrap performance Alternates
- available machine time ??
Populate
- forecasted prod schedule
- forecasted on-hand (via forecast perpetual transactions)
- forecasted available (via forecast transactions)
- forecasted purchases
Iterate through each calendar day
1. materialize forecasted purchases
1. update on-hand & available
2. materialize production
1. update on-hand & available
3. materialize transfers
1. update on-hand & available
3. materialize shipments
1. update on-hand & available
4. process forecasted order submissions
1. check for inventory available
1. Yes
1. mark unavailable
2. schedule shipment for request date
2. No or partial
1. mark unavailable any partial
2. schedule on next open slot regardless of request date (each part should be mapped to certain set of machines)
1. raw materials available
1. Yes
1. mark unavailable (at begin prod date?)
2. No
1. mark unavailable any partial (at begin prod date?)
2. schedule a purchase net of lead time
2. sub-components available?
1. Yes
1. mark unavialable (at begin prod date?)
2. No
1. (return to 4.1.2.2)
3. schedule transfer of production after completion if necessary
3. schedule shipment for request date, or production date if past request date
snap-shot STKB
snap-shot BOLH
snap-shot SOFT
some notes
-----------------
* shift schedules
* parallel resources
* setup time
* efficiencies
* scrap rates
* blends
* known 'A' item volumes planned regardless of demand
* visibility window for incomming orders
* grouping items to reduce change-overs
* initial start-up: merge with current machine schedule
* limit start date to child item availability
* procurement mix
* purchase lag
* transfer lag
* order priority
* inventory minimums
* tool availability

102
sales_planning.md → planning/sales_planning.md
View File

@ -1,51 +1,51 @@
A method to planning sales
----------------------------
## Summary
1. copy history
1. start with open orders
2. add orders as placed in past
1. true-up to current run rate
1. normalize price for current pricing
1. will need to idenitfy blocks in the base period that best represent pricing efforts
2. scale prior periods to match final pricing
2. exclude expired products/customers
3. scale new developments to reflect full-year (new products customers)
4. update cost to current
5. request date attainment performance
3. walk prior period sales to new baseline sales as change in run-rate
2. build in changes to current run-rate
1. volume changes
2. pricing changes
3. new products (must be defined in future at a mininum)
4. future cost changes
5. request date attainment
| timeline | day | running days | responsible |
| -------------------------------------------- | --- | ------------ | ----------- |
| **_establish run-rate sales_** | | | |
| copy history | 1 | 1 | executor |
| identify pricing windows | 1 | 2 | sales team |
| scale windows to match final | 1 | 3 | executor |
| identify expired products/customers | 3 | 6 | sales team |
| eliminate expired volume | 1 | 7 | executor |
| identify new products/customers | 3 | 10 | sales team |
| scale new to full year volume | 1 | 11 | executor |
| **_load new plans_** | | | |
| layer in planned changes not yet implemented | | | |
| identify changes to existing volume | 3 | 14 | sales team |
| load changes | 1 | 15 | executor |
| identify changes in price | 3 | 18 | sales team |
| load changes | 1 | 19 | executor |
| identify new products | 3 | 22 | sales team |
| load new | 1 | 23 | executor |
Table Layout
A method to planning sales
----------------------------
## Summary
1. copy history
1. start with open orders
2. add orders as placed in past
1. true-up to current run rate
1. normalize price for current pricing
1. will need to idenitfy blocks in the base period that best represent pricing efforts
2. scale prior periods to match final pricing
2. exclude expired products/customers
3. scale new developments to reflect full-year (new products customers)
4. update cost to current
5. request date attainment performance
3. walk prior period sales to new baseline sales as change in run-rate
2. build in changes to current run-rate
1. volume changes
2. pricing changes
3. new products (must be defined in future at a mininum)
4. future cost changes
5. request date attainment
| timeline | day | running days | responsible |
| -------------------------------------------- | --- | ------------ | ----------- |
| **_establish run-rate sales_** | | | |
| copy history | 1 | 1 | executor |
| identify pricing windows | 1 | 2 | sales team |
| scale windows to match final | 1 | 3 | executor |
| identify expired products/customers | 3 | 6 | sales team |
| eliminate expired volume | 1 | 7 | executor |
| identify new products/customers | 3 | 10 | sales team |
| scale new to full year volume | 1 | 11 | executor |
| **_load new plans_** | | | |
| layer in planned changes not yet implemented | | | |
| identify changes to existing volume | 3 | 14 | sales team |
| load changes | 1 | 15 | executor |
| identify changes in price | 3 | 18 | sales team |
| load changes | 1 | 19 | executor |
| identify new products | 3 | 22 | sales team |
| load new | 1 | 23 | executor |
Table Layout

72
AD convo.md → postgres/AD convo.md
View File

@ -1,37 +1,37 @@
[mailing_list](https://www.postgresql.org/message-id/flat/CAHq%2BKHJOvZT8M-o_sE%2BQzqqBGnUjNubWo_rRmpHZyw5ZUuaseg%40mail.gmail.com)
wouldn't that be Pg authing against the OS (pam) which in turn is forwarding to krb5? which seems like an extra added step
sfrost [11:11 AM]
it's basically this:
ktpass -out postgres.keytab -princ
POSTGRES/centos(at)MY(dot)TESTDOMAIN(dot)LAN -mapUser enterprisedb -pass XXXXXX
-crypto DES-CBC-MD5
(except adjusted a bit to make it not use a shitty crypto)
you use ktpass to create your keytab file
copy the keytab file to the Linux box
arossouw [11:12 AM]
Seems like effort, i'll just play dumb on that one
sfrost [11:12 AM]
oh, gotta fix the princ too or whatever
but it's not that hard
and you might have to configure the realms, but not necessairly (that info is often in DNS already)
then you just tell PG where the keytab file is, set gssapi in PG's hba.conf, and create your users using their princ names, like 'sfrost@SNOWMAN.NET'
dtseiler [11:13 AM]
I’m with @hunleyd, I’d love to see a great howto post on that.
arossouw [11:14 AM]
I suppose the question is what is the advantage of using kerberos, and then deciding if its worth spending time on
sfrost [11:14 AM]
I just wrote it
^^^ see above
also wrote the advantage...
hunleyd [11:14 AM]
[mailing_list](https://www.postgresql.org/message-id/flat/CAHq%2BKHJOvZT8M-o_sE%2BQzqqBGnUjNubWo_rRmpHZyw5ZUuaseg%40mail.gmail.com)
wouldn't that be Pg authing against the OS (pam) which in turn is forwarding to krb5? which seems like an extra added step
sfrost [11:11 AM]
it's basically this:
ktpass -out postgres.keytab -princ
POSTGRES/centos(at)MY(dot)TESTDOMAIN(dot)LAN -mapUser enterprisedb -pass XXXXXX
-crypto DES-CBC-MD5
(except adjusted a bit to make it not use a shitty crypto)
you use ktpass to create your keytab file
copy the keytab file to the Linux box
arossouw [11:12 AM]
Seems like effort, i'll just play dumb on that one
sfrost [11:12 AM]
oh, gotta fix the princ too or whatever
but it's not that hard
and you might have to configure the realms, but not necessairly (that info is often in DNS already)
then you just tell PG where the keytab file is, set gssapi in PG's hba.conf, and create your users using their princ names, like 'sfrost@SNOWMAN.NET'
dtseiler [11:13 AM]
I’m with @hunleyd, I’d love to see a great howto post on that.
arossouw [11:14 AM]
I suppose the question is what is the advantage of using kerberos, and then deciding if its worth spending time on
sfrost [11:14 AM]
I just wrote it
^^^ see above
also wrote the advantage...
hunleyd [11:14 AM]
maybe i'll try this as a 10% project some day

19
sales_meeting.md
View File

@ -1,19 +0,0 @@
pivot table (done)
* order days
* ASP & ASC
* calendar year
data rebuild
* Field names need to make sense and then evaluate
* Break out bill-to ship-to
* difference between forecast and actual, or budget and actual
* orders versus budget
* sales versus budget
* bring currency or value in original currency
* open orders - request date
* forecasted available date (Marty claims it is available)
* get rid of goofy fields like `FLAG-O`
forecasting
* Forecast iterations (evaluate at time all the other fields evaluated)
* Mechanism to build a live self-informing forecast

0
sr.ht → sr.ht.md
View File