Fakturatie middels portal, maar probleem met voorraadbeheer

[FMjunk]

Omdat ik op het punt sta FM 9 aan te schaffen leek het me leuk ons faktuursysteempje iets te ver-professionaliseren.

Middels een portal zou ik graag de zaken stroomlijnen. Alles werkt prima, behalve de voorraadadministratie.

Ter info, ik werk met faktuurlayouts op verschillende bestanden, allen verwijzend en gebruik makend van 1 produktenbestand en 1 klantenbestand. Dat wel.

Nu is het probleem, hoe kan ik een scriptje maken dat met een druk op de knop de verkochte artikelen uit de portal aftrekt van de huidige voorraad van de desbetreffende artikelen?

 

Eerder was dat zeer eenvoudig, 'voorraad' = insert calculated field('voorraad';'voorraad' - aantal verkochte artikelen).

Maar met een portal werkt dat toch even anders, immers het wil alleen maar werken met de eerste regel van de portal. De rest van de produkten laat FM links liggen.

 

Welnu, de functie 'voorraad' = 'oude voorraad'-sum(alle verkochte aantallen) werkt goed, maar we hebben nu eenmaal meer dan 1 produkt en van een lijstje van 10 produkten wordt zodoende slechts het eerste produkt uit de portal netjes verrekend. Maar de aantallen van de andere produkten worden vrolijk ook afgetrokken van de voorraad van het produkt van de eerste portal regel.

 

Voorbeeld er wordt besteld:

code 1 Plastic koe 6x (huidige voorraad 10)

code 2 pak vla 3x (huidige voorraad 10)

code 3 liter benzine 1x (huidige voorraad 10)

 

wil dit verrekenen met de voorraad, na verrekening staat er op voorraad:

Plastic koe 0x

pak vla 3x

liter benzine 1x

 

 

Wie weet hier iets op ? Heb zo'n beetje alles afgestruind en geprobeerd behalve kennelijk de juiste oplossing.

 

[AvD]

Ter info, ik werk met faktuurlayouts op verschillende bestanden

Welkom op dit forum. Het antwoord op je vraag is niet té eenvoudig...

Het hoofdprobleem heeft weinig of niets met FileMaker of met portals te maken, maar wel alles met je functionele analyse en de omzetting daarvan naar een bruikbaar datamodel, en dat is niet in één, twee, drie uitgelegd. Kijk eens op het internet hoe je een database opbouwt, meer kan ik echt niet zeggen.

[rmw]

Zonder iets af te doen aan het antwoord van AvD (zijn avatar laat dat niet toe ) zou ik willen vragen: als de berekening voorheen werkte en nu niet meer zit hij dan niet op de verkeerde locatie?

Je moet de berekening uitvoeren in de tabel waar de portal regels zijn opgeslagen (de factuurregels) en niet in de hoofdtabel (de factuur).

 

HTH

 

rmw

[FMjunk]

Bedankt voor de vlotte reakties! Dit forum heeft reeds gebleken interessant te zijn voor FM gebruikers, tips en trucs zijn altijd welkom.

 

Maar voor mijn portal-geval, wat zal ik zeggen, ik ben geen expert.

Maar ik heb het wel draaiende gekregen op een andere manier dan ik graag zou zien.

Ik heb alle layouts/tables in 1 file geplaatst. De voorraad in een tweede file en de klantgegevens in een derde file.

Vervolgens de berekening gemaakt als volgt:

 

(file1)voorraad huidig = (file 1)voorraad origineel - sum(verkochte artikelen in de portal van file2)

 

dat werkt 'on the fly' dus direkt als je iets aanpast qua aantal in de portal op elke willekeurige regel, wordt de 'voorraad huidig' aangepast. Kwestie van de relaties netjes opbouwen en dat werkt.

 

Enige nadeel, de voorraad origineel wordt telkens als er een nieuwe inkooporder volgt weer opgehoogd. Omdat er eigenlijk wordt berekend 'alles wat er ooit is binnengekomen' - 'alles wat er ooit verkocht is' = 'huidige voorraad'.

je kunt hiermee niet eens kiezen om na een voorraad telling en dus altijd een manco geconstateerd te hebben, handmatig de huidige voorraad even opnieuw goed te zetten. Dit zal altijd moeten via een aanpassing in 'voorraad origineel'.

Ik denk dat hier best mee te werken valt, maar liever had ik dat de voorraad pas werd aangepast als een bestelling / faktuur daadwerkelijk is verpakt en verzonden.

Nu wordt mijn voorraad via de portal al direkt aangepast voordat ik zeker weet dat de order verpakt en verzonden is. Misschien ook maar beter, misschien ook niet. Ik houd gewoon meer van scriptjes-met-een-druk-op-de-knop. Dan gebeurt het wanneer ik het wil en er klaar voor ben.

 

Feitelijk denk ik dat wat ik wil, een berekening maken per portal regel en het resultaat terugkoppelen aan een veld in een andere database, niet mogelijk is. Zo wel, dan hou ik me aanbevolen!

[AvD]

Je denkt dat het niet mogelijk is, maar dat is een vergissing.

