Heart-Profit ERP
September 30, 2024, 03:33:52 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Indikator "Mag niet gesplitst worden" op Artikelniveau  (Read 1492 times)
0 Members and 0 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27468


View Profile WWW
« on: October 24, 2019, 08:51:36 am »

Met ingang van deze Releasenote is het per Artikel mogelijk om aan te geven of een Subcharge van een Artikel geplitst moet worden, danwel ze helemaal niet geplitst mág worden. Aanleiding voor deze Releasenote is topic http://ha1.heartprofit.nl/profit/index.php?topic=29547.0

Op deze manier kunnen we per Artikel instellen of er geplitst moet worden, danwel dat absoluut niet mag. De keuze daarbij is òf het een, òf het ander; de een sluit het ander uit. Om dit voor de Gebruiker iets duidelijker te maken, hebben we hier geen J/N veld opgenomen, maar dient de gebruiker dit aan te geven met een radiobutton control.

We onderkennen hiermee vanaf heden twee situaties:

a. Artikelen waarbij we MOETEN splitsen

b. Artikelen waarbij we NIET MOGEN Splitsen

In beide gevallen hebben we het dan over het splitsen van een SubCharge naar een nieuwe Subcharge; iets wat alleen optreedt als we met een Hoofd-/Subcharge werken. Wordt er niet met Hoofd-/Subcharges gewerkt, dan is splitsen sowieso niet aan de orde.

Het al dan niet mogen/moeten splitsen hangen we hiermee bewust niet op aan het feit of iets een Koop- danwel een Produktieartikel is, immers, een Artikel wat in het ene bedrijf geproduceerd wordt, kan in het andere bedrijf ingekocht worden bij dat bedrijf, maar waarbij nog steeds dezelfde regels gelden omtrent het splitsen.

Het Splitsen van Subcharges is ontstaan vanuit de hoek waarbij we 6 pallets met ieder 40 zakken van 25 Kg inkopen bij een Leverancier, en deze Pallets ontvangen als Charge 12345.01 t/m 12345.06. Bij Goederen Ontvangst worden er dan 6 stickers geprint, met een Barcode die uniek is voor de betreffende Subcharge: de pallet. Een scan van deze Barcode (feitelijk: het palletnummer) is dan voldoende om deze partij waar dan ook in het systeem te kunnen identificeren.

Stel dat we 10 zakken van 25 Kg van pallet 03 afhalen, dan MOETEN we formeel 10 Verschijningen Splitsen naar een nieuwe (eerstvolgende) Subcharge (07). Door dit splitsen ontstaat er een nieuwe Subcharge 07, wordt er tevens een nieuw Etiket geprint (met Subcharge 12345.07 in Barcode) en dient dit Etiket op de pallet met de afgesplitste 10 Verschijningen worden geplakt. In Profit is nu bekend dat Subcharge 12345.03 nog 30 Verschijningen op de pallet heeft, en dat Subcharge 12345.07 10 Verschijngen bevat. In beide gevallen leidt de scan van dit Subchargenummer tot één uniek Voorraaditem. Bij eigenlijk alles wat we doen waardoor er een tweede Voorraaditem ontstaat, zullen we formeel moeten splitsen.

Op enig moment hebben we ook Subcharges geïntroduceerd aan de Produktiezijde. Een klant, die niet met Subcharges werkte bij Produktieartikelen wilde toch via een Scanner een deel van zijn voorraad kunnen overboeken. Dit projekterend op bovenstaand voorbeeld zouden zij de 6 pallets van 40 zakken als één Voorraaditem van 240 zakken x 25 Kg op voorraad hebben liggen, en daarvan wilden ze kunnen aangeven dat er 10 zakken moesten worden verplaatst naar een andere Lokatie. "Splitsen" is zónder Subcharges niet aan de orde, en dus is er toen een Bedrijfsparameter ontwikkeld waarmee we konden aangeven dat het scherm "Verplaatsen Voorraad" om het te verplaatsen aantal Verschijningen moest gaan vragen; deze rubriek is onlangs ingezet om de Splitsbuttons te disablen...

