Cheapskate!
Det har uppenbarligen sina nackdelar att vara duktig på något och samtidigt villig att lära andra.
Men OK, ett svar på din fråga kommer här:
I din fråga fattas detaljerna som kan vara nog så viktiga. Tex har du offerter, offertrader, order, orderrader, fakturor, fakturarader, kunder, artiklar, eller någon delmängd av det hela? Har du flera tabeller som tex prenumerationer mm?
Skillnaden på en offert, order och faktura kan i en del system bara vara en status i ett fält, men det blir lite klurigare som du märkt när man arbetar med delmängder av olika slag. Tex vissa rader på offerten skall vara med, eller när man gör delleveranser av en enskild rad på en offert osv.
En annan fråga är omfattningen - hur många timmars handjagande är det du försöker bygga bort med ett bättre system? Om du inte har en viss mängd på det hela så är det inte lönt att bygga bättre system. Ok, irritationen över ett dåligt system är också en faktor när man gör den bedömningen och förstås hur många fel och inkomstbortfall det representerar.
Här är några vanliga metoder att hantera en del av de problem som du har, en förutsättning för flera av dem är att man i en separat tabell (som kan heta inställningar eller Reg) så lagrar man olika saker i en enda post. Tekniken är vanligast för att innehålla just inställningar som tex kundens andress, logotyp osv. Då behöver man bara ändra telefonnummer på en enda plats istället för i 50 olika layouter den dagen kunden byter.
En annan sak i denna Inställnings-tabell är tex räknare. När det skapas en ny offert, hämtar man offertnumret ur tabellen inställningar och uppdaterar räknaren. När man skapar en order, faktura, så gör man på samma sätt. Det har några fördelar som jag kommer till strax.
* Om du har en tabell (Order) som även är Offerter och Fakturor (vilken status en post har i tabellen styrs av ett eller flera fält), sedan har du Orderrader för sig, så kan du sätta flera olika nummer och datum dels på ordern, offerten och fakturan, fast det i realiteten är samma post. Kan vara fiffigt och en lösning på dina problem.
* Orderraden är det roliga sedan, den kan ju märkas med ett offert-, order och faktura-nummer i separata fält, alltså syns raden bara på rätt offert, order och faktura.
* Orderraden kan även märkas med saker som har med leveranser att göra, tex ett kollinummer och därmed kan du få följesedlar.
* Delleveranser är lite klurigare, man kan antingen "dela" på en orderrad så att antalet som skickas nu är i den ena raden och antalet kvar är i den andra raden. Inte fullt så snyggt, men det fungerar. Hur man gör beror på mängden krångel och handjagande man försöker slippa.
* Vid lite större omsättning på antalet order man har att hantera så brukar man dela upp saker och ting i ett antal separata tabeller istället. Man utgår från livscykeln för en order som är att den börjar som en offert som sedan blir en order och ett antal orderrader.
Sedan kan den tabellen ha en koppling till en separat tabell för leveranser och leveransrader.
Då man märker leveransen och leveransraden med motsvarande ordernummer och orderradernummer kan man sedan på ordern och orderraden se antalet ex som är leverade av de antalet ex som beställdes och hur många som är kvar att leverera. Om allt är levererat kan man fakturera.
* Vill man sedan ha delfakturering i samband med leveranserna så märker man på motsvarande sätt fakturorna med ordernummer och fakturaraderna med orderradernummer och förstås leveransradnummer osv. Allt märks med nummer, dessa nummer används i relationer för att visa vad som pågår.
* Jobbar man på det viset så kan man få fram plocklistor och man kan även hantera inleveranser när man beställt en viss sak för en viss order osv osv.
* Man kan även hantera att av de 12 ex man beställde av sin leverantör, så skulle tre på den ordern, tre på den och tre på den (totalt nio) Tre till på en fjärder order räckte det inte till för leverantören skickade bara 10 ex, så den sista ordern i ordningen får denna gång bara ett ex.
* Man kan också hantera som jag gjorde i ett system en gång att du beställer av dina leverantörer tex en gång i veckan, och beställningen som går iväg skall vara en summering av antalet ex av olika saker som finns på olika ordrar och från olika leverantörer.
När kartongen kommer in så skall man bara tala om från vilken leverantör det kommer ifrån och vad som låg i lådan, så kommer det ur systemet att skrivas ut ett antal lappar som talar om på vilka ordrar de olika sakerna i lådan skall ligga. Om ordern är märkt delleverans så produceras utskrifter för paketet, om den är märkt delfakturering så produceras fakturor. Om den inte är märkt på det viset så kollar systemet om allt är levererat och först då skapas lapparna paketen/fakturan osv. Snurrar det i huvudet nu? Bra!
* Prenumerationer är en annan rolig sak. Dessa faktureras vanligen i förväg, men det går också att göra på andra sätt. Genom att ha titlar (tidningar/artiklar) för sig i en tabell, nummer av titeln (en post per nummer av tidningen), prenumeranter och prenumerationer (start och slut-datum), så kan man generera poster för faktureringen. Som du kanske vet så fungerar relationer i FileMaker så att man i ett fält på endera sidan i relationen kan ha flera rader, och varje enskild rad blir en träff. Om du på posten prenumerationer när du lägger upp den skriver tex:
2009-01
2009-02
2009-03
2009-04
2010-01
2010-02
För fyra nummer av en titel under 2009 och två under 2010), så kan du när du månadsvis/kvartalsvis/årsvis gör faktureringen se via en relation att dessa poster skall med fakturan.
* Vidare om prenumerationer, man kan även lägga upp fakturor utan fakturanummer om man tex har kommit överens om ett serviceavtal med månadsvis fakturing. Det kan görasi samband med att offerten blir order med ett manus.
Dessa fakturor har status ofakturerad (i ett fält) och när det är den 5 i månaden tex så klickar man på en knapp och alla fakturor som saknar nummer hittas och om fakureringdatumet är inom vissa bestämda gränser, så får de nummer och skrivs ut och statusen ändras.
* En sista variant av system är att man har en tjänst man fakturerar för regelbundet och kundens inbetalningar blir en sorts "konto". Varje faktura är ett negativt belopp, varje inbetalning är ett positivt belopp, men det blir poster i samma tabell. Beroende på med vilka olika nummer man märker raden med, så kan man se på en kund, order, faktura, leverans osv om den är fullt betald eller inte. Det fiffiga med detta är att när kunden gör en delinbetalning så funkar det fortfarande.
Jag har byggt alla varianter av ovanstående tidigare. System för logistik är de system som är svårast att bygga. Det betyder tyvärr inte att de är intressantast att bygga.
Tack till johan_tanying! Det du skrev uppskattas och värmer!
