Excel kassa systeem maken met barcodes etc..

[TjerkBennema]

Beste mede tweakers.

Ik ben met het volgende project bezig en eerlijk gezecht gaat het boven mijn pet.
Het gaat om het volgende.

Een kassa die facturen print voor de klant.
Er zijn meerdere kramen en elk artikel moet worden bijgeschreven bij de des betreffende kraam.
De artikelen hebben allemaal een barcode van de des betreffende kraam.

Idee is, barcode van het product word gescant, prijs word ingegeven en dat komt in een extra lijst te staan zodat er een duidelijk overzicht komt wat van welke kraam is verkocht.

Ik heb geprobeerd het zo duidelijk mogenlijk te maken in de volgende foto



Is het mogelijk na afdrukken automatisch opslaan, een nieuw te openen met opvolgend bon nummer?

Hier zou de informatie naar toe moeten.



Is dit allemaal mogelijk?
Of hoe zou ik het anders kunnen doen?

Bijvoorbaat dan voor alle hulp en ideeën.
Ik hoop dat het een beetje duidelijk is.
Tjerk

[Room42]

Maar wat heb je al dan? Wat is je concrete vraag? Of het kan is evident; Dit kan zeker, kijk maar naar de Albert Heijn. Maar dan hebben we het over een compleet ander systeem.

Hoe ver ben je? Heb je al wat gebouwd (buiten deze mock-up) en loop je daar tegen een probleem aan of moet het nog vanaf de grond opgebouwd gaan worden?

Uit je vragen lees ik dat je nog niks hebt... Ik zou dan op zoek naar een bestaand systeem, dat is vast ook wel gratis/goedkoop te krijgen als je niet teveel eisen stelt.

offtopic:
wordt* wordt* wordt*

[CAPSLOCK2000]

Is Excel een eis? Volgens mij is dat niet geschikt voor wat jij wil en heb je een database nodig, maar ik ben geen Excel-kenner.

[TjerkBennema]

Het moet een open systeem zijn, achteraf moeten er makkelijk dingen in veranderd worden, bijgezet en verwijderd.
Waar ik tegen aan loop is dat ik niet de juiste formules/macro's kan vinden.
Tot zo ver ben ik klaar met de barcodes

Excel is eigenlijk wel een eis. Van database programma's heb ik helemaal geen kaas gegeten en de prijs van bijv. acces is een probleem.

[Room42]

Nogmaals; wat heb je al dan? Want volgens mij is Excel inderdaad niet de uitgelezen tool tenzij je heftig aan de VBA en draaitabellen met database backends gaat. Heb je daar wel kaas van gegeten?

Access is ook geen vereiste. Je zou kunnen kijken naar LibreOffice Base met MySQL.

Maar hoeveel tijd heb je om dit in elkaar te zetten?

Verder een nuttige Google Query: [google=open source kassasoftware]

[ Voor 9% gewijzigd door Room42 op 25-03-2015 19:05 ]

[The Eagle]

Als de prijs van access een probleem is, is die van Excel dat net zo goed. Maakt deel uit van de zelfde suite enzo

Sowieso, dit soort dingen moet je, tenzij je slechts af en toe met het handje een factuur moet maken, niet in excel op willen lossen. En zeker niet voor een kassa. Ga je dan ok iedere bontransactie met het handje opslaan? En wat als je een bestand al dan niet per ongeluk overschrijft? Dan is het boekhouding

[Eparox]

Ik zou eerder kijken naar een Open Source ERP systeem, zoals bijvoorbeeld Odoo.

Dan heb je meteen alles wat je zoekt en eventueel meer, zoals de boekhouding. Je kunt zelf modules aanzetten en gebruiken wat je wilt, zit goed in elkaar en het is gratis t/m 2 gebruikers.

[Room42]

The Eagle schreef op woensdag 25 maart 2015 @ 19:23:
Als de prijs van access een probleem is, is die van Excel dat net zo goed. Maakt deel uit van de zelfde suite enzo

Da's natuurlijk onzin. Access zit in veel minder versies van de suite dan Excel en Excel is ook oneindig veel goedkoper als je die licentie al hebt

Sowieso, dit soort dingen moet je, tenzij je slechts af en toe met het handje een factuur moet maken, niet in excel op willen lossen. En zeker niet voor een kassa. Ga je dan ok iedere bontransactie met het handje opslaan? En wat als je een bestand al dan niet per ongeluk overschrijft? Dan is het boekhouding

Precies, Excel is geen runtime applicatie. In the heat of the moment kan er zomaar een (menselijke) fout optreden waardoor belangrijke data verloren kan gaan. Voor consistente opslag kun je beter een gespecialiseerd systeem gebruiken.

[Lustucru]

TjerkBennema schreef op woensdag 25 maart 2015 @ 18:47:
Van database programma's heb ik helemaal geen kaas gegeten en de prijs van bijv. acces is een probleem.

Dan moet je er niet aan beginnen. Sowieso is het een database-applicatie en het wordt er niet beter op als je dat in een spreadsheet programma probeert na te bouwen.

Nu vraag je hoe je met een hamer een televisie kunt repareren want van elektronica heb je geen verstand en een goed soldeerstation is te duur.

[TjerkBennema]

Allereerst bedankt voor alle reacties.
Dat het in excel gemaakt word is echt een must.

Waarvoor je een database nodig zou hebben is me niet helemaal duidelijk. Voor alleen de barcodes met informatie lijkt het een beetje overdreven.

Ik ben het commando =IF(logic_test, value_if true, value_if_false) tegen gekomen.
Snap niet helemaal hoe ik hier kloppend mee aan de slag kan, maar lijkt me het juiste om de regels naar de juiste cel te kopiëren.

Menselijke fouten ga ik tegen met een goed back-up systeem.

Qua tijd heb ik ongeveer nog een week.
Het lijkt mij vrij makkelijk als je weet hoe.
Zijn maar een paar regels in mijn ogen.
Ik weet dat mensen mij waarschijnlijk eigenwijs zullen vinden.
Maar het moet echt op deze manier.

[CAPSLOCK2000]

Niets persoonlijks maar jij bent niet de juiste persoon om dit in een week te bouwen.
Er zijn hier vijf mensen die zeggen dat Excel hier niet geschikt voor is en niemand die het wel een goed idee vindt. Ik zal direct toegeven dat mijn kennis van Excel vrij beperkt is en dat als je het echt wil het best kan maar als die 'if' geen gesneden koek is ben ik bang dat je de achtergrond mist.

Laat je door mij niet tegen houden, als je het maar hard genoeg wil kan het, maar als je per se volgende week iets nodig hebt zou ik over andere opties gaan nadenken.

[geforce5_guy]

Je zou het misschien kunnen doen met de volgende dingen:

=VERT.ZOEKEN()
=HORIZ.ZOEKEN()

Je moet dan wel een blad/sheet hebben met daarin een matrix waarin je gaat zoeken naar de info.

De error die je krijgt komt omdat C11 en E11 leeg is. leeg * leeg = error, hiervoor zou je met een =ALS() aan de gang om die netjes te krijgen.

Het is vast mogelijk om dit in excel te maken, maar het is zeker niet de tool om dit te doen. Als iemand paar verkeerde handelingen doet sta je daar met iets wat niet meer werkt.

Was in een goede bui en heb het volgende voor je gedaan:

link naar excel bestand

Hierin kan je beetje zien hoe het zou kunnen. Maar zodra iemand iets doet in de verkeerde kolom dan ja werkt hij niet meer.

In blad informatie kan je de gegevens invullen.
En bij bon kan je in de kolom artiekelen de barcode invullen. Hij zal automatisch de omschrijving en prijs invullen.

[ Voor 31% gewijzigd door geforce5_guy op 26-03-2015 23:35 ]

[edeboeck]

@TS,
niet om je te ontmoedigen, maar heb je er al bij stilgestaan dat je een toepassing voor een kassasysteem wilt maken? Dat er aan zo een systeem echt wel een aantal eisen gesteld wordt, tenzij je per se problemen wilt met de belastingdienst?
En ten slotte dat jij, die schijnbaar geen programmeerervaring hebt (NOFI, maar zo komt het wel over), dit wilt gaan maken? Binnen 1 week? Met een programma dat eigenlijk niet geschikt is en waar je bovendien weinig ervaring mee lijkt te hebben (aangezien een "IF"-je echt wel basis is).

Kortom, het lijkt me dat je jezelf een hoop ellende op de hals gaat halen (hoe goed je dat ook bedoelt).
Neem de tijd om een basis programmeren onder de knie te krijgen en houd dit project voor de toekomst.
Doorzetten is een mooie kwaliteit... keihard met je hoofd tegen een muur willen bonzen terwijl iedereen je vertelt dat het pijn zal doen, is geen kwaliteit volgens mij.

Just my 0,02...

[nemo55]

