Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
(cherry picked from commit ab7a8db43d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch corrects a mistake in the original implementaiton of bug
20595 where we introduced support for the LRP segments being used to
automatically assign items ordered via EDI to stock rotation plans.
Signed-off-by: Sophie Halden <sophie.halden@cheshiresharedservices.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
(cherry picked from commit 783a58a9d3)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The warn call here was passing the full item object which leads to
HASH() in the logs.. this patch updates it to pass the itemnumber which
is more helpful.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a check for ordernumber precence in the EDI Invoice
message lines and skips process if one is not found.
We log the failure as a trace log to allow administrators the oportunity
to track down the issue further.
We also add a trace log to entries to show which bib the invoice line
is receipting to.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Error in plack log is: Can't locate object method "new" via package
"Koha::Plugin::Com::ByWaterSolutions::MyEdifactPlugin" (perhaps you
forgot to load "Koha::Plugin::Com::ByWaterSolutions::MyEdifactPlugin"?)
at /usr/share/koha/lib/Koha/EDI.pm line 219.
Test Plan:
1) Set EdifactInvoiceImport to "Don't"
2) Configure an EDI vendor to use an EDIFACT plugin
3) Attempt to import an invoice file
4) You will be shown an error page
5) Apply this patch
6) Restart all the things!
7) Attempt to import another invoice file
8) It works!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a new system preference, EdifactLSQ, to allow
configuration of the ambiguous LSQ, sequence code, field included in the
EDIFACT specifications.
Originally the field was hard coded to map to 'location', but as per the
specification it could have been mapped to 'ccode'.
From the specification:
A code or other designation which identifies stock which is to be
shelved in a specified sequence or collection.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds get_column to ensure we are returning a string value of
a field rather than accidentally triggering a relationship accessor.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is important for proquest ordering to distinguish types of
material.
FTX segment from quote is stored as vendor note.
Contents of vendornote are included in the order FTX segment.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As requested by Tomás and Jonathan, we now log the entire basket object
when logging an action.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As requested by Jonathan in commit #28:
- We now no longer pass a flag to CloseBasket indicating if the closure
was due to an EDI basket approval, we log the closure and approval as
separate events.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Refactored the price calculations for Quotes and Invoices
This takes in to account various combinations used by different
vendors. Makes the extraction of basic price, quantity and tax
information more reliable. Tests are in Edifact.t and EdiInvoice.t
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes code use the new Koha::Acquisition::Basket->close
method and makes CloseBasket obsolete.
It then removes it, and adapts the few places in which it was used.
1. Apply this patch
2. Run:
$ kshell
k$ git diff origin/master --name-only | grep -e '\.t$' | xargs prove
=> SUCCESS: Tests pass!
3. Try playing with baskets, closing them
=> SUCCESS: All works as expected!
4. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Returns from Koha::Item calls were stored in temporary variables
called $item. Unfortunately they occur in routines already with
an $item variable holding a lineitem and hide that variable although
only required for two lines of code. An error occurs if girfield
is called on the wrong variable. Renamed all three occurences
of $item to $kitem to avoid the error
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Need to add call to store to Koha::Item->new so that itemnumber
is returned - otherwise is not defined and causes an error
Bug is a side-effect of Bug 23463 as this was implicitly
done in AddItem
Also set biblioitemnumber explicitly for item adds this also
used to be done explicitly but can now cause an FK error
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should use Koha::DateUtils instead of Date::Time directly
This patch simplay replaces calls to now() with a call to dt_from_string()
which does effectively the same thing.
Probably reading the code and verifying changes is sufficient but...
To test:
1 - confirm the files all compile
2 - confirm all tests pass
3 - confirm Koha still works
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
* EDI.pm - Add handling of the LRP EDI field to automatically add an
item to a stockrotation rota.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
create_edi_order requires two parameters to be passed
but if vendor was set to auto_order the subroutine
was called with basketno only resulting in the error
'no basket or ean passed' - pass the buyer_ean as
passed in the quotes message
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
There was a typo in the addition of a call to
effective_create_items causing processing to abort after adding
a single copy.
This patch reverts to using the C4::Context call as used for the
first copy created, the intended call to effective_create_items
is a wrapper around that as the field in the basket is guaranteed
to be null (its not set when we call AddBasket). Being consistent
and explicit in what we call should guard against future changes
in dependencies exposing the logic flaw
Added some comments to make logical flow of code clearer
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
When clicking Create EDIFACT Order on /acqui/basket.pl, an EDIFACT message will not be generated if aqbasket.branch does not match edifact_ean.branchcode. This failure does not generate any sort of error message, it just fails to produce a message.
We should allow ean's to not require a branch to be set, then if we don't find a branch specific each, we can look for the default version of the ean.
Test Plan:
1) Apply this patch set
2) Run updatedatabase
3) Verify you can create a Library EAN without setting a branchcode for it
4) Verify you can use this EAN to send an EDI order where the basket has a branchcode set
Signed-off-by: Colin Campbell <colin.campbell@ptfs-europe.com>
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Updates column name from rrp -> replacementprice when creating
order from EDI QUOTE message
Also ensure other rrp_tax* fields populated
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Caused by
commit 04aea91de0
Bug 15685: (QA follow-up) Address QA issues
->find is called on Koha::Object instead of the set class (Koha::Objects)
and raises the following error:
Can't use string ("Koha::Acquisition::Basket") as a HASH ref while
"strict refs" in use at /usr/share/koha/lib/Koha/Object.pm line 275.
This patch also makes sure $basketno refers to an existing basket in DB
I cannot provide a test plan, I have no idea how this code is used.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Sets the vendors currency in the edi generated order
The currency used is agreed between vendor and library
and the value in the quote is optional
Edifact potentially allows the currency to be overwitten
by specifying another currency in the CUX segment but
we know currently of no supplier doing this
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Remove reference to obsolete syspref EDIfactEAN
which was present in earlier test version of
EDI code but should not now be used
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Koha's EDIFACT module works great for many European vendors,
but does not work will for US vendors, which have a much different
interpretation of 'standard'. In fact, each vendor may require
different arrangements of values in EDIFACT messages. It would be
impossible to encompass all these requirements within Koha's EDIFACT
module itself. Instead, we should allow the module to be pluggable, so
versions of the module can be developed for vendors that require EDIFACT
messages that don't conform to the standard set by Koha's EDIFACT
module.
Test Plan:
1) Apply this patch
2) Run updatedatabase
3) Enable Koha plugins
4) Install the Edifact stub plugin available at
https://github.com/bywatersolutions/koha-plugin-edifact-stub
5) Edit the EDI Vendor account, assign the plugin to a Vendor EDI account
6) Test EDI functionality ( ORDER, INVOICE ), there should be no errors
or changes to the EDIFACT message input or output
Signed-off-by: Jason DeShaw <JDeShaw@cityoffargo.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Add support for processing incoming Edifact Quotes, Invoices
and order responses and generating and transmission of
Edifact Orders.
Basic workflow is that an incoming quote generates an aquisition
basket in Koha, with each line corresponding to an order record
The user can then generate an edifact order from this (or another)
basket, which is transferred to the vendor's site
The supplier generates an invoice on despatch and this will
result in corresponding invoices being generated in Koha
The orderlines on the invoice are receipted automatically.
We also support order response messages. This may include
simple order acknowledgements, supplier reports/amendments
on availability. Cancellation messages cause the koha order
to be cancelled, other messages are recorded against the order
Which messages are to be supported/processed is specifiable on a
vendor by vendor basis via the admin screens
You can also specify auto order i.e. to generate orders from quotes
without user intervention - This reflects existing
workflows where most work is done on the suppliers website
then generating a dummy quote
Received messages are stored in the edifact_messages table
and the original can be viewed via the online
Database changes are in installer/data/mysql/atomicchanges/edifact.sql
Note new perl dependencies:
Net::SFTP:Foreign
Text::Unidecode
Signed-off-by: Paul Johnson <p.johnson@staffs.ac.uk>
Signed-off-by: Sally Healey <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Kyle M Hall
Martin Renvoize
Colin Campbell
Jonathan Druart
Andrew Isherwood
Tomas Cohen Arazi
Nick Clemens
Kyle M Hall