diff --git a/Change in Margin Walk.xlsx b/analysis/Change in Margin Walk.xlsx similarity index 100% rename from Change in Margin Walk.xlsx rename to analysis/Change in Margin Walk.xlsx diff --git a/price_mix_vol.md b/analysis/price_mix_vol.md similarity index 84% rename from price_mix_vol.md rename to analysis/price_mix_vol.md index 3ec249b..f26651a 100644 --- a/price_mix_vol.md +++ b/analysis/price_mix_vol.md @@ -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₁ ) ) \ No newline at end of file diff --git a/email/selfhosted_options.md b/email/selfhosted_options.md new file mode 100644 index 0000000..1e9a725 --- /dev/null +++ b/email/selfhosted_options.md @@ -0,0 +1,3 @@ +iredmail +mailinabox +mailcow diff --git a/experience.md b/experience.md deleted file mode 100644 index 0ba90b3..0000000 --- a/experience.md +++ /dev/null @@ -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 - diff --git a/marketing.md b/marketing.md deleted file mode 100644 index 4121591..0000000 --- a/marketing.md +++ /dev/null @@ -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) \ No newline at end of file diff --git a/master_data_nodes.md b/master_data_nodes.md deleted file mode 100644 index 3e5cae5..0000000 --- a/master_data_nodes.md +++ /dev/null @@ -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 -) \ No newline at end of file diff --git a/production_scheduling.md b/planning/production_scheduling.md similarity index 96% rename from production_scheduling.md rename to planning/production_scheduling.md index e42eae2..43a3596 100644 --- a/production_scheduling.md +++ b/planning/production_scheduling.md @@ -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 \ No newline at end of file diff --git a/sales_planning.md b/planning/sales_planning.md similarity index 97% rename from sales_planning.md rename to planning/sales_planning.md index 92df6db..cdeeffe 100644 --- a/sales_planning.md +++ b/planning/sales_planning.md @@ -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 diff --git a/AD convo.md b/postgres/AD convo.md similarity index 94% rename from AD convo.md rename to postgres/AD convo.md index 76de892..7bd20b0 100644 --- a/AD convo.md +++ b/postgres/AD convo.md @@ -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 \ No newline at end of file diff --git a/sales_meeting.md b/sales_meeting.md deleted file mode 100644 index a67c400..0000000 --- a/sales_meeting.md +++ /dev/null @@ -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 diff --git a/sr.ht b/sr.ht.md similarity index 100% rename from sr.ht rename to sr.ht.md