TjerkBennema schreef op donderdag 26 maart 2015 @ 21:45:
Allereerst bedankt voor alle reacties.
...
Ik ben het commando =IF(logic_test, value_if true, value_if_false) tegen gekomen.
Snap niet helemaal hoe ik hier kloppend mee aan de slag kan, maar lijkt me het juiste om de regels naar de juiste cel te kopiëren.
...
Het lijkt mij vrij makkelijk als je weet hoe.
...

code:

=IF(CODE("is vrij makkelijk");"Good Luck";"Get some Luck")

[Gomez12]

TjerkBennema schreef op donderdag 26 maart 2015 @ 21:45:
Dat het in excel gemaakt word is echt een must.

Probeer eens uit te leggen waarom? Want excel wil je hier absoluut niet voor hebben, dat biedt 100% vrijheid wat leidt tot veels te veel menselijke fouten en in de praktijk zal dat betekenen dat je meerdere keren per dag terug moet grijpen naar je backup waardoor je aan het einde van het jaar een gribus bende hebt omdat het twijfelachtig is of je backup altijd goed terug gezet wordt (is een missend bonnr een missende bon omdat het niet opgeslagen is of is het de daarop volgende bon omdat het opnieuw ingetypt is, is een gelijk bonnr dezelfde bon of is het een andere bon maar is de backup teruggezet)

Als het gratis moet dan zijn er allerlei open source kassa systemen te downloaden die 100x beter zijn dan excel, dus dat kan niet de must zijn, maar probeer eens uit te leggen wat de must dan wel is.

Waarvoor je een database nodig zou hebben is me niet helemaal duidelijk. Voor alleen de barcodes met informatie lijkt het een beetje overdreven.

Je sheet "waar de data naartoe zou moeten" is in principe al een database in de basis.
Het aankomen met die 2e sheet (wat dus al een database in basis is) is zo ongeveer de reden voor noodzaak van een database, alleen excel kent geen echte beveiliging voor de data die er in je 2e sheet staat en een formele database doet niet echt iets anders als je 2e sheet alleen kent het ingebouwde beveiligingen zodat de data correct blijft over het jaar heen wat excel niet kent.

Menselijke fouten ga ik tegen met een goed back-up systeem.

Catastrofale fouten ga je tegen met een goed backup systeem, menselijke fouten ga je zonder input-validatie en data-consistentie checks pas aan het einde van het jaar opmerken als de boekhouder/accountant/belastingdienst erover valt en dan weet jij echt niet meer wat je nu 11 maanden geleden gedaan hebt.

[RGAT]

Maar wat is dan het hele plan met Excel? Per kassa een excel sheet en die elke vijf minuten handmatig op een laptop bij elkaar voegen? (Of kan Excel tegenwoordig meerdere gebruikers aan, laatste keer dat ik ermee werkte was het als medewerker 1 het opende niemand anders erin kon...)
Dan krijg je een setup waar je tien kassa's hebt (bijv...) en er nooit meer dan 1 tegelijk open kan...

Waarom zou een database overdreven zijn voor een systeem wat vrij belangrijke informatie bevat, je boekhouding, ontgaat me een beetje? Maar dit is belangrijke informatie die jij niet graag kwijt raakt, ik heb er geen ervaring mee met hoe de belastingdienst reageert als je zegt dat je boekhouding weg is...

Verder kan je dit nooit in 1 weekje maken, niet alleen omdat je niet echt veel kennis van VBA of databases hebt (no offence), maar vooral omdat het ontwikkelen van een goed betrouwbaar pakket veel, veel, veel langer duurt dan een weekje, kan dus niet.
Dan zijn je enige opties je deadline flink opschuiven en een ontwikkelaar inhuren, of een open source kassa systeem implementeren.

De eis dat het met Excel moet begrijp ik dus niet, je toont niet erg veel kennis van Excel te hebben (again, no offence) en het is verre van een goed pakket voor deze situatie...

Lijkt mij dat een simpele MySQL database met een tabel voor producten (met barcodes en prijzen), een tabel met kramen en een tabel met verkopen min of meer genoeg is, dan nog een front-end die ook de bon printers kan aansturen (.Net applicatie kan daar wel mee overweg?) en klaar, dat is wel in een weekje te maken.
Wat bedoel je overigens met dat het een open systeem moet zijn waar dingen achteraf veranderd/verwijderd/bijgezet kunnen worden, bedoel je dat artikelen toegevoegd en weggelaten kunnen worden of dat je functies aanpast? Want die laatste gaat altijd gedoe opleveren als je in een bestaande applicatie gaat snijden.

Menselijke fouten ga ik tegen met een goed back-up systeem.

*Please don't...*
Menselijke fouten als artikel 2 keer gescant, verkeerde prijs aan een artikel gekoppeld of alle betalingen van die dag verwijderd omdat Excel daar niets tegen doet... ga je niet elke dag opmerken, je bent dan elke dag de hele tijd bezig dat soort fouten op te zoeken en te herstellen (als dat al kan...) en aan het einde van de rit heb je een boekhouding die waardeloos is omdat de helft mist...

Neem in ieder geval van iedereen hier aan dat Excel echt niet de goede oplossing is hier, persoonlijk zie ik het nooit lukken met Excel, als het al lukt krijg je er een dagtaak aan monitoren bij...
Neem een al bestaand en bewezen kassa pakket, zijn er vast wel wat gratis of iig goedkope te vinden, die implementeren en dan ben je inderdaad in 1 week klaar.

[ Voor 36% gewijzigd door RGAT op 27-03-2015 01:53 ]

[Gomez12]

RGAT schreef op vrijdag 27 maart 2015 @ 01:40:
persoonlijk zie ik het nooit lukken met Excel, als het al lukt krijg je er een dagtaak aan monitoren bij...

Als pure theoretische exercitie waarbij je onbeperkt de tijd hebt zou je het wel in excel kunnen bouwen alleen moet je dan :
A : 99% in VBA bouwen en niet direct in excel
B : 99,9999% van de excel functionaliteit dicht moeten zetten / af moeten vangen
C : In VBA vanaf scratch een kassa-systeem bouwen wat gewoon manjaren werk is om op zichzelf al goed te krijgen, let op dat dit ook geldt voor een home-made .Net / database koppeling.

Als simpel voorbeeld voor C heb je bijvoorbeeld dat in sheet 2 al de btw mist, dat is voor nu niet zo spannend, maar volgend jaar komt de vraag voor meerjaren omzet grafiekjes en dan bouw je die op sheet 2 en dan komt er over 5 jaar bijv een btw-verandering en dan zit je opeens met het feit dat je je sheets aan moet passen, je moet je historische data gaan aanpassen, je moet je grafiekjes aan gaan passen etc. etc.
Terwijl met een fatsoenlijk OS kassa-systeem gewoon standaard btw-veranderingen ingebakken zitten omdat dat pakket het al een keer meegemaakt heeft en weet dat het over x jaar weer kan gebeuren.

Of bijv uitbreidingen vanuit wetgeving (bijv belasting digitaal aanleveren) dat gaat je met een hobby-bob systeem allemaal tijd kosten (en als je dit nu al in een week wilt opleveren dan heb je dan nog minder tijd) terwijl met een OS-systeem je het wellicht van een marketplace af kan halen of desnoods een expert in kan huren die het voor je maakt (waarna jij het weer op een marketplace kan zetten om je kosten terug te halen)

Kijk, in principe kan je het ook in Word wel bouwen(kost je waarschijnlijk net zo veel tijd als in excel omdat je simpelweg 99,9999% van office overboord moet gooien en via VBA moet gaan oplossen).

In principe kan je met een auto vast ook wel een schroefje losdraaien.
Je auto bevat vast wel ergens een scherp randje waarmee je kan schroeven, vereist alleen een hele installatie bouwen om je auto exact rond dat ene scherpe randje te laten draaien (wat wellicht net achter de passagiersstoel zit) alleen je gebruikt 99,9999% van je auto niet meer (alleen dat scherpe randje) en alhoewel je installatie in 1e instantie wellicht perfect is voor een schroefje op 3 meter hoogte (zodat je auto draairuimte heeft) zal het volgende schroefje wellicht op 50cm hoogte zitten waardoor je of een gat in de vloer moet maken of je moet van je auto van alles eraf strippen om de draaicirkel kleiner te krijgen.
Of de meest simpele oplossing : Gebruik een schroevendraaier.

[johnkeates]

Dit gaat niet werken. Gewoon niet. Nee. Niet om lelijk te doen ofzo, maar geen enkele specificatie klopt om ook maar in de buurt te komen van een kassasysteem.

- Je bent geen programmeur maar wil wel programmeren
- Excel is totaal niet geschikt voor dit doel, maar je wil het wel gebruiken
- Hoewel je Excel wil gebruiken lijkt het er niet op dat je echt weet hoe het werkt

