prijslijst per gebruiker

[Bruno]

Ik heb een prijslijst in filemaker (zie bijlage). Als verkopers op een prijs klikken op de prijslijst krijgen ze informatie zoals beschikbaarheid in de stock en wordt het product met de juiste prijs op een orderbon geplaatst.

Nu komt het probleem.

In de prijslijst wil ik een aantal parameters plaatsen (zie onder de prijslijst).

Deze parameters bepalen de korting.

Iedere verkoper moet dus zijn eigen prijslijst met zijn korting op het scherm krijgen.

Ik moet dus werken met globalen (iedere prijs een global ??) maar voor de rest heb ik geen flauw idee hoe te beginnen.

 

We werken in een terminal server omgeving.

[jw]

ik weet niet of de grbuikers moeten inloggen. Maar als je een inlogvenster maakt en een set voorkeuren per gebruiker, dan kan je de initiële waarden bewaren en inlezen. Deze kan je dan prima in globale velden kwijt. In het begin van je script lees je de globalen uit en grbuik je voor de erop volgende weergave. Lijkt me dat je er zo moet komen.

 

Mooier zou het zijn als je de globalen via parameters aan het script doorgeeft, maar dat zou wellicht een heleboel extra werk opleveren.

[tackenco]

Ik zou een verkopers tabel maken en per verkoper de settings opslaan.

Bij het inloggen moet de verkoper herkend worden (door de inlogcodes) en kun je de globalen in je artikelenbestand/prijslijst zetten (via een inlogscript)

De prijzen in je artikelenbestand/prijslijst moeten worden berekend aan de hand van die globalen en zijn dan per gebruiker in te stellen.

 

Succes

[Bruno]

Het probleem ligt anders.

 

Ik heb nu het volgende:

-een tabel prijslijst met al artikelen die op de prijslijst staan .

In die tabel staan ook een aantal globalen , die onderaan de prijslijst staan, die de korting gaan bepalen.

De korting verschilt niet per verkoper maar per klant (goede betaler, grote volumes,...)

 

Het probleem is dat de prijzen op het scherm momenteel gewoon nummerieke velden zijn.

gevolg: verkoper A vult de kortingparameters in, drukt op calculate en iedereen krijgt de prijzen met de korting die

verkoper A aan het geven is.

Die prijslijst op het scherm moet dus een verzameling van globalen (repeating fields ??)worden, denk ik ?????

Ik weet eigenlijk niet goed hoe ik dit het beste aanpak.

Het gemakkelijkste lijkt me de prijslijst zonder kortingen op het scherm laten en wanneer iemand op een artikel klikt dan krijgt hij de prijs - de korting.

Het zou natuurlijk mooier zijn dat alle prijzen op het scherm worden aangepast.

[ReneBr]

Hallo Bruno,

 

Ik heb even snel een voorbeeldje gemaakt. Wellicht kun je er iets mee. Het idee is dat je bij de relatie aangeeft voor welke korting zij in aanmerking komen. In dit geval heb ik gekozen voor A, B, C en D. Daarnaast maak je een zoek layout gebaseerd op de prijslijst waarin je een globaal veld hebt waar je het relatienummer invult. Als je dit aanroept vanuit je relatiescherm kun je deze eenvoudig middels een script automatisch laten invullen. Door de relatie tussen het globale veld en het relatienummer kun je bepalen welke prijs er getoond moet worden middels CASE.

 

Maak je gebruik van productgroepen met afwijkende kortingen dan zul je dit moeten vastleggen in een aparte tabel echter het principe is het zelfde.

 

Een voorbeeld zit in je mailbox

 

Gr. René

[eroos]

Volgens mij is dit forum erop gericht om elkaar en anderen te helpen. Als er iemand in de toekomst met hetzelfde probleem zit kan deze persoon niet bij de oplossing. Zou je zo vriendelijk willen zijn om het voorbeeld voor iedereen beschikbaar te stellen?

 

Super! bedankt.

Edited July 8, 2009 by Guest

[ReneBr]

Tuurlijk. Geen probleem. Zag alleen niet waar dat moest vandaar de pm maar heb het intussen gevonden.

 

Gr. René

Voorbeeld prijslijst per klant.fp7

[fmwebshop]

Ik heb een soortgelijk probleempje moeten oplossen.

 

Hier het globale idee:

Een aparte tabel verkoper/calculatie

Verkoper komt in de v/c tabel layout d.m.v. een inlog script met zijn gegevens en maakt hier op gebaseerd een record aan.

In dit record voert hij de gegevens in die gecalculeerd moeten worden.

Aangepast menu voor deze layout, zonder alle records tonen en ga naar record, ect.

Zonder statuspaneel.

Alle verdere handelingen in deze layout via scripts.

In de scripts beperk je de toegang tot andere dan zijn eigen records.

 

Vr groet

Harry

[Bruno]

Inderdaad. Dat laatste lijkt me een idee.

De gebruiker maakt eigenlijk een nieuw prijslijst aan bij het openen van de prijslijst.

Hij kan dan zijn persoonlijke kortingen ingeven.

 

Het ultieme is natuurlijk 1 prijslijst met globalen

[hiker]

Waarom wordt de korting bij de verkoper geregeld en niet bij de klant?

Ik zou een veldje maken bij de klant met % korting.

Je kunt dan werken met 1 prijslijst die voor iedereen geldt. Per klant worden echter andere prijzen berekend, afhankelijk van de korting.

 

De klant krijgt ook zijn korting onafhankelijk van de verkoper.

Wat gebeurt er als verkoper1 in vakantietijd of bij ziekte tijdelijk klanten overneemt van verkoper2?

Dan krijgt de klant de verkeerde korting?

[Bruno]

Het is niet echt per klant. Als klant kun je iedere keer een andere korting krijgen.

Het gaat als volgt:

 

vb.

Koop je cash -3% , koop je 30d -2%,.... koop je 120d +2%

Koop je meer dan 10000$ -2%, meer dan 5000$ -1%,..... minder dan 1000$ +1%

Goeie betalingshistoriek -1% anders 0%

 

Zo zijn er een 5-tal parameters die de verkoper invult en die redelijk objectief zijn

Op die manier kan eigenlijk iedereen aan alle klanten verkopen en de verkoper kan de klanten exact uitleggen waarom hij nu meer of minder betaalt

dan de vorige keer.

Het kan dus zelfs zijn dat je geen korting krijgt maar zelfs meer moet betalen (vb. voor kleine hoeveelheden en kleine bedragen) dan de prijslijst.

Al moet je een straffe zijn om dat aan uw kopers uit te leggen.

Er zijn natuurlijk een paar klanten die vaste kortingen hebben bedongen.

Die kortingen staan vast in de klantenfiche zodat ze automatisch van de verkoop in mindering wordt gebracht.

[pjotter]

Ik val er maar even in dus kan zijn dat ik mij vergis

Ik zou als ik het lees werken met een veld met vaste korting per klant. Dus bij de klant staat vermeld als deze een vaste korting krijgt.

In de prijslijst zou ik dus meerdere velden opnemen met de diverse kortingen. Als klant dan een bepaald aantal besteld, meerder produkten besteld enz enz zal de korting oplopen. Een calculatie veld berekend dan de korting. Als je dan een derde veld maak wat kijkt of er vaste korting is dan neemt hij die korting anders de opgetelde korting?

Is het zo iets wat het moet worden?