From db5089545965cac5792004a3b1af69bea2f1ee87 Mon Sep 17 00:00:00 2001 From: Lance Edgar Date: Sun, 20 Mar 2022 13:57:06 -0500 Subject: [PATCH] Add more docs for Feature Layer not complete, but progress.. --- docs/_static/batch-pattern.png | Bin 0 -> 20546 bytes docs/conf.py | 2 +- docs/data/batch/overview.rst | 4 + .../custorders/cancellation/index.rst | 6 ++ docs/features/custorders/entry/index.rst | 52 ++++++++++++ docs/features/custorders/fulfilment/index.rst | 20 +++++ docs/features/custorders/index.rst | 32 +++++++ docs/features/custorders/purchasing/index.rst | 12 +++ docs/features/custorders/receiving/index.rst | 15 ++++ docs/features/custorders/reporting/index.rst | 52 ++++++++++++ docs/features/index.rst | 14 +-- docs/features/people/customers/index.rst | 64 ++++++++++++++ docs/features/people/employees/index.rst | 32 +++++++ docs/features/people/entry/batches.rst | 36 ++++++++ docs/features/people/entry/editing.rst | 32 +++++++ docs/features/people/entry/exporting.rst | 42 +++++++++ docs/features/people/entry/importing.rst | 27 ++++++ docs/features/people/entry/index.rst | 16 ++++ docs/features/people/entry/merging.rst | 44 ++++++++++ docs/features/people/entry/overview.rst | 32 +++++++ docs/features/people/household/index.rst | 53 ++++++++++++ docs/features/people/index.rst | 22 +++++ docs/features/people/members/index.rst | 80 ++++++++++++++++++ docs/features/people/users/index.rst | 39 +++++++++ docs/features/products/entry/index.rst | 5 ++ docs/features/products/index.rst | 14 +++ docs/features/products/inventory/index.rst | 5 ++ docs/features/products/labels/index.rst | 5 ++ docs/features/products/pricing/index.rst | 5 ++ docs/features/products/vendors/index.rst | 5 ++ docs/features/purchasing/accounting/index.rst | 5 +- docs/features/purchasing/index.rst | 17 ++-- .../features/purchasing/ordering/additems.rst | 22 +++++ .../purchasing/ordering/convertpo.rst | 21 +++++ .../purchasing/ordering/execution.rst | 22 +++++ docs/features/purchasing/ordering/index.rst | 10 ++- .../features/purchasing/ordering/overview.rst | 27 ++++++ .../features/transactions/importing/index.rst | 47 ++++++++++ docs/features/transactions/index.rst | 17 ++++ .../features/transactions/reporting/index.rst | 57 +++++++++++++ 40 files changed, 998 insertions(+), 14 deletions(-) create mode 100644 docs/_static/batch-pattern.png create mode 100644 docs/features/custorders/cancellation/index.rst create mode 100644 docs/features/custorders/entry/index.rst create mode 100644 docs/features/custorders/fulfilment/index.rst create mode 100644 docs/features/custorders/index.rst create mode 100644 docs/features/custorders/purchasing/index.rst create mode 100644 docs/features/custorders/receiving/index.rst create mode 100644 docs/features/custorders/reporting/index.rst create mode 100644 docs/features/people/customers/index.rst create mode 100644 docs/features/people/employees/index.rst create mode 100644 docs/features/people/entry/batches.rst create mode 100644 docs/features/people/entry/editing.rst create mode 100644 docs/features/people/entry/exporting.rst create mode 100644 docs/features/people/entry/importing.rst create mode 100644 docs/features/people/entry/index.rst create mode 100644 docs/features/people/entry/merging.rst create mode 100644 docs/features/people/entry/overview.rst create mode 100644 docs/features/people/household/index.rst create mode 100644 docs/features/people/index.rst create mode 100644 docs/features/people/members/index.rst create mode 100644 docs/features/people/users/index.rst create mode 100644 docs/features/products/entry/index.rst create mode 100644 docs/features/products/index.rst create mode 100644 docs/features/products/inventory/index.rst create mode 100644 docs/features/products/labels/index.rst create mode 100644 docs/features/products/pricing/index.rst create mode 100644 docs/features/products/vendors/index.rst create mode 100644 docs/features/purchasing/ordering/additems.rst create mode 100644 docs/features/purchasing/ordering/convertpo.rst create mode 100644 docs/features/purchasing/ordering/execution.rst create mode 100644 docs/features/purchasing/ordering/overview.rst create mode 100644 docs/features/transactions/importing/index.rst create mode 100644 docs/features/transactions/index.rst create mode 100644 docs/features/transactions/reporting/index.rst diff --git a/docs/_static/batch-pattern.png b/docs/_static/batch-pattern.png new file mode 100644 index 0000000000000000000000000000000000000000..6e04df79d9474505b1ff8852cd62755f0e4782ce GIT binary patch literal 20546 zcma*P1z1$;*EVh(;V2@;u|VM%fI*0qD2Ryxh=MeNigXEx$WXQ-r63?Rph%arNU10x zF(3>bD&0BK%>Ukl`g{NH_rBlt9nR(P414x|Vm)i!>t6TTF6YmkVqL+$V$q^StY=Q2 zP+YWV$&*Ek7B~I91fR6*-V(QH(fQ?PP8_{>t6?D6UQKyfZk~PbCa>2b+68X9`Ww@3 z>=72W`69zjr|Ni~> zh}N>dXr)7A)>|j?L(MZ*937mPyJwL2`Q5-=ed}DpP=iULO>^GjMTe;1LM z@P{jHHV^-)hzm8qf5unhkM7O*Lux7hAg(wMI1zoh67Gt2pCkw*JUSjC&3`uHe2U#PFIXSbVo+o;L+^zc(bkxSFf z?`#@#?8QmBH=j&-waME|w%89*L*(vt?&UhoRkYEmBRD0~x=Te>HOye|o^OSm_HoLw zDt2~u1*fGdLS+=+zgC!TXW{RyD_+Vb`7|iVjT|3-+jgKKJTFDRY`=`t@CW9IXaDT$ z@jg6ttfVrtC}uW2G1Pkb>WUZRc2|lw zYTPBWK4j(a_4d9;PMlkE)7G~3-jqS*y?D(G?Kih2?Cy`B32}JI-K}0%U!R$onf8yA zpw`i+GH`?u@NH$J9|hIMt6_*F^iw9V9B zotvf=gmP-hFJ9WSbn2LrEoCXw%C|qPKUIub#NAd1IozCPQfuD)u4nNwx#`ymxfT0q zvpRH|j&WjQ=SG$8DRGteoxBmZ&xCCBb$D4%Yf3Soym|8`R_k9D=Q|4~@@H@V zCrkQ&Fp2+sE$sg^$RjMZ)+bMXw!uSccM8 z`s-6R3TT~{#I1r$UkJ4Y+qRrJd-h9dX(@#w$j>ijH+pTXPd#g;latfJoxXjzw~lHPt*%mEQXJ=zXKL;8gt=xQ!F(T83 z)SjP>7PeMaqd$MHVr7*-cTQzOOH;G4lr%rxml!D@D6=r~;6t_*p+^M-1afn8*Q{A% zWMp*muIGWj~Zti*sLC$jisa$Iaa_Inw5S;V$sv9&YvsZ`@Zd-}|75$d&fB+d zcXxMVU%!4;ls(sIt|2us*nDWuo+peO_B5pR@rF43`2Ib~eq!(*Gn>AFfvSp%*w`GI zg@xtNjqdBc)w_wg?0p>?`o5q*zbrtsG2N^&%hux9v18`u3EX~TrW#U@9z2j5e!rCQ zY!^R2RX>4CVy1Q91_rjSUF#JTQnhcfqj2WZX%EnO#oPJ-p7&^rE7o{6}o`(GtN8 z0NbxzAl9<#mvT8T3nnon>rBj)fy+Nt323+nZ09&=xPB z@Li?!EmAuDnV|-^BY4Ebus!L0wTTm>qbpXeIwvPrT2hk2c=Xs{bCzIz*dn$0X92#x z5kk#bw&F}wZjEDQ zWd4xaQtP9XMe^>S9J+#S4@yW(O-|l__%P!2YaD~>ni{bbvLB!Ne*2%MKkmrPo)%rT zyS8?C>PO`!cP?RlH=$ektm1~lpEv3}f1|wKH*T7XKKTgyvCQ4+sII?Q@%#Mzu=&cN zsj;p=4=3>hS1t5kbC)E2lF}!;Rvb>XtZSVdJaUhf+_OxaT2*EJ?fo4wF|h!Xx;Ixg zZ{8e{34?sNYOAq>=kT|CZ0|BNMb$3L%a;)c3(kf~FyN@U`QRs)b?%9KM9N@;A3uH+ z(T=UkCLNViVn1ZSCN=(aYI9k3w!Rouq&7g*Zd2H(6;co-`ksa_?R~j`zL0cT3|mxN-vuyyCxlykW|^IneO_@o1BON}N_^@`p-` zk}Lz^k|Zq(W}n10HeRLR_x$;DKfk`C_nL!UZ75!P=gxVg_s$IEB@PvR`*wL?<(WE? z`uO5&4wY{Z4X4M9H9&Z`=xG`V9pw@L}By?H;o?t--KGLl%z78aW6 ze5PTfHeJ-_4k`4*bn6!#IZA~3`0lWyId2L=wXd-T1Q_W`pK)}avt!$O@LH!t%XQzk zZ{IStrEO1(pH{tc>fj@YA8N5_P<`(0kNUaaCPAm1Mmk-rx~z3}?_nZdVh9un4_ zZ?m#YcomM7mX{|)MZM+o7Rx2a#>Nix_rnXgFek`RcuY-AudPy5Rjv9|J2k}L0%^%#KPFmU0)+7ky}{% zI<-@rHmhFBwnXcxH?Kl(@XvfU>02ZcPNn$a!-vJiGh$+5{Aoc!L2-lrw?dQNb&Uzp zo5!Xi-TePvvEm?|MR#3Wp{Ht~d9g}(c=%>k!?_SEBd%k*8~8PDd>C@!uT7ciP>V7c zql8z|_(TIFSSV}5d-7!uaTm;c-|5+ud{DI~1!##hTdkzfqvPS>;ahs^gK}W&#qpKy z$1YzEwUnR?G-f=ye}5-8_obQ+$-uJ|xDnN~)odccWOwg-a*?k`LOiYO9U9YmO zV?Ed}X4Y`}$p&*DcBL~3^NYVTmAksSX6=^>)bZdZ<+fW3{p6QpzRxfH)-g%w_@h;3 zZ&Iu>Nn$U9*IHN%G1*_(amqu)%O|pJZSEXqjAxGhD6{YPt6OwQH|CG{aXZ>)yS0&;4lImNuWgs=XsGk3SmBqt7#?+~}@2 zdM`pyUQq1otQBA77aS~5t;~Dr% zjWbHDproYa^x5Wz5s9sH92`xV)&_HC*M*$Ngvs<1r51Zg4`sfm)oOEy8dobw&y5oi zd#!SjpN#}1;%iF!nVC1AmdeK%ggxRsbTh6e<_f7PlzacG;dGPQ@&n{(Ha*AZ_9T+_ zbt8cE-sPc6sjem|?o~^6es)>MD>iw@dupKaQ)2FPj7p3_e4aOtd<=bk^4pogEcXtP z0|&1<6|m%X>Wi(HIv!S$VWHDzMUIJE%Dn2DzP_)I&!rlpM)_A=S%dFNW_JfH;(vPB zaXO0LnVG8QD{#qJq#|4O<%1op*g4CQAD>knBq%(UK(G&jgPZj(J>InFn^%Z!fna?v z{mAA}J*)BV3mhDQ1bA;u=Ra`Zz_xAQtpvO3cal8Z-1>1SMiw2>y|Sfus5*L``NP(~ z$Yk=RcQ-Nv;FMg*e*BtZx&(fkB5ksHtIQ6BZB=LQudmMoz7A;b7U1_MRo8mAv3TVr;Y}x0}pSMbp#t~r3 z;=0DiZ!j}6FJQo-mYknIf8w|`W>~ahK@}Ah0RiOY<%RpyHHEK!`g>sxjTU)1L%B0S z!NG*xZ`j})5I~xp94W~OGHC0wEB4|>+QP$0Am|8;-eGb$HkJXo+Q-HBBAg%Is1O~$ytZQh{o@4x`;knb? z^cn`19~>OaXm!f+_V&)mur)L^1QPeTRG#vTmW>&k4Dm=HC)u#yq9yz2J*LdJZzrdx zWlo%U9UgwEo^dB({Zh5$Ys(p!Z2!&vx{cbmt{}gfpP#>Q;ld*}u3RFtB$FSpazxxD zGmz+1KG%HcIcixM|Gs_0@9!*CS64@Fqw0`u6V`*|wjAl$c4GR+dV6~t(#^7Njr@?2 zFw3eO*HTk6G%zSMY9vybojg1Zb#-xO>qR`siOA93n5)F8eedbXv>j@hoSbZGYC;s~tWAkZND$by>$I$_tDD=(l`F@G zhbLim?~R`ZQV((+xc;r;<#B8zuL9Y04JjcydiS0^U%q@fD<|jn`0>-1&LA@0u;0CV z_f=S!lAr58XZ<*Zh}RS(0wyeqmv6FRxUWXV^%U{15k-k+4}=SyjiWsHl(+ zJH9*Ft)8`<_gv7f-Me@1+Er1YckS91uorLGJ+?@Ag@owfuwA(D(wAn8oI*~@MEqrX zdiuL}8d)o`YXrlhw$3VKr5a#|xK5cM8D@viD%3)|==m)zWZR`vOYrlm%lETQ?WI$! zPX&n|5|7irI>gVo-0XAl|NhC5+;*0BSF#HT58_8^oiuU9)GLD@%%jWjbCU9j4OcL( z330fCpGx78U(X?~;a<4$kzC@Zdn#s=Jl5zoCmJ2EozocY(lJFk3tyr#=Q`ttil#`hMUW}WiAv-76Ytd1jX{ezl#caAD=I32Xj!<;oSAS)@__{8`y!NIa0hoxgNRUg-BTcJpby z9iE$Lja>O_b{YS|SKhmKZ}-w)YlvO?MSkIL{{z|eUi5WW-?!RV>MbJK{lwGdgDsSL zrdlh;yKMya?v0I$i%UpIh>w?YoE}e9X~~{sToWKjnl~#92@ZDbuS?Q#nmTE*BxmU^ z3+%}#cdN+`o$=X54{5l67&T}j67#IFpBt|ZhV&q!e4`XSy^U@8a*12Rp)HFWPF1a9 z?~u=Jm(6XrH-kMmH;&9qPxo#ObxiH=?@vzN|0U3&*w3MOq5(F7Z_<%JJIzmZ6&0Nx z2%SUH_*{I-OK{3-DD9abDI%M=)X!nD)Y1-Cj8rza+kbNR!npopg@lbo{<;!2rPPA! zj^y4Z-x=k>_;p};-TuU1VTI!>3Bx5GfbU=i`0cOH7EJa3cN@YG|La{oDcE@n681&P z?N$=CM6Lwa{Bx+4?kbpjz`C!E z()_%iKYyK*9cYoOo-*E3RajOQKR=G(3lLDf$JERWR_puh*->Jw#6k*^at&v}rhxva zez8%uEhR{=}1Qr-B0GVURJvzX{Sw$&}*a%CEWf zd3)Bw;}yq$?F`ng>*0uaD8d{V0eyX=+Js>LN%;R5p`%BSZqy9^+3a>SXQ`VK=PwH) zc3@-kq1c!h(nPbZsD69Vvw|0JerLRSYzCV$!G+Q&+eFsoVbTR!!%ZK@c+Ky$-qgys zZzZfqHdlo_WT8y?Q5~(su4`gqvT_xtq}n~#4gAK#j!YwTnY^s+zqYydF4;YJf0c9F zj~@b?>D+AO^Mol7|GJVB+rJeP*`*M%Oy9ov?4_wCe#TL2z3jVc>p{aepie{!4$wkD zvyc)E_lb+Emc0IDQ^gylbhKw_d8ya0Uw^sD%s1*Kh2ZS-#|ECl3zneDG7mgyvnZrq1u%IO* z;~5={{6L63rC4@43l4CHkc1% z(!amu5;Ds4`@H^HFk*EOSt^9jw;Scu|ZpW#ykppZYO2~T0TTTEcV>HK~M z{NjIESvT@;m$I-K3#aD4?8g7i`4GE-AtXKlG61nNHx@z3}aro={oG)_CN`( zR>!&7`6_H>1RQKXHMSN2Dg<;H&xZz$H!<|UpEhuPfX$hM2 z3+e)w4Gd~yl=m_-KgxBS@z^AE72p$yZDu&1EpK+TBwW@n0pstF7b? zZ-vAD;ubAgK(1e91*Jwlt%Kjsq}6D448eb7!q}ast3o0aLgvfFTTh%i1t0SS+XwT* zPS`K@^73kLZppDP2?es>y#Lzc20hU-t6`KBUVq2&M=Y?rbqgsn3B?S1```z|;vFw1ka+()wzhX;js(KdmWJk=k12x!)ghIMHWX*|-inzzHl~ zy!e#ImTfw{zqUvvI8pnRdWycyK!dUhJkShPL=b3ypdn2$nf>aN+BqLBZVix)@87=% zO~$-z*)psQxN3lbM~{#Y_DjpQOSm0%uXPrcH#F?Vnu)mT6Qu=kP3@QY<>!5yS*@M1 zJ;o8#YpqT*1ICHqO=pUBc$Ok8@7WXMWFenh{p(C7jyUM*>K3|f-m#_y!zY##zg!c3E%U2nm zP3v5~e0jiy6q6hc4__W<*%pmStg)VByllDH{T%%=_5qQo5EWHamHLprp%8VZ@%W#y z2ny<)F$aNxQqLC(#o~LS*NMq?Zv}1VIhwIwS6N^NiDrE2)Txc&ylrhQEG#4xr4r(z zSE+IOC~>R0`~F*yMUfi0Tb;aCBvro~ufvqAYO(B%W9=N)<0bK3d%OCC{hdAnt; z17wuQl6HzFwQd19uU?^U_O;!jSd)cPR^~%X6Od?Jo&Ixq^)-&I=~qk!6nCj`adBm; zYeso!aYS^S&tq&n{Im6G$=)@38{V z)Qax5I@9NHuq`q>HVlYMPBdBTU{e~>OoD@g#4K9k^e+nf&GN4K^7t!xOEjly%|&KD zdU3Q@?91;m4w-VJVx{q_3Vn*&#M*{yi`MsgQqwrnJzQKah$n75@0cQ{DB#y1x{)S3 zw*XyoPAugQiDr2&nR-*y4#Z0nk_K1|*rxFsO$(`?b-FmSLgk81qs6?f4r65$X}SZP z4Ni*t%=RJ&qz&Lsn`0AmNffCGEsS*4s#U$6($n2x2*?r#526mmUYL~j;KPRx4H{Dl z+n=uqm&q~wN}kruOtJKFI3xG5=J1^W)3AIoQ+}?!=cNP(q`FVmoSsunl=w47(MPYh zheb^(_3fr^F4WJ@&z~4*#t3P`lz{7mk=i#q#4)#Yeidao32cojR0bXIR30R zs)}%gyC7`{m_#+e#l@wgqoYe&DgIo-*T0ac+upo6KhsJ-Y&Y7@OTP6AehgHzhCb#; zxK(7vnq(F6M59zWb#;z!U0nuS3Trm-?A+P?z>B`~SbUUvoM}Y9N^ODx>Bpz#W`RGQ zQul_bswKrxYl<2gGwwtVSIbp8U8twCCd++dm5bjD!9ja~Fk#jQ>sHjA1 z`oz1ZJa=?-q<#cLVm8)UMy&Jf)EEkV^I!HRx@|r56MkX{n8Ef=06!YA5Q;cb&V`EeW1ATq=LVdkHu(U5;Y-;1{ zsHix9ysp6IOM_LLB4@8UeBnAYZGJ=eg%z!OtT47XQFqFC{%}eM1(Ul#i)Y^z-qF zJ|pEc`}Uo3eZv7+3HUpH(__c(ZtL&vHl(FJOrf>`cd9n{YPt8_`g^L8zJ=rwQOKT1 zCp(v|=9e$IIFz9LA~%gXcsKoZcDB~c>IUy4rHsQkzOp8~YfRyy?}l(Cvz5Tnv-2;xL-a_T|^g@jI#zA=fSLGhg8K!3l-I5R9U-Y@4Vs!f-o2W-;_@QrS1 zK5rF9Kd=HbXBuBw8$d2Qq$!{N(u|h1-&S4S|AeNMuTJk3x5_+`J3LjN0!|9U4}Cpg zy@E?A52$Hsl1FEJW%uR^;ZOs>jX6c)!-W)wxLtSV@}!K6u9Klo09#=OK+gQv@c`A>+0pS56YTb%4tJ_d30L_! zJbVk;A$+PYDzt3CAYY#ECLBaBHCEiT?q61mhSW37!!_}m@F&?hIgY5oJ37wI&N?ML zYE^fe`D(&m72o40sB;(zTCKKyyfb|s>{=duZisv60n5h0`jo6p<O`~GxKv`{~#*95NIgVBSugcMRj6kVo2Ql zN*0}uJ#1t;5v99;mbZdAAC+_x!i#G(!lrw$-Y7;-&(912^UygrZhQpLiB-ij-N^J{ zA0Jw8Y+^%wJ*}szD`%o*rZ#Ur4aBj5fq{B`Rh7~nA1_32m9OrI(k?E~POMwE4%8p0 zqp$ddECoo)Icn+XL3BRWNG>Bnd{8#A4(>876`WaJo!XRk zjbA+V88Z{po`&^%RkEQHV3Qnvk0MrGo-cslSEM2lBRS1~SX}t1ON6+G=Opq3^k%FmJGcz+`246Tj zhPR*3>#lz_2}V?)_>6R(ON3o{kOZnQ&K*9gDhXPdDCD_wh{x!*BcDSGt*-YWzjq`v>8dOJ0~!_Ww51>E9jPMn}-><-G8FN#sc#l;Q$Ph+UcCR|rh z21OP>lt<4!Xp~dl($eB(3%XEDVN9{*xj2alhh66%2?7CoO3%M_cP|T>ACL6yH^ z?tJS_Z;h$DhBh*~W>FfKY>+{NwRiK?$Xaz)NbaIvYo0B`iVgl(MqV zjqPSp-&xq$T2VKLfszs50rci3oaqxUgmlHsn|6iGP7C@sC@CmV2rPgk3|SCP@KAO4 zAwbQ{Ow_<3r#U64hd7|3;wzSz`N`o!!n*}RbVlmQ6ue)9%>jqWH|a{iS;}QO^RjkI zE!~@=;1E{P9IOIUw>cNxEErKMrnI)w`x5iWVrCj4haELC%=wk2XZllQefiFuKK*oA zVD%T{$Ml~Wc}DI4Uv@AOr^)ZkF7?>v0|8rCufDvctfnuDC++p?6ZV?`S<3`E$25)2 zd~UK=@7-%*7Wpa8PeXIBv(oPk4?LdWbL=%Mtpb@=@0eR#64?0&rDr)gIn-<{0uAWG zZ$Gts6}yNbQi2jc!P;^6SM8;xaz?k19>Pb7`O^LJW$%vuZy^{ld_{AT2{A zX~S2XbPT#4oLPVUSY{WQa5O6M8Xeu;yY^z6>_{YIchDz_3S3*a#_OGJFPPGSa7uBj zs2mJ&TyE}TT67l+rzbyD8Q1qDS1N)Zlcl2ieL;1gtBZG?{jFPZYDrfsU!5#)e@Q0w zMkDF_l2-6QEHQ6>dV1oaqCwm7QdSoA?&-cy%skX)ZVdlndq-6XpD?Vhyzm+1Oy zp`O{F@w$&5V(3=Tm*AmswV*%<#n5)k45+mQA16P zH1xxCe!7klFd$mzEfdY*!_sdN1sdsM31|7Q)aLo0z_BXj@8O(R5Rqx4=@i$!ReGS$ zw`Y%+*WNvQQswwJ?#@+AaLJ8 z#Taz8h4*=N^-MSx5E87L_qQXz%0UDJ=C?;m`?IfhsPYuoRtc+ius$JDC2&h3WuZs! z4I+GjZfLntB~KJ6fT}>v5>-)K+X*P7z_qLZ?szU9O3X3m7(#pQRA*ozmva;J5h$r4 z%^)Zf>G{bv=ea&Y5m1g_BqY!*eA=h5^^YDEf{DqU?%f+bM`(7^ohPzd(~PQQ*bYyA zTS|qxhV?%yWwHh(2;&EOdTB+-1ZRJIcCC$5-@(lxzDCSk<1L{6`bvNrcTMhr`V`(> zy9|dU?v`JDSLMYsHa1qphZII9)2c&!M#-_tXo))G-o zEG|aED39 zk56@lB&w$rtR6#bnw^^qS5Q~yPktWc>+9?9zq_ZitBXt8DH|CWCK@x(m?$*GCooZ< zurn=I>G#c=D%FzxT&S9|)ZP-Rvf!n68{Hl=G*8uX}-11`yjtvVnmnE2++`NP=KUC{_o4IcwHuuq(>=0hFw zd1i;{@~o(+)9JpBY1e5r#&O}sHdGh|Hca_}fY#gV0P^B3x7yYzNPZt2G!Ggj5ZMneTe5t1k|$iwak%6;LqoZXxx>;|!%iw$(dIJ7`g#d{SPFVXN>k zA70h=qP|-XGDCSjVWRe^ud;=)iOHcWAMb;i*ess{0VCuvuXi0fTWaj5ycPOduPE~K z2kxWmFN@Ul7D0JI1&{#KQ&w6kA_;kCyb}q`08TsmzRS0@4F--xrFgo#Q$+%Z#bx-V z>ldo0%AoI)Cqw*Y5aOtE@nZE=*&}D|f7Tno_N5Uwp)Ud7hd?|~mvlTnhE$W9Dq>S= zY`|S2W9lau8?F+W;Hz;d>w6DWU~k_ZSl^HEle%=x+O=!ft=nPOmlv?|_rorGJbALh zCJ5o$86q|F?2!T(CaTm^D-yCRUz;|j50oDo>aU8V&}S+1P0XnPzA!H8%NXS{V8$^G zZS91zdC||NofWo5M$uwt?4^ynQ7hirdH?=j1IMo!7?iX&JUT-8<@jG5mkJ5c-+YeT zhy?|9aVp$un`%-!_+X=U9kdfEd1Gl;2yO`843)nQ!qWh5+uGRp#HX3XEVGF+4p3f2 z+5og7Z@X(|g{0Y*iJJ6|t}c$ew*A48Dwi%1X2J*z`yRcMq6Ncq`uqF$4p)0ZbrG+g zB6Bc%AidEEt|@2q%U%K}((;0Qi@`Yy2tm<78L!%1wb+anw&y+$1@=g+d7b;qRgV8>E-lK!yw;~5^$sJsaJP^-*(G0r-h>NF4R^Q?qpL_UG)h@&~t>YR75 zQ+j^Hb8U)crD>aZ8EGum2&Qr6 z9-f$BQAt=Ua!f$VDbx}qQNRYXu4$gB*In@vK28&Em|(NRI);p=M0f4#M)BYl#JBjD zQ?%PE#g}g+Q8S~wz8>1*vfdZ8^xA7kPF1Udo;|y=r9!1JF+Poaqe8gDok-|qh3Dvj zMs1I6fh)DO$(9fJ@~dcx*LwQ;Vh3*mNC8N5NZxvb{2cj)ym)gpG%M1x-`NnooN+P; zx+|kx2qc^V*{;)tm;4rW1~>bCfS9>Dc}@ZS(9LQmU47u2ZrLW&#-s!l9eDl*-U@c8 zuxaTyp=Q1z=Ux&EPXH^;ph(mR<;W`1@fncee1+%%87Npos*o&oG%6${BqJjupc$2f z*llD~HNf&hM7`Zw+SXUdz#p^%DumLAd~K$JX+_YSlPrKL{RgLZjl^DpNS(T;TFAs5 zyf>8z;`pe{jF<>Ol7;hs`GWK%`dMGpGmWEJl~F%99c6qIOp|^wDJv#NWgVZHeXw4m z#P}`j47=dwl0GP90zSX(3hQA~0+R}ZCuSvoHQmc107*4taasJjjH-P2WMyTMBqNH3 z8{3IUNl8gasFx*}Ze6!dw~0?ZL3GfMZ-^;G57}=0%fHwvXpgYd9w<`%z;2!0z2= z+PHP?=D_ze#%cL|6@S&+56`LTCBLojflPM{(o?-Hi~Q6flyeW{E=enx^Xh2MPHFG# zWM^YQIlD_kT`1bOkv$8HbkzQ=SH;eOv=Lc;;9T=E^%%;_LIjxV$&z=AQwX4j4B|Fn zUJH5<#@;g29t;!@S&6}qQ@9{{LGZ!wzfgSmPga5w>s^qJ;0{OT7$s2#7sODHc!JGR z$|J5^I6eRELwp@J^y@hUk-!kFz%kh=DCQA$K`xMEe=cA+EJ7KuxneAjj-pu4@bEBr z2>GA`mgrajgKQ7-2lQ9Mp+}rhd?mqdJS9hqWCe3l4J)_n=(K`=L{9Q+Htup4E>t2r z-ZzRZqcfbSh-Wd;rXA6>co0 zh|6hm0t10EU&fP@03n|~e+C8tLS#&NvT|&_RcGmDs8De%S^+7IpX=ClthdRBK)?#Z zb2o9bhIXjJpj2|4xruUyO)+F_(jmt^MP=HMFlLxFcJ}v6BFw;TX_o*ll|cq@N}X_X z0B^q*Q}B4{+UsBf2^j$!*L*Q=NE|%4ii&f#UdaZ43!;1pmJa|KsG%945YjVL08gCw zG;iIVR6vy95QLbShX5k??W<^Q)e$znP!*}*{Ot~N^<(MLq8-L*I1vA_jlkm?%7vx| z2I5xjMaa`gpf}E)JJ;(&{VSH&*DG98ejOMS4h{~~(-2od^#EIu$xhu{NO3~!A*inb zGJ<|uw=PUwBC z4vQnJ`O3@5$$Jwjx*lZFxu)-FWCx?tQGt83_h&K#)TAR&a-5gh&Va=ktz`)RfN zb2P5Ii0#~Yf~@`K@&{zMp!dWs69CCT4xtcrGlrC95RhfoWn9gQepvH#k+i0t^&6u`ISj0`#$I;0fw=};n; zp&JJhJP$cpS*1cgx@f`+j_Wug-jN_J)ApiQ&nFdq~KeL``ZA0OVz5%}hm_;3OR% zd>dN>j~I{ioEPqV+qP}UUE*hftjqyY^-DM9lp_xT4~#Y8CfMEYUlXZ_OnPapPXcS> zHF>|6y%0KXe)Hx{aNFl)*&(4u2M)BhMhX!Zbu{Vs6Ll8H58?|E`Wgc>$hN@sA`F5( zHtv@A_uqd-L_|QACEh%9X8Dj*FGG}(fASfX;4`4sMbuYTQAxip9;=F)RD4r5%E9?% z1n&c(q_MHFwzf7f<6l#KB4rzod#SV~s45;>(eT>M&F%H;oo7gBv}!n)sh*Qo04ijx zCCrH-%Xo2|H6$@{2+`cBgg?UpO=NyHLUB6YXaOuK0|VsS#HSG0#P=QELGI%Wb(Nvc z+P23NFw<)8uC6ZGuLX$-RK?iOf_!|{dAHgwEO_J63lJY(IlT>m8i{TmGGFwsod@oI zl~5Di*-~C^4yXJuu(`RpqZ8sV@4)bUovGVDJI*$|UHwG64qIR|l|2$gh>Je4b)K)< zedRPKTsG)&bu=-7qe9LwgDRX>{QwucA4pGtY%GIaO`LkfP+(t{db2ajjj<^&u`9Dn z0>wFL3{A_2EvO=U?K>+g8-9>h0YM?Gy){{{ghenr^dW6Qb(-^~aksV*002QIHCY2Y zPbsv0+yV6kvfIZ`o){N9jxFPEUet1{njtfLB+H>8mD*78>eY6e()|!-2JIZ^=nzHB zflRv(T*6#`3I%O<&Z0tH9Ub82Wx+H!f?!jPQ+r9)wqFip-Uy_A<3=jGW7R|%e{0#1 zxh1gN=M(D{>5)fy&Ts_ZxPE;Y!*nY-i}s8gQ==X7(`Dm=5Qc#LJ9%}mHIELJo$>73 zdO$9uad6%se5iTo0KEPyOt+G_;}45&+jf-I({tu< zuJFv~&sX^JYj&0g&vb`*HZ(SZN^l%)FCOiN3L)`GF}&S5Sy|2OTO&lN9bw_}``h&? z1{_y!+Sou35ep0$pg+L%`t@r=+oO$P4$gBdo{JW6Mqc>8wr9TFaEv zUN})2`FPg1Am<;nTe2z)A#P&nLE)?&BZB_bPmh^7Z+%N|H1~dEwtzE$n_E77c!?kp zAY(RxE}vwS%Rm_cF_^Yws}Cfj4&xi)p?+0NAjJn=Xc6l1*_N&>qu~p%C!c=Bf!}P) zh>Gx~^XH#>d+RohsjYSQ@L0vh#f^5 z4coCVl9H0JwFnogBI4*@%a#>S^p*pBmuft?`8Pt2iLr6&%|A~&8Q3#DAt{D@D!@hd0*M)uD8AI_H9ci<_GWr{OhJ zM{baxJ`Ht&G#YYg)Y$j5#vZEOPmPY%Jxu>+-|vy$J4qJH4N-|SiPCUS0bA z{^j~)y^XHU-#2_rCt~DepQSxu}r2H&^nbR{YWxmzCm7^c4=Zx1Tuk`-V;j zZ**V2W`T}VMa5(P`4lP(vrp3IO$VM3lL6qicKw%+uk>+iZLQzc-vd{b+t$ydFz%fsiF&QzBuoM%YaA?O|hw|smK{*2R+ee zD}WkC^E=UcVjf<>!Dc2VM0+9pK4fgXJ9oAtKID<%4h~-{TD{Pwg4F-NHGCw$>uP9d z(61STx=_ljL1f`NXzA`Tv07PLj?ifCj~}B!0TevA%!|T(b|{_iRf+qT(WN2-Sr^_I zK&$xE^MNs;MNdw+FB7>t^4uMa>+lMIk?)VV%sN;en$A0G>)@*SD}p6ks%m ztcZ?{HKE2(i2=e^LqkL1u>gR{SX_S^Hp#j6lI=p@3c*DL_M+ptqazJ|?$f7Fv$GDe zPUB6fq?+=N(84UV9;3Cm3Dhf`B{%~_7UbBV^fKC?kmX~$ARf4ZX)>0$7}!qKVe&e9 zC&0$22af}eqPoeS$t6?OYX>gBL2qHccrSvq-k0a-^?+-G(h>R?q!Jod4L7TLiQW!G ziiJHxZX-R_zK)H}6L_9W^431o5R;RW{f8#d$x?^gBV;hI#2)nmv2mMmGau#`}#MJd@>TeGZODG7xs+D9N#>0me8BV{e2@b+rL zi~^E9bUQjS>Q6-V;4Gdalimj<;BJ|?)mctw#@9N!*YUeqZc{= zQj?M@wICxaDJt4mwtnr}{pc`hv%k;Gfe%X%!qHuo17{<8t8yjG72(d%LHVT- zG-#_gY={`q2=1h^Tn+eICt=_H@=+K;Q(USF+pS=7@h@-_UoYb| z1|XhyDZbqa;%`vbQ>wGKH)et|KQ~i_7C#(AX|t^8aY>`EI|mM+P1Tp2)~23kUt=(` ztnsRZ8Y+dl=d)aB(!p?<1)f}7|NL`JpE^BE74bFoxp`j{^mHwg%=51Dg+2ujC(RbA zKy{A}lGvD*+uRGlmUjSx5Eihp_YZ2t+57TAt(vL~8K$G-DJEuS6NA$qYf4_R{oCgH z5N?SYqMBmZ;%XMZA>7C<=YCAgp50XkmPB@jeR#IExNfri5f71TC9%tH-tEWLXbttbceo z&RwkG#N5!EKHW_dv(^>mt$WnVCI{_4++Efg@_0IPZ$*m#LL>0WL$v9{XqM`wtTl9% z`Ku(cvR4Y5S$iLdGSRl1R8-4x%$(_+>7&?pS8Nlej66&MB_z5jaecHIkUI;DJNI54 z*52g-e;UPwe(rROG-4Nt_t^eG)(SK~UKCK++h7=xBNf224;{^v0P_l|TKZ$p$B)ko$Fq^-E1)cANli$&B=@Am33wr>@ZJ@6gDWw zi%Z1kMV;pzl(I}ks(Kyy{YUP`iseOjQLZ|z{&p7>r{Yj5Sg;RBC%}dRyrb3v#SGdt z+uN_%P(Cenr%Hu*P7RSM(t4#QkVs7FYzo|j0$alk+4Md9{AGqm`smMPXI8VP7*@Vw zaZ)hNB$o*m9+L`m7I056h^{PEzva72o=dx7x6sd!m2!noshMX(kcL&ZMUqKp>0r@P zuNAN)G|Wc4GBEsS$o?Qikx+FDvoK0WonJC~Czt{nW=bn3%^tNZ4I zHw^Cu`;<^qmJd9?Wp6KD=gJOI)w4KB{ygpB6L~DU9760zQh{o&^^ZFdRbzRSxj}I8#Sv({_TL}=VTeqK^wzr^)NiZOa(4Irj5BOK zzr@}9_Vyh+_*?hbM6s{ivc+^Id)KB!txQEvB6XzCO^Ck;M>9CPh@%lH=^0w-UC4q{ zT5ij$UDzWZ`nMbC$CmaXBqFv?)Un(+G@JU6)8rc-adR3fN^wYy zLy;q|%39UN#Q)6lb_Oat1tW5fyZXYKs;b8B$_And2YI@HNvs=B%MJ4Ngnb~8S!m4{@pd{cx|mfv!D(C?nX%_=>uC(sf8zx z6H4uAic%(X!6HVAbBRwsLnmU!7x|%b4c=)mEGnK7-MyLp0ZK3Ieq$H)wjQ|tudr}R zTwH%L8Z6gJwF1a@DpdYucn4L9Q*+{!@XyINdKAO%bmpw!-(rLUy9Xqdxj!&d7cvkT zdf^26j(u9R$Zs}V*r`~B&irK&zc(<`LVN5@A}_yq#} z?7C6>i&3L{L>JUUP`;gOM3-^jP9dR6v{ist$I*mIv1c!IQ)4?j7!yu&fcOOki$qMw z(^CP2KHf7$4I-MU$<7-Vk_x<*iXu7YhIe&@gtY#N?unDB12R=(Z!O!<6%W%yyE>F* zfQCfr5s1zWf|a78UHtqxKNt<%3mxA6jpkWI?>=f3S++wSC@eDG1~SuC@k#i>{LOQM;`ekayszwXq3ibfB*pU7g*gQm3vKbHB%suk!|kbS`o?Tek*#dEwm#mGE8gp&MQr4DcA5fHZ<;!ylcM z@@{_-ZPaMud4UAM+dE7@EjgL!DB(XwX^=;i@dPj`+GE57cI;?dP2BZ5#3*>N0nQrg z`e|`QOS^6_y0f8$fPSq(58TkqGW3QAJe|4r9G%Ghb7sffsNZx<{f-fYLnZ5eO2 z`yW%_%KuwR{NKMOL&2i_kGFw={>r4a|G{4wFW2+?O58hj^`ET!w(JOfQNZOjodKs) S8t|({XHK3wk#Owt-Tx1x+hIol literal 0 HcmV?d00001 diff --git a/docs/conf.py b/docs/conf.py index 934956e..f4974fd 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -23,7 +23,7 @@ master_doc = 'index' # -- Project information ----------------------------------------------------- project = 'Rattail Manual' -copyright = '2021, Lance Edgar' +copyright = '2021-2022, Lance Edgar' author = 'Lance Edgar' diff --git a/docs/data/batch/overview.rst b/docs/data/batch/overview.rst index 9af2f22..a6827cb 100644 --- a/docs/data/batch/overview.rst +++ b/docs/data/batch/overview.rst @@ -20,6 +20,10 @@ of a batch however do belong to the Data Layer, so are described here. Beyond that vague conceptual definition, a "batch" in Rattail also implies the use of its "batch framework" - meaning there is a "batch handler" involved etc. +And here is something hopefully worth 1000 words: + +.. image:: /_static/batch-pattern.png + Batch Workflow -------------- diff --git a/docs/features/custorders/cancellation/index.rst b/docs/features/custorders/cancellation/index.rst new file mode 100644 index 0000000..d48543a --- /dev/null +++ b/docs/features/custorders/cancellation/index.rst @@ -0,0 +1,6 @@ + +Cancellations / Other +===================== + +TODO: obviously sometimes a customer may cancel their order before it +arrives...then what? i'm sure it depends, as always... diff --git a/docs/features/custorders/entry/index.rst b/docs/features/custorders/entry/index.rst new file mode 100644 index 0000000..59152d7 --- /dev/null +++ b/docs/features/custorders/entry/index.rst @@ -0,0 +1,52 @@ + +Entry +===== + +Entering a new Customer Order into the system is very likely the most +complicated part. Consider: + +The "Customer" (or in some cases a "Person") must be identified, whose +order this will be. What if they're a new Customer/Person, not yet in +the system? Can they be added directly to Rattail and other systems +will be updated accordingly? Or must they be first added to the other +system and then imported back to Rattail? (For sake of the order, can +a "Pending Customer" record be created and then sort the rest out +later?) + +One or more "Products" will be added to the Order. Can they order +*any* (e.g. unit) amount or is there a "cases only" policy etc.? +Perhaps also some other restrictions based on Department, e.g. no more +than X cases of frozen product due to space limitations. + +Where does all that Customer and Product data come from anyway? Is it +accurate enough to be used for creating "reliable" Order data? Is the +Customer to be charged according to whatever price is calculated in +the Order, or are they charged "whatever the POS rings up" etc.? Are +discounts ever quoted in the order, vs. handled only by POS? + +Speaking of payments, does the customer need to pay up-front when +first placing the order? Or do they pay later when they pick it up? + +Wait, what if they want to order a Product which is not yet in the +system? Is this allowed, and if so what are the policies surrounding +that? + +So, the Rattail feature tries to accommodate all of the above +regardless of how you answer. + +First of all the Customer/Person and Product data should already be +*imported* to Rattail from your POS or other system(s), before +tackling Customer Orders. This feature assumes the underlying data is +already squared away and accurate (within reason). + +Second, it's worth noting that the New Customer Order tool is +implemented as a batch (see also :doc:`/data/batch/native/custorder`). +This is important because it makes it possible to use the New Customer +Order tool as the entry workflow for a Customer Order *even if* you do +not track those primarily in Rattail. In other words when the batch +is executed, it can "push" the Order data to whatever system is +needed. + +But of course the Rattail DB has its own schema for tracking these +Customer Orders, so the default "new batch" execution will create the +Order directly in Rattail. diff --git a/docs/features/custorders/fulfilment/index.rst b/docs/features/custorders/fulfilment/index.rst new file mode 100644 index 0000000..bc8315b --- /dev/null +++ b/docs/features/custorders/fulfilment/index.rst @@ -0,0 +1,20 @@ + +Fulfilment +========== + +In the context of Customer Orders, "fulfilment" requires that: + +* customer has paid for the product +* customer has possession of the product +* order data reflects these facts + +Some places will require the Customer to pay for the Order when they +place it, in which case the first is taken care of already. But if +not, then the physical product can be rang up at POS when they come to +pick up. + +If the product is paid for upon pick-up then Rattail has a way to +"automatically detect" that fulfilment has occurred (by monitoring the +POS Transactions). But if payment happens up-front then likely some +User must explicitly indicate to Rattail that fulfilment is complete, +i.e. product was picked up by Customer. diff --git a/docs/features/custorders/index.rst b/docs/features/custorders/index.rst new file mode 100644 index 0000000..97aa767 --- /dev/null +++ b/docs/features/custorders/index.rst @@ -0,0 +1,32 @@ + +Customer Orders +=============== + +Presumably all retailers sell products to customers. Most will have a +dedicated point of sale (POS) system for that. + +Additionally, some retailers let customers place orders for product +which will arrive in store for pickup at a later date. These are +often referred to as "special orders" or "case orders" etc. + +Rattail offers tools to facilitate entry and tracking for such orders, +providing visibility and workflows for their full life cycle. + +.. note:: + Now that we all know what "COVID" means, online orders with + curbside and delivery options have risen in prominence. For the + moment Rattail does not directly provide features with those in + mind. However this "customer orders" feature is clearly related, + and probably a lot of the schema and/or logic could be shared + between scenarios. But so far only the classic "special/case + order" scenario is being addressed. + +.. toctree:: + :maxdepth: 1 + + entry/index + purchasing/index + receiving/index + fulfilment/index + cancellation/index + reporting/index diff --git a/docs/features/custorders/purchasing/index.rst b/docs/features/custorders/purchasing/index.rst new file mode 100644 index 0000000..8f97965 --- /dev/null +++ b/docs/features/custorders/purchasing/index.rst @@ -0,0 +1,12 @@ + +Purchasing +========== + +In the context of Customer Orders, our concern here is making sure the +Buyer knows about them and includes them in the Purchase Order(s) +which they are already placing to the Vendor per normal procedure. + +TODO: this has been implemented a couple of different ways thus far +but the "best" has yet to be decided...in particular (how) should the +customer orders and purchase orders be linked? it is a slight hassle +up front but then can be leveraged during the receiving process... diff --git a/docs/features/custorders/receiving/index.rst b/docs/features/custorders/receiving/index.rst new file mode 100644 index 0000000..86502c6 --- /dev/null +++ b/docs/features/custorders/receiving/index.rst @@ -0,0 +1,15 @@ + +Receiving +========= + +In the context of Customer Orders, our concern here is making sure the +Receiver knows about them and sets them aside while receiving the +Purchase Order, once it's arrived from the Vendor. + +Another concern is how/when/who should contact the Customer to notify +them that their order has arrived. If the Customer account has a +valid email address on file then perhaps they are emailed +automatically; otherwise an Employee must call their phone number etc. +In either case the *attempt* to contact the Customer should be +recorded somehow, along with notes e.g. indicating if it was +successful. diff --git a/docs/features/custorders/reporting/index.rst b/docs/features/custorders/reporting/index.rst new file mode 100644 index 0000000..54352ce --- /dev/null +++ b/docs/features/custorders/reporting/index.rst @@ -0,0 +1,52 @@ + +Reporting +========= + +Reporting on Customer Orders data is possible but as of writing is +still being worked out. + +The asumption here is that you want to track "sales" which are +attributable to Customer Orders. + +The "easiest" way, though potentially inaccurate, is simply to query +the Customer Orders data and assume that if a given Order's "status" +reflects that e.g. it has been paid for, then include it in the +report. + +On the other hand the precise amount paid by the customer may or may +not even be in the Customer Order data. Even if it is there, is it +correct, or was it just an "estimate" and really a related POS +Transaction must be consulted for the true price. + +However the Order status likely *is* important on some level, to +detect cancellations etc. Presumably if a refund is given, the POS +Transaction would have that amount, but there likely is nothing to tie +that back to the particular Order which was canceled. + +So at the moment the focus is on recording "links" between a given +Customer Order and POS Transaction. This is done by way of a +Trainwreck DB (see also :doc:`../../transactions/importing/index`): + +A transaction is imported to Trainwreck as per usual, but in addition +to the normal stuff, the transaction is inspected for any "indicators" +of Customer Orders. (Often the cashier scans or enters some ID for +the Order when ringing it up.) Such indicators are then stored in a +dedicated place within Trainwreck. This takes care of the "high +level" meaning we now have links between a POS Transaction and +Customer Order. + +But really, a POS Transaction has "line items" and so does a Customer +Order. So we actually need a link between the relevant line items. + +The line item links are established in a second phase. So the first +phase is focused on importing POS Transaction data, and we've done +that. But now Trainwreck has all those line items and so the +item-level reconciliation can be done "natively". Again we already +have the high-level links, so we fetch a linked pair (Transaction and +Order) and then crawl each to identify item-level links, and record +any which are found. + +Once that is complete, a Customer Orders report can more easily obtain +accurate payment amounts from the POS Transaction data (although it +reads from Trainwreck instead for convenience). And of course it can +still leverage the Customer Order status etc. as needed. diff --git a/docs/features/index.rst b/docs/features/index.rst index 576d038..c1f5c5e 100644 --- a/docs/features/index.rst +++ b/docs/features/index.rst @@ -2,15 +2,19 @@ Feature Layer ============= -Here we'll try stay "high level" and describe some of the features +Here we'll try to stay "high level" and describe some of the features which are provided by the Rattail framework, in a more or less "ready -to go" state for use in your app. - -Note that this section is not very far along yet.. +to go" state for use in your app. We'll also describe some +"potential" features to consider, depending on your needs. +While technically the Rattail framework can be used for "any" +application, the following features reflect its retail roots. .. toctree:: :maxdepth: 2 - :caption: Contents: + people/index + products/index purchasing/index + transactions/index + custorders/index diff --git a/docs/features/people/customers/index.rst b/docs/features/people/customers/index.rst new file mode 100644 index 0000000..2c5c7e3 --- /dev/null +++ b/docs/features/people/customers/index.rst @@ -0,0 +1,64 @@ + +Customers +========= + +In many cases it's best for Customer data to live in Rattail (usually +in addition to POS, which is considered the authority). But possibly +not, so let's first look at *why* you might want/need to have it in +Rattail. + +And quickly even before that, let's just say that we're defining a +"Customer" simply as a "patron" (shopper) of the retailer. In some +cases Customer data is held not only in POS but also in a separate CRM +system, etc. Your own definition of "Customer" is free to vary a bit +in terms of how you must represent real-world concerns. + +If your POS does not expose a web app, then often there will only be a +few machines which can be used for account lookup etc. Rattail web +app can let you view this data directly (if it can be accessed via +SQL), i.e. *without* importing it to Rattail. However such +"dedicated" views for various tables in other systems are not given a +lot of priority in terms of aesthetic or utility. + +Importing the data to Rattail means the web app can show you the data +in (hopefully) the "best" way. That's obviously a loaded term but +what is meant here, is that the views for native Rattail data are +given the most attention and are what various other features are built +on top of. + +So if we assume you *are* importing Customer data into Rattail, then +what? You can view it, but can/should you edit it? That again +depends on whether or not you can (or how difficult it is to) export +the changes back to the source (or other) systems. It's *possible* +for instance, to allow edits in Rattail web app, which then are +automatically synced back to the POS in real-time (by a separate +datasync daemon process). But that is a more advanced topic, and in +most cases, at least in the beginning, you should only edit data in +one system, which likely is *not* Rattail. + +If you want to track *extra* data for Customer records in Rattail, +then things change again. You *would* (probably) want to import the +data to Rattail, *not* allow edit for that particular data, but then +*do* allow edit for only the "extra" fields. With this approach you +get to start tracking that data while avoiding the need to export +anything back to POS etc. Reports can be created in Rattail which +leverage data from both systems. + +And speaking of "extra data" - that is essentially what is happening +with the Customer Orders feature in Rattail. Underlying it is the +Customer record itself, which was likely imported from POS, but then +when an order is created, that is just extra data on top which never +needs to be synced back to the POS. See also +:doc:`../../custorders/index`. + +Finally again there is the concept of :doc:`../entry/batches`. In +fact when creating a new Customer Order, really you are creating a +batch and then adding items to it, finally "executing" which submits +the order for further processing. But batch logic can be crafted to +do anything you need with regard to Customer data maintenance. And in +some cases a Customer-related batch may be more "accurate" if it does +*not* use Rattail data but instead reads directly from the source +(e.g. POS) when making the batch. Also a "New Customers" batch by +definition would contain data not yet "in the system" - so importing +the data to Rattail is not a requirement in order to use batch +features generally. diff --git a/docs/features/people/employees/index.rst b/docs/features/people/employees/index.rst new file mode 100644 index 0000000..d6c4be8 --- /dev/null +++ b/docs/features/people/employees/index.rst @@ -0,0 +1,32 @@ + +Employees +========= + +Employee data normally comes from the POS, if it indeed comes into +play at all. You may or may not have a reason to import or otherwise +act on Employee data using Rattail. + +It is the User record in Rattail which is given attribution for +changes made etc. and not the Employee. So even if a certain User is +also an Employee, when logged in and making changes their User account +is deemed responsible. + +Whereas a User record does not technically need to tie back to a +Person record, an Employee record *must* tie back to a Person. When +importing Employee data from POS, both the Person and Employee records +are created in Rattail. + +There are certain places where an Employee *is* assumed, for instance +the "Buyer" of a Purchase Order will reference an Employee record and +not a User. Whereas the creation and execution of a "batch" related +to purchasing will reference a User. (See also +:doc:`../../purchasing/index`.) + +Rattail could also be used as a "time clock" system in which case the +Employee records must obviously be present, for tracking times. + +You also can use Rattail to track additional info for each Employee, +e.g. the start/end dates for their employment over time. Often an +employee might come and go more than once, and the POS will rarely +have a way to track historical dates. Rattail has a basic way to do +that built-in, but more "data extensions" are of course possible. diff --git a/docs/features/people/entry/batches.rst b/docs/features/people/entry/batches.rst new file mode 100644 index 0000000..c22d823 --- /dev/null +++ b/docs/features/people/entry/batches.rst @@ -0,0 +1,36 @@ + +Batches +======= + +Batches are a sort of hybrid of import/edit/export. They assume a +certain "data set" will be brought into a dedicated workspace, using +whatever (sometimes custom) logic, then the user previews the +"results" before committing to it. See also :doc:`/data/batch/index`. + +For instance one common type of batch is for new Customer entry. +Maybe there is a web form which some users fill out to enter new +Customer records, but in fact those go into a "queue" / batch and are +not truly injected to the system proper until the batch is reviewed +and executed by some (possibly more highly authorized) user. This can +be helpful not only for workflow optimization but also custom data +validation, and/or preventing duplicates from entering the system. + +Another type might be for a periodic import to "sync" 2 systems which +do not normally stay in sync. For instance if your POS and CRM do not +stay in sync all the time, but maybe once a month you export the data +from one system to Excel file, for import to the other. It is of +course possible to make a Rattail "importer" (or "exporter" depending +on your perspective) which could automate this. But for sake of +better visibility and instilling confidence in the logic, you might +prefer a batch. + +In the above example the process might be like: + +* export data from CRM to Excel +* upload file as new batch in Rattail +* preview the changes; execute the batch +* which generates yet another file, e.g. CSV +* which you then import to the POS + +There are many possibilities here; for instance more likely the batch +writes directly to POS when executed. diff --git a/docs/features/people/entry/editing.rst b/docs/features/people/entry/editing.rst new file mode 100644 index 0000000..99f1bb2 --- /dev/null +++ b/docs/features/people/entry/editing.rst @@ -0,0 +1,32 @@ + +Editing +======= + +Rattail makes it possible to edit most data it contains regardless of +its nature. This of course includes Person-related data. + +However just because you *can* edit data in Rattail, does not mean you +*should* do so. You must keep in mind, "which system is the +authority?" for any given data point. + +In other words if you import Customer records from your POS, but then +do not configure an export mechanism to get any changes made in +Rattail *back* into the POS system, then by far the easiest thing is +to just not allow editing in Rattail. But you still can view the +data, and use various app features which leverage the data (e.g. +:doc:`../../custorders/index`). + +However if you *do* configure export mechanisms then you may want to +allow editing directly in Rattail. This can be any data point which +is supported by the export mechanism. For instance if you allow +editing of a Customer name in Rattail, the change could be synced back +to POS. + +But it's also possible for Rattail to contain "more" data than the +source (e.g. POS) system does. For instance your POS DB may have a +field to track the "birthday" for each Customer, but maybe you also +need to track their "favorite color" and the POS DB does not provide a +way to do that. In this case you can import Customer records from POS +into Rattail, and then allow editing in Rattail only for the "favorite +color" field. Best of both worlds, you can now track whatever you +want with no need to export data back to the source system. diff --git a/docs/features/people/entry/exporting.rst b/docs/features/people/entry/exporting.rst new file mode 100644 index 0000000..8b1bbc1 --- /dev/null +++ b/docs/features/people/entry/exporting.rst @@ -0,0 +1,42 @@ + +Exporting +========= + +Once you have Person-related data in Rattail, you can export it +"anywhere else" you need. This may be an Excel file, SQL DB, web API +etc. but for the sake of this discussion we'll assume data is to be +exported back to the POS system. + +In fact the export features do not require you to first import the +data to Rattail. Every export that could be done "from Rattail DB" +could also be done e.g. "from POS DB". For instance that's exactly +what happens when data is imported from the POS into Rattail, it is +just another way of saying "export from POS to Rattail" and therefore +you can export straight from your POS to e.g. some web API for mailing +list or online shopping etc. + +An export is "reading" data from e.g. Rattail or POS DB, and then +"writing" it somewhere else. The reading part is pretty +straightforward but the writing part may have limitations depending on +your target. As a rule Rattail is willing to read directly from a SQL +DB but will always write data via some more "official" route, +i.e. documented API. Which means the writing "possibilities" are +limited to what the API exposes. Whereas exporting to e.g. Excel file +would not have such a limitation, but may have others (e.g. file +size). + +So how is data exported back to the POS specifically, for example? +That definitely will depend on your POS system, and as of writing only +3 are well supported. + +If you're lucky enough to run a SIL-compliant POS then a great deal is +possible; Rattail can generate SIL files which add/modify data of +nearly any kind. + +If your POS exposes a web API then Rattail can use that to write some +data. At this point in time these are rather limited though. + +If writing directly to POS SQL DB is an option for you, then Rattail +can certainly accommodate. It should be stressed that this is **not +ideal** as it would likely bypass any data validation, audit trail +etc. that the POS may be doing were an official channel used instead. diff --git a/docs/features/people/entry/importing.rst b/docs/features/people/entry/importing.rst new file mode 100644 index 0000000..7d2dd2e --- /dev/null +++ b/docs/features/people/entry/importing.rst @@ -0,0 +1,27 @@ + +Importing +========= + +The most common scenario involves Rattail importing most +Person-related data from other (e.g. POS or CRM) systems. + +However it should be noted that Rattail is meant to live "alongside" +the other systems, it is not normally going to "replace" them - and +this means Rattail must *continually* import data from the other +systems, to remain accurate. This may be done nightly, or hourly, or +even in "real-time" (e.g. once every few seconds, or 5 minutes) - +whatever is needed and/or is possible given the system constraints. + +One immediate feature that comes "for free" when importing data into +Rattail, is its versioning history, aka. audit trail. Each time an +import actually *changes* a record in Rattail, the new data is +separately stored as a "version" record along with the timestamp and +the "user" who made the change. In the case of import, the "user" is +the system from which data is being imported; a dedicated User account +is created for this purpose (which does not tie back to any Person). + +We're talking here of importing data from e.g. POS into Rattail. But +if it's also possible to "import" e.g. new Customer records into your +POS or other system, then Rattail can also be used as a workflow tool +to assist with organizing new records for import to your other system. +See :doc:`batches` for more about that. diff --git a/docs/features/people/entry/index.rst b/docs/features/people/entry/index.rst new file mode 100644 index 0000000..70add64 --- /dev/null +++ b/docs/features/people/entry/index.rst @@ -0,0 +1,16 @@ + +Entry +===== + +Here we'll discuss how various Person-related records are first +entered into the system, and how they are maintained going forward. + +.. toctree:: + :maxdepth: 1 + + overview + importing + editing + exporting + batches + merging diff --git a/docs/features/people/entry/merging.rst b/docs/features/people/entry/merging.rst new file mode 100644 index 0000000..6c9ab53 --- /dev/null +++ b/docs/features/people/entry/merging.rst @@ -0,0 +1,44 @@ + +Merging +======= + +Rattail ostensibly supports merging any 2 records, of any kind. But +the devil is always in the details... + +In most cases a merge involves: + +* inspect differences between 2 records +* choose which one to "keep" vs. "remove" +* perform the merge, which: + + * may *update* the "keep" record, with certain data from the "remove" record + * then *deletes* the "remove" record + +For some things this can be pretty straightforward, for instance if +your User records are maintained only in Rattail and aren't imported +from elsewhere, then a merge of 2 User records could by definition +only affect Rattail anyway. + +Although even that example can be tricky, because a User is often +involved in some audit trail(s) of various other data records. In +such cases Rattail can update the historical records to reflect the +new "keep" User record; but in practice there may be edge cases as yet +unexplored. + +Customer and Employee records etc. can present more of a challenge, +because often that data lives in multiple systems. The question +becomes, what should a merge actually *do*, i.e. what should the +ideal outcome be? + +In particular your POS may have 2 customer records which you'd like to +merge, but even if your ideal outcome is for one of them to be deleted +(i.e. typical use case described above), the problem of historical +data may come up again. Often times both of the customer records will +already have accrued some transaction history within your POS, and it +may not be possible or practical to correct those with the new +("keep") customer reference. + +But the merge tool is meant to be as flexible as is reasonable. Your +merge logic might be able to go ahead with certain "simple" merges but +then raise an error when complex situations are encountered. Then you +can look more closely at those and see what can be done (if anything). diff --git a/docs/features/people/entry/overview.rst b/docs/features/people/entry/overview.rst new file mode 100644 index 0000000..88e8309 --- /dev/null +++ b/docs/features/people/entry/overview.rst @@ -0,0 +1,32 @@ + +Overview +======== + +In most cases the Person-related data already lives in a (e.g. POS) +SQL database and may be queried directly by Rattail. This means you +may view that data directly in the web app. + +All of the Person-related records may also be *imported* into Rattail +from other systems, and this is usually the best place to get started; +see :doc:`importing`. + +Once the data lives in Rattail you obviously may view it within the +web app (so, reading from Rattail DB instead of POS DB now). But this +also sets the stage for other features which require such data to be +in place; for instance :doc:`../../custorders/index`. + +You also may want to allow editing for some or perhaps all aspects; +see :doc:`editing`. + +The data (and any changes made via editing, if applicable) may also be +exported back to the source and/or other systems; see +:doc:`exporting`. + +Sometimes you need to process a "set" of data, for instance taking an +export file from one system and then preparing it for import to +another system. This is a broad topic; for a starting point see +:doc:`batches`. + +Duplicate records are an ongoing problem in many systems, when it +comes to Person-related data. Rattail does allow merging of 2 records +but it can be tricky; see :doc:`merging`. diff --git a/docs/features/people/household/index.rst b/docs/features/people/household/index.rst new file mode 100644 index 0000000..da9eb98 --- /dev/null +++ b/docs/features/people/household/index.rst @@ -0,0 +1,53 @@ + +Household / Shared Accounts +=========================== + +A common scenario is where a Customer (or Employee, or Member) is able +to "share" benefits of their account, with their immediate household. +There may be other variations but we'll stick with that example here. + +Although to clarify, while many e.g. retail food co-ops may consider +the "Household" concept to be an extension of a "Member" account +specifically, Rattail instead considers it a logical extension of the +"Customer" account. This is because the benefits which are extended +to the household normally apply to "shopping" specifically, and +Rattail uses the "Customer" concept to represent that. (Same holds +true for a more traditional retailer which might extend benefits to +the Household of an Employee - the Household will still fall under a +Customer account logically.) + +So it might be possible for Rattail to add a broader / more generic +"Household" concept later, but for now it's all about Customers. (And +a Member account is normally tied to a Customer account, so it's not +much more than a difference of semantics.) + +Okay! With that out of the way... + +Household accounts can be tricky. For instance are these people +actually tracked in your system? (Do they need to be?) If so are +they tracked as separate accounts or just minimal (e.g. name) info +somehow tacked onto the main account? In particular how are the +accounts represented in your POS system? + +Rattail can be used to help track e.g. Household-related links between +various Person and/or Customer records. What you do with such links +is up to you of course, but some ideas: + +If your POS allows for it, you might have Rattail keep the POS in sync +for (at least certain types of) changes to Household-related accounts. +For instance in the dynamic coupon scenario, let's say you do maintain +separate POS accounts for the "parent" Customer as well as the +Household "shopper". When a coupon is given it may be enabled for +both of the accounts, but then when it is redeemed by either it +becomes disabled for both. + +Now, maybe your POS already has a way to link Household accounts, and +even a way to handle the dynamic coupon example. But then that sounds +like you already have a good enough system and don't need Rattail to +be the Household "system" at all. Although it could still be used for +reporting and similar needs, etc. + +So if your current situation is "not ideal" then Rattail is here to +help in whatever way it can; however it's difficult to describe the +scenarios it might best be suited for, until more real-world scenarios +are dealt with. diff --git a/docs/features/people/index.rst b/docs/features/people/index.rst new file mode 100644 index 0000000..d3e5432 --- /dev/null +++ b/docs/features/people/index.rst @@ -0,0 +1,22 @@ + +People +====== + +Rattail considers the Person to be a central concept, which underpins +various other concepts such as User, Customer etc. and ideally ties +them together (e.g. one Person may be both a Customer and Employee). + +Rattail can import this data from other (e.g. POS) systems, but it +also can *export* data to other systems. And once this data is in +Rattail it can be used for other features as needed; for instance +:doc:`../custorders/index`. + +.. toctree:: + :maxdepth: 2 + + entry/index + users/index + employees/index + customers/index + members/index + household/index diff --git a/docs/features/people/members/index.rst b/docs/features/people/members/index.rst new file mode 100644 index 0000000..71dbb23 --- /dev/null +++ b/docs/features/people/members/index.rst @@ -0,0 +1,80 @@ + +Members +======= + +As with Employee and Customer data, the first questions regarding +Member data are: What is it, and what does it have to do with Rattail? + +Rattail's concept of a "Member" comes primarily from the world of +retail food co-ops, where a Member is more like a Customer than an +Employee. But there exist also worker co-ops, where a Member is +really more like an Employee. Rattail's Member features are meant to +acommodate both scenarios. + +Members often have some equity account associated with them, with join +and (where applicable) withdrawal dates, and usually also a payment +history for the equity. + +So if your organization has a membership component, then you most +likely already have some way to track accounts and equity etc. Why +bring it into Rattail? + +As usual the first answer is simple visibility. For instance you +might be tracking accounts in a spreadsheet or Microsoft Access, or +any of a number of similar "undesirable" solutions. Even if you +continue with that tracking approach, you also could periodically +import data to Rattail just so it can be more easily viewed by others +via the web app. + +And part of visibility is cross-referencing related data. Maybe you +already have a good way to view accounts, but you have no way to view +an account alongside its equity, or perhaps POS Transaction history +etc. Showing the various types of data on one screen (maybe with a +link back to the other system) can be quite helpful in some cases. + +Another potential feature is to send email reminders to Members who +have an upcoming payment due, etc. based on their account details. +And it's possible to monitor an IMAP folder for any "bounces" that +result from sending such reminders, in which case can e.g. flag the +account as having a bad email on file. + +Similarly a Member account status may dynamically affect which +discounts are available to their Customer account at the POS. This +idea depends on the ability to effect certain changes in the POS +system, e.g. add/remove electronic coupons for an account. + +But..everything just stated is technically possible *without* +importing the data to Rattail. So still at this point we've not +established a good reason to actually import it. + +You can of course create batches for performing account maintenance in +whatever way is needed. Same general "rules" apply as for other +(e.g. Customer) tables. Member data need not be imported into Rattail +in order to use the batch features. + +But unlike the Customer data, where the POS is frequently the obvious +"authority", many times Member data is *not* tracked (well) by the +POS, and so custom spreadsheet workflows or similar tactics are +employed to keep track of it. + +So this finally is why you *might* want to import it into Rattail. +Any tasks being managed via spreadsheet workflows (or whatever) can +instead be managed directly in the web app. + +If you choose this route, a couple of implications: + +Rattail becomes your primary Member system, and you (presumably / +ideally) no longer need your previous system for that, other than to +keep it as an archive. + +Data is maintained directly in the web app, for instance creating a +new Member account, or withdrawing one etc. Also equity payments +could be entered directly if they happen outside of the POS, e.g. when +someone mails a check. + +But equity payments still likely will happen in the POS also. And for +this to work "seamlessly" it means Rattail must monitor the POS +Transactions which occur, at whatever frequency is acceptable. Near +real-time is possible and in some cases necessary for sake of dynamic +coupons etc. But in other cases a nightly processing of the previous +day's transactions may be sufficient. diff --git a/docs/features/people/users/index.rst b/docs/features/people/users/index.rst new file mode 100644 index 0000000..5266588 --- /dev/null +++ b/docs/features/people/users/index.rst @@ -0,0 +1,39 @@ + +Users +===== + +Users are a bit unique in the realm of Person-related data, because +it's often the case that they are *not* imported from some other +system, being instead maintained only in Rattail. (Of course it *is* +still possible to import User records from another system.) + +When you first setup a Rattail system you create the first "admin" +User. You then login as that User and can create other Users as +needed, depending on who needs access. For more info see also +:doc:`/data/auth`. + +It's possible to tie a User record to a Person record, although +technically not required. It is recommended since it opens up other +possibilities, for instance the app might present different features +based on some other related aspects e.g. of the Employee record of the +current User. + +It's also common to create dedicated User accounts to represent the +other systems involved, e.g. your POS. Such accounts do not tie back +to any Person and exist only for sake of attributing changes to the +applicable system, when data is imported to Rattail. + +The username for each User must be unique. Passwords are stored using +1-way encryption, so are not recoverable and must be reset if lost. + +It is possible to authenticate users against something other than +Rattail, instead of or in addition to normal Rattail authentication. +For instance it can check LDAP, or a corresponding employee table in +your POS DB (e.g. if those credentials are stored as plain text). + +It is also possible for Rattail to auto-create users upon first login, +if authenticating from another system like that. If your permissions +are setup such that *any* "authenticated" (i.e. logged in) user has +access to certain features, this may be a useful option for you. In +some cases you may also need to add logic to auto-assign the +newly-created user to some particular role(s) based on whatever... diff --git a/docs/features/products/entry/index.rst b/docs/features/products/entry/index.rst new file mode 100644 index 0000000..fd7548d --- /dev/null +++ b/docs/features/products/entry/index.rst @@ -0,0 +1,5 @@ + +Entry +===== + +TODO diff --git a/docs/features/products/index.rst b/docs/features/products/index.rst new file mode 100644 index 0000000..5b93a6a --- /dev/null +++ b/docs/features/products/index.rst @@ -0,0 +1,14 @@ + +Products +======== + +stuff here + +.. toctree:: + :maxdepth: 1 + + entry/index + vendors/index + pricing/index + labels/index + inventory/index diff --git a/docs/features/products/inventory/index.rst b/docs/features/products/inventory/index.rst new file mode 100644 index 0000000..675f497 --- /dev/null +++ b/docs/features/products/inventory/index.rst @@ -0,0 +1,5 @@ + +Inventory +========= + +TODO diff --git a/docs/features/products/labels/index.rst b/docs/features/products/labels/index.rst new file mode 100644 index 0000000..ccbdeac --- /dev/null +++ b/docs/features/products/labels/index.rst @@ -0,0 +1,5 @@ + +Labels +====== + +TODO diff --git a/docs/features/products/pricing/index.rst b/docs/features/products/pricing/index.rst new file mode 100644 index 0000000..66e497b --- /dev/null +++ b/docs/features/products/pricing/index.rst @@ -0,0 +1,5 @@ + +Pricing +======= + +TODO diff --git a/docs/features/products/vendors/index.rst b/docs/features/products/vendors/index.rst new file mode 100644 index 0000000..c90eb3e --- /dev/null +++ b/docs/features/products/vendors/index.rst @@ -0,0 +1,5 @@ + +Vendors / Catalogs +================== + +TODO diff --git a/docs/features/purchasing/accounting/index.rst b/docs/features/purchasing/accounting/index.rst index 92c890b..020ec03 100644 --- a/docs/features/purchasing/accounting/index.rst +++ b/docs/features/purchasing/accounting/index.rst @@ -2,4 +2,7 @@ Accounting ========== -TODO +TODO: while this is "virtually" supported as a 3rd phase, it has not +been "fully" implemented in production. in practice the 2nd +(receiving) phase is taking care of accounting duties thus far. see +also :doc:`../receiving/accounting`. diff --git a/docs/features/purchasing/index.rst b/docs/features/purchasing/index.rst index 165a0f5..022619e 100644 --- a/docs/features/purchasing/index.rst +++ b/docs/features/purchasing/index.rst @@ -1,16 +1,21 @@ -Purchasing -========== +Purchase Orders +=============== Presumably all retailers purchase products from vendors. Rattail offers tools to assist with the various workflows involved. -It splits the life cycle into 3 "phases" - although some purchases may -not explicitly go through every phase. In particular it's possible -for the Receiving phase to include everything Accounting does. +It splits the life cycle into 3 "phases" - Ordering, Receiving, +Accounting. + +Some purchases may not explicitly go through every phase. In +particular it's possible for the Receiving phase to include everything +Accounting does, and in many cases Ordering is skipped (wrt the +system), with the PO first "entering the system" in the Receiving +phase. .. toctree:: - :maxdepth: 1 + :maxdepth: 2 ordering/index receiving/index diff --git a/docs/features/purchasing/ordering/additems.rst b/docs/features/purchasing/ordering/additems.rst new file mode 100644 index 0000000..6481c06 --- /dev/null +++ b/docs/features/purchasing/ordering/additems.rst @@ -0,0 +1,22 @@ + +Adding Items +============ + +When creating a new Purchase Order using Rattail, the user first makes +a new Ordering batch, then adds items to it. + +There are three main "workflows" for adding the items. + +The first is where the user sees the (at first empty) batch and then +does some sort of product lookup to identify an item to add. The +lookup/add process is repeated as needed. + +The other way is what Rattail calls the "worksheet view" - but it's +only suitable for vendors with relatively small product lines. In +this view the user is presented with a "worksheet" form. All items +available from the vendor are visible on the worksheet, and the user +enters desired quantities for applicable line items. + +There also is a mobile interface for ordering, which if used on a +smart phone with bluetooth scanner attached, can be used for +"in-aisle" ordering by scanning shelf tags. diff --git a/docs/features/purchasing/ordering/convertpo.rst b/docs/features/purchasing/ordering/convertpo.rst new file mode 100644 index 0000000..e63b765 --- /dev/null +++ b/docs/features/purchasing/ordering/convertpo.rst @@ -0,0 +1,21 @@ + +Converting a PO +=============== + +This is given its own section just to better clarify. + +The "purpose" of an Ordering batch in Rattail can vary. Presumably +the most common use is to actually assemble a new PO, to be submitted +to the vendor. + +But this batch type can also be used to "convert" any arbitrary PO +data, to any other format/system. You might have multiple different +ordering "systems" which vary by vendor etc. If so then you could +process PO data from each of these, as separate Ordering batches. +Executing each batch would then produce whatever output you needed for +them to be in a "common" format etc. + +Probably the most common scenario for this is where you want to import +the PO data into your POS system. This lets it know that the product +is "on order" and will be what receiving happens against, once the +order arrives from the vendor. diff --git a/docs/features/purchasing/ordering/execution.rst b/docs/features/purchasing/ordering/execution.rst new file mode 100644 index 0000000..3011d42 --- /dev/null +++ b/docs/features/purchasing/ordering/execution.rst @@ -0,0 +1,22 @@ + +Batch Execution +=============== + +Often the user will have made an Ordering batch and added items to it +"manually" when assembling their order. + +But in some cases the PO data will have been imported from some other +system, or perhaps a CSV file, with the goal being just to get it into +the POS system. + +Regardless of how the batch data was obtained (e.g. from file, or user +input), ultimately the batch will be executed. So what does that do? + +This basically depends on what you need it to do... For instance in +the CSV file example just mentioned, if your goal is merely to get the +PO data into the POS system, then that's what executing the batch +should do. + +It is possible also to make batch execution actually "submit" +(e.g. email) the purchase order to the vendor, although this is less +common in practice. diff --git a/docs/features/purchasing/ordering/index.rst b/docs/features/purchasing/ordering/index.rst index 45cd73b..8261c66 100644 --- a/docs/features/purchasing/ordering/index.rst +++ b/docs/features/purchasing/ordering/index.rst @@ -2,4 +2,12 @@ Ordering ======== -TODO +All about *ordering* product from the vendor. + +.. toctree:: + :maxdepth: 3 + + overview + additems + execution + convertpo diff --git a/docs/features/purchasing/ordering/overview.rst b/docs/features/purchasing/ordering/overview.rst new file mode 100644 index 0000000..6032267 --- /dev/null +++ b/docs/features/purchasing/ordering/overview.rst @@ -0,0 +1,27 @@ + +Overview +======== + +Ordering is when the retailer expresses to the vendor, their interest +in purchasing some of their product for resale to their customers. +The retailer promises to pay for the product, so the vendor should +ship it to them ASAP. + +If the retailer has things "dialed in" then ordering may be fully or +partially automatic, aka. "suggested ordering" where the purchase +order is auto-generated based on current inventory levels. + +Rattail does not (yet?) offer any tools for suggested ordering. It +does though offer tools for the more classic scenario, where the buyer +"manually" assembles the purchase order. + +It does this using a batch. The buyer creates a new Ordering batch +for the given vendor, and then adds items to it. + +Adding items may be done in a few ways. These are discussed in +:doc:`additems`. + +One way or another the batch is populated, then ultimately executed. +Read more about that in :doc:`execution`. + +We also share some thoughts here, on :doc:`convertpo`. diff --git a/docs/features/transactions/importing/index.rst b/docs/features/transactions/importing/index.rst new file mode 100644 index 0000000..8c56f52 --- /dev/null +++ b/docs/features/transactions/importing/index.rst @@ -0,0 +1,47 @@ + +Importing +========= + +So, the POS is ringing transactions but now you want to *import* those +to another system? Why? + +The most frequent "use" for transaction data is probably to report on +sales trends etc. That is covered more in the next section, +:doc:`../reporting/index`. And commonly, it is done directly from the +POS DB. + +But there are other uses for the data, and even if reporting is your +*only* use, it still may be helpful to import it first, as will +(hopefully) be explained. + +Rattail has a separate / dedicated DB for this scenario, meant to +contain only POS (and similar) transaction data. This is referred to +as the "Trainwreck" DB; see also :doc:`/data/trainwreck`. + +If you *do* import transaction data then here are some implications: + +* you ultimately decide the schema, though default is likely sufficient +* schema is ideally *simpler* than "raw" POS transaction data + + * (in some cases POS transaction data is not even in SQL DB, but a file) + +* SQL reporting can then happen on the (simple!) Trainwreck data + +But those are just the obvious ones; here are some more advanced: + +* additional calculations may be made, e.g. custom "patronage" amount + for each transaction +* other data points known at time of transaction, may be recorded + within it; e.g.: + + * current account status of customer or member + * current [sub]department of each product sold + * "links" between transaction/items and related customer order(s) + + * (this makes reporting on the Customer Orders possible, or at + least much easier!) + +* transaction may later be "re-assigned" to a [different] customer, + with subsequent reports reflecting the change + + * (e.g. for attributing patronage to correct member for annual refund) diff --git a/docs/features/transactions/index.rst b/docs/features/transactions/index.rst new file mode 100644 index 0000000..c866145 --- /dev/null +++ b/docs/features/transactions/index.rst @@ -0,0 +1,17 @@ + +POS Transactions +================ + +Presumably all retailers have a dedicated point of sale (POS) system +which is where most if not all transactions occur. + +Rattail is not and likely will never be a POS system, so it's not +concerned with faciliating the transaction, but rather in "harvesting" +its data for whatever purposes you may have. + + +.. toctree:: + :maxdepth: 1 + + importing/index + reporting/index diff --git a/docs/features/transactions/reporting/index.rst b/docs/features/transactions/reporting/index.rst new file mode 100644 index 0000000..bc53606 --- /dev/null +++ b/docs/features/transactions/reporting/index.rst @@ -0,0 +1,57 @@ + +Reporting +========= + +Reporting on POS Transaction data is obviously standard practice. +Almost certainly your POS system already provides a way to do that. + +Rattail considers its job here to be, "make more things more easily +possible" - which is only needed if your existing reports are lacking +in some way. Some specific goals here include: + +If your POS Transaction data is already held in a SQL database, which +you can query, then the "hardest" part of a report really should just +be crafting the SQL query. For the common use case of generating an +Excel file with report data, Rattail can provide basically everything +but the SQL statement. + +Reports available to Rattail may be generated via the web app. A +report may accept/require certain parameters, which the user provides +when generating. + +When a report is generated the output file is "saved" for later +viewing in the web app, along with details of who generated it etc. + +It's possible to automate report generation, although at this time it +can't be done via web app. + +So that's why you might want to use Rattail for reporting on POS +Transaction data generally. But it's often the case that the "raw" +(native) schema for POS Transaction data is a bit complex, and this +can make crafting the SQL queries difficult. + +Additionally, the POS Transaction data may not even be in a SQL DB to +begin with; some store it in a file, e.g. XML. + +And not to mention, this data may not even have everything you need +for your report. You may need to query additional systems etc. to +supplement the transaction data in order to "complete" the report. + +So first of all that is of course possible. Any report can read data +from any "normal" place - SQL DB, file, web API, etc. and combine such +data as needed. + +But in the case of POS Transactions specifically, the process of +reading data from disparate sources and combining, can be "expensive" +in terms of compute power/time. Also you *may* need to do essentially +the same thing for multiple reports. + +And this is where Trainwreck comes in - the idea being that you +*import* the POS Transactions data from the source, into the +Trainwreck DB. It's a *little* like running a one-time report to +"translate" the transaction data into a simpler format, with all +supplemental data merged in as needed. + +Once the data is in Trainwreck you can write reports against that to +your heart's content. They will get to query a simpler schema and all +that extra data is right there with it.