Gebruik een bestaande oplossing, er zijn diverse gratis software oplossingen maar ook simpele huursystemen of betaalde software oplossingen. Als het een must is om een kassasysteem te hebben is er waarschijnlijk ook wel genoeg omzet om een kassasysteem in te begroten. Zo niet, dan is de vraag of het zin heeft om een kassasysteem te nemen. Bovendien is er erg veel typewerk, je zou eigenlijk beter als je toch al moet schrijven een kassablok/bonnenblok bij een postorder bedrijf kunnen kopen, dan ben je van al je problemen af. En stel dat je berekeningen niet met hoofdrekenen wil laten doen, dan leg je er een rekenmachine naast van de Action. Kosten vast niet meer dan een euro.

http://www.vikingdirect.n...cm-2-x-50-Vel/id=6906105/

[sprankel]

Akkoord dat Excel niet het geschikte programma is maar vaak is de realiteit dat bedrijven enkel met Excel werken en Acces naast hun neer leggen. Als jobstudent heb ik prompt een meeting gehouden over Acces toen ik zag wat men deed in Excel. Het argument was dat men van Acces geen kaas had gegeten en het dus niet wilde gebruiken. Maar om te doen in Excel wat men deed hadden ze wel een cursus VBA van hier tot in Tokyo liggen naast hun computer. Men heeft inderdaad ingezien dat Acces beter, gemakkelijker en sneller zou zijn maar toch heeft men geweigerd over te stappen omdat het hoofdkwartier in Amerika alles in Excel verwacht. En dan hebben we het over hele databanken inclusief input & output formulieren in Excel werden gebouwd.

Waar ik geen ervaring mee heb is een barcode scanner aan excel hangen maar van wat ik begrijp werkt een barcode scanner als input device. En daarmee bedoel ik als een keyboard waarbij je in de actieve cell een nummer terug krijgt.

Onderstaand is gewoon even uit het hoofd geschreven hoe je het kunt implementeren, zeker niet de meest ideale manier om het binnen Excel te doen maar geeft je een idee.

Button die het "scannen" begint waarachter volgende code
i = 9
loop
range.select("B" & i).select
scan de barcode en zorg dat de input in die cell komt.
i = i + 1
werk met een msgbox om na te gaan of men klaar is met scannen => exit loop
end loop

--hier ben je klaar met scannen

while i >= 9
--- lees barcode in
barcode = range.select("B" & i).value
worksheet("barcode").active
dim x as integer

---zoek de barcode op
x = 1
while range.select("A" & x).value != ""
if range.select("A" & x).value = barcode
artikel = range.select("B" & x).value
--- doe hetzelfde om alle andere info te kopiëren
exit loop
end if
x = x +1
loop
--- plak de info van je gevonden barcode in je bon
worksheet("tablad1").active
range.select("C" & i).value = artikel
--- ga door naar de volgende barcode, als i = 9 is heb je zonet de eerste barcode opgezocht en zal i nu op 8 komen te staan waardoor deze loop stopt
i = i -1
loop

totaal is af te vangen met klassiek Excel waarbij totaal gewoon een sum functie actief is op rij F
btw & korting is ook met klassiek Excel af te vangen.

Bon nummer kan je ergens een cell voor reserveren waar je iedere keer het nummer uithaalt, in principe heb je geen aparte cell nodig. Je moet juist uitmaken of je een event wilt gebruiken (bijvoorbeeld als workbook gesloten word) of je het achter een knop nieuwe bonnummer wilt steken. Dan ga je C5 gewoon +1 doen. Het probleem is dat dit vereist dat je het excel bestand overschrijft en dan staan de artikelen van de vorige bon er nog op.
Je kan dit oplossen door nog een extra sheet waar exact hetzelfde in staat als op een blanco bon.
Nadat je klaar bent laat je sheet1 verwijderen, maak je een kopie van blanco bon sheet en hernoem je die kopie naar sheet1. Hierbij is het wel noodzakelijk bonnumer bij te houden in een andere sheet dan sheet1.

Zowat kort samengevat hoe je het kunt oplossen. Als ik Chinees aan het spreken ben dan adviseer ik je om te concluderen dat dit niet gaat lukken.


Edit:
ik lees dat je net een IF structuur ontdekt hebt, nee, vergeet het, je moet op zijn minst enige programmeerervaring hebben om hieraan te beginnen. Niet alleen zou je alle structuren al moeten kennen (IF, While, Select,For, Do) maar je moet ze ook kunnen nestelen (lees ze door elkaar gebruiken). En dan nog zal het vloeken zijn, VBA in Excel heeft zijn limieten. Om dan nog maar te zwijgen over alle input checks en dingen die je zou moeten afvangen in VBA om ervoor te zorgen dat het niet fout gaat. En dan heb ik het hier nog maar over 1 kassa waarbij de bonnen niet digitaal worden bijgehouden. (je hebt enkel de afgedrukte bon).

[ Voor 9% gewijzigd door sprankel op 27-03-2015 03:42 ]

[Jean Paul]

TjerkBennema schreef op woensdag 25 maart 2015 @ 18:20:
Ik ben met het volgende project bezig en eerlijk gezecht gaat het boven mijn pet.

Niet om lelijk te doen, maar uit blijk van je TS en reacties heb je het hier bij het rechte eind. Het gaat boven je pet
 

Een kassa die facturen print voor de klant.
Er zijn meerdere kramen en elk artikel moet worden bijgeschreven bij de des betreffende kraam.
De artikelen hebben allemaal een barcode van de des betreffende kraam.

Als ik het goed lees gaat het om het (semi-)automatisch maken en printen van facturen op kramen, dus iets van een markt. Eigenlijk wil je dus 1 bon per kraam per verkoop, zonder elke keer productomschrijvingen en prijzen met de hand ter plaatse te moeten invullen. Een verbetering in het huidige handmatige proces.
 

Idee is, barcode van het product word gescant, prijs word ingegeven en dat komt in een extra lijst te staan zodat er een duidelijk overzicht komt wat van welke kraam is verkocht.

Hier hebben we het over het aanleggen van een database. Ja, dit kan ook in Excel, nee, Excel is hier niet voor bedoeld. Er zitten haken en ogen aan, zo is de performance in Excel voor database-doeleinden beduidend minder, kun je het niet of heel moeilijk delen voor gelijktijdig invoer en heb je een beperkt aantal rijen die je kan gebruiken. Of dit laatste voor jou een beperkende factor zal spelen kan ik moeilijk zeggen, hangt van de structuur en verkoop af
 

Ik heb geprobeerd het zo duidelijk mogenlijk te maken in de volgende foto

Is het mogelijk na afdrukken automatisch opslaan, een nieuw te openen met opvolgend bon nummer?

Ja, je kan het automatisch laten opslaan, een nieuwe template openen en de bonnummer aanpassen.

Maar, zoals al eerder benoemd is, zal je hiervoor VBA moeten gebruiken. En VBA, dat is een programmeertaal. Best een makkelijke naar mijn mening, maar aangezien een IF-statement én de uitleg bij de statement je niets zeggen, lijkt het niet voor jou weggelegd.

Daarbij, de "foutmelding" waar je het over hebt, de ######, dit geeft in deze aan dat je kolom niet breed genoeg is om de waarde te laten zien. Nogmaals een teken dat de meest standaard Excel-zaken je compleet onbekend zijn, een voorbode dat je het echt niet in een week zelf zal redden.
 

Hier zou de informatie naar toe moeten.

Een database dus, maar dat zou er qua data-structuur wel anders uit moeten komen te zien. En daarvoor heb je toch wel feeling en kennis nodig van databases.
 

Is dit allemaal mogelijk?
Of hoe zou ik het anders kunnen doen?

Ja, het is mogelijk. Misschien dat je je het jezelf aan kan leren, maar nogmaals, niet in een week, niet met de kennis die je nu hebt.

Hoe het anders zou kunnen is al aangedragen, gratis software e.d. Maar blijkbaar moet het in Excel. Tja.. Wil je dat, zul je je er echt in moeten verdiepen en jezelf veel meer tijd moeten gunnen.

[Croga]

Met het risico dat ik hier een aantal puristen tegen de schenen schop:

Als we dit idee incrementeel zouden bekijken zou je het kunnen opdelen in:

- Factuur maken en printen bij de kraam
- Het concept van meerdere kramen toevoegen inclusief overall ordernummering (met automatische ophoging) en centrale opslag van factuur-metadata

Die eerste is, naar mijn mening, in Excel te doen. Je praat dan over één sheet met producten en één sheet met "factuur". Zonder automatische ophoging van factuurnummers en zonder links tussen de verschillende kramen. Je hebt het dan over 90% eenvoudige standaard excel functionaliteit, 5% "vlookup" en 5% barcode scannen. Stelt heel erg weinig voor.