Zoals we hier nú tegenaan kijken, is die parameter eigenlijk niet juist. Immers, niet een Bedrijfsparameter bepaalt dit, maar het feit dat deze klant Voorraad verplaatst van een partij waarbij niet met Subchargenummers gewerkt wordt zou dat al mogen afdwingen. Met andere woorden: als we de 240 zakken als één Charge "12345" op voorraad zouden hebben liggen, en we werken niet met Subcharges, dan zou het scannen van zo'n Charge al mogen triggeren dat we het aantal Verschijningen mogen overrulen, anders kunnen we nl. nooit "een deel" van de voorraad verplaatsen (splitsen kan immers niet als we niet met een Hoofd-/Subcharge werken). Met ingang van heden zal derhalve gelden dat als we een partij scannen die niet met Hoofd-/Subcharges werkt, we dus altijd de hoeveelheid mogen aanpassen.

Werken we wél met Hoofd-/Subcharges, dan óók kan het zo zijn dat we juist altijd moeten splitsen, danwel dat dit nooit is toegestaan.

Zo is in het eerder genoemde topic de situatie beschreven waarbij de Subcharges die bij een Produktieorder ontstaan, óók op het etiket van het blik worden afgedrukt. De Produktieorder heeft er in dat geval al voor gezorgd dat we voor iedere Artikel-/Verschijning én Kenmerkkombinatie een separaat Subchargenummer krijgen. Een scan van de Barcode op het blik weet dus van zichzelf al of het om een 5-, 10- of 20 liter blik gaat, maar weet via de Kenmerken óók de (klant-) specifieke Emballageset gegevens, zoals 'afgevuld in een rood blik met een blauw deksel'.

Technisch gezien geldt dat als Profit van Subcharge 12345.03 weet dat dit om "40 blikken van 20 liter, afgevuld in rode blikken met een blauw deksel" gaat, en we zouden hiervan 10 blikken splitsen naar een Subcharge 07, Profit ook wel van Subcharge 12345.07 weet dat dit nu "10 blikken van 20 liter, afgevuld in rode blikken met een blauw deksel" betreft. Maar... in dit voorbeeld gaat het erom dat de Afvulmachine het Subchargenummer heeft afgedrukt op het blik zelf. In het eerdere voorbeeld van splitsen printen we één extra labeltje, en plakken die op de afgesplitste partij. Als we in dít voorbeeld zouden gaan splitsen, dan moeten we de pallet afstapelen, en moet er op ieder blik een nieuwe Barcode terecht komen. Tsja... en dan niet met een simpel stickertje wat er op geplakt wordt, nee, we zullen het blik van een totaal nieuw etiket moeten voorzien. Los van het feit dat dat tijd en geld kost, geldt bijv. ook dat zo'n label door de afvulmachine gegenereerd en geplakt wordt, en, opnieuw afvullen is nu niet aan de orde.

Ofwel, er zijn nu twee situaties ontstaan:

In het geval dat onze Barcode een pallet-barcode bevat puur opdat wij de partij eenvoudig kunnen scannen, dan kunnen we daar ook wel een nieuw etiketje voor afdrukken en op de pallet plakken. Nee, sterker, dan MOETEN we een nieuw Subchargenummer genereren zodra we iets van de pallet afhalen.

Als echter ieder blik op de pallet zo'n Subchargenummer voorgedrukt heeft op het etiket, dan willen we NOOIT een nieuw Subchargenummer genereren, simpelweg omdat we niet bereidt zullen zijn om ieder blik van die pallet van een nieuw etiket te voorzien. Ook als we die pallet verkopen aan ons zusterbedrijf (Turkije), voor wie dit produkt dan een Koop-artikel betreft, geldt voor Turkijke nog steeds dat zo'n partij niet gesplitst mag worden (immers, het Subchargenummer staat nog steeds op ieder blik). Het 'produkt' dwingt dit dus af, en derhalve een rubriek op Artikelniveau.

De defaultwaarde is overigens dat als we Subcharges gebruiken, er WEL moet worden gesplitst als we iets van de pallet af willen halen.

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
CLASSES     Geen standaard funktie    17-10-2019    23-10-2019
LOARTV1     Omschrijving (nog) niet bekend    07-10-2019    24-10-2019
LOARTV2     Omschrijving (nog) niet bekend    14-05-2019    24-10-2019
LOARTVF1    Omschrijving (nog) niet bekend    14-05-2019    24-10-2019
LOARWGA1    Omschrijving (nog) niet bekend    14-05-2019    24-10-2019
LOARWY1     Omschrijving (nog) niet bekend    07-10-2019    24-10-2019
LOARWY2     Omschrijving (nog) niet bekend    14-05-2019    24-10-2019
LOARWYF1    Omschrijving (nog) niet bekend    14-05-2019    24-10-2019
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.063 seconds with 20 queries.