Kijk hier eens, en ook hier. En er is nog meer op dit forum. Peter heeft pas nog de hele zaak goed samengevat. Kijk eens in de zoekfunctie.

[FMjunk]

Okay,

 

 

Ik heb door wat neuzen hier en daar de volgende oplossing gevonden, zodat mijn database niet een grote opslag van niet opgeslagen-permanent-berekenende velden gaat worden.

 

Ga naar Portaalrij[selecteren; Eerste]

Loop

Veld instellen[Artikel2::Aantal in Stock; Artikel2::Aantal in Stock-Verkooplijnen::Aantal]

Ga naar Portaalrij[selecteren; Volgende; Afsluiten na laatste]

End Loop

 

Als je het weet, is het simpel.

 

Toch heb ik nog een vraag waar ik geen andere info over kan achterhalen hier. Kan ik er voor zorgen dat zodra de faktuur 'definitief' is gemaakt en dus verrekend met de voorrad, de portaalregels NIET meer veranderd kunnen worden ?

Ander zou je alsnog in staat kunnen zijn je voorraad te vernachelen.

 

Ik denk dus aan iets als: if vlaggetje ="verrekend" dan veld 'produktcode' = niet meer veranderbaar.

 

Zou mooi zijn als dit te verwezenlijken is. Ik ben slechts zover gekomen om het veld een rode achtergrond te geven na verrekening zodat er in elk geval visueel gewaarschuwd wordt tegen verandering.

 

Naar een andere layout laten doorverwijzen na verrekening is ook mogelijk, maargoed daar kunnen ze bij ons weer gemakkelijk zelf omheen door handmatig de layout verkeerd te gaan kiezen uit de tabblaadjes of uit het normale Filemaker menu.

[Rony Rabijns]

Kijk eens bij Accounts and Privileges.

Je kan Record Access bepalen op basis van voorwaarde(n) met het vlaggetje dat jij voorstelt.

[FMjunk]

Bedankt voor deze tip. Daar had ik nog niet aan gedacht.

Ik werk met FM9 (geweldig stukje software) en ben blij dat dit tot de mogelijkheden behoort. Echter de cruciale stap krijg ik nog niet voor elkaar, nl. hoe switch je dan via Privilege Sets op basis van 'vlaggetje' aan / uit ?

 

En mocht dit zo werken, als je weer een nieuwe faktuur in gaat voeren moeten de velden in de volgende record wel weer toegankelijk zijn.

[Rony Rabijns]

Gebruik als voorwaarde in de custom privileges van record access bvb "not(flag-field)"

 

(in de veronderstelling dat flag-field de waarde 0 of 1 kan bevatten)

[FMjunk]

Rony super bedankt!

 

Dit was precies wat ik zocht. In FM9 heet het 'Data Access and Design' waar je onder Records een Custom Privilege kan laten berekenen (bv. if 'veldnaam'='1' dan niet doen ) bij de privileges van Field Edit.

Voor het geval iemand dit leest die met dezelfde problematiek stoeit heb ik het even uitgeschreven.

 

Ik moest er alsnog even mee stoeien maar het is helemaal goed gekomen.

Geweldig zo'n forum, dit zijn typisch dingetjes waar je als non-prof erg mee kan zitten stoeien

 

[WJ]

 

Ga naar Portaalrij[selecteren; Eerste]

Loop

Veld instellen[Artikel2::Aantal in Stock; Artikel2::Aantal in Stock-Verkooplijnen::Aantal]

Ga naar Portaalrij[selecteren; Volgende; Afsluiten na laatste]

End Loop

 

 

Let nog even op de record lock optie. Het is best mogelijk dat iemand net met dat product bezig is dan kan filemaker niks schrijven.

 

Gr,

 

WJ

[FMjunk]

over die file lock,

 

hoe zou je de records kunnen reverten indien er toch iemand anders tegelijk wellicht een faktuur aan het verrekenen is die dezelfde produkten bevat ?

Het zou wel erg toevallig zijn, maar het is in principe mogelijk.

 

Ik weet dat je via 'revert records' de zaak kunt herstellen, maar welke voorwaarde hang je hier dan aan ?

'If field was 'locked'' ofwel 'If error occured', then revert. Maar dat staat natuurlijk niet in het lijstje scriptmogelijkheden

[WJ]

Je kunt inderdaad met revert stappen ongedaan maken.

 

De truuk is om alle bewerkingen in een speciale layout uit te laten voeren en in een speciaal opgezette portal. Loop door de portal records en doe alle bewerkingen.

 

Krijg je ergens in het proces een record lock doe dan de revert stap alle stappen ervoor worden ongedaan gemaakt. Omdat je gerelateerde gegevens aan het bewerken was. Beetje ingewikkeld maar wel goed...

Het idee: slagen alle bewerkingen dan is het goed, gaat er 1 bewerking verkeert dan gaat het hele feest niet door.

 

Eenvoudiger en minder goede manier: Test of het te bewerken record open is is ie dat niet dan in een loop blijven wachten totdat het wel kan. Minder fraai wel makkelijk. Laat de gebruiker wel zien dat iemand anders het record aan het bewerken is en dat hij geduld moet hebben of even naar de persoon toe moet.

 

gr,

 

WJ