Stap twee is, in theorie, ook in Excel te doen alleen ga je heel hard tegen beperkingen aanlopen. Als je incrementeel gaat werken dan zou het totale product neerkomen op een excelsheet per kraam met een VBA link naar een centrale database.

Ik gok dat stap 1 in een week te doen is, voor iemand met excel kennis. Nog sterker: Iemand met kennis zet dit in een dag of 2 in elkaar. Ik gok dat stap 2, voor iemand met uitgebreide VBA kennis en ervaring, in een paar weken te doen is.
Voor iemand zonder kennis is stap 1 wellicht in een week te doen. Het keyword hierin is (V/H)LOOKUP. Daarmee haal je je productgegevens uit een tabel. De rest is vooral een kwestie van er op vertrouwen data degenen die de sheet gebruiken snappen hoe het werkt en weten waar ze mee bezig zijn.
Voor iemand zonder kennis is stap 2 geen optie. Gaat hem niet worden, vergeet het maar, niet aan beginnen.

Bottom line: Als je tijdspad je niet toestaat om op het juiste moment de juiste functionaliteit te bereiken kun je twee dingen doen:
- Je tijdspad aanpassen en de juiste functionaliteit later krijgen
- Je scope verkleinen en dus op het juiste moment minder functionaliteit krijgen
Als je kiest voor optie 1 dan kun je nooit naar optie 2. Kies je voor optie 2 dan kun je altijd nog naar optie 1 over gaan.
De verkleinde scope zou kunnen gaan werken, de scope zoals hij nu staat gaat zeker niet werken.
Persoonlijk zou ik gewoon kiezen voor een verkleinde scope, zelf realiseren en mee aan het werk gaan. Als dan uiteindelijk blijkt dat de scope uitbreiding écht nodig is, kun je altijd nog meer geld uit gaan geven om dat te bereiken.

[Jean Paul]

Croga schreef op vrijdag 27 maart 2015 @ 09:18:
[...]

Puristen of niet, je hebt het wel grotendeels bij het rechte eind.

Je hebt 1 sheet nodig, centraal of decentraal, met alle barcodes, productomschrijving indien van toepassing en prijzen. Op zich snel in elkaar te zetten, afhankelijk van de hoeveelheid producten.

Eenmaal deze sheet opgezet, kun je in ieder geval één stap makkelijker maken; het scannen met bijbehorende productomschrijving en -prijs.

Een scanner kan geprogrammeerd worden om na invoer automatisch een enter mee te geven, en zo kun je snel barcodes scannen om de factuur verder automatisch te vullen. Let wel, heb je meer rijen nodig dan in je standaard template, moet je dus ter plekke handmatig de rijen met formules doortrekken.

Gezien de huidige opzet zal de hoeveelheid producten met de hand ingevoerd moeten worden. Automatisch (dus x keer scannen van eenzelfde product) en dit op 1 rij krijgen in de factuur vergt een compleet andere aanpak en is niet te adviseren in dit stadium.

Met behulp van de VLOOKUP kun je in de product-sheet een omschrijving en prijs ophalen. Inderdaad simpel:

VLOOKUP([cel met barcode];[tabelnaam of range];[positie van kolom in tabelnaam of range met waarde terug te halen;0 (=barcode moet exact overenkomen))

Let wel; de eerste kolom van de tabel of range waarin je zoekt, moet de zoekwaarde bevatten. In dit geval de barcode. De tweede kolom kan de productomschrijving bevatten en de derde kolom de prijs.

Op deze manier heb je een deel van het handmatige schrijf- of typwerk al geautomatiseerd.

De product-sheet kun je het beste in een table format zetten (home ribbon - format as table), zo heb je een handige lijst in een tabel met bijbehorende tabelnaam en zit je in de toekomst, wanneer je producten toevoegt of weghaalt, niet te kloten met ranges in bestaande formules.

Maar het tweede deel, het wegschrijven van alle waarden in een centrale sheet, is iets waar je toch al snel naar VBA moet stappen. Je kan een knop in je factuurlijst bijvoorbeeld aanmaken, deze knop schiet een VBA-functie af welke:

• de factuur afdrukt
• de informatie van de factuur opslaat in een (de)centrale database (kan een Excel-bestand zijn)
• de bonnummer verhoogt (kan gelinkt worden met een decentrale database om unnieke bonnummers te gebruiken voor alle kramen)
• de invoerbare waarden in template weer leegmaakt zodat de bon herbruikbaar is

Je hoeft dan niet een sheet per factuur te generenen, immers sla je alles op in een centrale database. Hier kun je later alles uit reproduceren.

Het gevaar bij het gebruik van een Excel-bestand als database is dat wanneer meerdere kramen tegelijk een factuur aanmaken, waarden overschreven worden. Om dit te voorkomen, zal je een best controlesysteem moeten inbouwen voor het wegschrijven. Dit zou je niet hebben wanneer er naar bijvoorbeeld een Access-database weggeschreven wordt.

Wat je wel kan doen, is in een Excel-bestand meerdere sheets per kraam gebruiken, en deze later combineren. Unieke bonnummers heb je dan niet (is op een andere manier wel weer mogelijk, maar vergt ook weer programmeerwerk in bijvoorbeeld VBA), dan zijn ze alleen uniek per kraam. Voor deze aanpak hoef je echter geen centraal bestand te hebben, dit kun je ook in een aparte sheet zetten van het Excel-bestand met factuur.

In alle eerlijkheid is dat makkelijk in een week te doen, voor iemand met Excel en VBA kennis. Alleen het centraal wegschrijven is een uitdaging, zoals ik eerder benoemde. Niet het wegschrijven zelf, maar een manier dat je niet bij gelijktijdig wegschrijven elkaars informatie overschrijft.

Kun je ook weer ondervangen door Access te gebruiken, of door de sheet niet deelbaar te maken en steeds te openen, aan te passen en te sluiten, foutmeldingen ondervangen wanneer de sheet al in gebruik is en opnieuw te proberen in b.v. x seconden etc. Maar dat vergt meer VBA kennis dan het aanroepen van de de print-functie e.d.

Wat handig is, hangt van het doel van de TS af. Moet de bonnummer uniek zijn voor alle kramen, of mag je dezelfde bonnummer hebben voor andere kramen? Ofwel, kraam 1 heeft bonnummer 1, 2 en 3, en kraam 2 heeft ook bonnummer 1, 2 en 3 of moet dat dan 4, 5 en 6 zijn?
Volstaat het om een deel al te automatiseren, of moet het complete pakket inclusief centraal wegschrijven gelijk gerealesieerd zijn?

Dat laatste zal TS niet zelf redden in een week, zoals velen al benoemd hebben..

[Antique]

Misschien is TS wel zo koppig m.b.t. het vasthouden aan Excel, omdat zijn opdrachtgever / baas / organisator dat zo heeft bepaald. Die kent geen andere programma's, wat de boer niet kent etc. etc. dus Excel moet het zijn want daar heeft hij zelf zijn prive administratie ook maar mooi op gedaan en de rest is veel te veel risico want onbekend en eng.

Als ik de "computerman" in zo'n organisatie was zou ik die baas een demonstratie geven van een fatsoenlijk open source kassasysteem. Met uitvoer van data naar Excel, zodat hij de gegevens later in zijn vertrouwde programmaatje kan bekijken.

[Jean Paul]

Antique schreef op vrijdag 27 maart 2015 @ 10:17:
Misschien is TS wel zo koppig m.b.t. het vasthouden aan Excel, omdat zijn opdrachtgever / baas / organisator dat zo heeft bepaald. Die kent geen andere programma's, wat de boer niet kent etc. etc. dus Excel moet het zijn want daar heeft hij zelf zijn prive administratie ook maar mooi op gedaan en de rest is veel te veel risico want onbekend en eng.

Als ik de "computerman" in zo'n organisatie was zou ik die baas een demonstratie geven van een fatsoenlijk open source kassasysteem. Met uitvoer van data naar Excel, zodat hij de gegevens later in zijn vertrouwde programmaatje kan bekijken.

Gezien hier gesproken wordt over kramen, vermoed ik dat het om markten gaat, vaak ZZP'ers en geen organisaties. We hebben het dus hoogstwaarschijnlijk over verkopers welke hun eigen administratie bijhouden, en een deel handmatig werk willen automatiseren om het verkoopproces en latere administratie een stuk makkelijker en sneller te laten verlopen. Marktverkopers maken lange dagen, ik kan mij zeer goed voorstellen dat ze het proces daarom makkelijker en sneller willen maken.

Tuurlijk zijn er legio oplossingen, dure en gratis, maar daar is al snel veel meer technische kennis voor nodig. En die zal er niet (altijd) zijn, laat staan de tijd om het allemaal eigen te maken.

Het gaat iets in de trend van;

• 5 uur bus inladen
• 6 uur arriveren op markt
• na arriveren bus uitladen, marktkraam uitbouwen / inrichten etc
• verkoop tot 16 of 17 uur in de middag
• afbouwen en bus inladen en terugrijden
• 18 uur de bus uitladen
• 19 tot 22 uur administratie

Dan moet je ook nog ergens boodschappen doen, eten en een privé-leven leiden.

Ik snap de aanvliegroute dan ook zeker, en voor deze doelgroep is Excel imo een prima oplossing. Immers, het maakt het huidige werk al een heel stuk makkelijker en vrijwel iedereen heeft Excel beschikbaar.

[Antique]

Dat het een druk bestaan is en dat er daarom snelle en geen-gedoe oplossingen nodig zijn, begrijp ik heel goed.

Het probleem is het vooroordeel bij de groenteboeren, visboeren etc. dat alles wat geen Excel is, per definitie "te technisch" en daarom "gedoe" zal zijn. Terwijl krampachtig vasthouden aan Excel juist voor onnodig technisch gezeik gaat zorgen. Laat die boeren maar eens wat Excel VBA scripting zien. Is dat wat ze willen? Maar, zeg jij dan, die boeren hoeven toch nooit naar die VBA code te kijken. Zodra het gescript is kunnen ze gewoon scannen en gaan met die banaan.

Precies, zeg ik dan. Dat is ook zo als je geschikte kassasoftware neemt. Met het verschil dat ook de "technische man" dan in een paar dagen klaar is, i.p.v. vele maanden, en dat het resultaat veel betrouwbaarder is en minder onderhoud vereist.

Laat daarna die boeren eens een willekeurige kassa in de Trekpleister zien. Draait die op Excel? Nee. Kan een 16-jarige minimumloner ermee overweg? Prima.

En vergeet niet dat die kassasoftware ook Excel exports ondersteunt. Ze kunnen alle gegevens voor hun administratie dus in hun favoriete programma verwerken.

Vandaar dus mijn advies, een demonstratie. Zodra bij de eindgebruikers de angst weg is dat het "niet Excel is en dus moeilijk" heb je meteen het probleem opgelost. Desnoods bied je aan om meerdere systemen met ze te proberen en dan mogen zij de handigste kiezen.

[ Voor 24% gewijzigd door Antique op 27-03-2015 10:41 ]

[Jean Paul]

Antique schreef op vrijdag 27 maart 2015 @ 10:37:
Dat het een druk bestaan is en dat er daarom snelle en geen-gedoe oplossingen nodig zijn, begrijp ik heel goed.

Het probleem is het vooroordeel bij de groenteboeren, visboeren etc. dat alles wat geen Excel is, per definitie "te technisch" en daarom "gedoe" zal zijn. Terwijl krampachtig vasthouden aan Excel juist voor onnodig technisch gezeik gaat zorgen. Laat die boeren maar eens wat Excel VBA scripting zien. Is dat wat ze willen? Maar, zeg jij dan, die boeren hoeven toch nooit naar die VBA code te kijken. Zodra het gescript is kunnen ze gewoon scannen en gaan met die banaan.

Precies, zeg ik dan. Dat is ook zo als je geschikte kassasoftware neemt. Met het verschil dat ook de "technische man" dan in een paar dagen klaar is, i.p.v. vele maanden, en dat het resultaat veel betrouwbaarder is en minder onderhoud vereist.

Laat daarna die boeren eens een willekeurige kassa in de Trekpleister zien. Draait die op Excel? Nee. Kan een 16-jarige minimumloner ermee overweg? Prima.

En vergeet niet dat die kassasoftware ook Excel exports ondersteunt. Ze kunnen alle gegevens voor hun administratie dus in hun favoriete programma verwerken.

Maar dat vergt een investering, waarbij eenmalig (zelf) iets in Excel zetten alleen (vrije) tijd kost.

Ik ben het met je eens, er zijn systemen voor. Heck, je kan zelfs mobiele kassa's aanschaffen, je ziet ze genoeg op markten. Dat zijn alleen stevige investeringen welke niet elke ZZP'er kan of wil doen.

TS vraagt overigens of er andere manieren zijn, als je die hebt (lijkt erop gezien je reactie) zou ik ze aandragen, wellicht kun je "die boeren" een gouden tip geven en op weg helpen, in plaats van de kant van Excel te laten afdwalen.

[Antique]

Er zijn voldoende open source pakketten voorgesteld, die geen of amper geld kosten. TS doet daar vooralsnog niets mee. De bottleneck zit hem dus momenteel in de bereidheid van TS en zijn klanten om van Excel af te stappen. Imho zal hij geen goede oplossing vinden totdat hij die stap gezet heeft, en daar zijn mijn reacties dan ook op gericht.

Edit: op basis van je eerdere reacties in de thread zijn we het wel eens. Ik denk alleen dat technische oplossingen aandragen op dit moment het probleem niet gaat oplossen. Het maakt eigenlijk niet uit welk pakket ze kiezen, de crux hier is dat er angst onder de gebruikers is voor niet-Excel, en daar moet de oplossing zich dan ook op richten, Dit vereist meer een menselijke/sociale aanpak dan een technische. Ze moeten gewoon met elkaar eens gaan kijken of er tussen de gratis kassaprogramma's iets tussen zit waar ze iets mee kunnen. Misschien bestaat er wel eentje die de bonnen presenteert op een Excel-achtige spreadsheet inferface en is dat voldoende geruststelling.

Het vinden van zo'n pakket valt toch echt onder de eigen moeite die TS hierin mag steken, anders kunnen we met z'n allen in deze thread wel een collectief uurtarief gaan bespreken. Hier nog maar een linkje van iemand in een vergelijkbare situatie, kleine ondernemer zoekt systeem dat vooral eenvoudig en gratis moet zijn: http://hallo.kvk.nl/hallo...ict/f/144047/t/22393.aspx

[ Voor 67% gewijzigd door Antique op 27-03-2015 11:07 ]

[Breezers]

Geen idee of het wat is, maar kijk gewoon eens naar freeware POS software ?

http://www.nchsoftware.com/point-of-sale/

Deze is gratis, vrij aanpasbaar en ondersteund zo te lezen scanners.

Al zou je de pro versie moeten kopen, dan is 35 euro natuurlijk een schijntje:

Qty Select the Software you Need Normal Price Discount Price Euro
(est)*
Copper Point of Sale Software Pro Edition
Fully featured, single installation license more info... $60 $39.95* €35.83

[Bert2000]

Offtopic. Daar zijn TR's voor. Reageer on topic of reageer niet

[ Voor 71% gewijzigd door Lustucru op 27-03-2015 13:42 ]

[TjerkBennema]

Ok ik ben deels om.

Het concept waaraan het moet voldoen heb ik volgens mij niet helemaal duidelijk uitgelegd.

De kramen zijn geen losse winkels, hier staan spullen op van verschillende mensen.
Mensen kunnen een kraam huren, krijg een rol barcodes van de desbetreffende kraam.
Deze plakken ze op en plakken een stikker met prijs er op.
Alles van alle kramen word afgerekend op 1 kassa.
Vandaar uit moet het in een excel document komen waarin staat wat is afgerekend van welke kraam, zodat later de mensen die een kraam hebben gehuurd weten hoe veel geld ze krijgen.

Dus voor de duidelijkheid, het gaat om een beperkt aantal barcodes waar een kraam aan zit gekoppeld, geen product.
Er moet een overzicht komen waarin per kraam de afgerekende artikelen staan.

Hoop dat het zo duidelijker is.
Bedankt voor alle reacties tot nu toe die mij vertellen hoe stom ik eigenlijk ben en mij laten inzien dat het zo niet gaat werken.

[CAPSLOCK2000]

Vergeet Excel. Probeer het niet zelf te bouwen. Zoek iets kant en klaars, misschien, heel misschien haal je dan je deadline.

[Room42]

Ok, de barcode is dus meer een 'account' i.p.v. een productidentificatie. Die hoef je dus ook niet te scannen als product.

En de 'afgerekende artikelen' komen dan van....? Die typ je steeds handmatig in ofzo?

offtopic:
Enneh wordt*!

En verder totaal met CAPSLOCK2000 eens.

[RGAT]

TjerkBennema schreef op vrijdag 27 maart 2015 @ 16:44:
Ok ik ben deels om.

Het concept waaraan het moet voldoen heb ik volgens mij niet helemaal duidelijk uitgelegd.

De kramen zijn geen losse winkels, hier staan spullen op van verschillende mensen.
Mensen kunnen een kraam huren, krijg een rol barcodes van de desbetreffende kraam.
Deze plakken ze op en plakken een stikker met prijs er op.
Alles van alle kramen word afgerekend op 1 kassa.
Vandaar uit moet het in een excel document komen waarin staat wat is afgerekend van welke kraam, zodat later de mensen die een kraam hebben gehuurd weten hoe veel geld ze krijgen.

Dus voor de duidelijkheid, het gaat om een beperkt aantal barcodes waar een kraam aan zit gekoppeld, geen product.
Er moet een overzicht komen waarin per kraam de afgerekende artikelen staan.

Hoop dat het zo duidelijker is.
Bedankt voor alle reacties tot nu toe die mij vertellen hoe stom ik eigenlijk ben en mij laten inzien dat het zo niet gaat werken.

Hoop dat het niet zo overkwam, we bedoelen het iig goed

Maar wat koppel je nou daadwerkelijk aan de barcode? Als je gewoon een rol stikkers uitdeelt is de barcode niet gelinkt aan het product waar het op zit, dan moet je aan de kassa ook nog eens invullen wat het product is of in ieder geval wat de prijs ervan is.
Oftewel: Wil je echt alleen een kraamnummer (of naam) aan de barcode koppelen, of ook een artikelnaam en prijs?

Vooral omdat je aan de hand van de output, en die kan je ook met een database wel weer in een Excel documentje stoppen, maar het geheel in Excel doen is zonde de huurders van de kraampjes wilt betalen zal je dus elk artikel eerst moeten registreren aan een barcode.
Iets met een handscanner, of de kraamhuurder dat zelf laten doen kan, maar daar heb je ook iets voor nodig zodat ingevoerd kan worden dat het eiken tv meubel met barcode XXXX1 bij kraam 2 hoort en hetzelfde meubel wat bij kraam 1 staat barcode XXXX3 heeft, zodat als kraam 2 hun meubel verkoopt zij het geld krijgen en niet kraam 1

[TjerkBennema]

Ik weet dat het goed bedoelt is, snap heel goed met mijn eigenwijze kop dat ik tegen een muur aan liep. Duurt soms langer dan 1 reactie maar een bak code waar mijn van open valt helpt zeker.

Het gaat niet perse om het product, maar alleen om de prijs.
De mensen die het neer zetten(de kraam huren) moeten ook zo snel mogelijk weer de winkel uit kunnen.

[Antique]

TjerkBennema schreef op vrijdag 27 maart 2015 @ 16:44:
De kramen zijn geen losse winkels, hier staan spullen op van verschillende mensen.
Mensen kunnen een kraam huren, krijg een rol barcodes van de desbetreffende kraam.
Deze plakken ze op en plakken een stikker met prijs er op.
Alles van alle kramen word afgerekend op 1 kassa.
Vandaar uit moet het in een excel document komen waarin staat wat is afgerekend van welke kraam, zodat later de mensen die een kraam hebben gehuurd weten hoe veel geld ze krijgen.

Dus voor de duidelijkheid, het gaat om een beperkt aantal barcodes waar een kraam aan zit gekoppeld, geen product.
Er moet een overzicht komen waarin per kraam de afgerekende artikelen staan.

Probeer het eens vanuit de menselijke kant te benaderen. Dan vraag je jezelf af: wie moeten het systeem bedienen, d.w.z. wie staan er achter die kassa? Dat kunnen best andere mensen zijn dan de kraamverkopers, ik weet dat niet, jij wel hopelijk.

Het punt is: als er maar een paar personen achter de kassa staan, terwijl de rest van de betrokkenen in dit project lekker achter hun eigen kraam hangen en alleen achteraf een Excel sheetje met hun eindomzet moeten krijgen, dan heb je dus drie eisen aan je software:
1. De mensen die achter de kassa staan moeten er vlot mee om kunnen gaan.
2. Alle kooplui moeten hun productgegevens gemakkelijk kunnen aanleveren om in het kassasysteem te zetten. (Import functie, of handmatig overzetten uit een Excel sheet als het niet teveel producten zijn)
3. Jij moet als het feestje over is de gegevens naar Excel kunnen exporteren om door te sturen naar de kooplui.

Het wordt weer een heel ander verhaal als al die kooplui afwisselend kassadienst hebben, of als je uberhaupt geen idee hebt hoe dat geregeld gaat worden. In dat geval zou ik eens informeren bij en overleggen met de organisatie of het te regelen valt dat er één of twee man vaste kassadienst krijgen en dat de rest er vanaf blijft.

Dan ga jij een uurtje met die twee om de tafel zitten, je toont ze 2 of 3 kassasystemen (die je zelf van te voren hebt geselecteerd en getest), en laat ze kiezen welke ze het handigst vinden. Dan geef je ze een goede training en een korte cheat sheet voor als ze het even vergeten.

Het grootste probleem blijft dat je (mogelijk) met gebruikers te maken hebt die niets kennen behalve Excel. Daar moet je dus als eerste mee aan de slag. Twee mensen een systeempje leren die dat als vaste taak gaan krijgen is veel makkelijker dan 50 mensen een systeempje leren dat ze toch maar een half uur gaan gebruiken op die avond, en dus hebben ze tijdens je uitleg wel wat anders aan hun hoofd.

[TjerkBennema]

Er staan geen mensen achter de kraampjes, je kan ze beter zien als etalages.

[WhiteDog]

Je kan tegenwoordig geloof ik gratis Visual Studio downloaden (in het slechtste geval kopen). In Visual Basic kan je iets als dit wél makkelijk in elkaar draaien. Iemand die wat kan programmeren bouwt dit in een dag.

Voordeel: daarna heb je een EXE die je makkelijk overal kan installeren en waar niet iedereen aan loopt te prullen. Als iets als dit in VB je petje te boven gaat dan zal het in Excel met VBA ook niet lukken.

Zou zeggen ga is een dagje prullen met VB.NET, worst case geef je het op na een dag

Edit:
En voor Excel en Access zijn ook gratis open-source alternatieven...

[ Voor 7% gewijzigd door WhiteDog op 27-03-2015 17:33 ]

[Antique]

TjerkBennema schreef op vrijdag 27 maart 2015 @ 17:31:
Er staan geen mensen achter de kraampjes, je kan ze beter zien als etalages.

Ok, duidelijk. Maar waar het om gaat is: wie staat er nou achter die kassa? Hoeveel mensen, en hoe handig zijn ze, en kan je ze van te voren spreken?

Je moet wel je doelgroep van users kennen als je software uitzoekt / ontwikkelt, en daar hebben we tot nu toe vrijwel geen informatie over. Ja, we weten dat er mensen zijn die spullen aanleveren en Excel gegevens terugkrijgen, maar die staan niet achter de kassa (blijkt nu). Wie staat daar dan wel? Jij alleen? Of...?

Edit: anti-frustratiebal gevonden

[ Voor 37% gewijzigd door Antique op 27-03-2015 17:44 ]

[TjerkBennema]

Er komt denk ik maar 1 persoon in die winkel te staan.
Dat persoon is het probleem ook niet.

Heb meerdere opensource kassa systemen bekeken.
Ze werken eigenlijk allemaal met producten. Dit is juist niet nodig en niet gewenst.
De prijs moet altijd variabel zijn, dit zijn ook de voornaamste redenen dat ik naar excel keek

[Antique]

TjerkBennema schreef op vrijdag 27 maart 2015 @ 17:40:
Er komt denk ik maar 1 persoon in die winkel te staan.
Dat persoon is het probleem ook niet.

Dat is mooi, want dan hoeven er maar 2 mensen met dat programma te werken. Jij en de kassabediende. De andere mensen leveren gewoon Excel sheets die jij in het programma importeert, en als het klaar is krijgen ze Excel sheets die jij hebt geëxporteerd.

TjerkBennema schreef op vrijdag 27 maart 2015 @ 17:40:Heb meerdere opensource kassa systemen bekeken.
Ze werken eigenlijk allemaal met producten. Dit is juist niet nodig en niet gewenst.
De prijs moet altijd variabel zijn, dit zijn ook de voornaamste redenen dat ik naar excel keek

Je zegt in je andere posts steeds dat je met barcodes wilt werken. Hoe wil je met barcodes gaan werken als je geen database met producten aanlegt? Welke informatie staat er dan nog op zo'n barcode? Puur en alleen van welke kraam hij afkomstig is? Dus geen prijs? Die moet de kassabediende handmatig invullen?

[TjerkBennema]

Echt alleen de kraam. En dat wil ik automatisch in een overzicht hebben.

[Antique]

Dus de kassabediende moet wel voor elk product handmatig de prijs intikken?

[TjerkBennema]

Ja, van elk product
Anders zou de gene die een kraam huurt van alles de prijs moeten inkloppen en elk artikel in het systeem moeten zetten.

[Antique]

Dan lijkt het mij veel efficiënter als die kassabediende voor elk verkocht voorwerp handmatig ook het kraamnummer intikt.

Ik bedoel, stel je hebt 10 verschillende kramen die je uit elkaar moet houden. Dan is het kraamnummer letterlijk 1 toets op het cijferblok gevolgd door Enter, en daarna tik je de prijs van het voorwerp in. Simpel toch?

Vergelijk dat eens met de moeite die je moet doen als je met barcodes gaat werken: dan moet de kassabediende de scanner oppakken, de barcode scannen, de scanner neerleggen en zijn handen naar het toetsenbord bewegen om de prijs handmatig in te tikken, dan weer de scanner oppakken voor het volgende voorwerp, etc. etc.

Het hele idee van barcodes is dat je één keer hoeft te scannen en dan klaar bent. Als je je kassabediende dan toch met de hand prijzen laat intikken dan haal je dat idee onderuit. Als de kassabediede toch zijn handen al bij het toetsenbord nodig heeft om de prijs in te tikken, dan is een extra getalletje of lettertje voor de kraam toch veel minder moeite?

Dus: laat je kraameigenaren hun voorwerpen kleurcoderen. De ene geef je blauwe stickers om de prijzen op te schrijven, de andere groene stickers, etc. Vergeet die barcodes en scanner. Zoek een paar simpele POS programma's, test ze eerst zelf uit en kies er 3 uit, laat je kassabediende die proberen en er eentje kiezen.

Je zou dit zelfs met een klassieke kassa kunnen doen. Mijn vader heeft in zijn boekhandel verschillende productcategorieën op de kassa, bijvoorbeeld "Tijdschrift" en "Wenskaart" etc. In de einduitdraai kun je die bedragen dan gescheiden te zien krijgen. In plaats van "Tijdschrift" plak jij gewoon kleurstickers op die categorie-knoppen, en klaar.

[ Voor 18% gewijzigd door Antique op 27-03-2015 18:08 ]

[RVE_NL]

TjerkBennema schreef op vrijdag 27 maart 2015 @ 17:40:
Er komt denk ik maar 1 persoon in die winkel te staan.
Dat persoon is het probleem ook niet.

Heb meerdere opensource kassa systemen bekeken.
Ze werken eigenlijk allemaal met producten. Dit is juist niet nodig en niet gewenst.
De prijs moet altijd variabel zijn, dit zijn ook de voornaamste redenen dat ik naar excel keek

Ik denk dat je je het te moeilijk maakt. Geef ieder 'kraampje/etalage' een eigen barcode.
In je programma kun je natuurlijk aangeven productomschrijving: 'barcode 1' 'kraampje/etalage Piet', 'barcode 2' 'kraampje/etalage Henk', 'barcode 3' 'kraampje/etalage Jan' etc.

Als je met meerdere prijs niveau's per 'kraampje/etalage' wil werken kun je dit ook eenvoudig toepassen, geef ieder 'kraampje/etalage' bijvoorbeeld 3 barcodes.
Dus:
'barcode 1' 'kraampje/etalage Piet' 'prijs 5 euro'
'barcode 2' 'kraampje/etalage Piet' 'prijs 10 euro'
'barcode 3' 'kraampje/etalage Piet' 'prijs 15 euro'
'barcode 4' 'kraampje/etalage Henk' 'prijs 2,5 euro'
'barcode 5' 'kraampje/etalage Henk' 'prijs 5 euro'
'barcode 6' 'kraampje/etalage Henk' 'prijs 10 euro'
'barcode 7' 'kraampje/etalage Jan' 'prijs 3 euro'
'barcode 8' 'kraampje/etalage Jan' 'prijs 6 euro'
'barcode 9' 'kraampje/etalage Jan' 'prijs 9 euro'

Dit kun je prima doen met diezelfde bestaande opensource kassasystemen, scheelt je een hoop tijd en werkt tenminste ook goed.

Als het gaat om de data bij iemand aan leveren gaat, laat het programma gewoon een exel uitdraai maken .

Mocht je nog niet overtuigd zijn:
Iedereen probeert hier met je mee te denken, als je je concept deelt kunnen we misschien ookbegrijpen waarom het persé exel moet zijn. Wellicht is er dan ook een makkelijkere/betere optie.

[Gomez12]

Zoals je het nu weer beschrijft wil je imho helemaal geen barcodes / computers / excel hebben.

Je wilt gewoon in de basis een kassa met een makkelijke categorie / kosten-verdeling die kan exporteren naar excel.

Enige vraag die er dan relevant is is volgens mij : Hoeveel categorieeen / kostenposten / kramen heb je? Want die hoeveelheid bepaalt de weg die je wilt opgaan (waarbij barcodes imho pas een zinnige weg is als je er 10.000'en hebt).

Heb je 10 kramen dan is simpelweg een gekleurd toetsensysteem het makkelijkst.
Heb je 20 tot 999 kramen dan zou ik zeggen : Schaf een paar prijstangen aan die links een kraamnummer afdrukken en rechts de prijs oid. Zodat de kassabediende gewoon in 1x door kan typen van kraamnummer naar prijs.

Een gemiddelde kassabediende typt echt 100x sneller een kraamnummer + prijs in dan dat er een losse handeling moet plaatsvinden (barcode scannen) om daarna nog te gaan typen.
Plus dat eigenlijk elke kassa die ik ooit gezien heb wel een kostenverdeling systeem kent.

Daarom is volgens mij de enige vraag : Hoeveel kramen / kostenposten heb je en zoek daar de kassa bij

[CAPSLOCK2000]

Gebruik pen en papier.
Als je het echt op de computer wil doen laat de kassabediende het dan zelf allemaal invoeren.
Dat klinkt misschien lullig maar lijkt mij echt de beste oplossing voor jouw situatie.

[johnkeates]

Ik zal het nog even wat duidelijker posten, de vorige lijkt onopgemerkt langs te zijn gegaan:



Hier hebben we als mensheid natuurlijk al wat voor bedacht. Als je toch al aan het schrijven bent is dit het makkelijkste.

Wil je perse typen, dan is er makkelijk een digitale versie van te regelen, bijvoorbeeld een Google Docs formulier, of zelfs een Excel formulier, of een Access formulier, of een LibreOffice Base formulier...

Digitaal lijkt me in dit geval niet heel veel toe te voegen, maar stel dat het handig is om dat er aan het eind van de rit perse een digitale lijst moet zijn, zou dat makkelijk kunnen. Geen kassa systeem, maar gewoon een formuliertje.

[ Voor 103% gewijzigd door johnkeates op 27-03-2015 22:52 ]

[Megamind]

Als je geen prijs aan je barcodes koppelt, wat doen die barcodes dan?

Koop gewoon zoiets:

Dan ben je gelijk klaar aangezien je toch geen administratie of inventory hebt.

[Xanaroth]

Misschien domme opmerking.

Maar hoe krijg je een gedetailleerde bon voor het onderste deel tekst 'omruilen binnen 8 dagen'?

Als er enkel kraamnummers en prijzen rondgaan, dan kun je naderhand nooit bekijken welke prijs bij welk product hoort als het omgeruild wordt. Moet je die persoon met 3 artikelen nu 2,- 50,- of 12.50 teruggeven? Het prijsje is er niet meer, was een kado...

En bij welke kraam hoorde dat artikel eigenlijk, want als je de prijs/product koppeling niet hebt kan je die koppeling ook niet maken. Dus aan het einde van de dag geef je een willekeurig bedrag (in goed vertrouwen) uit de kassa terug, maar weet niet bij welke kraam je dat in mindering moet brengen.


Ik zie enorme welles-nietes spelletjes aankomen. Want ieder zal dan het volle pond eisen onder het mom van 'dat is niet mijn artikel wat retour kwam' of 'nee, die was 2,- niet 12,50 dus betaal zelf maar die 10,50 die je teveel teruggaf' en blijft de winkel (jij?) achter met het risico en de schuld, terwijl zij de winsten pakken.
Dus ik raad je aan toch echt meer koppelingen aan te brengen dan kraam/waarde, anders kom je in de toekomst vanzelf in de problemen omdat je de boekhouding vroeg of laat niet voldoende sluitend kunt maken met de inhoud van de kassa.

Of ze zeggen op een dag dat je uitdraai niet klopt, want ze hebben 5x een artikel minder in de kraam en dat bedrag komt maar 4x voor in het overzicht. Succes aan te tonen wat er is gebeurt (verkeerd aangeslagen? gestolen? over het hoofd gezien?) waardoor weer het risico door gebrek aan info terecht komt bij de winkel en niet de kraam.


Gepraat vanuit de gebruiker (kassamedewerker) is leuk, maar toekomstige problemen moet je ook proberen voor te zijn. De bewijslast bij problemen moet ergens vandaan komen, of je moet het serieus goed afdekken in de onderlinge contracten.

[ Voor 92% gewijzigd door Xanaroth op 27-03-2015 23:11 ]

[RGAT]

Maar je daadwerkelijke applicatie is 1 iemand (altijd/vrijwel altijd dezelfde persoon?) die op 1 systeem de kassa is?
Dan begrijp ik de Excel gedachte al wat meer, de barcodes was wat afleidend
Op zich kan het wel met Excel, denk alleen dat VB .Net een stuk makkelijker gaat zijn omdat die wat ruimer is, en er zal denk ik wat meer te vinden zijn (hoop hobbyisten die knoeien met .Net en topics met vragen en antwoorden openen), zoals al genoemd lijkt Visual Studio gratis te zijn tegenwoordig, je moet er alleen wat vrije tijd in steken en dan zou je het van scratch met een paar dagen wel voor elkaar moeten krijgen.

Enige wat dan nog een probleem lijkt is, mensen huren de kraampjes, en jij krijgt het geld van de klanten.
Jij moet die huurders gaan verantwoorden waarom je ze zo veel/zo weinig betaalt, gegarandeerd dat er eens een keer twijfel over is, en hoe ga jij dan aantonen dat het goed liep, je moet dus een herkenbare productbeschrijving erbij voegen, dat kraampje X op datum X twee 'rode klapstoeltjes' verkocht bijv.
Ik heb geen verstand van kassa's, maar het lijkt me dat een simpele tweedehands kassa zoals Megamind er een plaatje van heeft gepost een makkelijker idee is, en dan (bar/kleur)codes per kraampje, die print je bonnetjes uit en een wat nieuwere zal vast ook wel de data digitaal kunnen aanleveren aan je pc/laptop waarmee je het in Excel gooit (of een ander programma waarmee je een jaaroverzicht enz. duidelijk kan maken.

[Antique]

Hier stond eerst een nog veel langere post, maar hier is dan de "samenvatting".

De laatste reacties hier maken een heel goed punt: zonder productomschrijving heb je wel mooi "5+2+1+10+2=20€ omzet" staan bij elke kraam, maar je kunt niet verantwoorden hoe je precies tot die 20€ bent gekomen. Op zijn allerminst moet de kassabediende dus bij het verkopen van een item er een beschrijving bij opschrijven (kraam Rood / € 5 / "rode Ikea kastje") maar dan is die bediende in feite een database aan het aanleggen. Beter is om zo'n database van te voren door de kraameigenaren zelf te laten maken, want dan kunnen ze niet zeiken dat de kassabediende verkeerde omschrijvingen gebruikt of dat er spookvoorwerpen uit hun kraam ontbreken die ook niet op de lijst-van-verkochte-dingen staan.

Mocht je daarom alsnog beslissen om met een van te voren aangelegde database te werken, dan kun je elk voorwerp een eigen barcode geven en met één scan direct kraam, prijs en omschrijving ophalen. Precies zoals de bedoeling is in POS software.

Maar ok, laat ik aannemen dat een database maken teveel gevraagd is voor de kraameigenaren. Dan moet je kassabediende sowieso met de hand prijzen gaan invoeren, en daarmee wordt het direct efficiënter om die hele barcodescanner te vergeten. Laat dat hele kraam Rood / € 5 / "rode Ikea kastje" gewoon met de hand opschrijven op zo'n kassablok: als je daarvan een vel papier beschrijft drukt het automatisch door op het vel eronder zodat je de klant een kopie mee kunt geven. Of probeer net zo lang POS programma's tot je er eentje vindt dat je zo kunt instellen, dat het net werkt als zo'n kassablok. Dus bij elke klant, voor elk voorwerp vult de kassabediende in: Rood [enter] 5 [enter] rode ikea kastje [enter] [print]. (Excel is hier imho nog steeds niet geschikt voor omdat je weliswaar handmatig velden in kunt vullen, maar elke klant moet een eigen factuur krijgen en om vervolgens die facturen weer op te tellen is imho niet te doen zonder vrij ingewikkelde scripts.)

Waar je ook rekening mee moet houden zijn de printkosten. Heb jij al een printer op het oog om die facturen af te drukken? Als je denkt dat ff met je DeskJet te doen, reken dan eerst eens uit hoeveel je aan papier en inkt kwijt bent. Zelfs met het goedkoopste papier en een klassieke LaserJet 2100 waarvan de toners tegenwoordig voor € 20 van marktplaats te plukken zijn, schat ik 2ct per afdruk - en dat is nog HEEL gunstig. Vergelijk het kassablok: 62ct voor 50 facturen.

Neem verder iig de volgende maatregelen om jezelf een beetje in te dekken. Geef elke eigenaar een eigen kleur prijssticker en laat hem die met de hand beschrijven. (Zijn handschrift geeft de sticker nl. authenticiteit, dan kan hij niet claimen dat jij aan het omstickeren bent geweest.) Zorg verder dat je een type prijssticker kiest dat wel zonder gescheur te verwijderen valt, maar daarna niet opnieuw plakt, zodat ze niet verwisseld kunnen worden.

Bij het inrichten van de winkel / binnenhalen van nieuwe spullen tel je samen met de eigenaar hoeveel voorwerpen (stickers) van zijn kleur er in totaal zijn, en dat zet je op een formulier dat je beide ondertekent. Maak evt. wat foto's.

Laat vervolgens de kassabediende bij elke verkoop de prijssticker van het voorwerp verwijderen en in een bewaarbak "Verkocht Rood", "Verkocht Blauw", etc. deponeren. Nu kun je altijd natellen per kleur (kraam) of er voorwerpen (stickers) verdwenen zijn, en als je van te voren ook de totale waarde van alle stickers hebt opgeschreven kun je zelfs natellen voor hoeveel € er verkocht is, voor hoeveel € er nog staat en voor hoeveel € er gejat is. Als je de stickerbewaarbak "Verkocht" aan het einde van elke dag in een met de datum en kleur gelabeld zakje overgiet, kun je verder in geval van conflict met een kraameigenaar je kassa-administratie double checken met de stickertjes. Zolang het aantal verkochte stickers + het aantal stickers nog in de winkel = het aantal stickers op het ondertekende formulier, zit je goed.

Bij een "gewone" winkel spelen al deze problemen niet omdat "kraameigenaar" en "kasbeheerder" gewoon dezelfde persoon zijn. Dit is ook precies de reden waarom de meeste rommelmarkten elke kraameigenaar lekker zijn eigen kassysteem laten bijhouden. Misschien moet je toch eens overwegen of dat niet een optie is.

E.e.a. hangt ook af van hoe serieus deze handel gaat worden. Als het om grote bedragen gaat of een winkel voor langere tijd, dan moet je natuurlijk niet met een rommelmarkt-mentaliteit en gekleurde stickertjes aan de gang. Dan moet je ook geen advies bij Tweakers vragen maar een professional zoeken. Als het aan de andere kant een soort veredelde rommelmarkt is voor een paar weekjes, dan kan het best dat de kraameigenaren bereid zijn niet moeilijk te doen aangezien het hen ook kosten en moeite bespaart. Dit moet dan wel van te voren heel duidelijk zijn vastgelegd in een overeenkomst waarin ook bijv. je sticker-telsysteem als bindend is vastgelegd, waarin staat omschreven hoe de schade wordt verdeeld bij diefstal etc.

Ten slotte is er nog het Kringloopwinkel-model als alternatief: als jij gewoon van te voren voor een zeer scherpe prijs alle rommel over kunt kopen van de eigenaren, dan hoef je daarna geen verantwoording meer aan ze af te leggen en hoef je alleen maar bij te houden hoeveel geld je elke dag binnen krijgt van de verkoop. Wel moet je dan niet-verkochte troep uiteindelijk afvoeren.

[ Voor 136% gewijzigd door Antique op 28-03-2015 02:28 ]

[Gomez12]

Die garantie vragen zijn wel goede, die roepen namelijk extra moeilijkheden op. Wil je een kassabediende een omschrijving laten maken van een product terwijl een kraammedewerker de garantie moet geven?

Als er een klant terugkomt met een bon waarop staat : Tafel / 12,50 / kraam 1. En kraam 1 verkoopt tafels van 1 euro tot 12,50 accepteert die het dan dat de klant een tafel van 1 euro terugbrengt?

Om dat te voorkomen zou ik idd gewoon handbonnen bij de kramen neerleggen, dan mag de kraameigenaar de handbon met omschrijving + bedrag maken, daarna kan de klant naar de kassa toegaan waar de kassabediende enkel kraamnr + bedrag van de handbon intypt en er dan een extra bonnetje uitkomt die aan de handbon geniet kan worden oid.

Beetje hetzelfde als dat je bij sommige winkels ook losse pin-bonnetjes krijgt.

Het zijn simpelweg 2 gescheiden dingen imho (aan de ene kant heb je de omschrijving voor de garantie-afhandeling en die kan je het beste bij de kraameigenaar laten en aan de andere kant heb je de betaling die je gecentraliseerd bij een kassa wilt doen en waar je een snel overzicht van wilt hebben voor de kraameigenaren)